ターゲット

ターゲットは通常、パブリッシャーが生成したイベントの配信先となるエンドポイントです。ターゲットは、同じまたは異なるパブリッシャーから複数のイベントを受信できます。

ターゲットの例を以下に示します:

• UPIベースの決済アプリケーションでは、無効な支払い試行、異常なアカウントアクティビティ、取引パターンの異常などのイベントが、不正検出ソフトウェアに即座に配信されます。ここでは、イベントデータがWebhookエンドポイント（ターゲット）に共有され、不正検出ソフトウェアが適切に対応できるようにします。

• ソーシャルメディアアプリケーションでは、広告キャンペーン、スポンサー投稿、プロモーション活動に関連するイベントが、キャンペーンパフォーマンスの評価と戦略の最適化のためにマーケティングソフトウェアに配信されます。このシナリオでは、イベントデータがCatalyst Circuits（ターゲット）に共有され、マーケティングソフトウェアが人的介入なしに処理と対応を行えるようにします。

主要な機能

ターゲットは、ルール内の定義済みルールとフィルターに基づいて受信イベントを処理する責任を負います。Signalsでのこの処理には、データ抽出と変換、ディスパッチ、ダウンストリームプロセスのトリガーなどのアクションが含まれる場合があります。

ターゲットタイプ

プラットフォームは、ダウンストリームプロセスをトリガーする以下のさまざまなタイプのターゲットをサポートしています:

• Webhookは、アプリケーション間でリアルタイムデータを共有するのに役立つHTTPコールバックです。システム間のイベント駆動統合に一般的に使用されます。

• Functionは、受信イベントに応じて実行されるよう設定されます。Java、Node.js、Pythonプログラミング言語で記述されたコードスニペットで構成され、ターゲットで特定のタスクの実行やビジネスロジックを処理します。

• Circuitは、定義済みワークフローを使用して受信イベントに基づいてプロセスを自動化します。コーディングなしに複雑なイベント駆動ワークフローを設計できます。

単一のWebhook/Function/Circuitは、ディスパッチポリシー、リトライポリシー、ボディ設定のバリエーションを持つ異なるターゲット設定名で、Catalystプロジェクト内で複数回使用できます。

イベントディスパッチタイムアウト

イベントがターゲットにディスパッチされると、Signalsは指定された期間ターゲットの応答を待ちます。ターゲットがこの期間内に応答しない場合、イベントはFailedとしてマークされます。

各ターゲットタイプの時間間隔は以下のとおりです:

ディスパッチポリシー

Catalyst Signalsは、イベントをキュー内で個別に、またはバッチとしてまとめて受信する柔軟性を提供します。それぞれのタイプをカスタマイズすることもできます。

• 即時 - パブリッシャーシステムでイベントが発生するたびに即座に受信されます。ターゲットに送信する前にSignals内にイベントが保持されるカスタマイズされたTime To Live期間を設定できます。

• バッチ - さまざまなディスパッチ方法と頻度に基づいて、イベントがまとめて配信されます。この方法でディスパッチされるイベントのTime To Live期間はデフォルトで24時間に設定されており、変更できません。

ディスパッチポリシーのタイプについて詳しく学びましょう。

リトライポリシー

イベントがターゲットとの通信に失敗した場合、Signalsはその特定のイベントがターゲットに到達するために最大20回のリトライを許可します。これらのリトライは自動的に行われ、ユースケースに応じてリトライ回数や頻度をカスタマイズできます。

• 自動 - 自動頻度モードでは、最初のリトライは失敗したイベントの1分後に行われます。最初のリトライも失敗した場合、以降のリトライは前回の失敗時間に基づく指数関数的な間隔パターンに従います。

例えば、イベントがターゲットに到達できなかった場合、最初のリトライは失敗の1分後に発生します。このリトライも失敗した場合、以降のリトライは前回の時間の2倍の間隔で行われ、最大10分です。

間隔は次のとおりです: 2回目のリトライ - 2分、3回目のリトライ - 4分、4回目のリトライ - 8分、5回目以降のリトライ - 10分。このパターンはイベントがターゲットに到達するか、設定されたリトライ回数に達するまで続きます。

• 手動 - このモードでは、リトライの頻度間隔を手動で設定できます。要件に応じて、時間または分単位で設定できます。この頻度はイベントのTime To Live期間と互換性があり、それを超えてはなりません。手動頻度は1分から1時間の間で設定できます。

プレースホルダー

プレースホルダーは、このターゲットに関連付けられたWebhookのヘッダーまたはパラメーターの定義において重要な役割を果たします。このフィールドは、Webhook内のヘッダーとパラメーターに動的な値を使用し、このターゲットに関連付けた場合にのみ表示されます。静的な値の場合は、ユースケースに応じて値を直接追加できます。ただし、動的な値の場合は、イベントスキーマ内のキーのJSONパスを指定する必要があります。

イベント変換

イベントスキーマはイベントとともに自動生成され、Signalsに送信されます。ルールのターゲットページで、ターゲットに配信する前にスキーマをカスタマイズできます。ペイロード全体をターゲットに共有するか、ビジネス要件に合わせて抽出と変換を実行するかを選択できます。

• 抽出 - このアクションにより、既存のイベントスキーマから特定のキーを取得し、そのプロパティのみで新しいスキーマを構築できます。設定されたワークフローに不要な詳細をフィルタリングし、最適化されたイベントデータのみをターゲットに共有します。

• 変換 - これにより、希望する形式に合わせてイベントスキーマ内のキー名と値を変更できます。ターゲット環境でのワークフローやダウンストリームプロセスとの互換性を提供します。

イベントスキーマの抽出と変換のステップバイステップガイド