カスタム注文ステータスの実装
CommerceOrderStatusインターフェイスを実装することにより、カスタム注文ステータスを追加できます。 コマース注文エンジンは、すぐに使用できる標準の注文フローを提供しますが、ニーズに合わせてカスタマイズできます。
カスタム注文ステータスは、既存の注文フローに追加された新しいステージです。 標準の注文フローでは処理されない注文処理プロセスが必要な場合は、カスタム注文ステータスが必要です。 まず、注文ステータスがどのように機能するかを学習し、次に新しいサンプル実装をデプロイします。
注文ステータスの概要
Liferay Order Engineには、6つの主要なステータス、1) Open、2) In Progress、3) Pending、4) Processing、5) Shipped、6) Completedがあります。

Order Engineは、各注文ステータスに対してチェックを実行して、正しい注文処理を確認し、注文に適用される次のステータスを決定します。 上記の主なステータスに加えて、注文は3つの代替ステータスに移行できます。

-
On Hold - 注文が非最終注文ステータス(Pending、Processing、Shipped)のいずれかにある場合、注文を保留にすることができます。
-
Cancelled - 注文が最終以外の注文ステータス(Pending、Processing、Shipped)のいずれかにある場合、注文をキャンセルできます。
-
Partially Shipped - 注文に複数のアイテムがあり、一部のアイテムが出荷されていない場合、Partially Shippedステータスに移行します。

カスタム注文ステータスを追加して、すぐに使用できる注文フローを変更できます。 以下では、「 スケジュール 」という注文ステータスを追加し、それを既存の 「保留中 」と 「処理中 」ステータスの間に配置します。 このカスタムステージは、注文が受け付けられる前にスケジュールされるのを待機している注文を表します。 注文のカスタムフィールドは、Schedulingステータスを追跡します。 各注文ステータスとその遷移の詳細については、 注文ライフサイクル を参照してください。
注文ステータスのデプロイ
-
Liferay Commerceを開始します。
docker run -it -p 8080:8080 liferay/portal:7.4.1-ga2 -
Acme Commerce Order Status Methodをダウンロードして解凍します。
curl https://resources.learn.liferay.com/commerce/latest/en/developer-guide/order-management/liferay-m4v7.zip -O unzip liferay-m4v7.zip -
サンプルをビルドしてデプロイします。
./gradlew deploy -Ddeploy.docker.container.id=$(docker ps -lq)注このコマンドは、デプロイされたjarをDockerコンテナ上の
/opt/liferay/osgi/modulesにコピーするのと同じです。 -
Dockerコンテナコンソールでデプロイを確認します。
STARTED com.acme.m4v7.impl_1.0.0 -
注文のスケジュールを追跡するには、カスタムフィールドを作成する必要があります。 アプリケーション メニュー (
) をクリックし、 コントロール パネル → カスタム フィールドに移動します。 -
アイテムのリストからコマース注文を選択し、 追加 (
)ボタンをクリックして新しいフィールドを追加します。 使用可能なフィールドから[ドロップダウン]オプションを選択し、以下の情報を入力します。 完了したら、 「保存」 をクリックします。フィールド名: m4v7Scheduling
データ型: テキスト
値: 保留中、確認済み(2行に分かれて)

-
ブラウザで
https://localhost:8080を開き、アプリケーション メニュー (
) からサイトに移動して注文を行い、サンプルの注文ステータスが追加されたことを確認します。 -
もう一度アプリケーションメニューをクリックし、[コマース] → [注文]に移動して、発注した注文を選択します。 新しいステータス[Scheduling]と、進行中の新しい注文フローを設定する[Scheduling]というボタンが注文ライフサイクルに表示されます。 新しいカスタムフィールドは、注文の[カスタムフィールド]セクションの下にあります。

カスタム注文ステータスの仕組み
実装例は3つのステップで実装されます。 最初に、OSGi登録用にクラスに注釈を付ける必要があります。 次に、 CommerceOrderStatus インターフェースを確認します。 最後に、カスタムのCommerceOrderStatusの実装を終了します。
注文ライフサイクルで新しいステータスを配置する段階に応じて、正しい注文処理のために次の段階を微調整する必要があります。 この例では、新しいステータスを保留中ステータスと処理中ステータスの間に配置するため、既存の処理中ステータスを上書きして、ロジック内で新しいステータスをチェックする必要があります。
OSGi登録用にクラスに注釈を付ける
@Component(
property = {
"commerce.order.status.key=314159265",
"commerce.order.status.priority:Integer=40"
},
service = CommerceOrderStatus.class
)
public class M4V7SchedulingCommerceOrderStatus implements CommerceOrderStatus {
Liferay Commerceが注文ステータスレジストリ内の他のステータスと新しいステータスを区別できるように、注文ステータスに個別のキーを提供することが重要です。 すでに使用されているキーを指定すると、既存の関連付けられているステータスが上書きされます。 注文ステータスの優先度によって、注文ライフサイクルでの注文が決まります。 この場合、Pendingステータスの優先度は30で、Processingステータスの優先度は50です。 2つの間にステータスを配置するには、優先度がこれら2つの数値の間にある必要があります(この場合は40)。
この実装例では、ランダムな整数がキーとして設定され、40が優先度として設定されていますが、コード内で読みやすくするために変数を使用できます。 例 をこちらで参照してください。
CommerceOrderStatusインターフェイスを確認する
次のメソッドを実装します。
public String getLabel(Locale locale);
このメソッドは、注文ステータスの名前を返します。 この名前は、UIに表示される名前に対応する言語キーの場合があります。 この場合、文字列Schedulingが返されます。
public int getKey();
このメソッドは、注文ステータスの一意のキーを返します。 既存のキーを使用すると、そのステータスが上書きされます。
public int getPriority();
このメソッドは、注文ステータスの優先度を返します。 これは、このステータスが配置されるステージを決定するために使用されます。
public boolean isTransitionCriteriaMet(CommerceOrder commerceOrder) throws PortalException;
このメソッドは、注文が現在の注文ステータスに指定されたすべての移行基準を満たしているかどうかを確認します。
public CommerceOrder doTransition(CommerceOrder commerceOrder, long userId) throws PortalException;
このステータスの移行基準が満たされると、doTransitionメソッドは、注文がこのステータスに移行するために必要なすべてのアクションを実行します。
public boolean isComplete(CommerceOrder commerceOrder);
このメソッドは、注文ステータスがアクションを完了し、次のステータスに移行する準備ができているかどうかを確認します。 Schedulingステータスの場合、カスタムフィールド値が[Pending]かどうか、または[Confirmed]で[Processing]ステージに移行する準備ができているかどうかを確認します。
インターフェイスにはさらに2つのメソッドがあります。 最初のpublic boolean isValidForOrder(CommerceOrder commerceOrder) throws PortalExceptionは、ステータスが注文に適用可能かどうかをチェックします。 2番目のpublic boolean isWorkflowEnabled(CommerceOrder commerceOrder) throws PortalExceptionは、ステータスに関連付けられているワークフローがあるかどうかをチェックします。 この例では、これらのメソッドを実装する必要はありません。
注文ステータスを完了する
注文ステータスの実装は、Schedulingステータスのメソッドの実装と、Processingステータスに存在する既存のビジネスロジックの微調整で構成されます。
isTransitionCriteriaMetメソッドを実装するdoTransitionメソッドを実装するisCompleteメソッドを実装する- 既存のProcessingステータスをオーバーライドする
- Processingステータスのビジネスロジックを微調整する
isTransitionCriteriaMetメソッドを実装する
@Override
public boolean isTransitionCriteriaMet(CommerceOrder commerceOrder)
throws PortalException {
if (commerceOrder.getOrderStatus() ==
CommerceOrderConstants.ORDER_STATUS_PENDING) {
return true;
}
return false;
}
注文をScheduling注文ステータスに移行するには、注文がPendingステータスである必要があります。 これは、commerceOrderオブジェクトのgetOrderStatus()メソッドを使用してチェックされます。 このメソッドは、注文が保留中の場合はtrueを返し、それ以外の場合はfalseを返します。
doTransitionメソッドを実装する
@Override
public CommerceOrder doTransition(
CommerceOrder commerceOrder, long userId, boolean secure)
throws PortalException {
commerceOrder.setOrderStatus(314159265);
return _commerceOrderService.updateCommerceOrder(commerceOrder);
}
注文の移行基準が満たされると、一意のキーを使用して注文ステータスがSchedulingとして設定されます。 次に、_commerceOrderServiceからupdateCommerceOrder()メソッドを呼び出し、commerceOrderオブジェクトを渡して新しいステータスを更新します。
isCompleteメソッドを実装する
@Override
public boolean isComplete(CommerceOrder commerceOrder) {
ExpandoBridge expandoBridge = commerceOrder.getExpandoBridge();
String[] values = (String[])expandoBridge.getAttribute(
"m4v7Scheduling");
if (ArrayUtil.isEmpty(values)) {
return false;
}
return Objects.equals(values[0], "Confirmed");
}
Schedulingステージを完了するには、カスタムフィールドを[Confirmed]に設定する必要があります。 このカスタム属性は、キーm4v7Schedulingを使用してExpandoBridgeを介して取得されます。 これはドロップダウンであるため、戻り値はString配列内にあり、最初の値です。 値が[Confirmed]の場合、メソッドはtrueを返し、配列が空の場合はfalseを返します。
既存のProcessingステータスをオーバーライドする
@Component(
property = {
"commerce.order.status.key=" + CommerceOrderConstants.ORDER_STATUS_PROCESSING,
"commerce.order.status.priority:Integer=50",
"service.ranking:Integer=100"
},
service = CommerceOrderStatus.class
)
public class M4V7ProcessingCommerceOrderStatus implements CommerceOrderStatus {
内部に存在するロジックを微調整するには、既存のProcessingステータスをオーバーライドする必要があります。 これは、OSGi登録用にクラスに注釈を付け、既存のステータスと同じキーと優先度を使用することによって行われます。 service.rankingは、オーバーライドされたステータスに対して100に設定されるため、既存のステータスよりも優先されます。
Processingステータスのビジネスロジックを微調整する
@Override
public boolean isComplete(CommerceOrder commerceOrder) {
if (commerceOrder.isApproved() && !commerceOrder.isOpen() &&
(commerceOrder.getOrderStatus() != 314159265)) {
return true;
}
return false;
}
@Override
public boolean isTransitionCriteriaMet(CommerceOrder commerceOrder)
throws PortalException {
if (commerceOrder.getOrderStatus() == 314159265) {
return true;
}
return false;
}
元のProcessingステータスはそのメソッドでPendingステータスをチェックするため、新しく追加されたステータスをチェックするには、それらを少し微調整する必要があります。 これは、新しいステータスの一意のキーを使用して行われます。
さいごに
CommerceOrderStatusインターフェイスを実装するための基本を理解し、Liferay Commerceに新しい注文ステータスを追加しました。