ワークフローのベストプラクティス
ワークフローにより、Adobe Experience Manager（AEM）のアクティビティを自動化できます。
ワークフローは、通常、AEM 環境で発生する大量の処理を表します。そのため、カスタムワークフローステップがベストプラクティスに従って記述されていない場合や標準提供のワークフローが可能な限り効率的に実行されるよう設定されていない場合は、システムのパフォーマンスが低下する可能性があります。
したがって、ワークフローの実装を慎重に計画することを強くお勧めします。
設定
（カスタマイズされたものか標準提供されたものかに関わらず）ワークフロープロセスを設定する際は、いくつかの点に注意してください。
一時的ワークフロー
高い取り込み負荷を最適化するには、ワークフローを一時的として定義することができます。
ワークフローが一時的である場合、中間の作業ステップに関連する実行時データは、実行時に JCR に保持されません（出力レンディションは保持されます）。
次のような利点があります。
- ワークフロー処理時間が短縮されます（最大 10 ％）。
- リポジトリの肥大化が大幅に抑制されます。
- CRUD ワークフローをパージする必要はありません。
- さらに、圧縮する TAR ファイルの数が削減されます。
CAUTIONDAM ワークフローの調整
DAM ワークフローのパフォーマンスチューニングガイドラインについては、AEM Assets パフォーマンスチューニングガイドを参照してください。
同時実行ワークフローの最大数の設定
AEM では、複数のワークフロースレッドを同時に実行できます。デフォルトでは、スレッド数はシステム上のプロセッサーコア数の半分になるように設定されています。
実行中のワークフローがシステムリソースを要求している場合、AEM が他のタスク（オーサリング UI のレンダリングなど）に使用できるリソースがほとんどないことを意味している可能性があります。その結果、画像の一括アップロードなどのアクティビティでシステムの応答が遅くなる場合があります。
この問題に対処するには、Maximum Parallel Jobs の数値をシステム上のプロセッサーコア数の半分から 4 分の 3 に相当する数に設定することをお勧めします。これにより、このようなワークフローを処理する際にシステムの応答が遅くならないように、十分な容量が確保されます。
Maximum Parallel Jobs を設定するには、次のいずれかを実行します。
-
キュー：Granite のワークフローキュー（Apache Sling Job Queue Configuration）用に、AEM web コンソールから OSGi 設定 を行います。
-
http://localhost:4502/system/console/slingeventの Job Queue Configuration：Granite のワークフローキュー 用に、AEM web コンソールの Sling ジョブ オプションからキューを設定します。
さらに、Granite Workflow External Process Job Queue 用に別の設定があります。これは、InDesign Server や Image Magick などの外部バイナリを起動するワークフロープロセスに使用されます。
個々のジョブキューの設定
場合によっては、同時スレッドまたは他のキューオプションを個々のジョブに応じて制御するように、個々のジョブキューを設定すると便利なことがあります。web コンソールから個々のキューを追加および設定するには、Apache Sling Job Queue Configuration ファクトリを使用します。一覧表示する適切なトピックを見つけるには、ワークフローのモデルを実行し、トピックを Sling ジョブ コンソール（例えば http://localhost:4502/system/console/slingevent）で検索してください。
また、個々のジョブキューを一時的ワークフローに追加することもできます。
ワークフローのパージの設定
標準インストールの場合、AEM にはメンテナンスコンソールが用意されており、このコンソールでは、日次および週次のメンテナンスアクティビティをスケジュールおよび設定できます。次に例を示します。
http://localhost:4502/libs/granite/operations/content/maintenance.html
デフォルトでは、週別メンテナンスウィンドウ に ワークフローのパージ タスクがありますが、このタスクを実行するには事前に設定する必要があります。ワークフローのパージを設定するには、Web コンソールで新しい Adobe Granite のワークフローのパージ設定 を追加する必要があります。
AEM のメンテナンスタスクについて詳しくは、操作ダッシュボードを参照してください。
カスタマイズ
カスタムワークフロープロセスを記述する際は、いくつかの点に留意する必要があります。
ロケーション
ワークフローのモデル、ランチャー、スクリプトおよび通知の定義は、タイプ（つまり、ディフォルト、カスタムなど）に応じてリポジトリに保管されます。
NOTE場所 - ワークフローモデル
ワークフローモデルは、タイプに応じて次のリポジトリに保管されます。
-
デフォルトのワークフロー設計は、次のパスに保管されます。
/libs/settings/workflow/models/CAUTION禁止事項：- カスタムのワークフローモデルをこのフォルダーに配置する
/libs内の設定を編集すること
変更内容が、アップグレード時や、ホットフィックス、Cumulative Fix Pack またはサービスパックの適用時に上書きされる場合があるからです。 -
カスタムのワークフロー設計は、次の場所に保管されます。
/conf/global/settings/workflow/models/... -
実行時のワークフロー設計（デフォルトとカスタムの両方）は、次のパスに保管されます。
/var/workflow/models/ -
レガシーのワークフロー設計（設計時と実行時の両方）は、次のパスに保管されます。
/etc/workflow/models/NOTEこれらの設計が AEM UI を使用 して編集された場合は、詳細情報が新しい場所にコピーされます。
場所 - ワークフローランチャー
ワークフローランチャーの定義も、タイプに応じて次のリポジトリに保管されます。
-
デフォルトのワークフローランチャーは、次のパスに保管されます。
/libs/settings/workflow/launcher/CAUTION禁止事項：- カスタムのワークフローランチャーをこのフォルダーに配置すること
/libs内の設定を編集すること
変更内容が、アップグレード時や、ホットフィックス、Cumulative Fix Pack またはサービスパックの適用時に上書きされる場合があるからです。 -
カスタムのワークフローランチャーは、次の場所に保管されます。
/conf/global/settings/workflow/launcher/... -
レガシーのワークフローランチャーは、次のパスに保管されます。
/etc/workflow/launcher/NOTEこれらの定義が AEM UI を使用 して編集された場合は、詳細情報が新しい場所にコピーされます。
場所 - ワークフロースクリプト
ワークフロースクリプトも、タイプに応じて次のリポジトリに保管されます。
-
デフォルトのワークフロースクリプトは、次のパスに保管されます。
/libs/workflow/scripts/CAUTION禁止事項：- カスタムのワークフロースクリプトをこのフォルダーに配置すること
/libs内の設定を編集すること
変更内容が、アップグレード時や、ホットフィックス、Cumulative Fix Pack またはサービスパックの適用時に上書きされる場合があるからです。 -
カスタムのワークフロースクリプトは、次の場所に保管されます。
/apps/workflow/scripts/... -
レガシーのワークフロースクリプトは、次のパスに保管されます。
/etc/workflow/scripts/
場所 - ワークフロー通知
ワークフロー通知も、タイプに応じて次のリポジトリに保管されます。
-
デフォルトのワークフロー通知の定義は、次のパスに保管されます。
/libs/settings/workflow/notification/CAUTION禁止事項：- カスタムのワークフロー通知の定義をこのフォルダーに配置すること
/libs内の設定を編集すること
変更内容が、アップグレード時や、ホットフィックス、Cumulative Fix Pack またはサービスパックの適用時に上書きされる場合があるからです。 -
カスタムのワークフロー通知の定義は、次の場所に保管されます。
/conf/global/settings/workflow/notification/...NOTEワークフロー通知のテキストを上書きする場合は、次の場所にオーバーレイされるパスを作成します。/conf/global/settings/workflow/notification/<path-under-libs> -
レガシーのワークフロー通知の定義は、次のパスに保管されます。
/etc/workflow/notification/
プロセスセッション
カスタム開発の場合と同様に、以下の理由により、可能な場合はユーザーのセッションを使用することを常にお勧めします。
- セキュリティガイドラインに準拠するため
- システムでセッションの開始と終了を管理できるようにするため
ワークフロープロセスを実装すると、次のようになります。
- ワークフローセッションが提供されます。このワークフローセッションは、特別な理由がない限り使用する必要があります。
- ワークフローステップから新しいセッションを作成することはできません。これは、状態の不整合が生じると同時に、ワークフローエンジン内で同時実行の問題が発生する可能性があるからです。
- ワークフローのプロセスステップ内から新しい JCR セッションを取得することはできません。Process Step API から提供されるワークフローセッションを JCR セッションに適応させる必要があります。次に例を示します。
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);
セッションの保存：
-
ワークフロープロセス内で
WorkflowSessionがリポジトリを変更するために使用されている場合は、セッションを明示的に保存しないでください。ワークフローにより、セッションは完了時に保存されます。 -
Session.Saveは、ワークフローステップから呼び出すことはできません。- ワークフロー JCR セッションを適応させることをお勧めします。その後ワークフローの実行が完了すると、ワークフローエンジンによってセッションが自動保存されるので、
saveは必要ありません。 - プロセスの各ステップでは、独自の JCR セッションを作成しないことをお勧めします。
- ワークフロー JCR セッションを適応させることをお勧めします。その後ワークフローの実行が完了すると、ワークフローエンジンによってセッションが自動保存されるので、
-
不要な保存操作をなくすことでオーバーヘッドを減らし、ワークフローの効率を高めることができます。
CAUTIONランチャーの数／範囲の最小化
登録されているすべてのワークフローランチャーに対応するリスナーは 1 つです。
- このリスナーは、他のランチャーのグロビングプロパティで指定されているすべてのパスで変更をリッスンします。
- イベントがディスパッチされると、ワークフローエンジンは、各ランチャーを評価して、それを実行する必要があるかどうかを判断します。
作成するランチャーが多すぎると、評価プロセスの実行速度が低下します。
1 つのランチャーのリポジトリのルートにグロビングパスを作成すると、ワークフローエンジンは、作成／変更イベントをリッスンして、リポジトリ内の各ノードに対して評価します。このため、必要なランチャーのみを作成し、グロビングパスをできるだけ明確にすることをお勧めします。
これらのランチャーがワークフローの動作に与える影響により、使用されていない標準提供のランチャーを無効にすると有用な場合があります。
ランチャーの設定の強化
カスタムのランチャー設定が強化され、以下の点がサポートされるようになりました。
- 複数の条件を「AND」で組み合わせる。
- 1 つの条件内に複数の OR 条件を含める。
- 機能フラグが有効か無効かに基づいてランチャーを無効または有効にする。
- ランチャー条件で正規表現をサポートする。
ワークフローを他のワークフローから開始しない
ワークフローは、オブジェクトがメモリ内に作成され、リポジトリ内でノードが追跡されるという両方の点において、大量のオーバーヘッドを生成する可能性があります。このため、ワークフローでは、他のワークフローを開始するのではなく、そのワークフロー内で処理を行うことをお勧めします。
この例として、一連のコンテンツに対するビジネスプロセスを実装し、そのコンテンツをアクティベートするワークフローが挙げられます。公開する必要があるコンテンツノードごとに コンテンツをアクティベート モデルを開始するのではなく、これらの各ノードをアクティベートするカスタムワークフロープロセスを作成することをお勧めします。この手法では追加の開発作業が必要になりますが、実行時には、アクティベートするたびに別のワークフローインスタンスを開始するよりも効率的です。
もう 1 つの例として、いくつかのノードを処理し、ワークフローパッケージを作成してアクティベートするワークフローが挙げられます。パッケージを作成し、そのパッケージをペイロードとして別のワークフローを開始するのではなく、パッケージを作成するステップ内でワークフローのペイロードを変更した後、同じワークフローモデル内でそのステップを呼び出してパッケージをアクティベートすることができます。
ハンドラー処理の設定
ワークフローモデルを設計する際に、ワークフローステップのハンドラー処理の設定を有効にすることができます。また、次に実行するステップを決定するコードをワークフローステップに追加し、実行することもできます。
パフォーマンスが向上するので、ハンドラー処理の設定を使用することをお勧めします。
ワークフローステージ
ワークフローステージを定義し、タスク／ステップを特定のワークフローステージに割り当てることができます。
この情報は、インボックス](https://experienceleague.adobe.com/docs/experience-manager-65/sites-authoring/workflows-participating.html?lang=ja#opening-a-workflow-item-to-view-details-and-take-actions)から作業項目の「[ワークフロー情報」タブをクリックしたときにワークフローの進行状況を表示するために使用されます。既存のワークフローモデルを編集してステージを追加することができます。
ページをアクティベートプロセスステップ
ページをアクティベートプロセス ステップを実行するとページがアクティベートされますが、参照される DAM アセットは自動的に検出され、アクティベートされるわけではありません。
このステップをワークフローモデルの一部として使用することを計画している場合は、この点に注意する必要があります。
アップグレードに関する考慮事項
インスタンスをアップグレードする場合：
-
インスタンスをアップグレードする前に、すべてのカスタムワークフローモデルがバックアップされていることを確認してください。
-
次の場所にカスタムワークフローが格納されていないことを確認してください。
/libs/settings/workflow/models/projects
NOTEシステムツール
ワークフローの監視、メンテナンスおよびトラブルシューティングに役立つ多くのシステムツールがあります。以下に示す URL の例ではすべて localhost:4502 を使用していますが、どのオーサーインスタンス（<hostname>:<port>）を使用しても構いません。
Sling ジョブ処理コンソール
http://localhost:4502/system/console/slingevent
Sling ジョブ処理コンソールには次の情報が表示されます。
- 前回の再起動以降のシステム内のジョブの状態に関する統計情報が表示されます。
- すべてのジョブキューの設定も表示され、設定マネージャーでその設定を編集するためのショートカットが提供されます。
ワークフローレポートツール
ワークフローレポートツールは、パフォーマンスの低下を防ぐために 6.3 では削除されています。
ワークフローメンテナンス操作 MBean
http://localhost:4502/system/console/jmx/com.adobe.granite.workflow:type=Maintenance
ワークフローメンテナンス MBean は、完了したワークフローのパージやワークフロー統計情報の取得など、いくつかの便利なメンテナンスルーチンを公開します。
その他の情報
詳しくは、次のセクションを参照してください。
