フィードバックを送信

条件エバリュエーターの作成

ワークフローの条件ノードは、Groovyスクリプトを使用して、ワークフローアイテムが通過する適切なトランジションを決定します。 Groovyのロジックをワークフロー定義の <script> 要素に直接記述する代わりに、 ConditionEvaluator インターフェースを実装することで、Javaのロジックを展開することができます。

Javaの実装を書きます。
ワークフロー定義XMLファイルからJavaクラスを呼び出します。

まず、 ConditionEvaluatorをデプロイし、動作を確認します。

コンディション評価装置の導入

新しいLiferay インスタンスを起動し、以下を実行します。

docker run -it -m 8g -p 8080:8080 liferay/portal:7.4.3.120-ga120。

http://localhost:8080でLiferayへのサインインします。メールアドレス test@liferay.com とパスワード test を使用してください。プロンプトが表示されたら、パスワードを learn に変更します。

次に、以下の手順を実行します。

[Acme R6J9 Implementationプロジェクトをダウンロードし、解凍する。

curl https://resources.learn.liferay.com/dxp/latest/en/process-automation/workflow/developer-guide/liferay-r6j9.zip -O

unzip liferay-r6j9.zip

モジュールのルートから、ビルドおよびデプロイします。
```
./gradlew deploy -Ddeploy.docker.container.id=$(docker ps -lq)
```
tip

このコマンドは、デプロイされたjarをDockerコンテナの/opt/liferay/osgi/modulesにコピーするのと同じです。
Liferay Dockerコンテナコンソールでデプロイを確認します。
```
STARTED com.acme.r6j9.impl_1.0.0
```

note

便宜上、ConditionEvaluatorのactivateメソッドは、R6J9 Conditional Approverのワークフロー定義をオートロードしました。このコードは、ワークフロープロセスビルダーに移動し、ワークフロー定義をアップロードするのと同じことを実現します。新しいワークフロー定義のアップロードを参照してください。

条件エバリュエーターをテストする

Acme R6J9 Condition Evaluatorを使用するには、ブログエントリーで使用するように設定し、管理者のユーザーで新しいブログエントリーを追加します。

グローバルメニューの［アプリケーション］タブで、［ワークフロー］ → ［プロセスビルダー］を開きます。
設定タブで、ブログのエントリアセットタイプにR6J9 Conditional Approver の定義を割り当てる。
［保存］をクリックします。
デフォルトの管理者であるUser Test Testを使って、サイトメニューの → Content & Data → Blogsを開きます。
追加ボタン（）をクリックします。
タイトルと内容フィールドに何かを入力し、 Submit for Workflow をクリックします。
メインのBlogsビューに戻り、エントリーが表示され、ステータスが 承認済み と表示されていることを確認します。

tip

最初にステータスが［返答待ち］と表示された場合は、ページを更新してください。

唯一の承認者の定義や、管理者ではない別のユーザーでテストすると、ブログのエントリが 返答待ち というステータスで追加されていることがわかります。

R6J9Condition Evaluatorについて

Acme R6J9 Implementationプロジェクトには、ワークフローのユーザーがAdministrator Roleを持っている場合に、 approve の遷移をトリガーするための条件評価器が含まれています。 1つのクラスを含んでいます： R6J9ConditionEvaluator。

このプロジェクトでは、条件付き評価者に加えて、条件評価者を使用するR6J9 Conditional Approverというワークフロー定義が含まれ、自動でロードされます。

条件評価者は、ワークフローに送られるアセットのステータスを変更しません。これは、単にトランジションを実行するための便利な方法を提供するものです。ワークフローステータスの変更が必要な場合は、 WorkflowStatusManagerUtil クラスの UpdateStatusを 方法を呼び出します。定義の 承認済み 状態ノードは、ステータスを承認済みに設定します。

	</transitions>
</task>
		]]>
	</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>

`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 の条件評価器は ExecutionContext から workflowContext （Map型）とserviceContext（ServiceContext 型）を取得する：

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 で使用されているトランジションが、それが呼び出された条件ノードから有効なトランジションとして含まれていることを確認してください。

Capability: