通常、Salesforce を実装する場合、他のアプリケーションと統合する必要があります。インテグレーションシナリオはそれぞれ異なりますが、開発者とアーキテクトが解決する必要がある共通の要件と問題があります。

このドキュメントでは、次の一般的なインテグレーションシナリオの戦略 (パターン形式) について説明します。各パターンは、特定の実装の詳細を説明するのではなく、特定のシナリオの設計とアプローチを説明します。このドキュメントには、次の内容が記載されています。

• 主要な「アーキタイプ」インテグレーションシナリオに対応する多数のパターン
• シナリオに最も適したパターンを決定するのに役立つ選択マトリックス
• インテグレーションのヒントとベストプラクティス

目的と範囲

このドキュメントは、Salesforce Platform を社内の他のアプリケーションと統合する必要があるデザイナーやアーキテクトを対象としています。このコンテンツは、Salesforce アーキテクトとパートナーによる多くの成功した実装を絞り込んだものです。

Salesforce ベースのアプリケーションの大規模な採用に使用できるインテグレーション機能とオプションについての詳細は、『パターンの概要とパターンの選択ガイド』を参照してください。アーキテクトと開発者は、Salesforce インテグレーションプロジェクトの設計および実装フェーズで、次のパターンの詳細とベストプラクティスを考慮する必要があります。

これらのパターンを適切に実装すれば、本番環境にできるだけ早く移行でき、可能な限り安定性と拡張性が高く、メンテナンスフリーな一連のアプリケーションを使用できます。Salesforce 独自のコンサルティングアーキテクトは、アーキテクチャレビュー時にこれらのパターンを参照点として使用し、積極的に維持および改善します。

すべてのパターンと同様に、このコンテンツではほとんどのインテグレーションシナリオがカバーされますが、すべてはカバーされません。Salesforce では、ユーザーインターフェース (UI) インテグレーションが可能ですが、マッシュアップなどについては、このドキュメントの範囲外です。

パターンテンプレート

各インテグレーションパターンは一貫した構造に従います。これにより、各パターンで提供される情報の一貫性が確保され、パターンの比較も容易になります。

名前

パターンに含まれるインテグレーションの種別も示すパターン識別子。

コンテキスト

パターンで対応する全体的なインテグレーションシナリオ。コンテキストは、ユーザーが何を達成しようとしているか、および要件をサポートするためにアプリケーションがどのように動作するかに関する情報を提供します。

問題

パターンで解決するように設計されたシナリオまたは問題 (質問として表現)。パターンを確認するときは、このセクションを読んで、パターンがインテグレーションシナリオに適しているかどうかをすばやく理解してください。

勢力

示されたシナリオを解決するのを困難にする制約と状況。

ソリューション

インテグレーションシナリオを解決するための推奨方法。

スケッチ

ソリューションがシナリオにどのように対処するかを示す UML シーケンス図。

結果

ソリューションをインテグレーションシナリオに適用する方法の詳細と、そのシナリオに関連する勢力を解決する方法について説明します。このセクションでは、パターンの適用によって発生する可能性のある新しい課題についても説明します。

サイドバー

主要な技術的な問題、パターンのバリエーション、パターン固有の懸念などが含まれる、パターンに関連する追加のセクション。

例

実際の Salesforce シナリオでデザインパターンがどのように使用されるかを説明するエンドツーエンドのシナリオ。この例では、インテグレーションの目標とその目標を達成するためにパターンを実装する方法について説明します。

パターン概要

次の表に、このドキュメントに記載されているインテグレーションパターンを示します。

パターンのリスト remote-process-invocation--request-and-reply

パターンアプローチ

このドキュメントのインテグレーションパターンは、次の 3 つのカテゴリに分類されます。

• データインテグレーション — これらのパターンは、2 つ以上のシステムに存在するデータを同期して、両方のシステムに常にタイムリーで意味のあるデータが含まれるようにする要件に対応します。多くの場合、データインテグレーションは実装する最もシンプルなインテグレーションですが、ソリューションを持続可能でコスト効率の高いものにするには適切な情報管理技術が必要です。このような手法には、多くの場合、マスターデータ管理 (MDM)、データガバナンス、マスター、重複排除、データフロー設計などの側面が含まれます。

• プロセスインテグレーション — このカテゴリのパターンは、ビジネスプロセスが 2 つ以上のアプリケーションを活用して ToDo を完了するというニーズに対応します。この種類のインテグレーションのソリューションを実装する場合、トリガーアプリケーションはプロセスの境界を越えて他のアプリケーションにコールする必要があります。通常、これらのパターンにはオーケストレーション (1 つのアプリケーションが「コントローラー」の中心) と振付 (アプリケーションが複数の関係者であり、中央の「コントローラー」がない) の両方が含まれます。これらのインテグレーションでは、多くの場合、複雑な設計、テスト、例外処理の要件が必要です。また、このような複合アプリケーションは、多くの場合、実行時間の長いトランザクションや、プロセスの状態に関するレポートや管理の機能をサポートしているため、基盤となるシステムに対する要求も高くなります。

• 仮想インテグレーション — このカテゴリのパターンは、外部システムに保存されているデータをユーザーが表示、検索、変更するニーズに対応します。この種別のインテグレーションのソリューションを実装する場合、トリガーアプリケーションは、他のアプリケーションにコールアウトし、そのデータをリアルタイムで操作する必要があります。この種類のインテグレーションにより、システム全体でデータレプリケーションを行う必要がなくなり、ユーザーは常に最新のデータを操作できます。

システムに最適なインテグレーション戦略を選択することは容易ではありません。考慮すべき点や使用できるツールは多数あり、ツールによっては特定の作業に適したものもあります。各パターンは、各システムの機能、データ量、障害処理、トランザクション性など、特定の重要な領域に対応します。

パターン選択ガイド

選択マトリックステーブルには、インテグレーション要件に最も適したパターンを判断するのに役立つパターンとその主要な側面がリストされています。パターンは次のディメンションを使用して分類されます。

Salesforce と別のシステムの統合

次の表は、Salesforce から別のシステムへのインテグレーションの場合に要件に最も適したパターンを判断するのに役立つパターンとその主要な側面を示しています。

別のシステムと Salesforce の統合

次の表は、別のシステムから Salesforce へのインテグレーションの場合に要件に最適なパターンを判断するのに役立つパターンとその主要な側面を示しています。

ミドルウェアの用語と定義

次の表に、ミドルウェアに関連する主要な用語と、それらのパターンの定義を示します。

コンテキスト

Salesforce を使用して、リードの追跡、パイプラインの管理、商談の作成、リードを顧客に変換する注文の詳細の取得を行います。ただし、Salesforce システムには注文は含まれず、処理されません。注文の詳細が Salesforce に取り込まれると、注文がリモートシステムに作成され、そこで完了までの注文が管理されます。

このパターンを実装すると、Salesforce はリモートシステムをコールして注文を作成し、正常に完了するまで待機します。成功すると、リモートシステムは注文状況と注文番号で同期応答します。同じトランザクションの一環として、Salesforce は注文番号と状況を内部で更新します。注文番号は、リモートシステムの後続の更新で外部キーとして使用されます。

問題

Salesforce でイベントが発生したときに、リモートシステムでプロセスを開始し、必要な情報をそのプロセスに渡してリモートシステムから応答を受信し、その応答データを使用して Salesforce 内で更新を行うにはどうすればよいでしょうか?

勢力

このパターンに基づいてソリューションを適用するときは、次の点を考慮してください。

• リモートシステムへのコールで、処理を続行する前に Salesforce が応答を待機する必要がありますか?リモートシステムへのコールは同期要求-応答か非同期要求か?
• リモートシステムへのコールが同期の場合、Salesforce は応答を最初のコールと同じトランザクションの一部として処理する必要がありますか?
• メッセージサイズは小さいか大きいか?
• インテグレーションは、Salesforce ユーザーインターフェースでのボタンのクリックなどの特定のイベントや DML ベースのイベントの発生に基づいていますか?
• リモートエンドポイントは低遅延で要求に応答できますか?ピーク時にこのトランザクションを実行する可能性が高いユーザーの数は?

ソリューション

次の表に、このインテグレーションの問題の解決方法を示します。

スケッチ

次の図は、Apex コールを使用した同期リモートプロセス呼び出しを示しています。

リモートシステムへの Salesforce コールアウト

図のダウンロード

このシナリオの内容は次のとおりです。

• Lightning ページでアクションが開始されます（ボタンのクリックなど）。
• ブラウザ（Lightning コンポーネントの場合はクライアント側コントローラ経由）は HTTP POST を実行し、続いて対応する Apex コントローラでアクションを実行します。
• コントローラーがリモート Web サービスへの実際のコールを呼び出します。
• リモート・システムからの応答が Apex コントローラに返されます。コントローラーは応答を処理し、必要に応じて Salesforce のデータを更新して、ページを再表示します。

後続の状態を追跡する必要がある場合、リモートシステムは Salesforce レコードに保存されている一意の識別子を返します。

結果

このパターンに関連するソリューションの適用により、Salesforce が処理するイベント開始リモートプロセスの呼び出しが可能になります。

コールメカニズム

コールメカニズムは、このパターンを実装するために選択されたソリューションによって異なります。

エラー処理と回復

全体的なソリューションの一部としてエラー処理と回復戦略を含めることが重要です。

• エラー処理 — エラーが発生した場合 (例外またはエラーコードが通話者に返された場合)、通話者がエラー処理を管理します。たとえば、エンドユーザーのページに表示されるエラーメッセージや、追加アクションが必要なテーブルに記録されるエラーメッセージなどです。

• 復旧 — 通話者が応答に成功するまで、変更は Salesforce にコミットされません。たとえば、成功を示す応答を受信するまで、注文状況はデータベースで更新されません。必要に応じて、通話者は操作を再試行できます。

Idempotent Design Considerations (無力な設計に関する考慮事項)

Idempotent 機能は、繰り返しの呼び出しが安全であることを保証します。緊急性が実装されていない場合、同じメッセージを繰り返し呼び出すと結果が異なる可能性があり、データの整合性の問題が発生する可能性があります。潜在的な問題として、重複レコードの作成やトランザクションの重複処理などがあります。

コールされるリモートプロシージャが適切であることを確認することが重要です。ユーザーインターフェースによってコールが行われる場合、特に Salesforce が 1 回しかコールしない保証がない場合は、インテグレーションレイヤーで緊急性を考慮する必要があります。

最も典型的な受信者の作成方法は、コンシューマーが送信した一意のメッセージ識別子に基づいて重複を追跡することです。Apex Web サービスまたは REST コールは、一意のメッセージ ID を送信するようにカスタマイズする必要があります。

また、リモートシステムでレコードを作成する操作では、挿入する前に重複を確認する必要があります。Salesforce から一意のレコード ID を渡して確認します。リモートシステムにレコードが存在する場合は、レコードを更新します。ほとんどのシステムでは、この操作は更新/挿入操作と呼ばれます。

セキュリティに関する考慮事項

リモートシステムへのコールでは、要求の機密性、整合性、可用性を維持する必要があります。次のセキュリティ上の考慮事項は、このパターンでの Apex SOAP および HTTP コールの使用に固有です。

• 一方向 SSL はデフォルトで有効になっていますが、クライアントとサーバーの両方の認証を維持するために、自己署名証明書と CA 署名証明書の両方で双方向 SSL がサポートされます。

• Apex コードを合理化し、認証済みコールアウトの設定を簡略化するには、コールアウト エンドポイントで指定ログイン情報を指定します。

• 外部システムと統合するための認証メカニズムとして OAUTH 2.0 を使用することを検討してください。

• 必要に応じて、要求の整合性を確保するために、Apex Crypto クラスのメソッドを使用して一方向ハッシュまたはデジタル署名を使用することを検討します。

• リモートシステムは、適切なファイアウォールメカニズムを実装して保護する必要があります。「セキュリティの考慮事項」を参照してください。

• 現在、Salesforce では WS-Security はサポートされていません。これらの複雑な WS-Security ヘッダーをネイティブに生成したり、受信 WSDL から自動的に適用したりすることはありませんが、受信要求の SOAP ヘッダーとセキュリティ トークンを処理するカスタム Apex クラスを作成して、手動で作成および実装できます。

サイドバー

なし。

適時性

このパターンでは、タイミングが非常に重要です。通常、次のようになります。

• 通常、要求はユーザーインターフェースから呼び出されるため、このプロセスでユーザーを待たせてはなりません。
• Salesforce では、Apex からのコールに対して最大 120 秒のタイムアウトを設定できます。
• リモートプロセスの完了は、Salesforce タイムアウト制限内およびユーザーの期待の範囲内で完了するように適時に実行されます。
• 外部コールには Apex 同期トランザクション ガバナ制限が適用されるため、実行時間が 5 秒を超えるトランザクションが 50 件以上発生するリスクを軽減してください。外部エンドポイントのパフォーマンスを確保するだけでなく、タイムアウトのリスクを軽減するオプションを次に示します。
  • 外部コールアウトのタイムアウトを 5 秒に設定する。
  • Lightning コンポーネントの継続を使用した実行時間の長いトランザクションの処理

データボリューム

このパターンは、タイムアウト値が小さく、Apex コール ソリューションの要求または応答の最大サイズが小さいため、主に少量のリアルタイム アクティビティで使用されます。メッセージにデータペイロードが含まれる一括処理活動では、このパターンを使用しないでください。

エンドポイントの機能と標準のサポート

エンドポイントの機能と標準サポートは、選択したソリューションによって異なります。

状態管理

システムを統合する場合、キーは継続的な状態追跡で重要です。2 つのオプションがあります。

• Salesforce は、リモートレコードのリモートシステムのプライマリまたは一意の代理キーを保存します。
• リモートシステムには、Salesforce の一意のレコード ID またはその他の一意の代理キーが保存されます。

次の表に示すように、インテグレーションキーの処理には、マスターレコードが含まれるシステムに応じて特定の考慮事項があります。

複雑なインテグレーションのシナリオ

場合によっては、このパターンで規定されたソリューションで、いくつかの複雑なインテグレーションシナリオの実装が必要になることがあります。これは、ミドルウェアを使用するか、Salesforce に複合サービスをコールさせることが最適です。次のシナリオがあります。

• 複雑なフローロジックを含むビジネスプロセスとルールのオーケストレーション
• 複数のシステムへの通話の集計とその結果
• 受信メッセージと送信メッセージの両方の変換
• 複数のシステムへのコール間でトランザクションの整合性を維持する

ガバナ制限

Apex の制限については、『Apex 開発者ガイド』の「Execution Governors and Limits」を参照してください。

ミドルウェア機能

次の表は、このパターンに参加するミドルウェアシステムの望ましいプロパティを示しています。

例

ある公益事業会社は Salesforce を使用しており、顧客の請求情報を含む別のシステムを使用しています。注文プロセスの一環として、新しい請求取引先を請求システムで作成する必要があります。また、Salesforce は注文の有効化プロセス内で Billing 取引先番号を反映する必要があります。請求取引先の作成を許可し、応答として請求取引先番号を返す既存の Web サービスがあります。

この要件は、次の方法で達成できます。

1. Salesforce は、Apex プロキシ クラスから Billing Account Service WSDL を使用します。
2. カスタム Apex コントローラまたは外部サービスから外部 Web サービスに渡される顧客情報を使用して、Apex プロキシ クラスを実行します。
3. 次に、カスタム コントローラは Apex コールアウトからの戻り値を解析し、その情報を salesforce オブジェクトに保存します。

この例は、次のことを示しています。

• 顧客の状態は、Salesforce 取引先オブジェクトに保存されている取引先番号で追跡されます。
• 通話者による返信メッセージの後続の処理

コンテキスト

Salesforce を使用して、リードの追跡、パイプラインの管理、商談の作成、リードを顧客に変換する注文の詳細の取得を行います。ただし、注文管理プロセスの一環として、注文の請求システムで請求取引先を作成する必要があります。

このパターンを実装すると、Salesforce はリモートシステムをコールして請求取引先を作成しますが、通話の正常な完了は待機しません。必要に応じて、リモートシステムは個別のトランザクションで作成された新しい請求取引先で Salesforce を更新できます。

問題

Salesforce でイベントが発生したときに、リモートシステムでプロセスを開始し、リモートシステムからの応答を待たずに必要な情報をそのプロセスに渡す方法は?

勢力

このパターンに基づいてソリューションを適用するときは、次の点を考慮してください。

• リモートシステムへのコールで、処理を続行する前に Salesforce が応答を待機する必要がありますか?リモートシステムへのコールは同期か非同期か?
• リモートシステムへのコールが同期の場合、Salesforce でコールと同じトランザクションの一部として応答を処理する必要がありますか?
• メッセージサイズが小さいか?
• インテグレーションは、Salesforce ユーザーインターフェースでのボタンのクリックなどの特定のイベントや DML ベースのイベントの発生に基づいていますか?
• Salesforce からリモートシステムへのメッセージ配信の保証は必要ですか?
• リモートシステムは、Salesforce が契約を指定する契約優先インテグレーションに参加できますか?一部のソリューションバリエーション (アウトバウンドメッセージングなど) では、Salesforce によってリモートシステムエンドポイントが実装する契約が指定されます。
• エンドポイントまたはエンタープライズサービスバス (ESB) でロングポーリングはサポートされていますか?
• カスタムApex開発よりも宣言型構成方法が優先されますか?この場合、Apex コールアウトよりもプラットフォームイベントなどのソリューションが優先されます。

ソリューション

次の表に、このインテグレーションの問題の解決方法を示します。

スケッチ

次の図は、Salesforce からリモートシステムへのコールを示しています。このコールでは、レコードに対する操作を作成または更新するとコールがトリガーされます。

図のダウンロード

このシナリオの内容は次のとおりです。

1. リモートシステムがプラットフォームイベントに登録します。
2. Salesforce の特定のレコードセットで更新または挿入が実行されます。
3. 一連の条件が満たされると、Salesforce フローがトリガーされます。
4. このフローでは、プラットフォームイベントが作成されます。
5. リモートリスナーはイベントメッセージを受信し、メッセージをローカルキューに配置します。
6. キューイングアプリケーションがメッセージをリモートアプリケーションに転送して処理します。

リモートシステムが Salesforce に対して操作を実行する必要がある場合は、省略可能なコールバック操作を実装できます。

結果

このパターンに関連するソリューションの適用により、次のことが可能になります。

• ユーザーインターフェース – トランザクションの結果をエンドユーザーに表示できるリモートプロセスの呼び出し
• コール元プロセスでトランザクションの結果を処理できる DML イベント開始リモートプロセスの呼び出し

コールメカニズム

コールメカニズムは、このパターンを実装するために選択されたソリューションによって異なります。

エラー処理と回復

エラー処理と回復戦略は、ソリューション全体の一部として考慮する必要があります。最適な方法は、選択したソリューションによって異なります。

Idempotent Design Considerations (無力な設計に関する考慮事項)

プラットフォームイベントは 1 回のみバスに公開されます。Salesforce 側での再試行はありません。イベントの再実行の要求は ESB に任されます。リプレイでは、プラットフォームイベントのリプレイ ID は同じままで、ESB はリプレイ ID に基づいて重複メッセージを試行できます。

即時性は非同期であり、肯定的な確認が受信されなかったときに再試行が開始されるため、アウトバウンドメッセージングでは重要です。そのため、リモートサービスは Salesforce からのメッセージを適切に処理できる必要があります。

アウトバウンドメッセージングでは、メッセージごとに一意の ID が送信され、この ID は再試行で同じままです。リモートシステムは、この一意の ID に基づいて重複メッセージを追跡できます。更新される各レコードの一意のレコード ID も送信され、重複するレコードの作成を防止できます。

「Remote Process Invocation — Request and Reply (リモートプロセス呼び出し — 要求と返信)」パターンの設計上の考慮事項は、このパターンにも適用されます。

セキュリティに関する考慮事項

リモートシステムへのコールでは、要求の機密性、整合性、可用性を維持する必要があります。選択したソリューションに応じて、異なるセキュリティ上の考慮事項が適用されます。

「セキュリティの考慮事項」を参照してください

サイドバー

なし。

適時性

タイムリーさは、火と忘れのパターンでは影響しません。制御は、リモートシステムへの引き継ぎが成功した直後に、または確認応答後にクライアントに渡されます。Salesforce アウトバウンドメッセージングでは、確認は 24 時間以内に行う必要があります (最大 7 日間まで延長できます)。それ以外の場合、メッセージは期限切れになります。プラットフォームイベントの場合、Salesforce はイベントをイベントバスに送信し、登録者からの確認や確認を待機しません。登録者がメッセージを受信しない場合、登録者はイベント返信 ID を使用してイベントの再実行を要求できます。大規模イベントメッセージは 72 時間 (3 日) 保存されます。過去のイベントメッセージを取得するには、CometD クライアントを使用してチャネルを登録します。

データボリューム

データ量に関する考慮事項は、選択するソリューションによって異なります。各ソリューションの制限については、「Salesforce 制限クイックリファレンス」を参照してください

エンドポイントの機能と標準のサポート

エンドポイントの機能と標準サポートは、選択したソリューションによって異なります。

状態管理

システムを統合する場合、一意のレコード識別子は継続的な状態追跡で重要です。たとえば、リモートシステムでレコードが作成された場合、2 つのオプションがあります。

• Salesforce は、リモートレコードのリモートシステムのプライマリまたは一意の代理キーを保存します。
• リモートシステムには、Salesforce の一意のレコード ID またはその他の一意の代理キーが保存されます。

次の表に、このパターンの状態管理に関する考慮事項を示します。

複雑なインテグレーションのシナリオ

このパターンの各ソリューションでは、変換やプロセスオーケストレーションなどの複雑なインテグレーションシナリオに関する考慮事項が異なります。

ガバナ制限

Salesforce Platform のマルチテナントの性質上、アウトバウンドコールアウトには制限があります。制限は、発信通話の種別と通話のタイミングによって異なります。

プラットフォームイベントに適用される制限と割り当てについては、『Platforms Events Developer Guide』を参照してください。

信頼できるメッセージング

信頼性のあるメッセージングでは、個々のコンポーネントの信頼性が低いリモートシステムへのメッセージの配信を保証するという問題を解決しようとします。リモートシステムでメッセージを受信できるようにする方法は、選択したソリューションによって異なります。

Salesforce 変更データキャプチャの場合、Salesforce アプリケーションサーバーで捕捉されない変更のキャプチャや大量の変更の処理など、特殊な状況を処理するために変更イベント種別が用意されています。

場合によっては、Salesforce は変更イベントの代わりにギャップイベントを送信して、登録者にエラーを通知したり、変更イベントを生成できない場合に通知したりします。ギャップイベントには、変更種別やレコード ID など、ヘッダーの変更に関する情報が含まれます。レコード項目など、変更に関する詳細は含まれません。変更をより効率的に取得するために、しきい値を超える 1 つのトランザクションに対してオーバーフローイベントが生成されます。詳細については、こちらを参照してください。

ミドルウェア機能

次の表は、このパターンに参加するミドルウェアシステムの望ましいプロパティを示しています。

ソリューションバリエーション — プラットフォームイベント Behavior and Transactions (公開動作とトランザクション)

プラットフォームイベントメッセージがすぐに公開される場合、イベント公開では公開プロセスのトランザクション境界が考慮されません。イベントメッセージは、トランザクションが完了する前に、またはトランザクションが失敗した場合でも公開できます。この動作により、登録者が公開トランザクションで確定されたデータの検索を期待すると問題が発生する可能性があります。登録者がイベントメッセージを受信したときにデータが存在しない場合があります。この問題を解決するには、イベント定義でプラットフォームイベントの公開動作を [コミット後に公開] に設定します。プラットフォームイベント定義で設定できる公開動作は次のとおりです。

• [コミット後に公開]: トランザクションが正常にコミットされた後にのみイベントメッセージを公開します。公開トランザクションがコミットするデータにサブスクライバーが依存している場合、このオプションを選択します。たとえば、あるプロセスがイベントメッセージを公開し、ToDo レコードを作成するとします。そのイベントに登録している 2 つ目のプロセスは起動したときに ToDo レコードがあることを想定しています。この動作を選択するもう 1 つの理由は、トランザクションが失敗した場合にイベントメッセージを公開したくない場合です。
• すぐに公開: 公開コールの実行時にイベントメッセージを公開します。トランザクションが成功したかどうかに関係なくイベントメッセージを公開する場合、このオプションを選択します。また、公開者と登録者が独立していて、登録者が公開者によってコミットされたデータに依存していない場合もこのオプションを選択します。たとえば、記録目的で使用されるイベントにはすぐに公開する動作が適しています。このオプションを使用すると、パブリッシャートランザクションによってデータがコミットされる前に、登録者がイベントメッセージを受信できます。

例

ある通信会社は、リード-to-商談プロセスを使用して取引先を作成するためのフロントエンドとして Salesforce を使用したいと考えています。商談が成立して成立したときに Salesforce で注文が作成されますが、バックエンドの ERP システムがデータマスターです。注文を Salesforce 商談レコードに保存する必要があります。また、注文が作成されたことを示すように商談の状況が変更されます。

次の制約が適用されます。

• 実装できるのは宣言型開発のみです。
• 商談が注文に変換された後に注文番号をすぐに通知する必要はありません。
• 組織に CometD プロトコルをサポートする ESB があり、プラットフォームイベントを登録できます。

この例は Salesforce プラットフォームイベントを使用して実装するのが最適ですが、ESB がプラットフォームイベントに登録する必要があります。

Salesforce 側:

• プラットフォームイベントを開始するフローを作成します (商談の状況が商談成立に変更された場合など)。
• 商談の詳細を公開する新しいプラットフォームイベントを作成します。

リモートシステム側:

• ESB は CometD プロトコルを使用して Salesforce Platform イベントに登録します。
• ESB は、商談が注文に変換されることを示す 1 つ以上の通知を受信します。
• 注文を作成できるように、ESB がメッセージをバックエンドの ERP システムに転送します。
• 注文が ERP システムで作成されると、別のスレッドが SessionId を認証トークンとして使用して Salesforce にコールバックします。コールバックは、注文番号と状況で商談を更新します。このコールバックは、Salesforce Platform イベント、Salesforce SOAP API、REST API、Apex Web サービスなどのドキュメント化されたパターンソリューションを使用して実行できます。

この例は、次の内容を示しています。

• 非同期で呼び出されるリモートプロセスの実装
• エンドツーエンドの配送保証
• レコードの状態を更新する Salesforce への後続のコールバック

コンテキスト

CRM 実装を Salesforce に移行するときに、次のことを行う必要があります。

• 現在の CRM システムから取引先、取引先責任者、商談を抽出して変換し、データを Salesforce に読み込みます (初期データインポート)。
• 毎週 (継続的に) リモートシステムから顧客請求データを抽出、変換し、Salesforce に読み込みます。
• Salesforce から顧客活動情報を抽出し、週次 (継続) でオンプレミスデータウェアハウスにインポートします。

問題

Salesforce へのデータのインポートと Salesforce からのデータのエクスポートは、営業時間中にエンドユーザーの業務に干渉し、大量のデータが含まれる可能性があることを考慮して、どのように行いますか?

勢力

このパターンに基づいてソリューションを適用するときには、さまざまな考慮が必要です。

• データは Salesforce に保存する必要がありますか?そうでない場合、アーキテクトが考慮できるインテグレーションオプションや考慮すべきインテグレーションオプションが他にもあります (マッシュアップなど)。
• データを Salesforce に保存する必要がある場合、リモートシステムのイベントに応じてデータを更新する必要がありますか?
• データをスケジュールに従って更新する必要がありますか?
• データで主要なビジネスプロセスがサポートされているか?
• Salesforce でこのデータを使用できるかどうかによって影響を受ける分析 (レポート) 要件はありますか?

ソリューション

次の表に、このインテグレーション問題のさまざまな解決策を示します。

スケッチ

次の図は、Salesforce がデータマスターであるこのパターンの一連のイベントを示しています。

図のダウンロード

次の図は、Salesforce がデータマスターである場合のほぼリアルタイムのイベントの後続の同期を示しています。

結果

次のシナリオでは、外部ソースのデータを Salesforce と統合できます。

• 外部システムがデータマスター — Salesforce は、1 つのソースシステムまたは複数のシステムによって提供されるデータのコンシューマーです。このシナリオでは、データを Salesforce にインポートする前にデータを集計するデータウェアハウスまたはデータマートを使用するのが一般的です。
• Salesforce はデータマスターです。Salesforce は特定のエンティティの記録システムであり、Salesforce 変更データキャプチャアプリケーションは Salesforce データへの変更を通知できます。

一般的な Salesforce インテグレーションシナリオでは、実装チームは次のいずれかを実行します。

• ソースデータセットに変更データキャプチャを実装します。
• 一連のサポートデータベース構造 (制御テーブル) を中間のオンプレミスデータベースに実装します。

次に、ETL ツールを使用して次のプログラムを作成します。

1. 制御テーブルを参照して、ジョブの最終実行時刻を判断し、必要な他の制御値を抽出します。
2. 上記の制御値を検索条件として使用し、ソースデータセットを照会します。
3. 入力規則、強化規則など、定義済みの処理ルールを適用します。
4. ETL ツールの使用可能なコネクタ/変換機能を使用して、対象データセットを作成します。
5. データセットを Salesforce オブジェクトに書き込みます。
6. 処理が成功したら、制御テーブルの制御値を更新します。
7. 処理に失敗した場合は、再起動と終了を有効にする値で制御テーブルを更新します。

メモ にアクセスできない場合でも、ETL ツールがアクセスできる環境で制御テーブルと関連データ構造を作成することをお勧めします。これにより、十分なレベルの復元力が得られます。このプロセスでは Salesforce をスポークとして扱い、ETL インフラストラクチャをハブにします。

ETL ツールでデータ同期機能を最大限に活用するには、次の点を考慮してください。

• ETL ジョブをチェーニングおよび順序付けして、一貫性のあるプロセスを提供します。
• 両方のシステムの主キーを使用して、受信データを照合します。
• 特定の API メソッドを使用して、更新されたデータのみを抽出します。
• 主従関係または参照関係で子レコードをインポートする場合、ロックされないように、インポートしたデータをソースの親キーを使用してグループ化します。たとえば、取引先責任者データをインポートする場合は、1 つの取引先の取引先責任者の最大数を 1 回の API コールで読み込むことができるように、必ず親取引先キーで取引先責任者データをグループ化してください。通常、インポートしたデータをグループ化しないと、最初の取引先責任者レコードが読み込まれ、その取引先の後続の取引先責任者レコードが API コールのコンテキストで失敗します。
• トリガーなどのインポート後の処理では、データのみを選択的に処理する必要があります。
• シナリオに大量のデータが含まれる場合は、この Trailhead モジュール「 Best Practices for Deployments with Large Data Volumes 」のベストプラクティスに従ってください。
をクリックします。

エラー処理と回復

エラー処理と回復戦略は、ソリューション全体の一部として考慮する必要があります。最適な方法は、選択したソリューションによって異なります。

セキュリティに関する考慮事項

リモートシステムへのコールでは、要求の機密性、整合性、可用性を維持する必要があります。選択したソリューションに応じて、異なるセキュリティ上の考慮事項が適用されます。

• Salesforce APIへの認証済みAPIアクセスを許可するには、「APIのみ」以上のユーザー権限を持つLightning Platformライセンスが必要です。
• パスワードアクセスの安全性を維持するために、標準の暗号化を使用することをお勧めします。
• Salesforce API をコールするときは、HTTPS プロトコルを使用します。必要に応じて、オンプレミスセキュリティソリューションを介して Salesforce API へのトラフィックをプロキシすることもできます。

「セキュリティの考慮事項」を参照してください。

サイドバー

なし。

適時性

このパターンでは適時性は重要ではありません。ただし、すべての一括処理が指定された一括処理ウィンドウで完了するようにインターフェースを設計する必要があります。

すべてのバッチ指向の操作と同様に、バッチ処理ウィンドウ中にソースシステムと対象システムを分離することを強くお勧めします。営業時間中にバッチを読み込むと競合が発生し、ユーザーの更新に失敗するか、バッチの読み込み (または部分的なバッチの読み込み) に失敗する可能性があります。

グローバルに業務を行っている組織では、システムが継続的に使用されている可能性があるため、すべての一括処理を同時に実行できない場合があります。このような場合は、レコードタイプやその他の検索条件を使用したデータセグメンテーション手法を使用して、データの競合を回避できます。

状態管理

2 つのシステム間で代理キーを使用して状態管理を実装できます。Salesforce エンティティ間で何らかの種別のトランザクション管理が必要な場合は、Apex を使用したリモート コールイン パターンを使用することをお勧めします。

標準の楽観的レコードロックはプラットフォームで実行され、API を使用して更新する場合は、レコードを編集しているユーザーがレコードを更新してトランザクションを開始する必要があります。Salesforce API のコンテキストでは、楽観的ロックとは、次の状況のプロセスを指します。

• Salesforce では、特定のユーザーが編集しているレコードの状態は保持されません。
• 参照時に、データが抽出された時刻が記録されます。
• ユーザーがレコードを更新して保存すると、Salesforce は別のユーザーがそのレコードを更新しているかどうかを確認します。
• レコードが更新されている場合、更新が行われたことがユーザーに通知され、ユーザーは更新を続行する前に最新バージョンのレコードを取得する必要があります。

ミドルウェア機能

このパターンの実装に最も効果的な外部技術は、従来の ETL ツールです。選択するミドルウェアツールで Salesforce Bulk API がサポートされていることが重要です。

ミドルウェアツールで getUpdated() 関数がサポートされていることは有用ですが、重要ではありません。この関数は、Salesforce Platform の標準の変更データキャプチャ機能に最も近い実装を提供します。

次の表は、このパターンに参加するミドルウェアシステムの望ましいプロパティを示しています。

例

公益事業会社は、見込み客を個々の営業担当やチームに割り当てるメインフレームベースの一括処理を使用します。この情報は、夜間に Salesforce にインポートする必要があります。

顧客が、市販の ETL ツールを使用してソーステーブルに変更データキャプチャを実装することを決定した。このソリューションは、次のように動作します。

• cron のようなスケジューラーは、見込み客をユーザーとチームに割り当てる一括処理ジョブを実行します。
• 一括処理ジョブが実行されてデータが更新されると、ETL ツールは変更データキャプチャを使用してこれらの変更を認識します。ETL ツールは、データストアからの変更を照合します。
• ETL コネクタでは、Salesforce REST API を使用して変更を Salesforce に読み込みます。

コンテキスト

Salesforce を使用して、リードの追跡、パイプラインの管理、商談の作成、リードを顧客に変換する注文の詳細の取得を行います。Salesforce システムは内部で注文を作成し、そのデータを外部請求システムに転送してプロビジョニングと有効化を行います。請求注文は外部 (リモート) システムで管理されます。請求システム状況の注文または請求エンティティが変更された場合、そのリモートシステムは Salesforce で注文状況を更新する必要があります。

問題

リモートシステムが Salesforce に接続して認証し、外部イベントについて Salesforce に通知したり、レコードを作成したり、既存のレコードを更新したりする方法は?

勢力

このパターンに基づいてソリューションを適用するときには、さまざまな考慮が必要です。

• Salesforce へのリモートコールの目的は、イベント駆動型アーキテクチャを使用して外部で発生したイベントを Salesforce に通知することですか?または、特定のレコードに対して CRUD 操作を実行する目的ですか?イベント駆動型アーキテクチャを使用している場合、イベントプロデューサー (リモートプロセス) は Salesforce イベントコンシューマーから分離されます。
• Salesforce へのコールでは、処理を続行する前にリモートプロセスが応答を待機する必要がありますか?Salesforce へのリモートコールは常に同期要求-応答ですが、非同期コールをシミュレートする必要がない場合、リモートプロセスで応答を破棄できます。
• 各トランザクションは 1 つの Salesforce オブジェクトに対して実行されますか? 複数の関連オブジェクトに対して実行されますか?
• メッセージの形式は? (SOAP または REST、あるいは両方を HTTP 経由など)
• メッセージサイズは比較的小さいか大きいか?
• リモートシステムが SOAP 対応の場合、Salesforce によって契約が指示される契約優先アプローチにリモートシステムが参加できますか?これは、SOAP API が使用され、定義済みの WSDL が提供されている場合に必要です。
• トランザクション処理は必要ですか?
• Salesforce でのカスタマイズに対する許容範囲は?

ソリューション

次の表に、このインテグレーションの問題に対するさまざまな解決策を示します。

スケッチ

次の図は、外部イベントからの通知用の REST API または Salesforce オブジェクトを照会するための SOAP API のいずれかを使用してこのパターンを実装した場合のイベントの順序を示しています。REST API を使用する場合、イベントの順序は同じです。

SOAP API を使用したリモートシステムによる Salesforce の照会

REST API を介したイベントを使用した Salesforce へのリモートシステム通知

結果

イベント駆動型アーキテクチャでは、リモートシステムは SOAP API、REST API、または Bulk API 2.0 を使用して Salesforce にコールし、イベントを Salesforce イベントバスに公開します。イベントを公開すると、すべての登録者に通知されます。イベント サブスクライバは、フロー、Lightning コンポーネント、Apex トリガーなどの Salesforce Platform 上に存在できます。イベント登録者は、CometD 登録者などの Salesforce Platform の外部にすることもできます。

Salesforce オブジェクトを直接操作する場合、このパターンに関連するソリューションでは次のことができます。

• リモートシステムは、Salesforce API をコールしてデータベースを照会し、単一オブジェクト操作 (作成、更新、削除など) を実行します。
• 一連のオブジェクト操作を実行するために Salesforce REST API 複合リソースをコールするリモートシステム。
• マルチオブジェクトトランザクション操作とカスタム前/後処理ロジックをサポートできるカスタム組み込み Salesforce API (サービス) をコールするリモートシステム。

コールメカニズム

コールメカニズムは、このパターンを実装するために選択されたソリューションによって異なります。

エラー処理と回復

エラー処理と回復戦略は、ソリューション全体の一部として考慮する必要があります。

• エラー処理 — すべてのリモートコールインメソッド (標準 API またはカスタム API) では、タイムアウトや再試行の管理など、後続のエラーをリモートシステムで処理する必要があります。ミドルウェアを使用して、エラー処理と回復のロジックを提供できます。
• リカバリ — サービス品質の要件によってカスタム再試行メカニズムを作成する必要があります。この場合、最適な設計特性を確保することが重要です。プラットフォームイベントにより、登録者は再生 ID を使用して、メッセージの公開後一定期間内にメッセージを取得できます。

Idempotent Design Considerations (無力な設計に関する考慮事項)

Idempotent 機能は、繰り返しの呼び出しが安全で、悪影響がないことを保証します。イデムポテンシーが実装されていない場合、同じメッセージを繰り返し呼び出すと結果が異なる可能性があり、重複レコードの作成やトランザクションの重複処理など、データの整合性の問題が発生する可能性があります。

リモートシステムは、エラーやタイムアウトが発生した場合に複数の (重複する) コールを管理して、重複する挿入や冗長な更新を回避する必要があります (特にダウンストリームトリガーやワークフロールールが起動される場合)。これらの状況の一部は Salesforce 内で管理できますが (特にカスタム SOAP および REST サービスの場合)、エラー処理と適切な設計はリモートシステム (またはミドルウェア) で管理することをお勧めします。

セキュリティに関する考慮事項

選択したパターンソリューションに応じて、異なるセキュリティ上の考慮事項が適用されます。いずれの場合も、プラットフォームではログインユーザーのアクセス権 (プロファイル設定、共有ルール、権限セットなど) が使用されます。また、プロファイル IP 制限を使用して、特定の IP アドレス範囲で API へのアクセスを制限できます。

「セキュリティの考慮事項」を参照してください。

サイドバー

なし。

適時性

SOAP API と Apex Web サービス API は同期です。次のタイムアウトが適用されます。

• セッションタイムアウト — Salesforce 組織のセッションタイムアウト設定に基づいて活動がない場合、セッションはタイムアウトします。
• クエリタイムアウト — 各 SOQL クエリには 120 秒の個々のタイムアウト制限があります。

データボリューム

データ量に関する考慮事項は、選択したソリューションとコミュニケーション種別によって異なります。

エンドポイントの機能と標準のサポート

エンドポイントの機能と標準サポートは、選択したソリューションによって異なります。

状態管理

システムを統合する場合、キーは継続的な状態追跡で重要です。たとえば、リモートシステムでレコードが作成された場合、そのレコードの継続的な更新をサポートします。次の 2 つのオプションがあります。

• Salesforce は、リモートレコードのリモートシステムのプライマリまたは一意の代理キーを保存します。
• リモートシステムには、Salesforce の一意のレコード ID またはその他の一意の代理キーが保存されます。この同期パターンでのインテグレーションキーの処理には、特定の考慮事項があります。

複雑なインテグレーションのシナリオ

このパターンの各ソリューションでは、変換やプロセスオーケストレーションなどの複雑なインテグレーションシナリオを処理するときの考慮事項が異なります。

ガバナ制限

Salesforce Platform のマルチテナントの性質上、API を使用する場合には制限があります。

信頼できるメッセージング

信頼性のあるメッセージングでは、個々のコンポーネント自体が信頼性が低い可能性があるリモートシステムへのメッセージの配信を保証するという問題を解決しようとします。Salesforce SOAP API と REST API は同期的であり、それ自体が信頼できるメッセージングプロトコル (WS-ReliableMessaging など) を明示的にサポートしません。

エラーとタイムアウトのシナリオが正常に管理されるように、リモートシステムに信頼性の高いメッセージングシステムを実装することをお勧めします。外部システムからのプラットフォームイベントの公開は Salesforce API に依存するため、SOAP API と REST API について同じ考慮事項が適用されます。

ミドルウェア機能

次の表は、次のパターンに関与するミドルウェアシステムの特性を示しています。

例

ある印刷用品およびサービス会社は、Salesforce をフロントエンドとして使用して、プリンター用品と注文を作成および管理しています。プリンターを表す Salesforce 納入商品レコードは、クライアントサイトのプリンターを定期的に監視する社内プリンター管理システム (PMS) の印刷利用状況統計 (インク状況、用紙レベル) で定期的に更新されます。設定されたしきい値に達すると(インク残量が少なくなったり、用紙の空レベルが 30%未満になったりした場合など)、イベントに関連する複数のアプリケーション/プロセス(変数)に通知され、メールまたは Chatter アラートが送信され、注文レコードが作成されます。PMS には Salesforce ID が保存されます (Salesforce はアセットレコードマスターです)。

次の制約が適用されます。

• PMS は、Salesforce が契約を提供し、PMS が Salesforce サービス (Enterprise WSDL または Partner WSDL で定義) のクライアント (コンシューマー) として機能する契約優先インテグレーションに参加できます。
• Salesforce でカスタム開発を行うことはできません。

この例は、Salesforce SOAP API または REST API を使用してイベントを公開し、Salesforce で宣言型自動化 (フロー) を実装するのに最適です。プラットフォームイベントを使用する主な理由は、変数と無制限の登録者数です。ただし、注文などのレコードの有限リストを簡単に更新する場合は、SOAP または REST API を使用してレコードを更新します。

Salesforce:

• Salesforce でプラットフォームイベントを定義し、PMS からの通知データを含めます。
• プリンターイベント通知によってトリガーされるフローを作成します。このプロセスでは、プリンター納入商品が更新され、注文が作成されます (自動起動フローを使用)。
• Enterprise WSDL または Partner WSDL をダウンロードしてリモートシステムに提供します。

リモートシステムの場合:

• Enterprise WSDL または Partner WSDL からクライアントスタブを作成します。
• インテグレーションユーザーのログイン情報を使用して (OAuth Web サーバーまたはベアラートークンフローを介して) Salesforce に対して認証します。
• プリンター状況イベントが発生すると、PMS は API をコールしてプリンター状況プラットフォームイベント (プリンター使用状況統計を含む) を作成します。Salesforce イベントバスは、フロー登録者と他のすべての登録者に通知します。

プラットフォームイベントを使用すると、イベントバスで大規模プラットフォームイベントのイベントを 72 時間再生できます。ミドルウェアソリューションを使用してこれらのイベントを公開すると、公開側でエラー処理を組み込むことができます。ただし、より高い信頼性が必要な場合は、登録側でエラー処理を実装できます。

この例は、次の内容を示しています。

• Salesforce 同期 API クライアント (コンシューマー) の実装。
• プラットフォームイベントを公開するための Salesforce へのコールバック (以前に説明した要求/返信プラットフォームイベントパターンと一致)。

コンテキスト

Salesforce を使用して顧客のケースを管理します。カスタマーサービス担当がケースについて顧客と電話している。顧客が支払を行い、カスタマーサービス担当者は支払処理アプリケーションから Salesforce アプリケーション内のリアルタイムの更新を確認し、顧客が注文の未払い金額を正常に支払ったことを示す必要があります。

問題

Salesforce でイベントが発生したときに、画面を更新しなくても、作業を失うことなく Salesforce ユーザーインターフェースでユーザーに通知できる方法は?

勢力

このパターンに基づいてソリューションを適用するときには、さまざまな考慮が必要です。

• アクションの対象となるデータは Salesforce に保存する必要がありますか?
• このデータを表示するカスタムユーザーインターフェースレイヤーを作成できますか?
• カスタムユーザーインターフェースを呼び出すためのアクセス権をユーザーに付与しますか?

ソリューション

このインテグレーションの問題に対する推奨される解決策は、Salesforce でほぼリアルタイムのイベントを実現するプラットフォームイベントを使用することです。プラットフォームイベントは、Salesforce オブジェクトに依存しない構造化された柔軟なペイロードを提供します。また、再生期間が 72 時間の耐久性のあるトピックも確保されます。これにより、オフラインコンシューマーが後で使用可能になった場合でも、イベントを使用できます。このソリューションは、次のコンポーネントで構成されています。

• トピックに関するプラットフォーム イベントをパブリッシュするロジックを含む Apex トリガーまたはフロー
• Apex トリガーまたはフローからイベントをパブリッシュできるトピック
• ユーザー・インタフェースで使用できるBayeuxプロトコル（現在の CometD ）の JavaScript ベースの実装
• Lightning コンポーネント
• 静的リソースとして含まれる JavaScript ライブラリ

スケッチ

次の図は、Salesforce ユーザーインターフェースに通知をストリーミングするためのストリーミング API の実装方法を示しています。これらの通知は、Salesforce のレコードの変更によってトリガーされます。

データ変更によってトリガーされる Salesforce の UI 更新

結果

利点

このパターンに関連するソリューションの適用には、次の利点があります。

• カスタムポーリングメカニズムを記述する必要がなくなる
• ユーザーが開始するフィードバックループが不要

サポートされない要件

このソリューションには次の制限事項があります。

• 通知の配信は保証されません。
• 通知の順序は保証されません。
• 通知は、Bulk API によって行われたレコードの変更からは生成されません。

セキュリティに関する考慮事項

標準の Salesforce 組織レベルセキュリティに準拠しています。HTTPS プロトコルを使用してストリーミング API に接続することをお勧めします。「セキュリティの考慮事項」を参照

サイドバー

最適なソリューションは、Salesforce でカスタムユーザーインターフェースを作成することです。カスタムユーザーインターフェースの表示に使用できる適切なユーザーインターフェースコンテナを考慮する必要があります。サポートされるブラウザーは、『Streaming API Developer Guide (ストリーミング API 開発者ガイド)』に記載されています。

例

ある通信会社は、Salesforce を使用して顧客のケースを管理しています。カスタマーサービスマネージャーは、カスタマーサービス担当者の 1 人がケースを正常にクローズしたときに通知を受け取りたいと考えています。

このパターンで規定されたソリューションを実装する場合、お客様は次のことを行う必要があります。

• 状況が「Closed」で解決が「Successful」のケースが保存されるときにプラットフォームイベントを送信する Apex Trigger PushTopic を作成します。
• カスタマーサービスマネージャーが使用できるカスタムユーザーインターフェースを作成します。このユーザーインターフェースは、プラットフォームイベントを使用するイベントバスに登録します。
• そのマネージャーのカスタマーサービス担当が生成したアラートを表示するロジックをカスタムユーザーインターフェースに実装します。

コンテキスト

Salesforce を使用して、リードの追跡、パイプラインの管理、商談の作成、リードを顧客に変換する注文の詳細の取得を行います。ただし、Salesforce は注文を格納または処理するシステムではありません。注文は外部 (リモート) システムで管理されます。ただし、営業担当は、外部システムを学習したり使用したりすることなく、Salesforce でリアルタイムの注文情報を表示および更新したいと考えています。

問題

Salesforce では、外部システムから Salesforce にデータを移動せずに、Salesforce の外部に保存されているデータを表示、検索、変更する方法は?

勢力

このパターンに基づいてソリューションを適用するときには、さまざまな考慮が必要です。

• Salesforce で宣言型/ポイント & クリック型の送信インテグレーションまたは UI マッシュアップを作成しますか?
• Salesforce 組織にコピーしたくない大量のデータがありますか?
• 少量のリモートシステムデータにいつでもアクセスする必要がありますか?
• 最新データへのリアルタイムアクセスが必要ですか?
• データをクラウドまたはバックオフィスシステムに保存しますが、Salesforce 組織でそのデータを表示または処理する必要がありますか?
• Salesforce への特定の種別のデータの保存に関してデータレジデンシーの懸念がありますか?

ソリューション

次の表に、このインテグレーション問題のさまざまな解決策を示します。

スケッチ

次の図は、Salesforce Connect を使用して、Odata アダプタを使用して外部システムからデータを取り込む方法を示しています。

このシナリオの内容は次のとおりです。

1. ブラウザーは AJAX コールを実行し、続いて対応する外部オブジェクトアダプターでアクションを実行します。
2. アダプタはアクションを Odata 要求に変換し、インテグレーション層とサービス層を介してリモートシステムに対して HTTP GET 要求を実行します。
3. リモートシステムはインテグレーションレイヤーとサービスレイヤーを介して JSON 応答を Salesforce に返します。
4. 応答は Odata から外部オブジェクトに変換され、ブラウザに返されます。

結果

このパターンに関連するソリューションの適用により、エンドユーザーにトランザクションの結果を表示するユーザーインターフェースの起動が可能になります。

コールメカニズム

コールメカニズムは、このパターンを実装するために選択されたソリューションによって異なります。

エラーハンドリング

全体的なソリューションの一部としてエラー処理を含めることが重要です。エラーが発生した場合 (例外またはエラーコードがコール元に返された場合)、コール元がエラー処理を管理します。Salesforce Connect Validatorは、一般的なクエリを実行し、エラーの種類と失敗の原因を把握できる無料のツールです。

利点

Salesforce Connect ソリューションを使用するメリットには、次のようなものがあります。

• このソリューションでは、Salesforce のデータストレージは消費されません。
• ユーザーは、外部システムと Salesforce 間で定期的にデータを同期することを心配する必要はありません。
• Odataまたは組織間アダプターを使用して、またはカスタムApexアダプターを使用して最小限のコードで迅速に実行できる宣言型設定。
• ユーザーは、外部オブジェクトの形式でカスタムオブジェクトとほぼ同じ機能を使用して外部データにアクセスできます。
• グローバル検索を使用して、接続された外部システムで統合検索を実行する機能。
• クラウドおよびオンプレミスのソースから外部データにアクセスするレポートを実行する機能。次のレポートに関する考慮事項を参照してください。

Salesforce Connect の考慮事項

Salesforce Connect ソリューションでは、次の考慮事項があります。

• 外部オブジェクトはカスタムオブジェクトのように動作しますが、一部の機能は外部オブジェクトでは使用できません。詳細は、「Salesforce Compatibility Considerations for Salesforce Connect」を参照してください。
• 外部オブジェクトは、レポートのパフォーマンスに影響する可能性があります。詳細は、「Report Considerations for Salesforce Connect (Salesforce Connect のレポートに関する考慮事項)」を参照してください。
• Salesforce Connect アダプタの使用に関するその他の考慮事項については、「Considerations for Salesforce Connect — All Adapters」を参照してください。
• 組織間アダプタの使用を検討している場合は、「Considerations for Salesforce Connect — Cross-Org Adapter」(Salesforce Connect — 組織間アダプタに関する考慮事項)を参照してください。
• Odata アダプタの使用を検討している場合は、「Considerations for Salesforce Connect — Odata 2.0 and 4.0 Adapters」を参照してください。
• カスタム Apex アダプタの使用を検討している場合は、「Considerations for Salesforce Connect — Custom Adapter」を参照してください。

セキュリティに関する考慮事項

このパターンのソリューションは、標準の Salesforce 組織レベルセキュリティに準拠する必要があります。HTTPS プロトコルを使用して任意のリモートシステムに接続することをお勧めします。詳細は、「セキュリティの考慮事項」を参照してください。

Odata コネクタを使用している場合は、Odata 外部データソースのクロスサイト要求フォージェリ (CSRF) の特殊な動作、制限事項、推奨事項を理解してください。詳細については、「Salesforce Connect — Odata 2.0 および 4.0 アダプターに関する CSRF の考慮事項」を参照してください。

サイドバー

なし。

適時性

このパターンでは、タイミングが非常に重要です。次の点に留意してください。

• 通常、要求はユーザーインターフェースから呼び出されるため、このプロセスでユーザーを待たせてはなりません。
• 外部システムの可用性および外部システムへの接続によっては、外部データの取得に時間がかかることがあります。Salesforce では、外部システムからの応答を待機する最大タイムアウト値を 120 秒に設定できるようになっています。
• リモートプロセスの完了は、タイムリーに実行され、Salesforce タイムアウト制限内およびユーザーの期待以内に完了する必要があります。

データボリューム

このパターンは、タイムアウト値が小さく、Apex コール ソリューションの要求または応答の最大サイズが小さいため、主に少量のリアルタイム アクティビティで使用されます。メッセージにデータペイロードが含まれる一括処理活動では、このパターンを使用しないでください。

エンドポイントの機能と標準のサポート

エンドポイントの機能と標準のサポートは、選択したソリューションによって異なります。

状態管理

システムを統合する場合、進行中の状態追跡では鍵が重要です。たとえば、レコードがリモートシステムで作成された場合、通常、レコードには継続的な更新をサポートする何らかの識別キーが必要です。鍵の保存には 2 つのオプションがあります。

• Salesforce は、リモートレコードの主サロゲートキーまたは一意のサロゲートキーを保存します。
• リモートシステムには、Salesforce の一意のレコード ID またはその他の一意の代理キーが保存されます。この同期パターンでのインテグレーションキーの処理には、特定の考慮事項があります。

複雑なインテグレーション

場合によっては、このパターンで規定されたソリューションで複雑なインテグレーションシナリオの実装が必要になることがあります。これらのシナリオは多くの場合、ミドルウェアを使用して解決されます。

• 複数のシステムへの通話の集計とその結果
• 受信メッセージと送信メッセージの両方の変換
• 複数のシステムへのコール間でトランザクションの整合性を維持する
• Salesforce と外部システム間のその他のプロセスオーケストレーション活動

管理の制限

アダプターごとに異なる制限が適用されます。詳細は、「Salesforce Connect の一般的な制限」を参照してください。

ミドルウェア機能

次の表は、このパターンに参加するミドルウェアシステムの望ましいプロパティを示しています。

外部オブジェクトリレーション

外部オブジェクトでは、18 文字の Salesforce レコード ID を使用して関連レコードを関連付ける標準参照関係がサポートされます。ただし、Salesforce 組織の外部に保存されたデータは、多くの場合レコード ID が含まれていません。そのため、外部オブジェクトでは、外部参照と間接参照という、2 つの特殊なタイプの参照関係を使用できます。

この表には、外部オブジェクトで使用できるリレーション種別がまとめられています。

Salesforce Connect — OData 2.0 および 4.0 アダプターに関する高データボリュームの考慮事項

組織が外部オブジェクトにアクセスするときにレート制限に達した場合、関連付けられた外部データソースで [高データボリューム] オプションを選択することを検討してください。このオプションを選択すると、ほとんどのレート制限が迂回されますが、一部の特殊動作と制限は適用されます。詳細は、「High Data Volume Considerations for Salesforce Connect」を参照してください。

Salesforce Connect のクライアント駆動ページングおよびサーバー駆動ページング — Odata 2.0 および 4.0 アダプタ

外部データの Salesforce Connect クエリで、大量の結果セットがバッチやページに分割されて示されることはよくあります。ページングの動作を外部システム (サーバ駆動) で制御するか、Salesforce Connect の Odata 2.0 または 4.0 アダプタ (クライアント駆動) で制御するかを決定します。外部データソースの [サーバー駆動のページ設定] 項目は、クライアント駆動とサーバー駆動のどちらのページングを使用するかを指定します。外部データソースでサーバー駆動ページングを有効にすると、要求されたページサイズ (デフォルトの queryMore() バッチサイズである 500 行を含む) が無視されます。外部システムから返されたページによってバッチが決まりますが、各ページは 2,000 行を超えることはできません。ただし、その場合でも Salesforce Connect の OData アダプターの制限は適用されます。

例

ある製造会社は、Salesforce を使用して顧客のケースを管理しています。カスタマーサービスエージェントは、バックオフィスの ERP システムからリアルタイムの注文情報にアクセスして、ERP でレポートを学習して手動で実行することなく、顧客の全体像を把握したいと考えています。

このパターンで規定されたソリューションを実装するには、次の作業を行う必要があります。

• Odata エンドポイントを使用して外部データソースを設定します。リモート アプリケーションに Odata のネイティブ サポートが含まれている場合があります。その他のアプリケーションについては、Dell Boomi、Informatica、Jitterbit、MuleSoft、Progress Softwareなどの主要なインテグレーション ベンダーがSalesforce on Salesforce Connectと連携してアダプタを構築しています。
• Salesforce Connectで直接またはミドルウェア ソリューションを介してOdataエンドポイントを参照します。
• 外部データベーステーブルを Salesforce の外部オブジェクトと同期します。ユーザーがこれらの外部オブジェクトのデータを含むページにアクセスすると、Salesforce Connect はバックエンドアプリケーションにリアルタイムコールアウトを実行します。

開発者ドキュメント

• Salesforce ヘルプ:インテグレーションユーザーへの API 限定アクセス権の付与

• 『SOAP API Developer Guide』

• REST API 開発者ガイド

• ストリーミング API 開発者ガイド

• Bulk API 2.0 および Bulk API 開発者ガイド

• Apex 開発者ガイド

• SOQL および SOSL リファレンス

• Salesforce 開発者向け制限および割り当てクイックリファレンス

• プラットフォームイベント開発者ガイド

• Apex 開発者ガイド Connect

Trailhead

• 大規模データボリューム

• プラットフォームイベントの基本

• 変更データキャプチャの基本

• クイックスタート Connect

エンタープライズポートフォリオの有効なメンバーになるには、すべてのアプリケーションを作成し、関連するセキュリティメカニズムと統合する必要があります。最新の IT 戦略では、オンプレミスとクラウドベースのサービスを組み合わせて使用します。

通常、クラウド間サービスの統合は Web サービスと関連する認証に焦点が絞られますが、オンプレミスとクラウドサービスを接続すると複雑さが増します。このセクションでは、セキュリティツール、技術、Salesforce 固有の考慮事項について説明します。

リバースプロキシサーバ

リバースプロキシは、Web サーバーの前に配置され、クライアント (Web ブラウザーなど) 要求をそれらの Web サーバーに転送するサーバーです。リバースプロキシは通常、セキュリティ、パフォーマンス、信頼性を高めるために実装されます。

これは、クライアントの代わりに 1 つ以上のサーバーからリソースを取得するプロキシサーバーの一種です。これらのリソースは、プロキシサーバー自体から取得されたかのようにクライアントに返されます。フォワードプロキシは、関連付けられたクライアントが任意のサーバーに接続するための仲介者ですが、リバースプロキシは、関連付けられたサーバーが任意のクライアントから接続するための仲介者です。

Salesforce 実装では、通常、このようなサービスは外部ゲートウェイ製品を介して提供されます。たとえば、Apache HTTP、lighttpd、nginix などのオープンソースオプションを使用できます。商用製品には、IBM WebSeal や Computer Associates SiteMinder などがあります。これらの製品は、内部要求者の代わりにすべての送信 Salesforce 要求をプロキシして管理するように簡単に設定できます。

暗号化

企業によっては、オンプレミスとクラウドベースのアプリケーションの組み合わせ間で、選択したトランザクションまたはデータ項目を暗号化する必要があります。組織が追加のコンプライアンス要件に準拠する必要がある場合、次のような代替方法を実装できます。

• Salesforce 独自の暗号化ゲートウェイサービス、CipherCloud、IBM DataPower、Computer Associates など、オンプレミスの商用暗号化ゲートウェイサービス。ソリューションごとに、暗号化ペイロードを送受信するか、HTTP (S) 要求が実行される前に特定のデータ項目を暗号化または復号化することで、暗号化エンジンまたはゲートウェイがトランザクション境界で呼び出されます。

• クラウド ベースのオプション(Salesforce Shield Platform Encryption など)。Shield Platform Encryption では、重要なプラットフォーム機能を保持しながらデータに新しいセキュリティ層が追加されます。選択したデータは、高度な鍵派生システムを使用して保存時に暗号化されます。これまで以上に安全にデータを保護できます。詳細は、Salesforce オンラインヘルプを参照してください。

特殊な WS-* プロトコルのサポート

セキュリティプロトコル (WS-* など) の要件に対応するため、次の代替方法をお勧めします。

• セキュリティ/XML ゲートウェイ — WS-Security ログイン情報 (IBM WebSeal または Datapower、Layer7、TIBCO など) をトランザクションストリーム自体に挿入します。このアプローチでは、Salesforce からアプリケーションレベルの Web サービスや Web サービスを呼び出す必要はありません。Salesforce インストール全体でこのアプローチを再使用することもできます。ただし、既存のセキュリティゲートウェイアプローチへの適切な WS-Security インジェクションを管理するには、追加の設計、設定、テスト、メンテナンスが必要です。

• トランスポートレベルの暗号化 — 双方向 SSL および IP 制限を使用して通信チャネルを暗号化します。この方法では、WS-* プロトコルを単独で直接実装することはありませんが、ユーザー名とパスワードを渡すことなく、オンプレミスアプリケーションと Salesforce 間の通信チャネルを保護します。また、Salesforce で生成されたクラスを変更する必要もありません。ただし、一部のオンプレミス Web サービスの変更が必要になる場合があります (アプリケーション自体またはミドルウェア/ESB レイヤー)。

• Salesforce カスタム開発 — WSDL2Apex ユーティリティを使用して、WS-Security ヘッダーを送信 SOAP 要求に追加します。これにより、内部サービスの呼び出しに使用される WSDL ファイルから Java に似た Apex クラスが生成されます。このアプローチでは、DMZ のバックエンド Web サービスや追加のコンポーネントを変更する必要はありませんが、次のものが必要です。

  • ビルドおよびテスト作業の増加
  • WS-Security 属性を手動でコーディングする比較的複雑なプロセス (Apex コード内の XML シリアライゼーションを含む)
  • 長期的なメンテナンス作業の増加

メモ:最後のオプションは、その複雑さと、Salesforce の定期的な更新に基づく定期的なレビューが必要になるリスクのため、お勧めしません。

その他のセキュリティに関する考慮事項

• 指定ログイン情報:指定ログイン情報は、外部システムへの認証済み API コールアウトを保護して簡素化するために、コールアウトエンドポイントの URL とその必須認証パラメーターを 1 つの定義で指定します。Apex コードを合理化し、認証済みコールアウトの設定を簡略化するには、コールアウト エンドポイントとして指定ログイン情報を指定します。詳細については、こちらを参照してください。

• OAUTH 2.0 2.0 は、ユーザーがログイン情報 (パスワードなど) を共有することなく、サードパーティアプリケーションに保護リソースへの制限付きアクセス権を付与できる業界標準の認証フレームワークです。ユーザーは、パスワードを直接交換する代わりにアクセストークン要求を承認し、アプリケーションはこれを使用してリソースサーバーからユーザーのデータにアクセスします。このプロセスでは、クライアントアプリケーションをユーザーの ID とパスワードから分離し、リソースにアクセスするための一時的な範囲固有の「鍵」を提供することでセキュリティを強化します。詳細については、こちらを参照してください。

• プライベートコネクト 組織をサードパーティのクラウドサービスでホストされているアプリケーションと統合する場合、HTTP/s トラフィックを安全に送受信できることが不可欠です。プライベートコネクトでは、Salesforce 組織と AWS Virtual Private Cloud (VPC) の間に完全に管理された安全な接続を設定することにより、Amazon Web Services (AWS) インテグレーションでのセキュリティを強化できます。次に、クロスクラウドトラフィックを公開インターネットではなく接続を介して転送し、部外者のセキュリティ脅威にさらされるリスクを軽減します。プライベートコネクトは、AWS とのパートナーシップで AWS PrivateLink という機能を介して使用できます。プライベートコネクトは双方向で、受信トラフィックと送信トラフィックの両方を開始できます。受信接続では、標準 API を使用してトラフィックを Salesforce に送信できます。送信接続では、Apex コールアウト、外部サービス、外部オブジェクトなどの機能を介してトラフィックを Salesforce から送信できます。VPC の詳細については、こちらを参照してください。

プラットフォームイベント、変更データキャプチャ (CDC)、および Pub/Sub API を備えた Salesforce イベントバスを使用すると、企業はイベント駆動型スタイルアーキテクチャ (EDA) を作成できます。

EDA では、イベントメッセージのコンシューマー (登録者) がイベントメッセージのプロデューサー (公開者) から切り離されるため、拡張性と柔軟性が向上します。このドキュメントでは、関連する代替またはオプションを比較対照する既存のパターン構造の一部として特定のパターンを取り上げています。ただし、イベント駆動型アーキテクチャとパターンの相互作用について包括的に理解することで、ニーズに適したパターンを選択できます。

Khalid Mohamed は、Salesforce のプロフェッショナルサービスにおける優れたアーキテクトリーダーです。2015 年に Salesforce に入社して以来、エンタープライズアプリケーションとアーキテクチャに関する広範な専門知識を活用し、Salesforce での職務を果たすまでに多くの顧客変革を経験してきました。Khalid は、デリバリアーキテクチャ委員会を統括し、認定テクニカルアーキテクトリーダーとしても認められています。

Gulal Kumar は、Salesforce のソフトウェアエンジニアリングアーキテクトで、データおよびインテグレーションアーキテクチャに重点を置いています。インテグレーションと API、モダナイゼーションプログラム、セキュリティ、AIML イニシアチブで 20 年以上の経験があり、豊富な専門知識を備えています。Gulal は、ビジネス変革イニシアチブを推進し、セキュリティと耐障害性を強化し、アーキテクチャの卓越性を促進し、さまざまなドメインで AIML イニシアチブをリードしてきました。

Sushant は Salesforce のテクニカルアーキテクトで、ソリューションアーキテクチャと Salesforce プラットフォームのエンドツーエンドの提供を専門としています。プラットフォームガバナンス、アプリケーション開発、インテグレーション、DevOps に関する深い専門知識を持ち、さまざまな業種の多数の顧客変革プログラムを率いてきました。Sushant は、優れたデリバリとスケーラブルなアーキテクチャの成果の実現に取り組んでいます。