こんにちは、技術開発室の藤野です。
プラットフォームイベント(Platform Events)はSalesforceでイベント駆動型のアーキテクチャを実現する仕組みです。 特に、Salesforce外部からのレコード操作を疎結合にする手段として有用なのではと個人的に注目しています。
詳しくは公式ガイドを参照してください。
本記事では例として下記のシチュエーションを実現する一連の手順を紹介します。
- Salesforceは「デバイス」カスタムオブジェクトを持つ
- 「デバイス」カスタムオブジェクトは「シリアルナンバー」「状態」カスタム項目を持つ
- デバイスの識別は「シリアルナンバー」カスタム項目で行う
- 「状態」カスタム項目をイベントプラットフォーム経由で更新する
- REST APIで上記イベントを公開(publish)する
目次:
カスタムオブジェクトの作成
まず、イベントで更新するカスタムオブジェクトを作成します。 シリアルナンバーと状態を持つだけの単純なものです。
Salesforce上で[設定]-タブの[オブジェクトマネージャ]-[作成]-[カスタムオブジェクト]と進み、新規カスタムオブジェクトを作成します。
カスタムオブジェクトの定義は下記のとおりです。
表示ラベル | オブジェクト名 | レコード名 | データ型 |
---|---|---|---|
デバイス | Device | デバイス名 | テキスト |
オブジェクトの作成後、オブジェクトの「詳細」ページが表示されます。[項目とリレーション]-[新規]と進み、カスタム項目を作成します 定義は下記のとおりです。
項目の表示ラベル | 項目名 | 文字数 | データ型 |
---|---|---|---|
状態 | Status | 10 | テキスト |
シリアルナンバー | SerialNumber | 100 | テキスト |
シリアルナンバーはイベントからレコードを特定する際のキーとして使うため、「ユニーク+外部ID」を指定しています。
このオブジェクトを画面から見られるようにするためにタブに設定します。 Salesforce上で[設定]-メニューの[ユーザインターフェース]-[タブ]と進み、新規カスタムオブジェクトタブを作成します。
設定は下記のとおりです。
オブジェクト | タブスタイル |
---|---|
デバイス | (任意のものを選択) |
他の項目はデフォルトのままにします。
カスタムオブジェクトの作成は以上です。
プラットフォームイベントの作成
デバイスオブジェクトを更新するためのプラットフォームイベントを作成します。
Salesforce上で[設定]-メニューの[インテグレーション]-[プラットフォームイベント]と進み、新規プラットフォームイベントを作成します。 定義は下記のとおりです。
表示ラベル | オブジェクト名 |
---|---|
デバイス状態更新イベント | DeviceStatusUpdateEvent |
イベント作成後、イベントの定義が表示されます。[カスタム項目 & リレーション]の[新規]からカスタム項目を作成します。 これはイベントを公開、登録(subscribe)する際のパラメータに当たります。
定義は下記のとおりです。
項目の表示ラベル | 項目名 | 文字数 | データ型 | 必須項目 |
---|---|---|---|---|
状態 | Status | 10 | テキスト | 必須 |
シリアルナンバー | SerialNumber | 100 | テキスト | 必須 |
カスタムプラットフォームイベントの作成は以上です。
プロセスの作成
今回は、イベントを元にレコードを更新する処理をイベントプロセスで実装します。
Salesforce上で[設定]-メニューの[プロセスの自動化]-[プロセスビルダー]と進み、[新規]からプロセスを作成します。 プロセスのプロパティは下記のとおりです。
プロセス名:デバイス状態更新 API参照名:DeviceStatusUpdate プロセスを開始するタイミング:プラットフォームイベントメッセージを受信したとき
プロセス名 | API参照名 | プロセスを開始するタイミング |
---|---|---|
デバイス状態更新 | DeviceStatusUpdate | プラットフォームイベントメッセージを受信したとき |
プロセストリガの設定は下記のとおりです。
プラットフォームイベント | オブジェクト |
---|---|
デバイス状態更新イベント | デバイス |
一致条件は下記のとおりです。
項目 | 演算子 | 種別 | 値 |
---|---|---|---|
シリアルナンバー | 次の文字列と一致する | イベントの参照 | シリアルナンバー |
プロセストリガの次にプロセス条件を追加します。設定は下記のとおりです。
条件名 | アクションの実行条件 |
---|---|
いつも | アクションを実行する条件がない |
プロセス条件のTRUE
側にアクションを追加します。設定は下記のとおりです。
アクション名 | レコード | レコードの更新条件 |
---|---|---|
UpdateStatus | プロセスを開始した Device__c レコードを選択 | レコードを更新する条件がない |
「更新するレコードの新しい項目値」は下記のとおりです。
項目 | 種別 | 値 |
---|---|---|
状態 | イベントの参照 | 状態 |
プロセスを有効化後、プラットフォームイベントの設定画面を見ると、「登録」にProcessが登録されています。
プロセスの作成は以上です。
接続アプリケーションの作成
Salesforce API によるイベントメッセージの公開を使用するために、接続アプリケーションを作成します。 今回は認証にOAuth 2.0 ユーザ名パスワードフローを使うことにします。
Salesforce上で[設定]-メニューの[アプリケーション]-[アプリケーションマネージャ]と進み、[新規接続アプリケーション]からアプリケーションを作成します。
アプリケーションの設定値は下記のとおりです。アプリケーション名などは任意の値でかまいません。
アプリケーション名 | API参照名 | 取引先責任者 メール | OAuth 設定の有効化 | コールバック URL | 選択した OAuth 範囲 |
---|---|---|---|---|---|
RESTイベント確認 | RestEventTest | 任意のメールアドレス | チェックする | https://login.salesforce.com/services/oauth2/success | 範囲:データへのアクセスと管理(api) |
設定後の画面の「コンシューマ鍵」「コンシューマの秘密」の値は認証に使用するため控えておきます。(あとで参照することもできます)
接続アプリケーションの作成は以上です。
イベントの発行によるレコードの更新
更新対象レコードの準備
まず、イベントによって更新するレコードを作成します。 ここでは下記のレコードを作成しました。
PostmanでのREST APIの送信
REST APIによるプラットフォームイベントメッセージの発行のために、今回はPostmanを使います。
まず、認証してアクセストークンを取得します。
Postmanで新規Requestを作成します。Request name、collectionは任意です。(ここではそれぞれ「authentication」「event_platform」としました)
メソッド、URLを下記に設定します。
メソッド | URL |
---|---|
POST | https://login.salesforce.com/services/oauth2/token |
(Sandboxの場合、URLが https://test.salesforce.com/services/oauth2/token になります。)
[Body]タブから、下記を設定します。
(データ形式) | grant_type | client_id | client_secret | username | password |
---|---|---|---|---|---|
form-data | password | 接続アプリケーションのコンシューマ鍵 | 接続アプリケーションのコンシューマの秘密 | 使用するアカウントのユーザ名 | パスワード |
(パスワードは、セキュリティトークンが必要な設定をしている場合、パスワード+セキュリティトークンになります。)
[Send]からリクエストを送信します。レスポンスのうち、access_token
instance_url
を控えます。
アクセストークンが取得できたので、イベントメッセージ発行のリクエストを作成します。
Salesforce上では下記のレコードが作成されていました。
このレコードのうち、シリアルナンバー「Serial123」のレコードの状態を「Off」、「Serial456」のレコードの状態を「On」に更新してみます。シリアルナンバー「Serial789」のレコードは更新しません。
任意のRequest nameでリクエストを作成します。(ここでは「publish_event」としました)
メソッド、URLを下記に設定します。
今回は複数イベントをまとめて発行するREST API 複合(composite)リソースを使います。
メソッド | URL |
---|---|
POST | https://[instance_url]/services/data/v47.0/composite/ |
[Authorization]タブから下記を設定します。
TYPE | TOKEN |
---|---|
Bearer Token | 認証時のレスポンスのaccess_token の値を指定 |
[Headers]タブから下記を設定します。
Content-Type |
---|
application/json; charset=UTF-8 |
[Body]タブから、下記を設定します。
(データ形式) |
---|
raw |
{ "allOrNone": true, "compositeRequest": [ { "method": "POST", "url": "/services/data/v47.0/sobjects/DeviceStatusUpdateEvent__e", "referenceId": "event1", "body": { "SerialNumber__c" : "Serial123", "Status__c" : "Off" } }, { "method": "POST", "url": "/services/data/v47.0/sobjects/DeviceStatusUpdateEvent__e", "referenceId": "event2", "body": { "SerialNumber__c" : "Serial456", "Status__c" : "On" } } ] }
[Send]からリクエストを送信します。成功した場合、下記のようなレスポンスが返ってきます。
それでは、Salesforce上でレコードが更新されているか確認しましょう。
無事、シリアルナンバー「Serial123」のレコードの状態が「Off」、「Serial456」のレコードの状態を「On」、「Serial789」のレコードは変更なしになりました。
まとめ
冒頭の繰り返しになりますが、レコードの操作をSalesforceに任せて、接続アプリケーションと疎結合にできる点だけでも、とても強力な機能だと思います。
今回はシンプルな例でしたが、外部からレコードの挿入、更新をする処理はほとんどプラットフォームイベントに任せられるのではと期待しています。
本記事を作成するにあたり、下記ページを参考にしました。
補足
プラットフォームイベントには考慮事項や各種割り当てがあります。 特にイベント定義数などは注意が必要かと思います。詳細はドキュメントをご参照ください。