【SFDC】Integrationパターン読んだ際のメモ①

勉強用メモです。
※自分が読み替えすために随時更新中

★残TODO：
・ミドルウェアに関する機能の用語
・付録：イベント駆動型アーキ
・付録：SFDCの参考サイト
・拡張外部サービス

##■Input
インテグレーションのパターンと実践 v50.0(2020/11/22時点)
https://developer.salesforce.com/docs/atlas.ja-jp.integration_patterns_and_practices.meta/integration_patterns_and_practices/integ_pat_intro_overview.htm
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/450298/a7c072e0-26d5-065d-d5e3-723f81973a31.png)

##言葉
・同期/非同期→システム間で通信する際に、対向システムへ投げた（連携した）データの処理結果を待つか否かを表現。
例）Webサイトでクレカ決済する際に、「通信中…」などの画面が表示され、少し待たされる場合が同期。システム間でデータの整合性を保つために、結果を待ちます。
一方、注文後に即座に完了画面に遷移し、「注文受付しました。結果はメールで送るのでお待ちください」のような表示がされ、後ほど少し遅れてメールで「注文完了しました」と連絡が来るのが非同期です。

・データ、プロセス、仮想の連携
★データ連携⇒名前の通りデータを連携します。（DB間の連携。）システムの初期移行など、これに該当します。
★プロセス連携⇒SFが注文情報を別システムに渡し（連携し）、別システム側で処理するような場合に、プロセス連携が該当します。（渡した先のシステムのロジック/処理を使うかどうかが論点。）
★仮想連携⇒データそのものを連携しないパターンです。（データを連携先システムで腹持ちしない。）例えば、外部システムへの画面埋め込みが該当します。

##連携パターンの概要
**:beer:同期の、データ/プロセス連携（SF→外部）
①リモートプロセスの呼び出し — 要求と返信**
※要求と返信は訳しすぎかと思われます。「リクエスト」と「レスポンス」と読めば自然です。
Salesforce は、データをリモートシステム（外部システム）へ渡し、プロセスを実行/完了するまで待機し、応答に基づいて状態を追跡します。
　→つまり、同期で、SFDCから外部システムへデータ連携し、必要に応じで外部システム側で処理を行い、データを返す流れが当該パターンに該当します。
　→同期とは、データ通信のリクエスト（SFDC→外部システム）を出してからレスポンス（外部システム→SFDC）が来るまでほかの処理を行わずにレスポンスを待ち続けること。（クレカの決済画面をイメージすると分かりやすいかも。決済処理がおわるまで「処理中…」など表示されますが、この待ってる状況が処理の同期をしているために起こります。待たないとシステム間のデータの整合性がおかしくなる場合に該当します。）
　→例えば、SFDCは注文情報を入力する窓口となるが、実際の注文プロセスは外部の注文管理システムで行うとする。ユーザはSFDCの注文情報を入力し、保存のタイミングで外部システムへ注文情報を渡し、SFDCと外部システムとで整合性を保つために、外部システム側からSFDCに注文のキーやステータスを返す場合など。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/450298/68730f7f-79ba-b399-92dd-9554b37a0975.png)

:beer:**非同期のプロセス連携（SF→外部）
②リモートプロセスの呼び出し — ファイアアンドフォーゲット**
Salesforce は、リモートシステム（外部システム）でプロセス（処理）を呼び出しますが、プロセスが完了するまで待機しません。代わりに、リモートプロセスが要求を受信して確認し、制御を Salesforce に戻します。
　→「プロセスが完了するまで待機しません。」ということで非同期。
　→例えば、SFDCは注文情報を入力する窓口となるが、実際の注文プロセスは外部の注文管理システムで行うとする。ユーザはSFDCの注文情報を入力したあとに、②～④の処理を待たない。
　→システムに注文情報などを入力するとすぐぐ完了画面（※「注文が完了したらメール通知が届きます、とか書かれている」）に遷移し、少し遅れてメールで「注文完了しました」などの通知が届くのがこのパターンに該当。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/450298/96bbb2a5-8033-6b3b-ead4-5bc39d12eb8e.png)

**:beer:非同期のデータ連携（SF←外部（※））
③バッチデータの同期**
※説明文を見ると、SF→外部に関しても言及対象となる模様だが、パターン比較図にはSF←外部と記載のためSF←外部としている。
外部システムの更新を反映させるには、Lightning Platform に保存されるデータを作成または更新します。また、逆に Lightning Platform で変更が発生した場合は、それを外部システムに送信します。いずれの場合も更新はバッチ形式で行われます。
　→定期的に、SFDCにデータを反映させる場合や、初期移行などを想定。
　（①②のように、何かデータの入力/更新などがトリガーでではなく、定期的にデータをバサッと投入する場合に、このパターンが該当。）
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/450298/cd7f3791-f8f9-2eb3-6dc5-79bf2ca9bc3d.png)

**:beer:同期・非同期のデータ/プロセス連携（SF←外部）
④リモートコールイン**
※非同期データ連携は③が該当　
Lightning Platform に保存されるデータは、リモートシステムによって作成、取得、更新、削除されます。
　→SF側からすると、外部システム（リモート）からコールインされたので、リモートコールインという名称になったと理解してます。
　→外部システムからSFへ通信する場合にこのパターンが該当します。
　例）外部システムが、SFDCの情報を取得し、外部システム上に表示している場合など。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/450298/3ea97839-94d9-4037-3c09-17be6e067740.png)

:beer:**非同期のデータ連携（SF内部）
⑤データの変更に基づく UI の更新**
Salesforce ユーザインターフェースは、Salesforce データが変更されたときに、自動的に更新される必要があります。
　→SFから外部へのポーリング（定期的に通信）する場合に該当。
　→外部のシステムにステータスなどの更新があれば、SF側の画面が更新される。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/450298/81b785b6-4c72-595c-5312-70461c738991.png)


**:beer:同期の仮想連携（SF→外部）
⑥データ仮想化**
Salesforce はリアルタイムで外部データにアクセスします。これにより、Salesforce でデータを保持し、Salesforce と外部システム間でデータを調整する必要がなくなります。
　→リアルタイムにアクセスするので画面埋め込み（Canvasやiframeなど）がここに該当。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/450298/a9ad638e-721c-e0de-6174-51f270cbaa70.png)

##連携パターンのカタログ
:wine_glass:**同期のデータ/プロセス連携（SF→外部）
①リモートプロセスの呼び出し — 要求と返信**
 ・（最適）拡張外部サービス→初見。なに？★★★（TODO）
 ・（最適）VForLC+Apexコールアウト
 ・（最適）VF+Apex Httpコールアウト
 ・Triggerでコールアウト
　　　→DMLのあとなので同期で連携できない。非同期になるため最適でない。
　・Apex一括Jobでコールアウト
　　　→非同期になるため最適でない。

:wine_glass:**非同期のプロセス連携（SF→外部）
②リモートプロセスの呼び出し — ファイアアンドフォーゲット**
　・（最適）プロセス駆動型プラットフォームイベント
　・（よい）カスタマイズ駆動型プラットフォームイベント
　・（よい）アウトバウンドメッセージ
　・VFやLWCからApexコールアウト
　・変更データキャプチャでApexコールアウト

:wine_glass:**非同期のデータ連携（SF←外部（※））
③バッチデータの同期**　
最適ソリューション
＜SF→外部の時＞
　・（最適）変更データキャプチャ
　　　→予め外部システムで購読（Subscribe）が必要。
　　　→SF側のデータ変更を変更データキャプチャで検知し、プラットフォームイベントへ公開、外部システムへニアリアルでデータ連携する。
　・（よい）ETLでのデータ連携
　・リモートプロセス呼び出し
＜外部→SFの時＞
　・（最適）ETLでのデータ連携
　　　→サードパーティを利用し、連携元の外部システムからデータ抽出・変換を行い、SFへ連携する。
　・リモートコールイン　

:wine_glass:**同期・非同期のデータ/プロセス連携（SF←外部）
④リモートコールイン**
　・（最適）SOAP/REST API
　　　　→Salesforceが標準提供しているAPI
　・Apex Webサービス（SOAP/REST API）
　　　　→上記で対応できない場合、個別にカスタムしたい場合はこちら。
　・BulkAPI
　　　　→大量データの場合はこちら。

:wine_glass:**非同期のデータ連携（SF内部）
⑤データの変更に基づく UI の更新**
→SFDC上のDBに変更があった際に、トーストとかで「更新したよ」と通知が来る機能とかここに該当。
　・ストリーミング APIの利用
　　→PushTopic+プラットフォームイベントや、Visualforce ページまたは Lightning コンポーネントなど

:wine_glass:**同期の仮想連携（SF→外部）
⑥データ仮想化**
→Salesforce でデータを外部システムから Salesforce に移行することなく、Salesforce の外部に保存されているデータを表示、検索、変更するには?
・Salesforce Connect（追加ライセンス）
　　→（最適）外部オブジェクトを利用。レポートなどは使えないが、関連リストに表示されるUIは標準を利用可能。
・要求と変更
　　→画面をVisalforceやLightningWebComponentで構築し、RESTやSOAPうを使ってApexでコールアウト



##そのmemo（別でまとめる予定）
SOAP API	リモートシステムは Salesforce Enterprise または Partner WSDL を使用してクライアントスタブを生成します。このスタブは標準 SOAP API の呼び出しに使用されます。
REST API	リモートシステムは、Apex REST サービスにアクセスする前に認証を行う必要があります。リモートシステムでは、OAuth 2.0 またはユーザ名/パスワード認証を使用できます。いずれの場合も、クライアントは認証 HTTP ヘッダーと適切な値 (SOAP API へのログインコール経由で OAuth アクセストークンまたはセッション ID を取得可能) を設定する必要があります。
次に、リモートシステムは、適切な動詞で REST 呼び出し (HTTP 要求) を生成し、返された結果 (JSON および XML データ形式がサポート対象) を処理します。
★変更データキャプチャ（追加ライセンス）
https://qiita.com/nori83/items/01ba54570d68c2cc1c8c
　　　→ストリーミング製品。変更データキャプチャを使用すると、Salesforce レコードの変更をリアルタイムに受信し、外部データストアの対応するレコードに同期可能。
　　　→SFのデータ作成や更新を変更データキャプチャで検知し、イベントをイベントバスへ公開（パブリッシュ）する。
　　　→購読者（リスナー）は、上記データを変換し、ローカルDBに書き込む。エラーがあった場合はエラーテーブルに書き込む。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/450298/645bbe1f-17d6-f994-188c-0532fad6817c.png)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/450298/bcc75061-00e5-bb1a-1cd1-199de5c1a090.png)

★プラットフォームイベント（追加ライセンス）
★拡張外部サービス
★SalesforceConnect（OData）