Event streamsのユースケース例 ​

このガイドでは、Event streamsのユースケース例を示します。 ユースケース例では、特定のシナリオの概要と解決策を説明します。

レシピの分離 ​

次の例を検討してください。 当社の組織には、オンラインでフォームに入力したリードから連絡先データを取得するために構築されたWebToLead HTTP requestを受信した後、Salesforceでリードを作成するレシピがあります。 リードを作成した後、レシピはPostgresの分析データベースを更新します。

オンラインフォームからSalesforceとPostgreSQLにリードを移動するレシピ

当社の組織がデータベースをPostgreSQLからRedShiftに変更し、メーリングリストアプリケーションとしてMailChimpの使用を開始する場合、次のいずれかのアプローチを取ることができます。

• Event streamsを使用せずに元のレシピを変更する
• Event streamsを使用する

Event streamsを使用せずに元のレシピを変更する ​

レシピを次のように更新する必要があります。

PostgreSQLの代わりにRedshiftに行を追加し、MailChimpにサブスクライバーを追加するように変更されたレシピ

元のレシピを変更するには、レシピのDevelopmentライフサイクルを追加で繰り返す必要があります。これは、レシピの変更、後方互換性のテスト、プロダクションへのプッシュが必要になるためです。 QAをすり抜けたバグがあると、プロダクションレシピのダウンタイムにつながります。

Event streamsを使用する ​

Event streamsを利用する場合、リードデータをトピックに公開する前にSalesforceリードを作成するように、元のレシピを構築します。 このレシピではコンシューマーを考慮する必要がないため、下流のレシピが変更されていることを把握する必要もありません。

Salesforceでリードを作成し、リードデータをトピックに公開するパブリッシャーレシピ

リードデータを使用してRedshift行を作成する、対応するコンシューマーレシピは次のようになります。

トピックからリードデータを消費し、そのリードデータを使用してRedshift行を作成するコンシューマーレシピ

リードデータを使用してMailChimpリードを作成する、対応するコンシューマーレシピは次のようになります。

トピックからリードデータを消費し、そのリードデータを使用してMailChimpリードを作成するコンシューマーレシピ

リアルタイムイベントからのバッチの作成 ​

たとえば、同じシナリオでリードが非常に高い頻度で生成され、SalesforceおよびPostgreSQLへのAPI呼び出し回数を最適化することを計画しているとします。 WebToLeadはリードを1件ずつ公開するため、単一のレシピではそれを実現できません。

Event topicを使用すると、新規リードを集約し、一定の時間間隔で一括公開できます。 元のレシピは、新規リードを1件ずつEvent topicに公開するだけです。

WebToLeadから新規リードを受信し、Event streamsに公開するパブリッシャーレシピ

対応するコンシューミングレシピはNew batch of messagesトリガーを使用し、1時間に1回実行されます。 その後、バッチ全体をSalesforceとPostgreSQLに、それぞれ1回のAPI呼び出しだけで公開します。

新規リードのバッチを受信し、SalesforceとPostgreSQLに公開するコンシューミングレシピ