ワークフローのベストプラクティス workflow-best-practices
実行とパフォーマンス execution-and-performance
ワークフローに当てはまるベストプラクティスを含む、Campaign のパフォーマンス最適化に関する一般的なガイドラインを以下に示します。
ワークフローの実行に関するトラブルシューティングのガイドラインは、Campaign Classic v7 実稼動ガイドでも参照できます。
ログ logs
JavaScript の logInfo() メソッドは、ワークフローのデバッグに適しています。これは利用価値がありますが、特に頻繁に動作するアクティビティでは注意が必要です。過度な負荷がログかかり、ログテーブルのサイズを大幅に増大させてしまう可能性があります。一方で、logInfo() の以外のログが必要となることもあります。
他には役に立つソリューションが 2 つあります。
-
2 つの実行間の中間母集団の結果を保持
このオプションでは、ワークフローの 2 つの実行の間に一時テーブルを保持します。これはワークフロープロパティの「一般」タブにあり、データを監視し結果を確認できるよう、開発とテストの目的で利用可能です。このオプションは開発環境では使用できますが、本番環境では絶対に使用しないでください。一時テーブルを保持していると、データベースのサイズが大幅に増大し、サイズの制限に達してしまうかもしれません。更に、バックアップも遅くなります。
最後に実行したワークフローのワークテーブルのみ保持されます。
それ以前に実行した分のワークテーブルは、毎日実行される クリーンアップ ワークフローによりパージされます。note caution CAUTION プロダクションワークフローでは、このオプションを選択しないでください。このオプションは、結果の分析に利用され、テスト目的でのみ設計されたものですので、開発環境またはステージング環境のみに限定して使用する必要があります。 -
SQL クエリをジャーナルに記録
これはワークフロープロパティの「実行」タブにあり、様々なアクティビティのツールによって生成された全ての SQL クエリを記録します。プラットフォームが実際に何を実行したのかを確認するのに適しています。ただし、このオプションは開発の際に一時的に利用するべきもので、本番では有効にしないでください。
不要になったログはパージしてください。ワークフローの履歴は自動でパージされません。すべてのメッセージは、デフォルトで保持されます。履歴は、ファイル/アクション メニューを選択するか、リストの上にあるツールバー内の「アクション」ボタンをクリックすることでパージできます。「履歴をパージ」を選択します。ログをパージする方法について詳しくは、このドキュメントを参照してください。
ワークフローの計画 workflow-planning
- インスタンスのオーバーロードが発生するのを防ぐよう、1 日を通じてアクティビティのレベルを安定させ、ピークを回避してください。このためには、ワークフローの開始時間を 1 日を通じて均等に分散させる必要があります。
- リソースの競合を削減するため、データ負荷を夜間にスケジュールします。
- 時間がかかるワークフローは、サーバーおよびデータベースリソースに影響を与える可能性があります。処理時間を短縮するため、一番時間のかかるワークフローを分割します。
- 全体的なランタイムを短縮するには、時間のかかるアクティビティを、シンプルで迅速なアクティビティに置き換えます。
- 20 を超えるワークフローを同時に実行しないでください。同時に実行するワークフローが多すぎると、リソースが不足し、システムが不安定になる可能性があります。ワークフローが開始しない理由について詳しくは、この記事を参照してください。
「エンジン内で実行」オプション execute-in-the-engine-option
ワークフローのプロパティ ウィンドウで、「エンジン内で実行」オプションを絶対に選択しないでください。このオプションを有効にした場合、そのワークフローが優先され、優先されたワークフローが完了するまで、その他すべてのワークフローがワークフローエンジンによって中断されます。
ワークフローのプロパティ workflow-properties
ワークフローフォルダー 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
アクテビティの名前 name-of-the-activity
ワークフローを開発する際、アクティビティには他の Adobe Campaign オブジェクト同様に名前が付けられます。名前はツールが生成しますが、アクティビティを設定する際にわかりやすい名前に変更することをお勧めします。後から名前変更をおこなうと、それより前の他のアクティビティの名前を使用するアクティビティを含むワークフローが中断する恐れがあります。このため、後から名前を変更するのは困難な作業になります。
アクティビティの名前は、「詳細設定」タブにあります。query、query1、query11 といった名前のままにせず、querySubscribedRecipients などのわかりやすい名前を付けてください。この名前は、ジャーナルおよび場合によっては SQL ログに表示され、ワークフロー設定の際、デバッグするのに役立ちます。
最初と最後のアクティビティ first-and-last-activities
-
常に「開始」アクティビティまたは「スケジューラー」アクティビティでワークフローを開始します。適宜、「外部シグナル」アクティビティも使用できます。
-
ワークフローを作成する場合、分岐ごとに「スケジューラー」アクティビティを 1 つだけ使用します。ワークフローの同じ分岐に、相互にリンクされた複数のスケジューラーがある場合、実行タスクの数が指数関数的に増大するので、データベースに膨大な負荷がかかりかねません。このルールは、「スケジュール設定と履歴」タブで、すべてのアクティビティに適用されます。詳しくは、スケジュール設定を参照してください。
-
すべてのワークフローで、「終了」アクティビティを使用します。これにより、ワークフロー内で計算に使用される一時スペースが解放されます。詳しくは、開始および終了を参照してください。
アクティビティ内の JavaScript javascript-within-an-activity
ワークフローアクティビティを初期化する際、JavaScript を追加する必要がある場合があります。アクティビティの「詳細設定」タブで追加できます。
ワークフローを見つけやすくするため、アクティビティのラベルの最初と最後にダッシュを 2 つ使用して、「–ラベル名–」のようにすることをお勧めします。
シグナル signal
大抵の場合、シグナルがどこから呼び出されたのかは判断できません。この問題を避けるには、シグナルアクティビティの「詳細設定」タブの「コメント」フィールドを使用し、このアクティビティのシグナルの予測される出どころを記録します。
ワークフローの更新 workflow-update
本番ワークフローは直接更新しないでください。テンプレートワークフローを使用してキャンペーンを作成する以外の作業は、まず開発環境でテストしてください。この検証が終了したら、本番環境にワークフローをデプロイし、開始することができます。
すべてのテストは、実稼働環境ではなく、開発環境またはステージング環境で実行します。この場合、パフォーマンスの保証はできません。
開発あるいはテストプラットフォーム上で、アーカイブ済みフォルダー内にアーカイブ済みのワークフローを保存しておくことはできますが、本番環境では可能な限り削除してください。アクティブでない古いワークフローは、本番環境から削除してください。