条件エバリュエーターの作成
ワークフロー 条件ノード は、Groovy スクリプトを使用して、ワークフロー項目が通過する適切な遷移を決定します。 Groovyのロジックをワークフロー定義の <script> 要素に直接記述する代わりに、 ConditionEvaluator インターフェースを実装することで、Javaのロジックを展開することができます。
-
Javaの実装を書きます。
-
ワークフロー定義XMLファイルからJavaクラスを呼び出します。
まず、 ConditionEvaluatorをデプロイし、動作を確認します。
コンディション評価装置の導入
新しいLiferay インスタンスを起動し、以下を実行します。
docker run -it -m 8g -p 8080:8080 liferay/portal:7.4.3.132-ga132
http://localhost:8080でLiferayにサインインします。 メールアドレス test@liferay.com とパスワード testを使用してください。 プロンプトが表示されたら、パスワードを learnに変更します。
サンプルプロジェクトを展開する前に、システム設定 → スクリプト管理(セキュリティカテゴリ内)でスクリプトを有効にします。
次に、以下の手順に従います。
-
Acme R6J9 Implementationプロジェクトをダウンロードして解凍します。
curl https://resources.learn.liferay.com/examples/liferay-r6j9.zip -Ounzip liferay-r6j9.zip -
モジュールのルートから、ビルドおよびデプロイします。
./gradlew deploy -Ddeploy.docker.container.id=$(docker ps -lq)ヒントこのコマンドは、デプロイされたjarをDockerコンテナの/opt/liferay/osgi/modulesにコピーするのと同じです。
-
Liferay Dockerコンテナコンソールでデプロイを確認します。
STARTED com.acme.r6j9.impl_1.0.0
便宜上、 ConditionEvaluator の activate メソッドは、R6J9 Conditional Approver ワークフロー定義を自動ロードしました。 このコードは、ワークフロープロセスビルダーに移動し、ワークフロー定義をアップロードするのと同じことを実現します。 新しいワークフロー定義のアップロードを参照してください。
条件エバリュエーターをテストする
Acme R6J9 Condition Evaluatorを使用するには、ブログエントリーで使用するように設定し、管理者のユーザーで新しいブログエントリーを追加します。
-
グローバル メニューのアプリケーション タブで、ワークフロー → プロセス ビルダーに移動します。
-
設定タブで、ブログのエントリアセットタイプにR6J9 Conditional Approver の定義を割り当てる。
-
[保存]をクリックします。
-
デフォルトの管理ユーザー テスト テストを使用して、サイト メニュー → コンテンツ & データ → ブログを開きます。
-
追加ボタン(
)をクリックします。 -
タイトルとコンテンツのフィールドに何か入力し、 ワークフローに送信をクリックします。
-
メインのBlogsビューに戻り、エントリーが表示され、ステータスが 承認済みと表示されていることを確認します。
ヒントステータスが最初に
保留中と表示された場合は、ページを更新してください。
唯一の承認者の定義や、管理者ではない別のユーザーでテストすると、ブログのエントリが 返答待ちというステータスで追加されていることがわかります。
R6J9Condition Evaluatorについて
Acme R6J9 Implementationプロジェクトには、ワークフローのユーザーがAdministrator Roleを持っている場合に、 approve の遷移をトリガーするための条件評価器が含まれています。 1つのクラスを含んでいます: R6J9ConditionEvaluator。
このプロジェクトでは、条件付き評価者に加えて、条件評価者を使用するR6J9 Conditional Approverというワークフロー定義が含まれ、自動でロードされます。
条件評価者は、ワークフローに送られるアセットのステータスを変更しません。 これは、単にトランジションを実行するための便利な方法を提供するものです。 ワークフローステータスの変更が必要な場合は、 WorkflowStatusManagerUtil クラスの UpdateStatusを 方法を呼び出します。 定義の 承認済み 状態ノードは、ステータスを承認済みに設定します。
<state>
<name>approved</name>
<metadata>
<![CDATA[
{
"xy": [
380,
51
]
}
]]>
</metadata>
<actions>
<action>
<name>approve</name>
<script>
<![CDATA[
import com.liferay.portal.kernel.workflow.WorkflowConstants;
import com.liferay.portal.kernel.workflow.WorkflowStatusManagerUtil;
WorkflowStatusManagerUtil.updateStatus(WorkflowConstants.getLabelStatus("approved"), workflowContext);
]]>
</script>
<script-language>groovy</script-language>
<execution-type>onEntry</execution-type>
</action>
</actions>
</state>
ConditionEvaluatorを実装します。
条件付き評価者クラスは、 com.liferay.portal.workflow.kaleo.runtime.condition.ConditionEvaluator インターフェースを実装し、単一の evaluate メソッドをオーバーライドします。 scripting.language=java コンポーネントプロパティを設定します。
@Component(
property = "scripting.language=java", service = ConditionEvaluator.class
)
public class R6J9ConditionEvaluator implements ConditionEvaluator {
evaluate メソッドは、ワークフロー定義で呼び出されたときに、ワークフローがトランジションを介して適切なノードに進むことができるように、有効なトランジション名を返す必要があります。
evaluate メソッドは、 KaleoCondition と ExecutionContextの2つのパラメータを受け取ります。 ワークフローエンジンは、ワークフロープロセスの中で条件判定器を呼び出す役割を担っているため、お客様のコードではこれらのオブジェクトをインスタンス化したり構築したりする必要はありません。 しかし、そこから有益な情報を得ることができます。 例えば、以下のようになります。R6J9 Condition Evaluatorは、 workflowContext (type Map) と serviceContext (type ServiceContext) を
から取得します。index='4' /> serviceContext (タイプ ServiceContext ) と、 ExecutionContextから構成されています。
Map<String, Serializable> workflowContext =
executionContext.getWorkflowContext();
ServiceContext serviceContext = executionContext.getServiceContext();
workflowContext はワークフローユーザーのIDを、 serviceContext はバーチャルインスタンスのID( companyId)を取得するために使用されます。 どちらも、ユーザーが管理者権限管理者を持っているかどうかを確認するために必要です。ユーザーが管理者権限を持っている場合、ワークフローによって資産が自動承認されます(承認というトランジションに沿って送信されます)。 それ以外の場合は、 review トランジションを実行します。
if (_userLocalService.hasRoleUser(
serviceContext.getCompanyId(), RoleConstants.ADMINISTRATOR,
userId, false)) {
return "approve";
}
return "review";
ワークフロー定義での ConditionEvaluator の呼び出しについて
Acme R6J9実装プロジェクトで自動ロードされたR6J9 Conditional Approverワークフロー定義は、Liferay DXP/Portalに同梱されている唯一の承認者唯一の承認者の定義とほぼ同じです。 最初の違いは、 が作成された の状態ノードにあります。 実行唯一の承認者の定義では,レビューの遷移を常に実行するが,R6J9 Conditional Approverでは, チェック・ロール の遷移を実行する. 主な違いは、同じ名前の 条件ノード追加です。 conditionノードは、 R6J9ConditionEvaluator に依存して条件ロジックを実行します。
<condition>
<name>check-role</name>
<script>
<![CDATA[com.acme.r6j9.internal.kaleo.runtime.condition.R6J9ConditionEvaluator]]>
</script>
<script-language>java</script-language>
<transitions>
<transition>
<name>review</name>
<target>review</target>
</transition>
<transition>
<name>approve</name>
<target>approved</target>
</transition>
</transitions>
</condition>
承認されたトランジションとレビューされたトランジションが、条件ノードの有効なターゲットとして追加されることに注意してください。 ConditionEvaluator で使用されているトランジションが、それが呼び出された条件ノードから有効なトランジションとして含まれていることを確認してください。