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

以下に、Campaign ワークフローのパフォーマンスを最適化し、ワークフローのデザインを改善し、正しい設定を選択するための一般的なガイドラインを示します。

ワークフローフォルダー workflow-folders

専用フォルダーでワークフローを作成することをお勧めします。

プラットフォーム全体に影響するワークフローの場合には(例えばクレンジングの処理など)、ビルトインの​ テクニカルワークフロー フォルダーにサブフォルダーを追加することを検討できます。

ワークフローの命名 workflow-naming

ワークフローには、適切な名前とラベルを付けることをお勧めします。そうすると、正常に機能していないワークフローを簡単に見つけてトラブルシューティングできるようになります。また、オペレーターが理解しやすいように、実行される処理の概要をワークフローの説明フィールドに記述してください。

そのワークフローが、複数のワークフローが関与する処理の一部となっている場合、ラベルの入力は手動でおこないます。ワークフローを(ラベルによって)順序付けるには数字の利用が適しています。

次に例を示します。

  • 001 - インポート - 受信者のインポート
  • 002 - インポート - 売上のインポート
  • 003 - インポート - 売上詳細のインポート
  • 010 – エクスポート - 配信ログのエクスポート
  • 011 – エクスポート - トラッキングログのエクスポート

ワークフローの重大度 workflow-severity

ワークフローの重大度は、ワークフローのプロパティの「実行」タブで設定することができます。

  • Normal(標準)
  • Production(本番)
  • Critical(重要)

ワークフローを作成する際にこの情報を入力しておくと、設定されている処理の重大度を理解するのに役立ちます。

このオプションでは、キャンペーンワークフロー以外のワークフローに対する機能上の影響はありません。

重要度の高いキャンペーンワークフロー(キャンペーン/操作の一部として作成されたワークフロー)は、同時に実行されるべきプロセスがキャンペーンに多数ある場合に、優先して実行されます。デフォルトでは、1 つのキャンペーンで同時に実行できるプロセスは最大 10 個です。この数は、NmsOperation_LimitConcurrency オプションによって決まります。例えば、キャンペーンに 25 個のワークフローが含まれている場合、重要度の高いワークフローが最初の 10 個のプロセスで実行されることになります。

ワークフローの監視 workflow-monitoring

エラーが発生した場合に通知を受けられるよう、本番環境で動作するすべてのスケジュール設定されたワークフローを監視する必要があります。

ワークフロープロパティにて、デフォルトの「ワークフロースーパーバイザー」あるいはカスタムグループを「スーパーバイザー」グループとして選択します。少なくとも 1 人のオペレーターがこのグループに属し、メールも設定されていることを確認します。

ワークフローを作成する前に、ワークフロースーパーバイザーを必ず定義します。エラーが発生した場合、スーパーバイザーにメールで通知されます。詳しくは、エラーの管理を参照してください。

監視」タブを定期的にチェックして、有効なワークフローの全体的なステータスを確認します。 詳しくは、インスタンスの監視を参照してください。

ワークフローヒートマップを使用すれば、Adobe Campaign 管理者はインスタンス上の負荷を監視し、それに従ってワークフローを計画することができます。詳しくは、ワークフローの監視を参照してください。

アクティビティ using-activities

CAUTION
同じワークフロー内でアクティビティをコピーして貼り付けることができます。ただし、異なるワークフロー間でアクティビティをコピーして貼り付けることはお勧めしません。アクティビティに関連付けられた配信やスケジューラーなどの設定が、貼り付け先ワークフローの実行中に競合やエラーの原因となる可能性があります。代わりに、ワークフローを​ 複製 ​することをお勧めします。詳しくは、ワークフローの複製を参照してください。

アクテビティの名前 name-of-the-activity

ワークフローを開発する際、アクティビティには他の Adobe Campaign オブジェクト同様に名前が付けられます。名前はツールが生成しますが、アクティビティを設定する際にわかりやすい名前に変更することをお勧めします。後から名前変更をおこなうと、それより前の他のアクティビティの名前を使用するアクティビティを含むワークフローが中断する恐れがあります。このため、後から名前を変更するのは困難な作業になります。

アクティビティの名前は、「詳細設定」タブにあります。queryquery1query11 ​といった名前のままにせず、querySubscribedRecipients などのわかりやすい名前を付けてください。この名前は、ジャーナルおよび場合によっては SQL ログに表示され、ワークフロー設定の際、デバッグするのに役立ちます。

最初と最後のアクティビティ first-and-last-activities

  • 常に「開始」アクティビティまたは「スケジューラー」アクティビティでワークフローを開始します。適宜、「外部シグナル」アクティビティも使用できます。

  • ワークフローを作成する場合、分岐ごとに「スケジューラー」アクティビティを 1 つだけ使用します。ワークフローの同じ分岐に、相互にリンクされた複数のスケジューラーがある場合、実行タスクの数が指数関数的に増大するので、データベースに膨大な負荷がかかりかねません。このルールは、「スケジュール設定と履歴」タブで、すべてのアクティビティに適用されます。詳しくは、スケジュール設定を参照してください。

  • すべてのワークフローで、「終了」アクティビティを使用します。これにより、ワークフロー内で計算に使用される一時スペースが解放されます。詳しくは、開始および終了を参照してください。

アクティビティ内の JavaScript javascript-within-an-activity

ワークフローアクティビティを初期化する際、JavaScript を追加する必要がある場合があります。アクティビティの「詳細設定」タブで追加できます。

ワークフローを見つけやすくするため、アクティビティのラベルの最初と最後にダッシュを 2 つ使用して、「–ラベル名–」のようにすることをお勧めします。

シグナル signal

大抵の場合、シグナルがどこから呼び出されたのかは判断できません。この問題を避けるには、シグナルアクティビティの「詳細設定」タブの「コメント」フィールドを使用し、このアクティビティのシグナルの予測される出どころを記録します。

ワークフローの更新 workflow-update

本番ワークフローは直接更新しないでください。テンプレートワークフローを使用してキャンペーンを作成する以外の作業は、まず開発環境でテストしてください。この検証が終了したら、本番環境にワークフローをデプロイし、開始することができます。

すべてのテストは、実稼働環境ではなく、開発環境またはステージング環境で実行します。この場合、パフォーマンスの保証はできません。

開発あるいはテストプラットフォーム上で、アーカイブ済みフォルダー内にアーカイブ済みのワークフローを保存しておくことはできますが、本番環境では可能な限り削除してください。アクティブでない古いワークフローは、本番環境から削除してください。

実行とパフォーマンス execution-and-performance

ログ logs

JavaScript の logInfo() メソッドを使用すると、ワークフローのデバッグを行えます。ただし、頻繁に実行するアクティビティでは特に注意が必要です。過度な負荷がログにかかり、ログテーブルのサイズを大幅に増大させてしまう可能性があります。

中間母集団を保持

2 つの実行間の中間母集団の結果を保持」オプションを指定すると、ワークフローの実行から次の実行までの間、一時テーブルを保持できます。

これはワークフロープロパティの「一般」タブにあり、データを監視し結果を確認できるよう、開発とテストの目的で利用可能です。このオプションは開発環境では使用できますが、本番環境では絶対に使用しないでください。一時テーブルを保持していると、データベースのサイズが大幅に増大し、サイズの制限に達してしまうかもしれません。更に、バックアップも遅くなります。

最後に実行したワークフローのワークテーブルのみ保持されます。
それ以前に実行した分のワークテーブルは、毎日実行される クリーンアップ ワークフローによりパージされます。

CAUTION
実稼動 ​ワークフローでは、このオプションを​ 選択しない ​でください。このオプションは、結果の分析に利用され、テスト目的でのみ設計されたものですので、開発環境またはステージング環境のみに限定して使用する必要があります。

SQL クエリをログに記録

SQL クエリをジャーナルに記録」オプションは、ワークフロープロパティの「実行 」タブにあります。このオプションを指定すると、様々なアクティビティのすべての SQL クエリを記録し、プラットフォームが実際に何を実行したかを確認できるようになります。ただし、このオプションは開発時に​ 一時的に ​利用するべきもので、実稼働では有効にしない ​でください。

不要になったログはパージすることをお勧めします。ワークフローの履歴は自動でパージされません。すべてのメッセージは、デフォルトで保持されます。履歴は、ファイル/アクション ​メニューを選択するか、リストの上にあるツールバー内の「アクション」ボタンをクリックすることでパージできます。「履歴をパージ」を選択します。ログをパージする方法について詳しくは、このドキュメントを参照してください。

ワークフローの計画 workflow-planning

ワークフローの実行計画には、問題を回避するためのベストプラクティスを追加して適用する必要があります。

  • インスタンスの過負荷を防ぐため、1 日のアクティビティ量を安定させて、ピークの発生を回避してください。このためには、ワークフローの開始時間を 1 日を通じて均等に分散させる必要があります。
  • リソースの競合を削減するため、データ負荷を夜間にスケジュールします。
  • 時間がかかるワークフローは、サーバーおよびデータベースリソースに影響を与える可能性があります。処理時間を短縮するため、一番時間のかかるワークフローを分割します。
  • 全体的なランタイムを短縮するには、時間のかかるアクティビティを、シンプルで迅速なアクティビティに置き換えます。
  • 20 を超えるワークフローを同時に実行しないでください。同時に実行されるワークフローが多すぎると、プラットフォームが過負荷になり、不安定になる可能性があります。

「エンジン内で実行」オプション execute-in-the-engine-option

実稼動環境では、エンジン内でワークフローを実行しないでください。ワークフローのプロパティ ​で「エンジン内で実行」オプションを指定した場合、そのワークフローが優先され、優先されたワークフローが完了するまで、その他のすべてのワークフローがワークフローエンジンによって中断されます。

recommendation-more-help
cffff7e4-091f-472e-87ca-52087599f99d