イベント駆動型ソフトウェアアーキテクチャの理解
学習の目的
この単元を完了すると、次のことができるようになります。
- イベント駆動型ソフトウェアアーキテクチャのコンポーネントを挙げる。
- イベント駆動型ソフトウェアアーキテクチャの利点を説明する。
- プラットフォームイベント機能のユースケースを説明する。
- プラットフォームイベントの特徴を説明する。
このモジュールを始める前に
すぐにでも始めたいと思っていらっしゃると思いますが、このモジュールを完了するために理解しておく必要な概念について先に少しご説明させてください。
このモジュールでは、Apex、REST API、フロー、プロセスを使用してプラットフォームイベントを公開する方法を説明します。また、このモジュールでは、他の方法に加えて、Apex トリガーを使用してプラットフォームイベントに登録する方法も説明します。このモジュールの内容を理解するには、これらのテクノロジーのうち少なくとも 1 つに精通している必要があります。このモジュールのハンズオン Challenge を実行するには、Apex トリガーの知識が必要です。そこで、Apex について学べるトレイルとモジュールをご紹介しておきます。
- オブジェクト指向プログラミング言語についての知識が必要な場合は、「Apex コーディングスキルの構築」トレイルを受講してください。
- オブジェクト指向プログラミング言語に詳しい方は、「Apex の基本とデータベース」、「Apex トリガー」、「Apex テスト」モジュールがお勧めです。
また、Pub/Sub API の概念に精通しておくことは必須ではありませんが、このモジュールの理解に役立ちます。Pub/Sub API についての詳細は、Pub/Sub API のドキュメントを参照してください。
イベント駆動型ソフトウェアアーキテクチャの理解
注文システムで荷物が発送されているか? プリンターカートリッジを交換する必要があるか? など、受け取る通知の種類に関わらず、Salesforce のエンタープライズメッセージングプラットフォームでは、安全で拡張性の高いカスタム通知を Salesforce 内と外部ソースから配信できます。プラットフォームイベントでは、システムを監視して変更を他のシステムに伝達できます。
イベントベース通信のパラダイムは、公開者-登録者モデル (送信者がメッセージをブロードキャストとして 1 人以上の受信者が取得する) を中心に進化しています。それは、送信塔が相手を限定せずにラジオ電波を送信し、聴取者は適切な周波数に合わせていれば電波を受信できる、ラジオ放送に似ています。
ラジオ放送と同様、イベントベースの通信は送信者から受信者に流れます。イベントは、受信者がリスンしているかどうかに関係なく非同期に送信され、受信者はイベントを受信しても受信確認をしません。イベントベースの通信はリアルタイム、厳密に言えば準リアルタイムで行われます。ラジオ電波は光速で伝送されますが、イベントベースのソフトウェアおよびハードウェアシステムには通常何らかの遅延があります。
Trailhead モジュール「プラットフォーム API の基礎」では、イベント検出を表現するのに海賊船のレーダーの比喩を使用しました。この比喩は、Salesforce レコードの変更に基づく変更データキャプチャイベントのストリーミングには適しています。この通信モデルに必要なのは登録者のみです。一方、プラットフォームイベントでは、通信には送信者と受信者という 2 つの関係者がいます。この 2 つはイベント駆動型アーキテクチャのコンポーネントです。
イベント駆動型システムのコンポーネント
先に進む前に、いくつかの用語を定義しましょう。
イベント
ビジネスプロセスにおいて意味のある状態の変化。たとえば、発注は意味のあるイベントです。注文履行センターは、注文を処理する前に通知を受け取ることを想定しているからです。
イベントメッセージ
イベントに関するデータが含まれるメッセージ。イベント通知とも呼ばれます。たとえば、イベントメッセージとして、注文の情報が含まれる、発注に関する通知などがあります。
イベントプロデューサー
イベントメッセージの公開者。たとえば、発注アプリケーションなどがあります。
イベントチャネル
イベントのストリームで、そのストリーム上でイベントプロデューサーはイベントメッセージを送信し、イベントコンシューマーはそのメッセージを読み込みます。プラットフォームイベントの場合、チャネルは 1 つのプラットフォームイベント用か、複数のプラットフォームイベントのイベントメッセージをグループ化するカスタムチャネルです。
イベントコンシューマー
チャネルの登録者で、そのチャネルからメッセージを受信します。たとえば、新規注文の通知を受信する注文履行アプリケーションなどがあります。
イベントバス
公開-登録モデルに基づいたマルチテナントでマルチクラウドのイベントストレージおよび配信サービス。イベントバスを使用することで、保持期間内であればいつでも保存されたイベントメッセージを取得できます。時系列イベントログに基づいたイベントバス。イベントメッセージが Salesforce で受信された順序で保存されて配信されるようにします。
次の図は、イベントベースのソフトウェアアーキテクチャを示します。
要求-応答通信モデルとは異なり、イベント駆動型モデル上に構築されたソフトウェアアーキテクチャは、イベントプロデューサーをイベントコンシューマーから分離し、それによって接続システムの通信モデルを簡略化します。特定の状態に関する情報を取得するのに、サーバーに対して要求を行う必要はありません。代わりに、システムはイベントチャネルに登録し、新しい状態が発生するたびに通知を受け取ります。コンシューマーは何人でも同じイベントを受信して反応できます。イベントが発生すると、システムはこの情報を取得し、ほぼリアルタイムで反応できます。イベントを送信するシステムとイベントを受信するシステムには、メッセージ内容のセマンティックを除き、互いに連動関係がありません。
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 トリガーまたは Emp API Lightning コンポーネントを用いてイベントを使用します。コードの代わりに、Flow Builder 宣言型ツールでイベントを公開できます。外部アプリケーションは Pub/Sub API を使用してイベントを公開し、Pub/Sub API を使用してイベントを使用します。このように、プラットフォームイベントの使用方法は非常に柔軟に選択することができます。
プラットフォームイベントは次のケースで使用します。
- 事前定義されたスキーマを使用してカスタムイベントデータを送受信する
- Apex でイベントの公開または登録を行う
- Salesforce Platform 上かどうかに関係なく柔軟にイベントの公開と処理を行う
ストリーミングイベントには、変更データキャプチャイベントという種類もあります。このイベントには、作成、更新、削除、復元の操作による Salesforce レコードへの変更内容が格納されます。 詳細は、「変更データキャプチャの基礎」 Trailhead モジュールを参照してください。
次の単元では、プラットフォームイベントを定義してイベントを公開します。
リソース