ワークフローのベストプラクティス -Campaign Classicでの設定と監視

この記事では、Adobe Campaign Classicでのワークフローの設定と監視に関するベストプラクティスをいくつか説明します。

説明 description

環境

  • Adobe Campaign
  • Adobe Campaign Classic

問題

ほとんどの場合、ワークフローは、プラットフォームのコア機能(組み込みまたはカスタム)の一部を構成します。 そのため、設定には十分注意が必要です。

解決策 resolution

一般設定

組織

tableXXX への読み込みなど、ワークフローをカスタムフォルダーに作成します。

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

ワークフロー名

前述のように、ワークフローに適切な名前とラベルを付けることが非常に重要です。 オペレーターは必ずしもドキュメントを参照するわけではないので、ワークフローの 説明 フィールドに入力して、実行するプロセスの概要を確認します。

ワークフローが複数のワークフローを含むプロセスの一部である場合は、ラベルを入力する際に明示的に指定してください。数値を使用すると、ワークフローを(ラベルで)並べ替えるのに最適な方法です。 例:

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

重大度

実行 」タブのワークフローのプロパティで、ワークフローの重要度を設定します。

  • Normal(標準)
  • 実稼動
  • Critical(重要)

ワークフローの作成時にこの情報を提供すると、設定されたプロセスの重大度を理解するのに役立ちます。

ログ

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

ただし、logInfo() 以外の値も必要になる場合があります。 2 つの追加のソリューションを利用できます。

2 つの実行間の中間母集団の結果を保持

このオプションはワークフローのプロパティの 一般 タブで使用でき、危険な場合と同様に役に立ちます。 これにより、Adobe Campaignは、2 回の実行の間に作成された一時テーブルを削除しなくなります。 開発環境には便利ですが、実稼動環境では使用できないので、監視する必要があります。 一時テーブルを保持していると、データベースのサイズが大幅に増大し、サイズの制限に達してしまうかもしれません。更に、バックアップも遅くなります。

実稼動環境の ワークフローなし では、このオプションをいつでもオンにする必要があります。

SQL クエリをジャーナルに記録 :

ワークフロープロパティの「 実行 」タブで使用可能です。これにより、様々なアクティビティからツールで生成されたすべての SQL クエリがログに記録されます。 プラットフォームが実際に何を実行しているかを確認するのに最適な方法です。 ただし、このオプションは開発の際に一時的に利用するべきもので、本番では有効にしないでください。

監視

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

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

ワークフローを一時停止したままにしない :

一時的なワークフローを作成する場合は、そのワークフローが正しく終了でき、「一時停止」状態にならないことを確認してください。 一時停止した場合は、一時テーブルを保持する必要があるので、データベースのサイズを大きくする必要があります。

ワークフロー内

アクティビティ名

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

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

アクティビティ内のJavaScript

ワークフローアクティビティを初期化する際、JavaScript を追加する必要がある場合があります。これは、アクティビティの 詳細 タブで実行できます。 ワークフローのスポッティングを簡単にするために、アクティビティラベルの先頭と末尾には次のように二重のダッシュを使用することをお勧めします。— マイラベル —

シグナル

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

ワークフローの更新

本番ワークフローは直接更新しないでください。テンプレートワークフローでキャンペーンの作成が含まれていない限り、可能であれば、まず開発環境でプロセスをテストする必要があります。 この検証の後にのみ、ワークフローをデプロイして実稼動環境で開始できます。

アーカイブされたワークフローは、開発プラットフォームやテストプラットフォームの アーカイブ済み フォルダーに保持できますが、実稼動環境は可能な限りクリーンな状態に保つ必要があります。 古いワークフローは、非アクティブの場合、実稼動環境から削除する必要があります。

recommendation-more-help
3d58f420-19b5-47a0-a122-5c9dab55ec7f