ワークフローのベストプラクティス workflow-best-practices

ワークフローにより、Adobe Experience Manager（AEM）のアクティビティを自動化できます。

ワークフローは、通常、AEM 環境で発生する大量の処理を表します。そのため、カスタムワークフローステップがベストプラクティスに従って記述されていない場合や標準提供のワークフローが可能な限り効率的に実行されるよう設定されていない場合は、システムのパフォーマンスが低下する可能性があります。

したがって、ワークフローの実装を慎重に計画することを強くお勧めします。

設定 configuration

（カスタマイズされたものか標準提供されたものかに関わらず）ワークフロープロセスを設定する際は、いくつかの点に注意してください。

一時的ワークフロー transient-workflows

高い取り込み負荷を最適化するには、ワークフローを一時的として定義することができます。

ワークフローが一時的な場合、中間ワークステップに関連するランタイムデータは、実行時にJCRに保持されません（出力レンディションは保持されます）。

次のような利点があります。

DAM ワークフローの調整 tuning-dam-workflows

DAM ワークフローのパフォーマンスチューニングガイドラインについては、AEM Assets パフォーマンスチューニングガイドを参照してください。

同時実行ワークフローの最大数の設定 configure-the-maximum-number-of-concurrent-workflows

AEM では、複数のワークフロースレッドを同時に実行できます。 デフォルトでは、スレッドの数は、システム上のプロセッサ・コアの数の半分になるように設定されています。

実行中のワークフローがシステムリソースを要求している場合、AEM が他のタスク（オーサリング UI のレンダリングなど）に使用できるリソースがほとんどないことを意味している可能性があります。 その結果、画像の一括アップロードなどのアクティビティでシステムの応答が遅くなる場合があります。

この問題に対処するには、Maximum Parallel Jobs の数値をシステム上のプロセッサーコア数の半分から 4 分の 3 に相当する数に設定することをお勧めします。 これにより、このようなワークフローを処理する際にシステムの応答が遅くならないように、十分な容量が確保されます。

Maximum Parallel Jobs を設定するには、次のいずれかを実行します。

さらに、Granite ワークフロー外部プロセスジョブキュー​用に別の設定があります。 これは、InDesign Server や Image Magick などの外部バイナリを起動するワークフロープロセスに使用されます。

個々のジョブキューの設定 configure-individual-job-queues

場合によっては、個々のジョブキューを設定して、同時スレッドやその他のキューオプションを個々のジョブベースで制御すると便利です。 web コンソールから個々のキューを追加および設定するには、Apache Sling Job Queue Configuration ファクトリを使用します。 一覧表示する適切なトピックを見つけるには、ワークフローのモデルを実行し、トピックを Sling ジョブ​コンソール（例えば http://localhost:4502/system/console/slingevent）で検索してください。

また、個々のジョブキューを一時的ワークフローに追加することもできます。

ワークフローのパージの設定 configure-workflow-purging

標準インストールでは、AEMはメンテナンスコンソールを提供します。このコンソールでは、毎日および毎週のメンテナンスアクティビティをスケジュールおよび設定できます（例：）。

http://localhost:4502/libs/granite/operations/content/maintenance.html

デフォルトでは、週別メンテナンスウィンドウ​に​ ワークフローのパージ ​タスクがありますが、このタスクを実行するには事前に設定する必要があります。 ワークフローのパージを設定するには、Web コンソールで新しい Adobe Granite のワークフローのパージ設定​を追加する必要があります。

AEM のメンテナンスタスクについて詳しくは、操作ダッシュボードを参照してください。

カスタマイズ customization

カスタムワークフロープロセスを記述する際は、いくつかの点に留意する必要があります。

ロケーション locations

ワークフローのモデル、ランチャー、スクリプトおよび通知の定義は、タイプ（つまり、ディフォルト、カスタムなど）に応じてリポジトリに保管されます。

場所 - ワークフローモデル locations-workflow-models

ワークフローモデルは、タイプに応じて次のリポジトリに保管されます。

場所 - ワークフローランチャー locations-workflow-launchers

ワークフローランチャーの定義も、タイプに応じて次のリポジトリに保管されます。

場所 - ワークフロースクリプト locations-workflow-scripts

ワークフロースクリプトも、タイプに応じて次のリポジトリに保管されます。

場所 - ワークフロー通知 locations-workflow-notifications

ワークフロー通知も、タイプに応じて次のリポジトリに保管されます。

プロセスセッション process-sessions

カスタム開発の場合と同様に、以下の理由により、可能な場合はユーザーのセッションを使用することを常にお勧めします。

ワークフロープロセスを実装すると、次のようになります。

public void execute(WorkItem item, WorkflowSession workflowSession, MetaDataMap args) throws WorkflowException {
        // to obtain a jcr session:
        javax.jcr.Session jcrSession = workflowSession.adaptTo(javax.jcr.Session.class);

        // to obtain a sling resource resolver:
        org.apache.sling.api.resource.ResourceResolver slingResourceResolver = workflowSession.adaptTo(org.apache.sling.api.resource.ResourceResolver.class);

セッションの保存：

ランチャーの数／範囲の最小化 minimize-the-number-scope-of-launchers

登録されているすべてのワークフローランチャーに対応するリスナーは 1 つです。

作成するランチャーが多すぎると、評価プロセスの実行速度が低下します。

1 つのランチャーのリポジトリのルートにグロビングパスを作成すると、ワークフローエンジンは、作成／変更イベントをリッスンして、リポジトリ内の各ノードに対して評価します。 このため、必要なランチャーのみを作成し、グロビングパスをできるだけ明確にすることをお勧めします。

これらのランチャーがワークフローの動作に与える影響により、使用されていない標準提供のランチャーを無効にすると有用な場合があります。

ランチャーの設定の強化 configuration-enhancements-for-launchers

カスタムのランチャー設定が強化され、以下の点がサポートされるようになりました。

ワークフローを他のワークフローから開始しない do-not-start-workflows-from-other-workflows

ワークフローは、オブジェクトがメモリ内に作成され、リポジトリ内でノードが追跡されるという両方の点において、大量のオーバーヘッドを生成する可能性があります。 このため、ワークフローでは、他のワークフローを開始するのではなく、そのワークフロー内で処理を行うことをお勧めします。

この例として、一連のコンテンツに対するビジネスプロセスを実装し、そのコンテンツをアクティベートするワークフローが挙げられます。 公開する必要があるコンテンツノードごとに​ コンテンツをアクティベート ​モデルを開始するのではなく、これらの各ノードをアクティベートするカスタムワークフロープロセスを作成することをお勧めします。 このアプローチでは、追加の開発作業が必要となりますが、実行する際には、アクティベーションごとに個別のワークフローインスタンスを開始するよりも効率的です。

もう 1 つの例として、いくつかのノードを処理し、ワークフローパッケージを作成してアクティベートするワークフローが挙げられます。 パッケージを作成し、そのパッケージをペイロードとして別のワークフローを開始するのではなく、パッケージを作成するステップ内でワークフローのペイロードを変更した後、同じワークフローモデル内でそのステップを呼び出してパッケージをアクティベートすることができます。

ハンドラー処理の設定 handler-advance

ワークフローモデルを設計する際に、ワークフローステップでハンドラーの事前設定を有効にするオプションがあります。 また、次に実行するステップを決定するコードをワークフローステップに追加し、実行することもできます。

ハンドラーの高度な機能を使用することをお勧めします。これにより、パフォーマンスが向上します。

ワークフローステージ workflow-stages

ワークフローステージを定義し、タスク／ステップを特定のワークフローステージに割り当てることができます。

この情報は、インボックス​🔗​から作業項目の「ワークフロー情報」タブをクリックしたときにワークフローの進行状況を表示するために使用されます。 既存のワークフローモデルを編集してステージを追加することができます。

ページをアクティベートプロセスステップ activate-page-process-step

ページをアクティベートプロセス​ステップを実行するとページがアクティベートされますが、参照される DAM アセットは自動的に検出され、アクティベートされるわけではありません。

このステップをワークフローモデルの一部として使用することを計画している場合は、この点に注意する必要があります。

アップグレードに関する考慮事項 upgrade-considerations

インスタンスをアップグレードする場合：

システムツール system-tools

ワークフローの監視、メンテナンスおよびトラブルシューティングに役立つ多くのシステムツールがあります。 以下に示す URL の例ではすべて localhost:4502 を使用していますが、どのオーサーインスタンス（<hostname>:<port>）を使用しても構いません。

Sling ジョブ処理コンソール sling-job-handling-console

http://localhost:4502/system/console/slingevent

Sling ジョブ処理コンソールには次の情報が表示されます。

ワークフローレポートツール workflow-report-tool

ワークフローレポートツールは、パフォーマンスの低下を防ぐために 6.3 では削除されています。

ワークフローメンテナンス操作 MBean workflow-maintenance-operations-mbean

http://localhost:4502/system/console/jmx/com.adobe.granite.workflow:type=Maintenance

ワークフローメンテナンス MBean は、完了したワークフローのパージやワークフロー統計情報の取得など、いくつかの便利なメンテナンスルーチンを公開します。

その他の情報 further-information

詳しくは、次のセクションを参照してください。