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

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

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

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

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

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

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

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

次に例を示します。

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

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

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

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

重要度の高いキャンペーンワークフロー（キャンペーン／操作の一部として作成されたワークフロー）は、同時に実行されるべきプロセスがキャンペーンに多数ある場合に、優先して実行されます。 デフォルトでは、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

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

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

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

シグナル signal

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

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

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

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

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

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

ログ logs

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

中間母集団を保持

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

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

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

SQL クエリをログに記録

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

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

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

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

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

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