＜R2＞Integrationアーキテクト試験／インテグレーションパターンのメモ #Salesforce

CTA最終試験が保留/リテイク2（Integration・ソリューション）の2つでしたので、Integrationの復習です。

リテイクに向けたネガティブフィードバック

Intergration

・アーカイブに関して、具体的なデータやソリューションの言及がない
・インテグレーションパターンの適応説明が不十分
・自動化期待に対してインポートの提案
・ESBが解決する拡張性につて言及がない

Solution Architecture

・事業拡張を見据えたスケーラビリティなアーキじゃなかった
・LWCの奨励にたいしてCRM Analyticsを提案した
・業務に即した形て特定ツールをソリューションに組み込めなかった。

ミドルウェア

ミドルウェアを挟むことにより、連携ポイントがシンプルになる。
監視やセキュリティの統合管理ができる。

ESB：少量・ニアリアルの処理に向いている。(システム連携)

・ロギングがしっかりしている。（Salesforce内だと簡易なものになってしまう）
・プロトコル変換できる点
・キューイング（失敗した際のリトライの機能）
・複数システムと繋ぐ場合に、コンポーネントの再利用性あり。
・疎結合になる。
・ポーリング（プラットフォームイベントは必須）
・冪等性の担保（重複チェック、一意のIDをもとに識別など）
・適切なフォーマットへの変換

ETL：より大量データのバッチ処理に向いている。

・初期データ移行など。
・夜間の大量データのバッチ連携

※最近ESBとETLの垣根もなくなってきているが・・・

インテグレーションパターン（実装方針）の特徴

Salesforceに画面をうめこみたい

Canvas

・対向シスタムの【画面】をそのまま埋め込むケース。
・ただし対向が改修できること（CanvasのJavaScriptライブラリを読み込めるか）が条件
・認証方式はOAuth、ないしはSignedリクエスト（後者は、接続アプリケーションのように、Client_id、Client_Secretを対向に埋め込み、Salesforce側はその埋め込みが払い出したものかを確認して認証する）

Salesforceと外部システムをリアル連携したい

SalesforceConnect（リアルタイムで外部データにアクセス）

・少量、リアルでデータを取得。（一応更新もできるが、基本ReadOnlyのケース）
・Salesforceにはデータを持たない。（ストレージ消費しない）
・対向のデータベースの情報をSalesforce画面に出したいケース。（リスト形式）
・制限：1時間に2万回のコールアウト、新規10万行まで取得可能。ODataのみ対応。

ユースケース
・外部のERPシステムに大量の請求データがあり、Salesforce画面に出したいケース
・規制要件でSalesforceに保持できないヘルスケアデータへのアクセス

画面フロー＋外部サービス（リクエスト&レスポンス＝同期連携）

・画面フローに外部サービスを組み込み、対向システムと同期で連携可能
※レコードトリガフローは非同期の連携のみ対応。

外部サービス
外部のWebサービスをOpenAPIで呼び出す機能。外部サービスのAPIの仕様から、自動でApexコードを生成できる。Flowから呼び出しも可能。

LWC＋Apexコールアウト(対向の取得/更新)（リクエスト&レスポンス＝同期連携）

・画面から、ボタンを押した際に対向システムの情報を同期で取得/更新したいケース
・少量、リアル（同期）

ユースケース
・例えば、ボタンを押したら対向からデータ取得して画面に出したり、〒を入れたら住所を即時で取得して出したり。。。

Salesforce側のDMLのタイミングによって対向システムと連携したい（非同期）

プラットフォームイベント（ファイア&フォーゲット＝非同期）

・非同期で少量、リアルのデータを対向へ連携する際に有効
・StreamingAPIを使って、対向（ESB）がSalesforceに対してロングポーリングをする。
・購読はCometDを使って行われる。※最近はPubSubAPIも出てきており、購読可能。
・72時間イベントが保持され、障害が起きた際にはReplyIdというIDを持っているので、特定のReplyID以降のイベントデータを取得など可能。（連携ツールでどこまで処理されたか確認する）
・データ落ちしないという特性（72時間）、対向がダウンしたときにミドルウェアを挟んでリトライできる点。（対向の障害に強い）
⇒なので他にApexコールアウト（非同期）などの類似ソリューションもあるが、Apexコールアウト（非同期）はエラハンが難しかったり(非同期という性質上お土地たときにどう検知するかなど)、対向がダウンしてる際にリトライが困難（リトライ機能がシンプルにない。Apexコールアウトにおいて。）なことを考えると、プラットフォームイベントを第一に考える。ローコードだし。

変更データキャプチャとの違い
・変更データキャプチャは実機で設定してみるとわかるが、オブジェクト単位で対象を指定することしかできず、オブジェクト単位の作成・更新・削除でPublush（他システムに全データを反映）するケースに向いている。この条件のときはこのデータを連携、等の場合プラットフォームイベントがよい。

リアルタイムが要望だが、結果を即座に確認する必要がないケース→非同期（プラットフォームイベント）を奨励。

ApexCallOut非同期処理との比較
・一応Apexコールアウトで非同期処理を実行できるが、エラハンが難しかったり、対向がダウンしているときにリトライが困難。なので、基本的にはローコードで72時間イベント保持しているプラットフォームイベントが優勢かと思う・・・

プラットフォームイベントが使えないケース
・ミドルウェアがなく、直接連携が必要で、対向がPubSubやStreamingAPIに対応してない場合、ApexCallOut（非同期）を検討

▽大規模プラットフォームイベント
https://qiita.com/nori83/items/01af2f773d3141c37225

対向システムからSalesforceに対してデータ連携したい。

RESTAPI/SOAPAPI、必要に応じてカスタムRESTAPI/カスタムSOAPAPI（リモートコールイン）

・対向システムからSalesforceのAPIをCallしてデータの取得や更新を行いたい。
・その時に加工や複数のデータの一括更新など必要な場合にApexでカスタムAPIを作ることが可能
・更新するレコードが大量ならBulkAPIも検討する。（バッチデータ連携など）
※APIコール数に要注意

システム間でバッチ連携したい。

ETL（BulkAPI）

連携タイミングやオブジェクト毎連携などであれば、変更データキャプチャも検討。変更データキャプチャも、対向（ミドルウェア）からSalesforceに対してStreamingAPIで購読。SalesforceからイベントをPublishする。

同期/非同期のメリデメ

・非同期は結果を待たないのですぐに次に進めることができる（UX改善）
　⇒また疎結合なので、拡張性/障害体制がある。
　⇒対向がダウンしていても処理を継続できる。ガバナも緩和
・一方非同期だとエラハンが複雑になるのはデメリット
　⇒同期の方が順序性を担保しやすい。

アーカイブ戦略（データ）

（１）1テーブルに100万件以上の場合、要件やパフォーマンスに応じてアーカイブを検討。
（２）別ストレージへのアーカイブは、
（a）履歴などDB構造が変わる可能性の低い履歴⇒BigObject（インデックスを貼りなおす場合、オブジェクトを作りなおしたりする必要があるので扱いづらい。なので項目が変わらない履歴など仕様変更が置きづらいものに適している。
（b）注文データなど項目が変わりやすいデータについては、例えば社内にストレージがある場合、そこにETLなど介して定期的にデータを投入。Salesforce側は削除することによりストレージを空かせる。
（c）社内にストレージがない場合、安価で実績/拡張性のあるAWSなど検討。同様にETLで定期的にアーカイブ、Salesforce側は削除
（d）Salesforc画面から上記のようなデータを見れるようにしたい、という場合はSalesforceConnectで関連リストからリアルに少量データを出す方針も検討（ただし1時間2万回のCallOutなど制限あり。）
（３）もし業務的に消していいものであれば、夜間バッチのタイミングで、例えばクローズしたデータを定期削除するケースも検討

アーカイブ戦略（ストレージ）

・まずは今のストレージにハマるか？
　※Edtionや利用者数に応じて試算（組織10G＋社内ライセンス数×2G）
・ハマらない場合、以下を検討する。
（１）追加キャパシティ購入
（２）外部ストレージへのアーカイブ
（３）パージ（削除）

（１）追加キャパシティ購入は、例えば1年以上ストレージが持つケースなどに検討
（２）別ストレージへのアーカイブは、シェアポなど用意し、FileConnect、ないしはETLで定期的にアーカイブを検討
（３）もし業務的に消していいものであれば、夜間バッチのタイミングで、例えばクローズしたデータを定期削除するケースも検討

その他（セキュリティなど）

Salesforce ← 対向システム

・接続アプリケーション（＝Salesforceに接続”された”アプリケーション＝Connected App）
なので、外部からSalesforceのAPIをCallするときなどに使用し、API接続の設定を管理する。
権限セットで利用できる接続アプリケーションを指定可能、IP制限、認証（OAuth）、CallbackURLなど管理。

Salesforce → 対向システム

・指定ログイン情報を活用する。
直接ソースコードにID/PWをかかず、設定から管理できる指定ログイン情報にて管理する。ソースコードに直接PWなどかかないので、セキュリティ向上になるのと、変更の際にソースコードの変更ではなく設定ベースで対処できるため、保守性の意味でもよい。
・リモートサイト設定
Apexコールアウトするシステムを登録しないと、APICallできない仕様

双方向SSL（TSL）、相互認証

・双方の身元を証明する。
・Salesforceはマルチテナントなので、IPを絞るだけだと、ID/PWが分かった際に、他社の環境にもアクセスできない、とは言い切れない。（不正アクセス）
　→対処として証明書を利用し、相互認証することで、自社組織を特定する。

気にすべき制限

・非同期含めて、外部とのコールアウト通信の累計時間は2分（トランザクション内のすべてのコールアウト (HTTP 要求または Web サービスコール) のタイムアウトの最大累積値）
・Apex処理の5秒10多重制限（ここにHttp通信時間は含まれない、Apexのみ）

＜R2＞Integrationアーキテクト試験／インテグレーションパターンのメモ