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

ワークフローを使用すると、Adobe Experience Manager(AEM) アクティビティを自動化できます。

多くの場合、AEM環境で発生する処理の量が多いので、ベストプラクティスに従ってカスタムワークフロー手順が記述されない場合や、標準のワークフローが可能な限り効率的に実行するように設定されていない場合、結果としてシステムに影響が出ます。

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

設定 configuration

ワークフロープロセス（カスタマイズされた、またはそのまま使用できる）を設定する際には、いくつかの点に注意する必要があります。

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

取り込みの負荷を高く抑えるために、 一時的なワークフロー.

ワークフローが一時的な場合、中間の作業手順に関連するランタイムデータは、実行時に JCR に保持されません（出力レンディションはもちろん保持されます）。

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

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

DAM ワークフローのパフォーマンスチューニングガイドラインについては、 AEM Assets Performance Tuning Guide.

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

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

実行されるワークフローがシステムリソースを要求する場合、AEMがオーサリング UI のレンダリングなど、他のタスクに使用する負荷がほとんど残っていないことを意味する場合があります。 その結果、バルク画像のアップロードなどのアクティビティ中にシステムの動作が遅くなる場合があります。

この問題に対処するため、Adobeでは、 並列ジョブの最大数 は、システム上のプロセッサコア数の半分から 4 分の 3 の間に設定します。 これにより、このようなワークフローを処理する際にシステムの応答が遅くならないように、十分な容量が確保されます。

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

さらに、Granite Workflow External Process Job Queue 用に別の設定があります。これは、外部バイナリを起動するワークフロープロセス（例： ）に使用されます。 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

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

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

すべての ワークフローランチャー 登録済み：

ランチャーが多すぎると、評価プロセスの実行に時間がかかります。

単一のランチャーでリポジトリのルートにグロビングパスを作成すると、ワークフローエンジンはリスンを実行し、リポジトリ内のすべてのノードに対する作成/変更イベントを評価します。 このため、必要なランチャーのみを作成し、グロビングパスをできる限り具体的にすることをお勧めします。

これらのランチャーがワークフローの動作に与える影響により、使用中でない標準のランチャーを無効にすると便利です。

ランチャーの設定の強化 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

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