イベント駆動型ソフトウェアアーキテクチャの理解

学習の目的

この単元を完了すると、次のことができるようになります。
  • イベント駆動型ソフトウェアアーキテクチャのコンポーネントを挙げる。
  • イベント駆動型ソフトウェアアーキテクチャの利点を説明する。
  • プラットフォームイベント機能の使用事例を説明する。
  • プラットフォームイベントの特徴を説明する。

このモジュールを始める前に

すぐにでも始めたいと思っていらっしゃると思いますが、このモジュールを完了するために理解しておく必要な概念について先に少しご説明させてください。 

このモジュールでは、Apex、REST API、フロー、プロセスを使用してプラットフォームイベントを公開する方法を説明します。また、Apex トリガ、フロー、プロセス、Lightning コンポーネント、CometD ベースのツールを使用してもプラットフォームイベントに登録できます。このモジュールの内容を理解するには、これらのテクノロジーのうち少なくとも 1 つに精通している必要があります。このモジュールのハンズオン Challenge を実行するには、Apex トリガの知識が必要です。そこで、Apex について学べるトレイルとモジュールをご紹介しておきます。

また、ストリーミング API の概念にも精通しておくと、このモジュールの理解に役立ちます。まだ完了していない場合は、このモジュールを始める前に「Lightning プラットフォーム 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 でリードが割り当てられると、リードトリガが起動し、リード所有者に関連する進行中の商談とケースを確認します。関連レコードに基づいて、トリガがイベントを公開し、Salesforce アプリケーションがイベントを受信します。イベント情報に基づいて、アプリケーションはリードを再割り当てして Chatter 投稿を作成します。

このシナリオでは、プロセスビルダーやフローなど他の Salesforce 機能を使用して同じアクションを実行できます。ただし、プラットフォームイベントを使用すると、イベントベースのプログラミングモデルとアプリケーション間の標準的なプログラミング方法による利点があります。

次の図では、Salesforce のアプリケーションがプラットフォームイベントを公開します。トリガはこのイベントチャネルに登録し、イベントを受信します。

プラットフォームイベントの特徴

どのような場合にプラットフォームイベントを使用するか理解できたので、次はそのコンポーネントと特徴を詳しく見てきましょう。

ユーザは、プラットフォームイベントに含まれるカスタムデータを定義します。カスタムオブジェクトと同様に、プラットフォームイベントは Salesforce で定義します。名前を付け、カスタム項目を追加して、プラットフォームイベント定義を作成します。次のサンプルは、Cloud News 通信社のニュースイベントのカスタム項目定義です。

項目の表示ラベル/名前 項目 API 参照名 データ型
場所 Location__c テキストの
長さ: 100
緊急 Urgent__c チェックボックス
News Content News_Content__c テキストエリア (ロング)

プラットフォームイベントと sObject

プラットフォームイベントは特殊な種類の Salesforce エンティティであり、多くの点で sObject に似ています。イベントメッセージは、プラットフォームイベントのインスタンスで、レコードがカスタムオブジェクトのインスタンスであるのと似ています。カスタムオブジェクトとは異なり、イベントレコードの更新や削除、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 を介して登録する チェックマーク チェックマーク
Apex トリガを介して登録する
チェックマーク
プロセスビルダーや Flow Builder を使用して宣言型で公開する
チェックマーク
メモ

メモ

他のイベント種別の比較については、『Streaming API 開発者ガイド』の「ストリーミングイベント機能」を参照してください。

次の単元では、プラットフォームイベントを定義してイベントを公開します。

無料で学習を続けましょう!
続けるにはアカウントにサインアップしてください。
サインアップすると次のような機能が利用できるようになります。
  • 各自のキャリア目標に合わせてパーソナライズされたおすすめが表示される
  • ハンズオン Challenge やテストでスキルを練習できる
  • 進捗状況を追跡して上司と共有できる
  • メンターやキャリアチャンスと繋がることができる