イベント駆動型ソフトウェアアーキテクチャの理解
学習の目的
このモジュールを始める前に
すぐにでも始めたいと思っていらっしゃると思いますが、このモジュールを完了するために理解しておく必要な概念について先に少しご説明させてください。
このモジュールでは、Apex、REST API、フロー、プロセスを使用してプラットフォームイベントを公開する方法を説明します。また、Apex トリガー、フロー、プロセス、Lightning コンポーネント、CometD ベースのツール、Pub/Sub API を使用してもプラットフォームイベントに登録できます。このモジュールの内容を理解するには、これらのテクノロジーのうち少なくとも 1 つに精通している必要があります。このモジュールのハンズオン Challenge を実行するには、Apex トリガーの知識が必要です。そこで、Apex について学べるトレイルとモジュールをご紹介しておきます。
- オブジェクト指向プログラミング言語についての知識が必要な場合は、「Alexa コーディングスキルの構築」トレイルを受講して下さい。
- オブジェクト指向プログラミング言語に詳しい方は、「Apex の基本とデータベース」、「Apex トリガー」、「Apex テスト」モジュールがお勧めです。
- CometD についての詳細は、「Lightning プラットフォーム API の基本」モジュールの「ストリーミング API を使用する」単元を参照してください。
- Pub/Sub API についての詳細は、Pub/Sub API のドキュメントを参照してください。
イベント駆動型ソフトウェアアーキテクチャの理解
注文システムで荷物が発送されているか? プリンターカートリッジを交換する必要があるか? など、受け取る通知の種類に関わらず、Salesforce のエンタープライズメッセージングプラットフォームでは、安全で拡張性の高いカスタム通知を Salesforce 内と外部ソースから配信できます。プラットフォームイベントでは、システムを監視して変更を他のシステムに伝達できます。
イベントベース通信のパラダイムは、公開者-登録者モデル (送信者がメッセージをブロードキャスとして 1 人以上の受信者が取得する) を中心に進化しています。それは、送信塔が相手を限定せずにラジオ電波を送信し、聴取者は適切な周波数に合わせていれば電波を受信できる、ラジオ放送に似ています。
ラジオ放送と同様、イベントベースの通信は送信者から受信者に流れます。イベントは、受信者がリスンしているかどうかに関係なく送信され、受信者はイベントを受信しても受信確認をしません。イベントベースの通信はリアルタイム、厳密に言えば準リアルタイムで行われます。ラジオ電波は光速で伝送されますが、イベントベースのソフトウェアおよびハードウェアシステムには通常何らかの遅延があります。
「Lightning Platform API の基本」モジュールでは、海賊船のレーダーを比喩として用いてイベント検出について説明しました。この比喩は、Salesforce レコードの変更に基づく PushTopic イベントのストリーミングには適しています。この通信モデルに必要なのは登録者のみです。一方、プラットフォームイベントでは、通信には送信者と受信者という 2 つの関係者がいます。この 2 つはイベント駆動型アーキテクチャのコンポーネントです。
イベント駆動型システムのコンポーネント
先に進む前に、いくつかの用語を定義しましょう。
イベントビジネスプロセスにおいて意味のある状態の変化。たとえば、発注は意味のあるイベントです。注文履行センターは、注文を処理する前に通知を受け取ることを想定しているからです。
イベントメッセージ
イベントに関するデータが含まれるメッセージ。イベント通知とも呼ばれます。たとえば、イベントメッセージとして、注文の情報が含まれる、発注に関する通知などがあります。
イベントプロデューサー
イベントメッセージの公開者。たとえば、発注アプリケーションなどがあります。
イベントチャネル
イベントのストリームで、そのストリーム上でイベントプロデューサーはイベントメッセージを送信し、イベントコンシューマーはそのメッセージを読み込みます。プラットフォームイベントの場合、チャネルは 1 つのプラットフォームイベント用で、そのプラットフォームイベントのすべてのイベントメッセージがグループ化されます。
イベントコンシューマー
チャネルの登録者で、そのチャネルからメッセージを受信します。たとえば、新規注文の通知を受信する注文履行アプリケーションなどがあります。
次の図は、イベントベースのソフトウェアアーキテクチャを示します。
Salesforce エンタープライズメッセージングプラットフォームは、イベント駆動型ソフトウェアアーキテクチャの利点をもたらします。プラットフォームイベントは、アプリケーションが送受信するイベントメッセージです。プラットフォームイベントにより、変更の伝達および応答プロセスが簡略化され、複雑なロジックを記述する必要がなくなります。公開者と登録者はプラットフォームイベントを介して相互に通信します。1 人以上の登録者が同じイベントをリスンして、アクションを実行できます。
たとえば、Cloud News という通信社が登録クライアントに、目的地の山荘付近の交通および道路の状況に関する最新のニュース速報を含むイベントを送信するとします。それらのイベントの内容には、単なるニュース記事だけではなく、ニュースが緊急かどうかや事故の場所など、関連する詳細も含まれます。登録者は、これらのイベントを受信し、ニュースの緊急度に応じてどのようなアクションを取るかを判断できます。
いいことづくめのように聞こえますが、プラットフォームイベントを使用可能な実際のケースではどうでしょうか? もちろん、プラットフォームイベントの使用は通信社に限定されません。次は、いくつかの有益なアプリケーションを紹介します。
プラットフォームイベントを使用するケースの例
プラットフォームイベントを使用するビジネスシナリオをいくつか見ていきましょう。これらのシナリオでは、Salesforce と外部システムがプラットフォームイベントメッセージ経由で通信します。最初のシナリオでは、Salesforce のアプリケーションが外部の注文履行アプリケーションに商品配送注文の通知を送信します。2 つ目のシナリオでは、外部商品アプリケーションが Salesforce に商品の返品に関する通知を送信します。最後のシナリオでは、Salesforce 内でのトリガーを使用したイベントメッセージの使用方法を示します。
プラットフォームから外部アプリケーションへ: ベンダーアプリケーションの注文履行
Salesforce で商談が「成立」として完了した場合、会社は顧客との取引を獲得しています。この商談に関連付けられた商品の配送にベンダーを使用するとします。各ベンダーには、特定の商品の配送注文を処理する外部アプリケーションがあります。この外部アプリケーションは、プラットフォームイベントをリスンします。商談が成立すると、Salesforce の商品注文アプリケーションに含まれるトリガーが起動してプラットフォームイベントメッセージを公開します。各ベンダーアプリケーションにイベントが通知されます。特定の商品の配送を担うベンダーが発送を作成します。
外部アプリケーションからプラットフォームアプリケーションへ: Salesforce での商品返品処理
顧客が購入した商品をベンダーに返品するとします。外部システムは商品返品要求を Salesforce に送信します。外部システムはプラットフォームイベントを公開して、Salesforce に商品返品をアラート通知します。Salesforce のイベントリスナー (トリガー) がイベントを受信して何らかのアクションを実行します。たとえば、トリガーは営業担当に返品をアラート通知したり、顧客に確認メールを送信したりします。
プラットフォームからプラットフォームへ: リードレコードの再割り当て
Salesforce でリードが割り当てられると、リードトリガーが起動し、リード所有者に関連する進行中の商談とケースを確認します。関連レコードに基づいて、トリガーがイベントを公開し、Salesforce アプリケーションがイベントを受信します。イベント情報に基づいて、アプリケーションはリードを再割り当てして Chatter 投稿を作成します。
このシナリオでは、Flow Builder を使用して同じアクションを実行できます。ただし、プラットフォームイベントを使用すると、イベントベースのプログラミングモデルとアプリケーション間の標準的なプログラミング方法による利点があります。
プラットフォームイベントの特徴
どのような場合にプラットフォームイベントを使用するか理解できたところで、次はそのコンポーネントと特徴を詳しく見てきましょう。
ユーザーは、プラットフォームイベントに含まれるカスタムデータを定義します。カスタムオブジェクトと同様に、プラットフォームイベントは Salesforce で定義します。名前を付け、カスタム項目を追加して、プラットフォームイベント定義を作成します。次のサンプルは、Cloud News 通信社のニュースイベントのカスタム項目定義です。
| 項目の表示ラベル/名前 | 項目 API 参照名 | データ型 |
|---|---|---|
| 場所 | Location__c | テキストの 長さ: 100 |
| 緊急 | Urgent__c | チェックボックス |
| News Content | News_Content__c | テキストエリア (ロング) |
プラットフォームイベントと Salesforce オブジェクト
プラットフォームイベントは特殊な種類の Salesforce エンティティであり、多くの点で Salesforce オブジェクトに似ています。イベントメッセージは、プラットフォームイベントのインスタンスで、レコードが Salesforce オブジェクトのインスタンスであるのと似ています。レコードとは異なり、イベントメッセージの更新や削除、Salesforce ユーザーインターフェースでのイベントメッセージの表示はできません。
プラットフォームイベントに対する参照および作成権限は設定できます。ユーザーへの権限付与は、プロファイルまたは権限セットで行います。
ネイティブおよび外部アプリケーションでのプラットフォームイベントの使用
プラットフォームイベントによって、Salesforce 内および外部アプリケーションとの間でのイベントメッセージのフローが可能になります。Salesforce Platform 上のアプリケーションは Apex メソッドを使用してイベントを公開し、Apex トリガーまたは empApi Lightning コンポーネントを用いてイベントを使用します。コードの代わりに、Flow Builder 宣言型ツールでイベントを公開できます。外部アプリケーションは sObject API を使用してイベントを公開し、CometD を使用してイベントを使い切ります。このように、プラットフォームイベントの使用方法は非常に柔軟に選択することができます。
プラットフォームイベントと他のストリーミングイベントの違い
他のストリーミングイベントについてはどうでしょうか? 他のイベントとして、PushTopic イベントや汎用イベントなどがあります。PushTopic イベントでは、クライアントは事前定義されたクエリに基づいて Salesforce レコードの変更に関するメッセージを受信します。汎用イベントでは、任意のメッセージコンテンツ (ペイロード) を送受信できます。これらは Salesforce レコードに関連付けられていなくても構いません。プラットフォームイベントは汎用イベントに似ていますが、より強力なカスタマイズが可能です。プラットフォームイベントでは、任意のカスタムデータを公開できます。イベントデータのスキーマを型付けされた項目として詳細なレベルで定義します。また、Salesforce Platform のネイティブアプリケーションと外部アプリケーションで同様にプラットフォームイベントを使用できます。プラットフォームイベントは次のケースで使用します。
- 事前定義されたスキーマを使用してカスタムイベントデータを送受信する
- Apex でイベントの公開または登録を行う
- Salesforce Platform 上かどうかに関係なく柔軟にイベントの公開と処理を行う
次の表では、汎用イベントとプラットフォームイベントの機能を比較しています。
| 機能 | 汎用イベント | プラットフォームイベント |
|---|---|---|
| イベントスキーマを型付けした項目として定義する |  |
|
| ユーザー定義のペイロードを含める |  |
 |
| 1 つ以上の API を介してイベントを公開する |  |
|
| Apex を介してイベントを公開する | |
|
| CometD を介して登録する | |
|
| Pub/Sub API を介して登録する |
 |
|
| Apex トリガーを介して登録する | |
|
| Flow Builder を使用して宣言型で公開する |
|
他のイベント種別の比較については、『Streaming API 開発者ガイド』の「ストリーミングイベント機能」を参照してください。
次の単元では、プラットフォームイベントを定義してイベントを公開します。
