インテグレーションのパターンと実践
jバッチデータの同期
コンテキスト
- 現在の CRM システムから取引先、取引先責任者、および商談を抽出して加工し、データを Salesforce に読み込む (初期データインポート)。
- リモートシステムから週次で (継続的に) 顧客請求データを抽出して加工し、Salesforce に読み込む。
- 週次で (継続的に) Salesforce から顧客���動情報を抽出し、オンプレミス型のデータウェアハウスにインポートする。
問題
これらのインポートとエクスポートにより営業時間中のエンドユーザ操作に支障が出る可能性があり、また大量のデータを扱うことを考慮した場合、Salesforce へのデータのインポートと Salesforce からのデータのエクスポートをどう行えばよいか?
検討項目
- データを Salesforce に保存する必要があるか? 必要がない場合、アーキテクトが検討可能で検討すべきインテグレーションオプションが他にあります (たとえば、マッシュアップなど)。
- データを Salesforce に保存する必要がある場合、データはリモートシステムのイベントに応じて更新する必要があるか?
- データは定期的に更新する必要があるか?
- データは主なビジネスプロセスをサポートしているか?
- Salesforce でこのデータが使用できるかどうかによって影響を受ける分析 (レポート) 要件があるか?
ソリューション
| ソリューション | 適合度 | データマスタ | コメント |
|---|---|---|---|
| Salesforce 変更データキャプチャ | 最適 | Salesforce | Salesforce 変更データキャ���チャでは、Salesforce レコードの変更を表す変更イベントが公開されます。変更には、新規レコードの作成、既存のレコードの更新、レコードの削除、レコードの復元が含まれます。 変更データキャプチャにより、Salesforce レコードのほぼリアルタイムの変更、および外部データストアの対応するレコードの同期が実現されます。 変更データキャプチャは、複製の継続的な同期部分を処理します。新規レコードと変更されたレコードで、Salesforce データのデルタを公開します。変更データキャプチャには、イベントを受信し、外部システムで更新を実行するインテグレーションアプリケーションが必要です。 |
| サードパーティの ETL ツールを介した複製 | 最適 | リモートシステム | サードパーティの ETL ツールを利用して、供給元データに対する変更データキャプチャを実行できます。 ツールは供給元データセットの変更に反応し、データを加工してから、Salesforce Bulk API をコールして DML ステートメントを発行します。これは、Salesforce SOAP API を使用して実装することもできます。 |
| サードパーティの ETL ツールを介した複製 | 良い | Salesforce | サードパーティの ETL ツールを利用して、ERP および Salesforce データセットに対する変更データキャプチャを実行できます。 このソリューションでは Salesforce がデータの供給元であるため、各行の時間/状況情報を使用してデータを照会し、供給先結果セットを絞り込むことができます。これは、SOQL と共に SOAP API と query() メソッドを使用するか、SOAP API と getUpdated() メソッドを使用することで実装できます。 |
| リモートコールイン | 準最適 | リモートシステム | データ更新が発生したら、リモートシステムはいずれかの API を使用して Salesforce にコールインし、データ更新を実行できます。ただし、これによって 2 つのシステム間に大量のトラフィックが継続的に発生します。 エラー処理とロックに十分に注意する必要があります。このパターンでは更新が絶え間なく発生する可能性があり、エンドユーザのパフォーマンスに影響を与えることが予想されます。 |
| リモートプロセス呼び出し | 準最適 | Salesforce | データ更新が発生したら、Salesforce はリモートシステムにコールインしてデータ更新を実行できます。ただし、これによって 2 つのシステム間に大量のトラフィックが継続的に発生します。 エラー処理とロックに十分に注意する必要があります。このパターンでは更新が絶え間なく発生する可能性があり、エンドユーザのパフォーマンスに影響を与えることが予想されます。 |
概要図
次の図は、このパターンでリモートシステムがデータマスタとなる場合のイベントの順序を示します。
次の図は、このパターンで Salesforce がデータマスタとなる場合のイベントの順序を示します。
結果
- 外部システムがデータマスタ — Salesforce が 1 つの供給元システムまたは複数のシステムによって提供されるデータのコンシューマになります。このシナリオでは、通常、Salesforce にデータをインポートする前に、データウェアハウスまたはデータマートでデータで集約します。
- Salesforce がデータマスタ — Salesforce が特定のエンティティのレコードシステムになります。Salesforce 変更データキャプチャクライアントアプリケーションは Salesforce データへの変更の通知を受けることができます。
- 供給元データセットに対する変更データキャプチャを実装します。
- 制御テーブルと呼ばれる、サポートデータベース構造のセットを、中間のオンプレミス型データベースに実装します。
- 制御テーブルを読み取ってジョブの最終実行時間を判別し、必要な他の制御値を抽出します。
- 上記の制御値を検索条件として使用して供給元データセットを照会します。
- 検証、改良など、事前定義された処理ルールを適用します。
- ETL ツールで使用可能なコネクタ/加工機能を使用して、供給先データセットを作成します。
- データセットを Salesforce オブジェクトに書き込みます。
- 処理が成功したら、制御テーブルの制御値を更新します。
- 処理が失敗したら、制御テーブルを再起動可能にする値で更新し、終了します。
- ETL ジョブをチェーンにして順に並べ、まとまった 1 つのプロセスにする。
- 入力データの照合には両方のシステムの主キーを使用する。
- 特定の API メソッドを使用して更新されたデータのみを抽出する。
- 主従関係または参照関係の子レコードをインポートする場合、供給元での親キーを使用してインポートするデータをグループ化し、ロックを回避する。たとえば、取引先責任者データをインポートする場合、取引先責任者データを親の取引先キーでグループ化し、1 回の API コールで 1 つの取引先に対して最大数の取引先責任者を読み込めるようにします。インポートするデータがグループ化されていないと、通常、最初の取引先責任者レコードが読み込まれ、API コールのコンテキスト内ではその取引先の後続の取引先責任者レコードは読み込みに失敗します。
- トリガなど、インポート後処理は、必ずデータを選択的に処理する。
- シナリオで大量のデータを扱う場合、ホワイトペーパー『大量のデータを使用するリリースのベストプラクティス』を参照してください。
| エラー表示場所 | エラー処理および回復戦略 |
|---|---|
| 変更データキャプチャを使用した Salesforce からの読み取り |
|
| サードパーティの ETL システムを使用した Salesforce からの読み取り |
操作は成功してもレコード単位で失敗する場合は、ジョブの即時再起動か後続処理の実行で問題に対処します。この場合、遅延再起動は、エラーの原因と思われるデータに優先順位を付けて修正する時間を取れるため、適したソリューションとなる可能性があります。 |
| Salesforce への書き込み |
操作は成功してもレコード単位で失敗する場合は、ジョブの即時再起動か後続処理の実行で問題に対処します。この場合、遅延再起動は、エラーの原因と思われるデータに優先順位を付けて修正する時間を取れるため、適したソリューションとなる可能性があります。 |
| 外部マスタシステム | エラーは、マスタシステムのベストプラクティスに従って処理する必要があります。 |
- Salesforce API への認証された API アクセスを可能にするには、Lightning Platform ライセンスと少なくとも「API 限定」ユーザ権限が必要です。
- パスワードアクセスのセキュリティを確保するために、標準の暗号化を使用することをお勧めします。
- Salesforce API へのコールを行うときには、HTTPS プロトコルを使用します。必要に応じて、オンプレミス型のセキュリティソリューションで Salesforce API へのトラフィックにプロキシを適用することもできます。
補足
このパターンでは、適時性の重要性はそれほど大きくはありません。ただし、インターフェースの設計では、すべてのバッチプロセスが指定されたバッチ時間帯内に完了するように注意する必要があります。
どのバッチ指向操作にも言えることですが、バッチ処理時間帯の間は、供給元システムと供給先システムを隔離することをお勧めします。営業時間内にバッチを読み込むと、何らかの競合が発生し、ユーザの更新が失敗するか、より深刻な事態としてバッチ読み込み (あるいは部分的なバッチ読み込み) が失敗することがあります。
グローバルな事業展開をしている組織の場合、システムは常時使用中であるため、すべてのバッチプロセスを同時には実行できない場合があります。こうした場合、レコードタイプやその他の検索条件を使用したデータセグメント化手法により、データの競合を回避できることがあります。
状態管理を実装するには、2 つのシステム間でサロゲートキーを使用します。Salesforce のエンティティ全体で何らかのトランザクション管理が必要な場合、Apex を使用するリモートコールインパターンを使用することをお勧めします。
- Salesforce は、特定のユーザが編集中のレコードの状態を維持しない。
- 読み取り時、データが抽出された時間を記録する。
- ユーザがレコードを更新して保存すると、Salesforce は、その間に他のユーザがそのレコードを更新していないかチェックする。
- レコードが更新されていた場合、システムはユーザに、更新が行われためレコードの最新バージョンを取得してから更新を続行するように通知する。
このパターンの実装に使用する最も効果的な外部技術は、従来の ETL ツールです。重要なのは、選択するミドルウェアツールが、Salesforce Bulk API をサポートしていることです。
ミドルウェアツールが getUpdated() 関数をサポートしていることは、役には立ちますが、不可欠ではありません。この関数は、Salesforce Platform で標準の変更データキャプチャ機能にきわめて近い実装を提供します。
次の表は、このパターンに使用されるミドルウェアシステムの望ましいプロパティの一覧です。
| プロパティ | 必須 | 望ましい | 不要 |
|---|---|---|---|
| イベント処理 | X | ||
| プロトコル変換 | X | ||
| 変換/加工 | X | X | |
| キューイングとバッファリング | X | ||
| 同期伝送プロトコル | X | ||
| 非同期伝送プロトコル | X | ||
| 仲介ルーティング | X | ||
| プロセスコレオグラフィとサービスオーケストレーション | X | ||
| トランザクション性 (暗号化、署名、信頼できる配信、トランザクション管理) | X | ||
| ルーティング | X | ||
| 抽出、加工、読み込み (ETL) | X | ||
| long polling | X (Salesforce 変更データキャプチャでは必須) |
例
ある公益企業では、メインフレームベースのバッチプロセスを使用して、見込み客を個々の営業担当者とチームに割り当てています。この情報は、夜間処理で Salesforce にインポートする必要があります。
この顧客は、市販の ETL ツールを使用して供給元テーブルの変更データキャプチャを実装することを決定しました。
- cron に似たスケジューラが、一括処理ジョブを実行して見込み客をユーザとチームに割り当てます。
- 一括処理ジョブが実行されてデータが更新された後、ETL ツールが変更データキャプチャを使用してこれらの変更を認識します。ETL ツールが、データストアからの変更を順に並べます。
- ETL コネクタが Salesforce SOAP API を使用して変更を Salesforce に読み込みます。