--- schema_version: "1" id: 6a1a5fd7812c18a78d99e3f5d0fb2cca4bd46a58594a3bb1791790c01108d30c title: インテグレーションパターン collection: architect version: current locale: ja-jp portal_url: https://docs.salesforce.com/architect/current/ja-jp/fundamentals/guides/integration-patterns.md canonical_url: https://architect.salesforce.com/docs/architect/ja-jp/fundamentals/guide/integration-patterns.html source_site: architect.salesforce.com content_type: documentation content_hash: f16f14e05572675ed8b0a0ffda096bdf9e63753a3080279c990ad8a257a8cda3 products: - 基礎 - Architect Site Content Repo updated_at: 2026-06-01T00:00:00Z --- # インテグレーションパターンの概要 通常、Salesforce を実装する場合、他のアプリケーションと統合する必要があります。インテグレーションシナリオはそれぞれ異なりますが、開発者とアーキテクトが解決する必要がある共通の要件と問題があります。 このドキュメントでは、次の一般的なインテグレーションシナリオの戦略 (パターン形式) について説明します。各パターンは、特定の実装の詳細を説明するのではなく、特定のシナリオの設計とアプローチを説明します。このドキュメントには、次の内容が記載されています。 - 主要な「アーキタイプ」インテグレーションシナリオに対応する多数のパターン - シナリオに最も適したパターンを決定するのに役立つ選択マトリックス - インテグレーションのヒントとベストプラクティス **目的と範囲** このドキュメントは、Salesforce Platform を社内の他のアプリケーションと統合する必要があるデザイナーやアーキテクトを対象としています。本コンテンツは、多くの成功した実装から抽出されています。 Salesforce ベースのアプリケーションの大規模な採用に使用できるインテグレーション機能とオプションについての詳細は、『パターンの概要と選択ガイド』を参照してください。アーキテクトと開発者は、Salesforce インテグレーションプロジェクトの設計および実装フェーズで、次のパターンの詳細とベストプラクティスを適用する必要があります。 これらのパターンを適切に実装すれば、本番環境にできるだけ早く移行でき、可能な限り安定性と拡張性が高く、メンテナンスフリーな一連のアプリケーションを使用できます。Salesforce 独自のコンサルティングアーキテクトは、アーキテクチャレビューの際にこれらのパターンを参照点として使用し、積極的に維持および改善します。 すべてのパターンと同様に、このコンテンツではほとんどのインテグレーションシナリオがカバーされますが、すべてはカバーされません。Salesforce ではユーザーインターフェース (UI) インテグレーションが可能ですが、マッシュアップなどについては、このドキュメントの範囲外です。 **パターンテンプレート** 各インテグレーションパターンは一貫した構造に従います。この構造により、パターンの比較や関連情報の検索が容易になります。 _名前_ パターンに含まれるインテグレーションの種別も示すパターン識別子。 _コンテキスト_ パターンで対応する全体的なインテグレーションシナリオ。コンテキストは、ユーザーが何を達成しようとしているか、および要件をサポートするためにアプリケーションがどのように動作するかに関する情報を提供します。 _問題_ パターンで解決するように設計されたシナリオまたは問題 (質問として表現)。パターンを確認するときは、このセクションを読んで、パターンがインテグレーションシナリオに適しているかどうかをすばやく理解してください。 _勢力_ 示されたシナリオを解決するのを困難にする制約と状況。 _ソリューション_ インテグレーションシナリオを解決するための推奨方法。 _スケッチ_ ソリューションがシナリオにどのように対処するかを示す UML シーケンス図。 _結果_ ソリューションをインテグレーションシナリオに適用する方法の詳細と、そのシナリオに関連する勢力を解決する方法について説明します。このセクションでは、パターンの適用によって発生する可能性のある新しい課題についても説明します。 _サイドバー_ 主要な技術的な問題、パターンのバリエーション、パターン固有の懸念などが含まれる、パターンに関連する追加のセクション。 _例_ 実際の Salesforce シナリオでデザインパターンがどのように使用されるかを説明するエンドツーエンドのシナリオ。この例では、インテグレーションの目標とその目標を達成するためにパターンを実装する方法について説明します。 **パターン概要** 次の表に、このドキュメントに記載されているインテグレーションパターンを示します。 **パターンのリスト** | パターン | シナリオ | | :------------------------------------------------------------------------------------------------------------------------------------------------------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | [リモートプロセス呼び出し — 要求と応答](/docs/architect/ja-jp/fundamentals/guide/integration-patterns.html#remote-process-invocation--request-and-reply) | Salesforce は、リモートシステムでプロセスを呼び出してそのプロセスの完了を待ち、リモートシステムからの応答に基づいて状態を追跡します。 | | [リモートプロセス呼び出し — Fire and Forget](/docs/architect/ja-jp/fundamentals/guide/integration-patterns.html#remote-process-invocation--fire-and-forget) | Salesforce はリモートシステムでプロセスを呼び出しますが、プロセスの完了は待機しません。代わりに、リモートプロセスはリクエストを受け取り応答し、その後制御をSalesforceに返します。 | | [バッチデータ同期](/docs/architect/ja-jp/fundamentals/guide/integration-patterns.html#batch-data-synchronization) | Salesforce Platform に保存されているデータは、外部システムからの更新を反映するように作成または更新されます。また、Salesforce Platform からの変更が外部システムに送信されるタイミングも変更されます。どちらの方向の更新もバッチで行われます。 | | [リモートコールイン](/docs/architect/ja-jp/fundamentals/guide/integration-patterns.html#remote-call-in) | Salesforce Platform に保存されているデータは、リモートシステムによって作成、取得、更新、または削除されます。 | | [データの変更に基づく UI の更新](/docs/architect/ja-jp/fundamentals/guide/integration-patterns.html#ui-update-based-on-data-changes) | Salesforce ユーザーインターフェースは、Salesforce データの変更の結果として自動的に更新する必要があります。 | | [データ仮想化](/docs/architect/ja-jp/fundamentals/guide/integration-patterns.html#data-virtualization) | Salesforce は外部データにリアルタイムでアクセスします。これにより、Salesforce でデータを保持し、Salesforce と外部システム間でデータを調整する必要がなくなります。 | **パターンアプローチ** このドキュメントのインテグレーションパターンは、次の 3 つのカテゴリに分類されます。 - データインテグレーション: これらのパターンは、2 つ以上のシステムに存在するデータを同期して、両方のシステムに常にタイムリーで意味のあるデータが含まれるようにする要件に対応します。多くの場合、データインテグレーションは実装する最もシンプルなインテグレーションですが、ソリューションを持続可能でコスト効率の高いものにするには適切な情報管理技術が必要です。このような手法には、多くの場合、マスターデータ管理 (MDM)、データガバナンス、マスター、重複排除、データフロー設計などの側面が含まれます。 - プロセスインテグレーション: このカテゴリのパターンは、ビジネスプロセスが 2 つ以上のアプリケーションを活用して ToDo を完了するというニーズに対応します。この種類のインテグレーションのソリューションを実装する場合、トリガーアプリケーションはプロセスの境界を越えて他のアプリケーションにコールする必要があります。通常、これらのパターンには、オーケストレーション（1 つのアプリケーションが中央の「コントローラー」として機能する場合）と、コレオグラフィ（複数の関係者が存在し、中央の「コントローラー」が存在しない場合）の両方が含まれます。これらのインテグレーションでは、多くの場合、複雑な設計、テスト、例外処理の要件が必要です。また、このような複合アプリケーションは、多くの場合、実行時間の長いトランザクションや、プロセスの状態に関するレポートや管理の機能をサポートしているため、基盤となるシステムに対する要求も高くなります。 - 仮想インテグレーション: このカテゴリのパターンは、外部システムに保存されているデータをユーザーが表示、検索、変更するニーズに対応します。この種別のインテグレーションのソリューションを実装する場合、トリガーアプリケーションは、他のアプリケーションにコールアウトし、そのデータをリアルタイムで操作する必要があります。この種類のインテグレーションにより、システム全体でデータレプリケーションを行う必要がなくなり、ユーザーは常に最新のデータを操作できます。 システムに最適なインテグレーション戦略を選択することは容易ではありません。考慮すべき点や使用できるツールは多数あり、ツールによっては特定の作業に適したものもあります。各パターンは、各システムの機能、データ量、障害処理、トランザクション性など、特定の重要な領域に対応します。 **パターン選択ガイド** 選択マトリックステーブルには、インテグレーション要件に最も適したパターンを判断するのに役立つパターンとその主要な側面がリストされています。パターンは次のディメンションを使用して分類されます。 | アスペクト | 説明 | | :----- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Type | インテグレーションのスタイル (**プロセス**、**データ**、**仮想**) を指定します。

**プロセス:** プロセスベースのインテグレーションは、2 つ以上のアプリケーション間で機能フローの処理を統合する方法です。通常、これらのインテグレーションでは、特にトランザクション性およびロールバックに関して、抽象化レベルと複雑さが高まります。

**データ:** データインテグレーションは、アプリケーションで使用される情報の統合です。これらのインテグレーションは、単純なテーブル挿入やアップサートから、参照整合性や複雑な変換を必要とする複雑なデータ更新まで、多岐にわたります。

**仮想:** 仮想インテグレーションは、Salesforce が外部システムに存在するデータを操作するための機能です。Salesforce 内のデータを複製する必要はありません。この種のインテグレーションは、ユーザーアクション、検索、レコード更新などの Salesforce Platform からのイベントを介して常にトリガーされ、外部ソースとのデータインテグレーションがリアルタイムで行われます。 | | タイミング | タイミングに基づいてインテグレーションのスタイル (**同期**または**非同期**) を指定します。

**同期:** ブロック要求とリアルタイム要求は要求/応答操作です。結果は、このオペレーションを通じてすぐに呼び出し元に返されます。

非**同期:** ノンブロッキング、キュー、またはメッセージベースの要求は、ほぼリアルタイムの一方向操作によって呼び出されます。結果と障害は、他の一方向オペレーションを呼び出すことで返されます。そのため、呼び出し元はリクエストを実行し、応答を待たずに続行します。 | _Salesforce と別のシステムの統合_ 次の表は、Salesforce から別のシステムへのインテグレーションの場合に要件に最も適したパターンを判断するのに役立つパターンとその主要な側面を示しています。 | タイプ | タイミング | 考慮すべき主要なパターン | | :------------------ | :----------- | :------------------------------------------------------------------------------------------------------------------------------------------------------- | | プロセスインテグレーション | 同期 | [リモートプロセス呼び出し — 要求と応答](/docs/architect/ja-jp/fundamentals/guide/integration-patterns.html#remote-process-invocation--request-and-reply) | | プロセスインテグレーション | 非同期 | [リモートプロセス呼び出し — Fire and Forget](/docs/architect/ja-jp/fundamentals/guide/integration-patterns.html#remote-process-invocation--fire-and-forget) | | データインテグレーション | 同期 | [リモートプロセス呼び出し — 要求と応答](/docs/architect/ja-jp/fundamentals/guide/integration-patterns.html#remote-process-invocation--request-and-reply) | | データインテグレーション | 非同期 | [データの変更に基づく UI の更新](/docs/architect/ja-jp/fundamentals/guide/integration-patterns.html#ui-update-based-on-data-changes) | | 仮想インテグレーション | 同期 | [データ仮想化](/docs/architect/ja-jp/fundamentals/guide/integration-patterns.html#data-virtualization) | _別のシステムと Salesforce の統合_ 次の表は、別のシステムから Salesforce へのインテグレーションの場合に要件に最適なパターンを判断するのに役立つパターンとその主要な側面を示しています。 | タイプ | タイミング | 考慮すべき主要なパターン | | :------------------ | :----------- | :-------------------------------------------------------------------------------------------------------------------- | | プロセスインテグレーション | 同期 | [リモートコールイン](/docs/architect/ja-jp/fundamentals/guide/integration-patterns.html#remote-call-in) | | プロセスインテグレーション | 非同期 | [リモートコールイン](/docs/architect/ja-jp/fundamentals/guide/integration-patterns.html#remote-call-in) | | データインテグレーション | 同期 | [リモートコールイン](/docs/architect/ja-jp/fundamentals/guide/integration-patterns.html#remote-call-in) | | データインテグレーション | 非同期 | [バッチデータ同期](/docs/architect/ja-jp/fundamentals/guide/integration-patterns.html#batch-data-synchronization) | **ミドルウェアの用語と定義** 次の表に、ミドルウェアに関連する主要な用語と、それらのパターンの定義を示します。 | 用語 | 定義 | | --------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | イベント処理 | イベント処理とは、指定された受信者 (「ハンドラー」) で識別可能な発生を受信することです。イベント処理に関連する主要なプロセスは次のとおりです。イベントハンドラーは最終的にイベントをイベントコンシューマーに転送できます。

ミドルウェアでのこの機能の一般的な用途は、一般的な「Publish/Subscribe (公開/登録)」または「pub/sub (公開/サブ)」機能に拡張できます。パブリッシュ/購読シナリオでは、ミドルウェアはアクティブなデータイベントパブリッシャーからアクティブなデータイベント購読者へリクエストまたはメッセージを転送します。有効なリスナーを持つこれらのコンシューマーは、公開時にイベントを取得できます。

ミドルウェアを使用する Salesforce インテグレーションでは、ミドルウェアレイヤーがイベント処理の制御を引き受けます。同期または非同期のすべての関連イベントを収集し、Salesforce を含むすべてのエンドポイントへの配信を管理します。

または、この機能はプラットフォームイベントと共に Salesforce イベントバスを使用して実現できます。 | | プロトコル変換 | 通常、プロトコル変換は、あるデバイスの標準プロトコルまたは独自プロトコルを、相互運用性を実現するために別のデバイスに適したプロトコルに変換するソフトウェアアプリケーションです。

ミドルウェアのコンテキストでは、特定の対象システムへの接続がプロトコルによって制限される場合があります。このような場合は、ペイロードを抽出できる対象システムの形式にメッセージ形式を変換するか、その形式内にカプセル化する必要があります。これはトンネリングとも呼ばれます。

Salesforce ではネイティブプロトコルの変換はサポートされていないため、ミドルウェアレイヤーまたはエンドポイントによってそのような要件が満たされていることが前提となります。 | | 翻訳と変換 | 変換とは、統合するさまざまなシステム間の相互運用性を確保するために、あるデータ形式を別のデータ形式にマッピングする機能のことです。通常、このプロセスでは、送信者または受信者の要件に合わせてメッセージを再フォーマットする必要があります。より複雑なケースでは、1 つのアプリケーションが独自のネイティブ形式でメッセージを送信し、他の 2 つ以上のアプリケーションがそれぞれのネイティブ形式でメッセージのコピーを受信できます。

多くの場合、ミドルウェアの翻訳および変換ツールには、従来のエンドポイントやその他の非標準エンドポイントのサービスの外観を作成する機能が含まれています。これらのサービスファサードにより、これらのエンドポイントはサービスとしてアドレス指定可能に見えるようになります。

Salesforce インテグレーションでは、ミドルウェアレイヤーまたはエンドポイントによってそのような要件が満たされていることが前提となります。ミドルウェアは依然として複雑な変換に適していますが、Salesforce Platform は成熟しました。OmniStudio インテグレーション手順、Flow データマッピング、そして最新のパターンを用いた Apex は、いずれも中程度の変換に適しています。 | | キューイングとバッファリング | 一般に、キューイングとバッファリングは、要求-応答アーキテクチャとは異なり、非同期メッセージパッシングに依存します。非同期システムでは、対象プログラムがビジー状態の場合や接続性が低下している場合に、メッセージキューによって一時的なストレージが提供されます。また、ほとんどの非同期ミドルウェアシステムは、メッセージキューをバックアップする永続的なストレージを提供します。

非同期メッセージプロセスの主な利点は、何らかの理由で受信者アプリケーションが失敗した場合でも、送信者が影響を受けずに続行できることです。送信されたメッセージは、受信者が再起動したときに後で処理できるようにメッセージキューに蓄積されます。

Salesforce では、Pub/Sub API を使用した変更データキャプチャ/プラットフォームイベントの形式で非同期機能が提供されます。オーケストレーション、プロセス振付、サービス品質など、他のインテグレーションシナリオで真のメッセージキューを提供するには、ミドルウェアソリューションが必要です。 | | 同期転送プロトコル | 同期転送プロトコルとは、「通話者の 1 つのスレッドが要求メッセージを送信し、応答メッセージを待機してブロックし、応答を処理する」活動をサポートするプロトコルです。応答を待機している要求スレッドは、1 つの未処理の要求のみが存在するか、この要求の応答チャネルがこのスレッドで非公開であることを意味します。 | | 非同期転送プロトコル | 非同期転送プロトコルとは、「通話者の 1 つのスレッドが要求メッセージを送信し、返信のコールバックを設定する」活動をサポートするプロトコルです。別のスレッドが返信メッセージをリスンします。返信メッセージが届くと、返信スレッドは適切なコールバックを呼び出し、呼び出し元のコンテキストを再確立して返信を処理します。この方法では、複数の未処理の要求で 1 つの返信スレッドを共有できます」 | | 仲介ルーティング | 仲介ルーティングは、コンポーネント間のメッセージの複雑な「フロー」の仕様です。たとえば、ミドルウェアベースのソリューションの多くはメッセージキューシステムに依存しています。実装によっては、メッセージングレイヤー自体でルーティングロジックを提供できますが、クライアントアプリケーションに依存してルーティング情報を提供したり、両方のパラダイムを混在させたりすることもできます。このような複雑なケースでは、ミドルウェア側で仲介することで、開発、インテグレーション、検証が簡素化されます。メディエーターは、適切なメッセージが適切なコンシューマーに届くようにします。 | | プロセス振付とサービスオーケストレーション | プロセス振付とサービスオーケストレーションは、任意の数のエンドポイントと機能が調整される「サービス構成」の各形式です。

振付とサービスオーケストレーションの違いは次のとおりです。さらに、オーケストレーションは各サービスの完全な動作を示し、コレオグラフィーは各サービスのインターフェース動作の説明を組み合わせます。ビジネスプロセスの振付の一部は、フロー オーケストレーション、Salesforceワークフロー、またはApexを使用して作成できます。

Salesforce ネイティブ Flow Orchestration では、バックグラウンドステップ、対話型ステップ、MuleSoft® ステップを含む実行時間の長い複数ステップのプロセスを利用できます。そのネイティブ機能は、組み込みのフェーズ管理と割り当てルーティングを使用して、ミドルウェアなしでオーケストレーションできます。

特に真のトランザクション処理が必要なソリューションでは、Salesforce のタイムアウトやガバナ制限を回避するために、ミドルウェアレイヤーにすべての複雑なクロスシステムオーケストレーションを実装することをお勧めします。 | | トランザクション性 (暗号化、署名、信頼性の高い配信、トランザクション管理) | トランザクション性は、必要な各リソースに対する必要なすべての操作を含むグローバルトランザクションをサポートする機能として定義できます。トランザクション性は、4 つの ACID プロパティ (原子性、一貫性、分離性、耐久性) すべてをサポートすることを意味します。原子性は、作業単位 (トランザクション) の結果がすべて揃うか、まったく揃わないかを保証するものです。

Salesforce 自体はトランザクションですが、分散トランザクションや Salesforce の外部で開始されたトランザクションには参加できません。そのため、複雑なマルチシステムトランザクションを必要とするソリューションの場合、トランザクション性および関連付けられたロールバック/補償メカニズムがミドルウェアレイヤーで実装されることが想定されます。 | | ルーティング | ルーティングは、コンポーネントからコンポーネントへのメッセージの複雑なフローを指定するものとして定義できます。最新のサービスベースのソリューションでは、このようなメッセージフローは、ヘッダー、コンテンツタイプ、ルール、優先度など、多くの条件に基づくことができます。

Salesforceインテグレーションの場合、ミドルウェア レイヤーまたはエンドポイントによってこれらの条件が満たされていることが前提ですが、メッセージ ルーティングもApexでコーディングできます。 | | 抽出、変換、読み込み | 抽出、変換、読み込み (ETL) とは、次のプロセスを指します。厳密には必要ありませんが、ほとんどの成熟した ETL ツールには変更データキャプチャ機能があります。この機能は、前回の抽出以降に変更されたソースシステムのレコードをツールで識別するものであり、レコード処理量を削減します。

Salesforce では、変更データキャプチャもサポートしています。これは、Salesforce レコードへの変更を表す変更イベントの公開です。変更データキャプチャを使用すると、クライアントまたは外部システムは Salesforce レコードの変更をほぼリアルタイムで受信できます。この情報を使用して、クライアントまたは外部システムは外部データストアの対応するレコードを同期できます。 | | ロングポーリング | ロングポーリングは、コメットプログラミングとも呼ばれ、サーバーからクライアントへの情報の転送をエミュレートします。通常のポーリングと同様に、クライアントは接続してサーバーに情報を要求します。ただし、情報が使用できない場合は空の応答を送信する代わりに、サーバーは要求を保持し、情報が使用可能になるまで待機します (イベントが発生する)。その後、サーバーは完全な応答をクライアントに送信します。クライアントはすぐに再度情報をリクエストします。クライアントはサーバーへの接続を継続的に維持するため、常に応答の受信を待機します。サーバーがタイムアウトすると、クライアントは再度接続して最初からやり直します。

Salesforce ストリーミング API では、長時間のポーリングに Bayeux プロトコルと CometD が使用されます。このメカニズムは従来のインテグレーション手法です。すべての新しいソリューションで Pub/Sub API を使用する必要があります。 | これらのインテグレーションツールに加えて、MuleSoft と Informatica は、最新のハイパフォーマンスインテグレーション戦略の基礎となる柱を提供します。どちらも同じエコシステム内に存在しますが、アーキテクチャ上の個別の課題を解決します。業界をリードする企業は、これらのプラットフォームを連携してリリースし、データとアプリケーションのあらゆるニーズを満たす包括的な「[連携強化](/docs/architect/ja-jp/fundamentals/guide/integration-informatica-mulesoft.html)」フレームワークを構築します。 [MuleSoft](https://www.salesforce.com/mulesoft/)は、Salesforceの主要な統合プラットフォームです。これにより、組織はオンプレミス環境とクラウド環境でアプリケーション、データ、デバイスを接続できます。MuleSoft は、システム全体のデータをロック解除し、拡張性の高いインテグレーションおよび自動化フレームワークを開発し、差別化された接続された環境を迅速に作成するためのツールを IT 部門に提供します。また、コア組織をAPIカタログのAnypointインスタンスに接続して、MuleSoft APIをアクションとしてApex、フロー、およびAgentforceで呼び出し可能にすることもできます。Anypoint Exchange には、多数の事前作成済み Salesforce コネクタがあります。 [Informatica](https://www.informatica.com/salesforce.html)は、業界をリードするエンタープライズ データ管理および統合プラットフォームです。これにより、組織はさまざまなソースからデータを収集、管理、統合、分析できます。ETL (抽出、変換、読み込み) プロセスを使用して、最新の分析と自律 AI エージェントを強化するために必要な、接続された信頼性の高いデータを提供します。 ## リモートプロセス呼び出し — 要求と返信 **コンテキスト** Salesforce を使用して、リードの追跡、パイプラインの管理、商談の作成、リードを顧客に変換する注文詳細の取得を行います。ただし、Salesforce システムには注文は含まれず、処理されません。注文の詳細が Salesforce に取り込まれると、注文がリモートシステムに作成され、そこで完了までの注文が管理されます。 このパターンを実装すると、Salesforce はリモートシステムをコールして注文を作成し、正常に完了するまで待機します。成功すると、リモートシステムは注文状況と注文番号で同期応答します。同じトランザクションの一環として、Salesforce は注文番号と状況を内部で更新します。注文番号は、リモートシステムの後続の更新で外部キーとして使用されます。 **問題** Salesforce でイベントが発生したときに、リモートシステムでプロセスを開始し、必要な情報をそのプロセスに渡してリモートシステムから応答を受信し、その応答データを使用して Salesforce 内で更新を行うにはどうすればよいでしょうか? **勢力** このパターンに基づいてソリューションを適用するときは、次の点を考慮してください。 - リモートシステムへの呼び出しにおいて、Salesforce が処理を続行する前に応答を待つ必要がありますか?リモートシステムへの呼び出しは、同期的なリクエスト・返信方式か、あるいは非同期リクエストですか？ - リモートシステムへのコールが同期の場合、Salesforce は応答を最初のコールと同じトランザクションの一部として処理する必要がありますか? - メッセージサイズは小さいか大きいか? - インテグレーションは、Salesforce ユーザーインターフェースでのボタンのクリックなどの特定のイベントや DML ベースのイベントの発生に基づいていますか? - リモートエンドポイントは低遅延で要求に応答できますか?ピーク時にこのトランザクションを実行する可能性が高いユーザーの数は? **ソリューション** 次の表に、このインテグレーションの問題の解決方法を示します。 | ソリューション | 適合 | コメント | | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | 外部サービスが REST API コールを呼び出す | 最善 | 外部サービスでは、外部でホストされるサービスを宣言型で呼び出すことができます (コードは必要ありません)。この機能は、次の条件を満たす場合に最適です。 | | Salesforce Lightning：Lightning コンポーネントまたはページで同期 Apex REST または SOAP コールアウトを開始します。リモートエンドポイントが高レイテンシ応答のリスクになる場合（適用される制限については、最新の本ドキュメンテーションを参照してください）、同期 Apex トランザクションガバナ制限に達しないように、継続とも呼ばれる非同期コールアウトをお勧めします。 | 最善 | Salesforce では、WSDL を使用して、結果のプロキシ Apex クラスを生成できます。このクラスは、リモートサービスをコールするために必要なロジックを提供します。

Salesforce では、標準の GET、POST、PUT、DELETE メソッドを使用して HTTP (REST) サービスを呼び出すこともできます。

次に、Lightningページでユーザーが開始するアクションが、このプロキシApexクラスを実行するApexコントローラ アクションをコールし、指定ログイン情報を使用してリモート コールを実行します。Lightning ページには、Salesforce アプリケーションのカスタマイズが必要です。
| | フローの HTTP コールアウトアクション | 良い | このソリューションでは、Apexや外部サービスの完全な登録プロセスを使用せずに、フローから宣言的に同期アウトバウンドRESTコールを実行できます。

これは、完全な OpenAPI 仕様を使用できない場合の宣言型実装に適しています。 | | Salesforceデータの変更から呼び出される同期トリガーは、非同期Apex SOAPまたはHTTPコールアウトを実行します。 | 最適ではない | Apexトリガーを使用して、レコード データの変更に基づいて自動化を実行できます。

Apex プロキシ クラスは、Apex トリガーを使用して、DML 操作の結果として実行できます。ただし、トリガーコンテキスト内から実行されたすべてのコールは、開始イベントから非同期で実行する必要があります。そのため、このインテグレーションの問題にはこのソリューションはお勧めしません。このソリューションは、Remote Process Invocation — Fire and Forget パターンに適しています。 | | Apex一括処理ジョブは、同期Apex SOAPまたはHTTPコールアウトを実行します。 | 最適ではない | 一括処理ジョブからリモートシステムへのコールを実行できます。このソリューションでは、Salesforce のリモートシステムから一括リモートプロセス実行と応答処理を実行できます。ただし、特定のバッチにはコール数の制限があります。詳細は、[ガバナ制限](https://developer.salesforce.com/docs/atlas.en-us.integration_patterns_and_practices.meta/integration_patterns_and_practices/integ_pat_remote_process_invocation_state.htm#governor_limits_header)を参照してください。

1つの一括処理実行では、複数のトランザクションコンテキストを実行できます（通常は200レコードごとに）。ガバナ制限はトランザクションコンテキストごとにリセットされます。 | | **スケッチ** 次の図は、Apex コールを使用した同期リモートプロセス呼び出しを示しています。 **Salesforce からリモートシステムへのコールアウト** ![Salesforce から要求と返信を伴うリモートシステムへのコールアウト](https://architect.salesforce.com/ns-assets/integration-patterns-request-reply-callout.png) このシナリオの内容は次のとおりです。 - Lightning ページでアクションが開始されます（ボタンのクリックなど）。 - ブラウザ（Lightning コンポーネントの場合はクライアント側コントローラ経由）は HTTP POST を実行し、続いて対応する Apex コントローラでアクションを実行します。 - コントローラーがリモート Web サービスへの実際のコールを呼び出します。 - リモートシステムからの応答が Apex コントローラーに返されます。コントローラーは応答を処理し、必要に応じて Salesforce のデータを更新して、ページを再表示します。 後続の状態を追跡する必要がある場合、リモートシステムは Salesforce レコードに保存されている一意の識別子を返します。 **結果** このパターンに関連するソリューションの適用により、Salesforce が処理するイベント開始リモートプロセスの呼び出しが可能になります。 **呼び出しメカニズム** コールメカニズムは、このパターンを実装するために選択されたソリューションによって異なります。
呼び出しメカニズム 説明
フローに埋め込まれた拡張外部サービスまたは

Lightning コンポーネントまたは

Apex コントローラ 		リモートプロセスがユーザーインターフェースを含むエンドツーエンドのプロセスの一部としてトリガーされ、その結果を Salesforce レコードに表示または更新する必要がある場合に使用されます。たとえば、クレジットカード支払を外部支払ゲートウェイに送信すると、支払結果がすぐに返され、エンドユーザーに表示されます。
Apex トリガー 主に、DML が開始するイベントからの Apex コールアウトを使用したリモートプロセスの呼び出しに使用されます。この呼び出しメカニズムについての詳細は、「Remote Process Invocation — Fire and Forget」パターンを参照してください
Apex 一括処理クラス バッチでのリモートプロセスの呼び出しに使用されます。この呼び出しメカニズムについての詳細は、「Remote Process Invocation — Fire and Forget」パターンを参照してください
**エラー処理と回復** 全体的なソリューションの一部としてエラー処理と回復戦略を含めることが重要です。 - **エラー処理:** エラーが発生すると (例外またはエラーコードがコール元に返される)、コール元がエラー処理を管理します。たとえば、エンドユーザーのページに表示されるエラーメッセージや、追加アクションが必要なテーブルに記録されるエラーメッセージなどです。 - **復旧:** 通話者が正常な応答を受信するまで、変更は Salesforce にコミットされません。たとえば、成功を示す応答を受信するまで、注文状況はデータベースで更新されません。必要に応じて、呼び出し元は操作を再試行できます。 **Idempotent Design Considerations (無力な設計に関する考慮事項)** 冪等性のある機能は、繰り返しの呼び出しが安全であることを保証します。緊急性が実装されていない場合、同じメッセージを繰り返し呼び出すと結果が異なる可能性があり、データの整合性の問題が発生する可能性があります。潜在的な問題として、重複レコードの作成やトランザクションの重複処理などがあります。 呼び出されるリモートプロシージャが冪等であることを確認することが重要です。コールがユーザーインターフェースによって実行された場合、特に Salesforce がコールを 1 回しか呼び出す保証がない場合は、インテグレーションレイヤーで冪等性を処理します。 最も典型的な受信者の作成方法は、コンシューマーが送信した一意のメッセージ識別子に基づいて重複を追跡することです。Apex Web サービスまたは REST コールは、一意のメッセージ ID を送信するようにカスタマイズする必要があります。 また、リモートシステムでレコードを作成する操作では、挿入する前に重複を確認する必要があります。Salesforce から一意のレコード ID を渡して確認します。リモートシステムにレコードが存在する場合は、レコードを更新します。ほとんどのシステムでは、この操作は更新/挿入操作と呼ばれます。 **セキュリティに関する考慮事項** リモートシステムへのコールでは、要求の機密性、整合性、可用性を維持する必要があります。次のセキュリティ上の考慮事項は、このパターンでの Apex SOAP および HTTP コールの使用に固有です。 - 一方向 SSL はデフォルトで有効になっていますが、クライアントとサーバーの両方の認証を維持するために、自己署名証明書と CA 署名証明書の両方で双方向 SSL がサポートされます。 - Apexコードを合理化し、認証済みコールアウトの設定を簡略化するには、コールアウト エンドポイントで指定ログイン情報を指定します。 - 外部システムへのインテグレーションの認証メカニズムとして OAuth 2.0 を使用することを検討してください。 - 必要に応じて、要求の整合性を確保するために、Apex Crypto クラスのメソッドを使用して一方向ハッシュまたはデジタル署名を使用することを検討します。 - リモートシステムは、適切なファイアウォールメカニズムを実装して保護する必要があります。「[セキュリティの考慮事項](/docs/architect/ja-jp/fundamentals/guide/integration-patterns.html#appendix-b-security-considerations)」を参照してください。 - 現在、Salesforce では WS-Security はサポートされていません。これらの複雑な WS-Security ヘッダーをネイティブに生成したり、受信 WSDL から自動的に適用したりすることはありませんが、受信要求の SOAP ヘッダーとセキュリティ トークンを処理するカスタム Apex クラスを作成して、手動で作成および実装できます。 **サイドバー** なし。 **適時性** このパターンでは、タイミングが非常に重要です。通常、次のようになります。 - 通常、要求はユーザーインターフェースから呼び出されるため、このプロセスでユーザーを待たせてはなりません。 - Salesforce では、Apex からのコールに対して最大 120 秒のタイムアウトを設定できます。 - リモートプロセスの完了は、Salesforce のタイムアウト制限内およびユーザーの期待の範囲内で適時に実行されます。 - 外部コールには Apex 同期トランザクション ガバナ制限が適用されるため、実行時間が 5 秒を超えるトランザクションが 50 件以上発生するリスクを軽減してください。外部エンドポイントのパフォーマンスを確保するだけでなく、タイムアウトのリスクを軽減するオプションを次に示します。 - 外部コールアウトのタイムアウトを 5 秒に設定する。 - Lightning コンポーネントの継続を使用した実行時間の長いトランザクションの処理 **データボリューム** このパターンは、タイムアウト値が小さく、Apex コール ソリューションの要求または応答の最大サイズが小さいため、主に少量のリアルタイム アクティビティで使用されます。メッセージにデータペイロードが含まれる一括処理活動では、このパターンを使用しないでください。 **エンドポイントの機能と標準のサポート** エンドポイントの機能と標準サポートは、選択したソリューションによって異なります。 | ソリューション | エンドポイントに関する考慮事項 | | ------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Apex HTTP コールアウト | エンドポイントは HTTP コールを受信できる必要があります。Salesforce が公開インターネット経由でエンドポイントにアクセスできる必要があります。プライベートで安全な通信のために、SalesforceはHyperforceプラットフォームを介したSalesforce Private Connectもサポートしています。詳細は、「Salesforce Private Connect」を参照してください。

Apex HTTP コールアウトを使用して、標準の GET、POST、PUT、DELETE、および PATCH メソッドを使用して REST サービスをコールできます。指定ログイン情報を使用してエンドポイントと必要な認証を定義し、独自の認証メカニズムを実装しないでください。 | | Apex SOAP コールアウト | エンドポイントは HTTP コールを受信できる必要があります。Salesforce が公開インターネット経由でエンドポイントにアクセスできる必要があります。プライベートで安全な通信のために、SalesforceはHyperforceプラットフォームを介したSalesforce Private Connectもサポートしています。詳細は、「Salesforce Private Connect」を参照してください。

このソリューションでは、リモートシステムが Salesforce でサポートされる標準と互換性がある必要があります。現在、Salesforce で Apex SOAP コールアウト用にサポートされている Web サービス標準は次のとおりです。 | **状態管理** システムを統合する場合、キーは継続的な状態追跡で重要です。2 つのオプションがあります。 - Salesforce は、リモートレコードのリモートシステムのプライマリまたは一意の代理キーを保存します。 - リモートシステムには、Salesforce の一意のレコード ID またはその他の一意の代理キーが保存されます。 次の表に示すように、インテグレーションキーの処理には、マスターレコードが含まれるシステムに応じて特定の考慮事項があります。 | マスター | システムの説明 | | :------------ | :----------------------------------------------------------------------------------------------------------------------------------------- | | Salesforce | リモートシステムには、Salesforce RecordId またはレコードの他の一意の代理キーが保存されます。 | | リモートシステム | リモートプロセスへのコールでアプリケーションから一意のキーが返され、Salesforce はそのキー値を一意のレコード項目に保存します。 | **複雑なインテグレーションシナリオ** 場合によっては、このパターンで規定されたソリューションで、いくつかの複雑なインテグレーションシナリオの実装が必要になることがあります。これは、ミドルウェアを使用するか、Salesforceがコンポジットサービスを呼び出すことで最適に対応できます。これらのシナリオには、次のようなものがあります。 - 複雑なフローロジックを含むビジネスプロセスとルールのオーケストレーション - 複数のシステムへのコールの集約とその結果 - 受信メッセージと送信メッセージの両方の変換 - 複数のシステムへのコール間でトランザクションの整合性を維持する **ガバナ制限** Apex の制限については、『Apex 開発者ガイド』の「[_Execution Governors and Limits_](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_gov_limits.htm)」を参照してください。 **ミドルウェア機能** 次の表は、このパターンに参加するミドルウェアシステムの望ましいプロパティを示しています。 | プロパティ | 必須 | 望ましい | 不要 | | :-------------------------------------------------------------------------------- | :-------- | :-------- | :----------- | | イベント処理 | | X | | | プロトコル変換 | | X | | | 翻訳と変換 | | X | | | キューイングとバッファリング | | X | | | 同期転送プロトコル | X | | | | 非同期転送プロトコル | | | X | | 仲介ルーティング | | X | | | プロセス振付とサービスオーケストレーション | | X | | | トランザクション性 (暗号化、署名、信頼性の高い配信、トランザクション管理) | | X | | | ルーティング | | | X | | 抽出、変換、読み込み | | | X | | ロングポーリング | | | X | | gRPC サポート (Pub/Sub API 用) | | | X | **例** ある公益事業会社は Salesforce を使用しており、顧客の請求情報を含む別のシステムを使用しています。注文プロセスの一環として、請求システムで新しい請求取引先を作成する必要があります。Salesforce は注文の有効化プロセス内で請求取引先番号を反映する必要があります。会社には、請求取引先の作成を許可し、応答として請求取引先番号を返す既存の REST API があります。 この要件は、次の方法で達成できます。 - Salesforce は、請求取引先 HTTP API を外部サービスまたはフロー HTTP コールアウトとして使用します。請求システムで HTTP API を使用せずに SOAP ベースのサービスのみを提供する場合、SOAP サービス消費に Apex プロキシ クラスのみを使用する必要があります。 - 顧客情報は外部 HTTP API オブジェクトに渡されます。 - 外部サービスまたは HTTP フローコールアウトは、Salesforce オブジェクトに保存できる HTTP API の応答を返します。 この例は、次のことを示しています。 - 顧客の状態は、Salesforce 取引先オブジェクトに保存されている取引先番号で追跡されます。 - その後、通話者は返信メッセージを処理します。 ## リモートプロセスの呼び出し — Fire and Forget (起動と忘れ) **コンテキスト** Salesforce を使用して、リードの追跡、パイプラインの管理、商談の作成、リードを顧客に変換する注文の詳細の取得を行います。ただし、注文管理プロセスの一環として、注文の請求システムで請求取引先を作成する必要があります。 このパターンを実装すると、Salesforce はリモートシステムを呼び出して請求アカウントを作成しますが、呼び出しの成功完了は待機しません。必要に応じて、リモートシステムは個別のトランザクションで作成された新しい請求取引先で Salesforce を更新できます。 **問題** Salesforce でイベントが発生したときに、リモートシステムでプロセスを開始し、リモートシステムからの応答を待たずに必要な情報をそのプロセスに渡す方法は? **勢力** このパターンに基づいてソリューションを適用するときは、次の点を考慮してください。 - リモートシステムへのコールで、処理を続行する前に Salesforce が応答を待機する必要がありますか？リモートシステムへのコールは同期か非同期か? - リモートシステムへのコールが同期の場合、Salesforce でコールと同じトランザクションの一部として応答を処理する必要がありますか? - メッセージサイズが小さいですか？ - インテグレーションは、Salesforce ユーザーインターフェースでのボタンのクリックなどの特定のイベントや DML ベースのイベントの発生に基づいていますか? - Salesforce からリモートシステムへのメッセージ配信の保証は必要ですか? - リモートシステムは、Salesforce が契約を指定する契約優先インテグレーションに参加できますか?一部のソリューションバリエーション (アウトバウンドメッセージングなど) では、Salesforce によってリモートシステムエンドポイントが実装する契約が指定されます。 - エンドポイントまたはエンタープライズサービスバス (ESB) でロングポーリングはサポートされていますか? - カスタムApex開発よりも宣言型構成方法が優先されますか?この場合、Apex コールアウトよりもプラットフォームイベントなどのソリューションが優先されます。 **ソリューション** 次の表に、このインテグレーションの問題の解決方法を示します。 | ソリューション | 適合 | コメント | | ----------------------------------------------------------------------------------- | ---------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | フロー駆動型プラットフォームイベント | 最善 | プラットフォームイベントを実装するフローを宣言的に作成します。推奨される解決策は、挿入または更新イベントからリモートプロセスを呼び出すことです。

プラットフォームイベントは、アプリケーションがさらにアクションを実行するために送受信するイベントメッセージ (または通知) です。プラットフォームイベントは、変化をやり取りしてその変化に応答するためのプロセスを簡素化します。複雑なロジックを記述することはありません。1 人以上の登録者が同じイベントをリスンしてアクションを実行できます。

たとえば、ソフトウェアシステムは、プリンターのインクカートリッジに関する情報を含むイベントを送信できます。登録者はイベントに登録して、プリンターのインクレベルを監視し、インクレベルが低いカートリッジの交換を注文できます。

外部アプリケーションは、gRPC および HTTP/2 に基づく Salesforce Pub/Sub API を使用してイベントメッセージをリスンできます。

Salesforce ではプラットフォームイベントトリガーフローもサポートされており、Flow Builder インターフェースを使用してリスナーを効率的に作成できます。この種別のフローは、特定のプラットフォームイベントメッセージが Salesforce イベントバスに公開されたときに自動的に開始されます。 | | Pub/Sub API | 最善 | Pub/Sub API は、外部コンシューマーがイベントバスでイベントを使用するための推奨方法です。

gRPC ベースの Pub/Sub API: | | 変更データキャプチャ | 最善 | Change データキャプチャ (CDC) は、作成、更新、削除、復元操作に対応する Salesforce レコードの変更イベントを公開します。Salesforce での変更データキャプチャ (CDC) の有効化は、Apex コードを必要としない純粋な宣言型プロセスです。

通知メッセージは、クライアントが Pub/Sub API または Apex トリガーを使用して登録できるイベント バスに送信されます。イベント駆動型システムは、分散した企業システム間の通信を合理化し、拡張性を高め、リアルタイムのデータを提供します。

たとえば、注文情報が ERP システムと Salesforce の両方にある場合、注文変更イベントを Salesforce からインテグレーションアプリケーションにストリーミングできます。次に、アプリケーションは ERP システムの変更を同期します。 | | イベントリレー | 最適（AWS インテグレーション付き） | Salesforce イベントリレーは、サーバーレスのローコードリアルタイムインテグレーションを提供し、Salesforce Platform イベントと変更データキャプチャ (CDC) イベントを Amazon EventBridge に直接ストリーミングします。Salesforce イベントリレーは、これらのイベントを Salesforce から Amazon Web Services (AWS) に送信し、イベントを Salesforce に送り返すことでエンドツーエンドのイベントフローを実現します。イベントリレーを使用すると、インテグレーションアプリケーションを記述することなくイベントを AWS にネイティブでストリーミングできます。 | | Omnistudio インテグレーション手順 | 良い | OmniStudio Integration Procedure を使用して、Salesforce と外部のサードパーティアプリケーション間のデータインタラクションを宣言して自動化します。Integration Procedure は、複雑なデータ変換、API コール、イベント駆動型の自動化を処理し、1 回のサーバーコールで複数のアクションを実行できます。

インテグレーション手順は、実行中にユーザーインタラクションが不要で、次の場合に使用します:Integration Procedure の詳細は、こちらを参照してください | | カスタマイズ駆動型プラットフォームイベント | 良い | フロー駆動型プラットフォームイベントに似ていますが、イベントは Apex トリガーまたはクラスによって作成されます。Apex または API を使用して、プラットフォーム イベントを公開および使用できます。

プラットフォーム イベントは、Apex トリガーを介して Salesforce Platform と統合されます。トリガーは、イベントメッセージを聞く Salesforce Platform のイベントコンシューマーです。

外部アプリケーションが API を使用するか、ネイティブ Salesforce アプリケーションが Apex を使用してイベント メッセージを公開すると、そのイベントに対するトリガーが起動されます。トリガーは、イベント通知に応じてアクションを実行します。 | | フロー駆動型アウトバウンドメッセージング | 最適ではない | これは従来のインテグレーション方法で、リモートプロセスが insert または update イベントから呼び出されるときに使用できます。Salesforce では、Salesforce の挿入操作または更新操作によってトリガーされるリモートシステムに SOAP メッセージを送信する、このフロー駆動型アウトバウンドメッセージング機能が提供されています。これらのメッセージは非同期で送信され、Salesforce ユーザーインターフェースからは独立しています。

送信メッセージは特定のリモートエンドポイントに送信されます。リモートサービスは、Salesforce が契約を提供する契約優先インテグレーションに参加できる必要があります。

メッセージの受信時に、リモートサービスが肯定的な確認応答を返さない場合、Salesforce はメッセージの送信を再試行し、確実な配信を実現します。

これは従来の統合方法です。すべての新しいソリューションで Pub/Sub API を使用したフローを使用する必要があります。 | | Apex SOAP または HTTP 非同期コールアウトを開始するカスタム Lightning コンポーネント | 最適ではない | このソリューションは通常、ユーザーインターフェースベースのシナリオで使用されますが、カスタマイズが必要です。さらに、このソリューションでは、コード内のメッセージの保証された配信を処理する必要があります。

Remote Process Invocation：指定ログイン情報を使用した Apex コールアウトと共に Lightning コンポーネントを使用するように指定する要求および返信パターン ソリューションに似ています。違いは、このパターンでは、Salesforce はリクエストの完了を待たずに、ユーザーに制御を引き渡します。

メッセージを受信すると、リモート システムは応答してメッセージの受信を示し、メッセージを非同期で処理します。リモートシステムは、メッセージの処理を開始する前に制御を Salesforce に戻します。そのため、Salesforce は処理の完了を待つ必要はありません。 | | Apex SOAP または HTTP 非同期コールアウトを実行する Apex トリガー | 最適ではない | Apexトリガーを使用して、レコード データの変更に基づいて自動化を実行できます。

Apex プロキシ クラスは、Apex トリガーを使用して、DML 操作の結果として実行できます。ただし、トリガーコンテキスト内から実行されたすべてのコールは非同期で実行する必要があります。 | | Apex SOAP または HTTP 非同期コールアウトを実行する Apex トリガー | 最適ではない | リモートシステムへのコールは一括処理ジョブから実行できます。このソリューションでは、一括リモートプロセス実行と、Salesforce でのリモートシステムからの応答の処理が可能です。ただし、特定のバッチコンテキストのコール数には制限があります。詳細は、『Salesforce Developer Limits and Allocations Quick Reference (Salesforce 開発者の制限と割り当てクイックリファレンス)』を参照してください。 | **スケッチ** 次の図は、Salesforce からリモートシステムへのコールを示しています。このコールでは、レコードに対する操作を作成または更新するとコールがトリガーされます。 ![Fire & forget を使用してリモートシステムにコールアウトする Salesforce](https://architect.salesforce.com/ns-assets/integration-patterns-fire-forget-callout.png) [図のダウンロード](https://a.sfdcstatic.com/developer-website/prod/assets/architect/pdf/integration-patterns/Integration%20Patterns%20-%20Fire%20and%20Forget.pdf) このシナリオの内容は次のとおりです。 - リモートシステムがプラットフォームイベントに登録します。 - Salesforce の特定のレコードセットで更新または挿入が実行されます。 - 一連の条件が満たされると、Salesforce フローがトリガーされます。 - このフローでは、プラットフォームイベントが作成されます。 - リモートリスナーはイベントメッセージを受信し、メッセージをローカルキューに配置します。 - キューイングアプリケーションがメッセージをリモートアプリケーションに転送して処理します。 リモートシステムが Salesforce に対して操作を実行する必要がある場合は、省略可能なコールバック操作を実装できます。 **結果** このパターンに関連するソリューションの適用により、次のことが可能になります。 - ユーザーインターフェース – トランザクションの結果をエンドユーザーに表示できるリモートプロセスの呼び出し - コール元プロセスでトランザクションの結果を処理できる DML イベント開始リモートプロセスの呼び出し **コールメカニズム** コールメカニズムは、このパターンを実装するために選択されたソリューションによって異なります。 | コールメカニズム | 説明 | | :--------------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | フロー | プロセス駆動型ソリューションとカスタマイズ駆動型ソリューションの両方で使用されます。イベントは Salesforce プロセスをトリガーし、その後、リモートシステムが購読するためのプラットフォームイベントを公開します。 | | Pub/Sub API | Pub/Sub API では、リアルタイムイベント監視イベントや変更データキャプチャチャイベントなどのプラットフォームイベントを 1 つのインターフェースで公開および登録できます。Pub/Sub API は、gRPC と HTTP/2 に基づいて、バイナリイベントメッセージを Apache Avro 形式で効率的に公開および配信します。 | | 変更データキャプチャ | Salesforce 変更データキャプチャは、Salesforce レコードへの変更を表す変更イベントを公開します。変更には、新規レコードの作成、既存のレコードの更新、レコードの削除、レコードの復元などがあります。 | | Lightning コンポーネントおよび Apex コントローラー | Apex コールアウトを使用してリモート プロセスを非同期で呼び出すために使用される。 | | Apex トリガー | トリガー駆動型プラットフォーム イベントおよびリモート プロセスの呼び出しに使用され、DML が開始するイベントからの Apex コールアウトを使用します。 | | Apex 一括処理クラス | バッチモードでのリモートプロセスの呼び出しに使用されます。 | **エラー処理と回復** エラー処理と回復戦略は、ソリューション全体の一部として考慮する必要があります。最適な方法は、選択したソリューションによって異なります。 | ソリューション | エラー処理と回復戦略 | | ------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | フロー | | | 指定ログイン情報を使用した Apex コールアウト | | | 変更データキャプチャ (CDC) / プラットフォームイベント | | **Idempotent Design Considerations (無力な設計に関する考慮事項)** プラットフォームイベントは 1 回のみバスに公開されます。Salesforce 側での再試行はありません。イベントの再生を要求するのは ESB に委ねられます。リプレイでは、プラットフォームイベントのリプレイ ID は同じままで、ESB はリプレイ ID に基づいて重複メッセージを試行できます。 「Remote Process Invocation — Request and Reply (リモートプロセス呼び出し — 要求と返信)」パターンの[設計上の](/docs/architect/ja-jp/fundamentals/guide/integration-patterns.html#remote-process-invocation--request-and-reply)考慮事項は、このパターンにも適用されます。 **セキュリティに関する考慮事項** リモートシステムへのコールでは、要求の機密性、整合性、可用性を維持する必要があります。選択したソリューションに応じて、異なるセキュリティ上の考慮事項が適用されます。 | ソリューション | セキュリティに関する考慮事項 | | ------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | 指定ログイン情報を使用した Apex コールアウト | リモートシステムへのコールでは、要求の機密性、整合性、可用性を維持する必要があります。次に、このパターンでの Apex SOAP および HTTP コールの使用に固有のセキュリティ上の考慮事項を示します。 | | 変更データキャプチャ (CDC) / プラットフォームイベント | プラットフォームイベントの場合、登録する外部システムは Salesforce ストリーミング API に対して認証できる必要があります。

プラットフォームイベントは、Salesforce 組織で設定されている既存のセキュリティモデルに準拠します。イベントに登録するには、ユーザーにイベントエンティティへの参照アクセス権が必要です。イベントを公開するには、ユーザーにイベントエンティティに対する「作成」権限が必要です。 | 「[セキュリティの考慮事項」](/docs/architect/ja-jp/fundamentals/guide/integration-patterns.html#appendix-b-security-considerations)を参照してください **サイドバー** なし。 **適時性** 適時性は、fire-and-forget パターンではあまり重要ではありません。制御は、リモートシステムへの引き継ぎが成功した直後に、または確認応答後にクライアントに渡されます。プラットフォームイベントの場合、Salesforce はイベントをイベントバスに送信し、購読者からの確認応答を待機しません。登録者がメッセージを受信しない場合、登録者はイベント返信 ID を使用してイベントの再実行を要求できます。 大量のイベントメッセージは 72 時間 (3 日間) 保存されます。過去のイベントメッセージを取得するには、Pub/Sub API を使用してチャネルを登録します。 **データボリューム** データ量に関する考慮事項は、選択するソリューションによって異なります。各ソリューションの制限については、「[Salesforce 制限クイックリファレンス](https://developer.salesforce.com/docs/atlas.en-us.salesforce_app_limits_cheatsheet.meta/salesforce_app_limits_cheatsheet/salesforce_app_limits_overview.htm)」を参照してください **エンドポイントの機能と標準のサポート** エンドポイントの機能と標準サポートは、選択したソリューションによって異なります。 | ソリューション | エンドポイントに関する考慮事項 | | ------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Apex SOAP コールアウト | エンドポイントは HTTP 経由で Web サービスコールを処理できる必要があります。Salesforce が公開インターネット経由でエンドポイントにアクセスできる必要があります。このソリューションでは、リモートシステムが Salesforce でサポートされる標準と互換性がある必要があります。この記事の執筆時点で、Salesforce で Apex SOAP コールアウト用にサポートされている Web サービス標準は次のとおりです。 | | Apex HTTP コールアウト | エンドポイントは HTTP コールを受信でき、Salesforce によってパブリックインターネットを介してアクセスできる必要があります。

Apex HTTP コールアウトを使用して、標準の GET、POST、PUT、DELETE メソッドを使用して RESTful サービスをコールできます。 | | 変更データキャプチャ (CDC) / プラットフォームイベント | | **状態管理** システムを統合する場合、一意のレコード識別子は継続的な状態追跡で重要です。たとえば、リモートシステムでレコードが作成された場合、2 つのオプションがあります。 - Salesforce は、リモートレコードのリモートシステムのプライマリまたは一意の代理キーを保存します。 - リモートシステムには、Salesforce の一意のレコード ID またはその他の一意の代理キーが保存されます。 次の表に、このパターンの状態管理に関する考慮事項を示します。 | マスター | システムの説明 | | ------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Salesforce | リモートシステムは、Salesforce RecordId または他の一意の代理キーを Salesforce レコードに保存する必要があります。 | | リモートシステム | Salesforce は、リモートシステムに一意の識別子への参照を保存する必要があります。このプロセスは非同期であるため、この一意の識別子を保存することは元のトランザクションに含めることができません。

Salesforce は、リモートプロセスへのコールで一意の ID を指定する必要があります。その後、リモートシステムは Salesforce にコールバックして、Salesforce の一意の ID を使用してリモートシステムの一意の識別子で Salesforce のレコードを更新する必要があります。

コールバックは、リモートアプリケーションが、処理完了時のコールバックに使用するためにそのトランザクションの Salesforce 一意の識別子を保存するなど、特定の状態管理を行うことを意味します。または、Salesforce の一意の識別子がリモートシステムのレコードに保存されます。 | **複雑なインテグレーションシナリオ** このパターンの各ソリューションでは、変換やプロセスオーケストレーションなどの複雑なインテグレーションシナリオに関する考慮事項が異なります。 | ソリューション | 考慮事項 | | ------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | 指定ログイン情報を使用した Apex コールアウト | 場合によっては、このパターンで規定されたソリューションで、ミドルウェアを使用するか、Salesforce に複合サービスをコールさせるのに最適な複数の複雑なインテグレーションシナリオを実装する必要があります。次のシナリオがあります。 | | 変更データキャプチャ (CDC) / プラットフォームイベント | イベントの静的で宣言的な性質上、Salesforce では集計、オーケストレーション、変換などの複雑なインテグレーションシナリオを実行できません。リモートシステムまたはミドルウェアは、次の種別の操作を処理する必要があります。 | | OmniStudio インテグレーション手順 | Integration Procedure (OmniStudio) は、複雑な宣言型のデータ変換を実行しながら複数のバックエンドサービスを調整するためのサーバー側のステートレスなオーケストレーションを提供します。

Integration Procedure では、HTTP アクション、DataRaptor 抽出/変換/読み込み、値を設定、ループ/If、マトリックスルックアップなどのステップをチェーニングして、UI 契約や異なる API 間でペイロードを正規化、強化、集計、マッピングします。

条件付き分岐、ページネーション、タイムアウト、再試行、部分的な障害の処理、エラー発生時の継続などの堅牢なランタイム制御と、サーバー側キャッシュや応答シェーピングなどのパフォーマンスの最適化をサポートしています。

IP は、OmniScript から同期的に呼び出すことも、REST を介してヘッドレスで呼び出すこともできます。これにより、バックエンドの複雑さをチャネルから隠す、再利用可能なバージョン管理された「インテグレーションの外観」が可能になります。 | **ガバナ制限** Salesforce Platform のマルチテナントの性質上、アウトバウンドコールアウトには制限があります。制限は、発信通話の種別と通話のタイミングによって異なります。 プラットフォームイベントに適用される制限と割り当てについては、『[Platforms Events Developer Guide](https://developer.salesforce.com/docs/atlas.en-us.256.0.platform_events.meta/platform_events/platform_events_intro.htm)』を参照してください。 **信頼性のあるメッセージング** 信頼性のあるメッセージングでは、個々のコンポーネントの信頼性が低いリモートシステムへのメッセージの配信を保証するという問題を解決しようとします。リモートシステムでメッセージを受信できるようにする方法は、選択したソリューションによって異なります。 Salesforce 変更データキャプチャの場合、Salesforce アプリケーションサーバーで捕捉されない変更のキャプチャや大量の変更の処理など、特殊な状況を処理するために変更イベント種別が用意されています。 場合によっては、Salesforce は変更イベントの代わりにギャップイベントを送信して、購読者にエラーを通知したり、変更イベントを生成できない場合に通知します。ギャップイベントには、変更種別やレコード ID など、ヘッダーの変更に関する情報が含まれますが、レコード項目など、変更に関する詳細は含まれません。変更をより効率的に取得するために、しきい値を超える 1 つのトランザクションに対してオーバーフローイベントが生成されます。詳細については、[こちら](https://developer.salesforce.com/docs/atlas.en-us.change_data_capture.meta/change_data_capture/cdc_other_events.htm)を参照してください。 | ソリューション | 信頼性の高いメッセージングに関する考慮事項 | | ------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | 指定ログイン情報を使用した Apex コールアウト | Salesforce では、信頼性の高いメッセージングプロトコル (WS-ReliableMessaging など) は明示的にサポートしていません。Salesforce メッセージを受信するリモートエンドポイントは、JMS や MQ などの信頼性の高いメッセージングシステムを実装することをお勧めします。このシステムにより、最終的にメッセージを処理するリモートシステムへの完全なエンドツーエンドの保証配信が保証されます。ただし、このシステムは Salesforce からコール元のリモートエンドポイントへの配信を保証しません。

配信の保証は、Salesforce のカスタマイズで対応する必要があります。カスタム再試行ロジックに加えてリモートエンドポイントからの肯定応答を処理するなど、特定の技術を実装する必要があります。 | | 変更データキャプチャ (CDC) / プラットフォームイベント | プラットフォームイベントは、イベントバスにイベントメッセージを一時的に保持することで、信頼性のあるメッセージングを提供します。登録者は、イベントメッセージのリプレイ ID を使用してイベントバスからメッセージを再生することで、見逃したイベントメッセージに気付くことができます。

イベントバスは分散システムであり、トランザクションデータベースと同じ保証はありません。そのため、Salesforce はイベント公開要求の同期応答を提供できません。イベントはキューに入れられてバッファリングされ、Salesforce はイベントを非同期で公開しようとします。まれに、初回またはその後の試行時にイベントメッセージが分散システムに保持されないことがあります。つまり、イベントは登録者に配信されず、復元できません。 | | | | **ミドルウェア機能** 次の表は、このパターンに参加するミドルウェアシステムの望ましいプロパティを示しています。 | プロパティ | 必須 | 望ましい | 不要 | | :-------------------------------------------------------------------------------- | :----------------------------- | :-------- | :----------- | | イベント処理 | | X | | | プロトコル変換 | | X | | | 翻訳と変換 | | X | | | キューイングとバッファリング | X | | | | 同期転送プロトコル | | | X | | 非同期転送プロトコル | X | | | | 仲介ルーティング | | X | | | プロセス振付とサービスオーケストレーション | | X | | | トランザクション性 (暗号化、署名、信頼性の高い配信、トランザクション管理) | X | | | | ルーティング | | | X | | 抽出、変換、読み込み | | | X | | ロングポーリング | X (ストリーミング API で必要) | | | | gRPC サポート (Pub/Sub API 用) | X | | | **ソリューションバリエーション: Platform Events Publishing Behavior and Transactions (プラットフォームイベントの公開動作とトランザクション)** プラットフォームイベントメッセージがすぐに公開される場合、イベント公開では公開プロセスのトランザクション境界が考慮されません。イベントメッセージは、トランザクションが完了する前に、またはトランザクションが失敗した場合でも公開できます。この動作により、登録者が公開トランザクションで確定されたデータの検索を期待すると問題が発生する可能性があります。登録者がイベントメッセージを受信したときにデータが存在しない場合があります。この問題を解決するには、イベント定義でプラットフォームイベントの公開動作を \[コミット後に公開] に設定します。プラットフォームイベント定義で設定できる公開動作は次のとおりです。 - \[コミット後に公開]: トランザクションが正常にコミットされた後にのみイベントメッセージを公開します。公開トランザクションがコミットするデータにサブスクライバーが依存している場合、このオプションを選択します。たとえば、あるプロセスがイベントメッセージを公開し、ToDo レコードを作成するとします。そのイベントに登録している 2 つ目のプロセスは起動したときに ToDo レコードがあることを想定しています。この動作を選択するもう 1 つの理由は、トランザクションが失敗した場合にイベントメッセージを公開したくない場合です。 - 「すぐに公開」を選択すると、公開コールの実行時にイベントメッセージが公開されます。トランザクションが成功したかどうかに関係なくイベントメッセージを公開する場合、このオプションを選択します。また、公開者と登録者が独立していて、登録者が公開者によってコミットされたデータに依存していない場合もこのオプションを選択します。たとえば、記録目的で使用されるイベントにはすぐに公開する動作が適しています。このオプションを使用すると、パブリッシャートランザクションによってデータがコミットされる前に、登録者がイベントメッセージを受信できます。 **例** ある通信会社は、リードから商談へのプロセスを利用して、取引先を作成するためのフロントエンドとして Salesforce を使用したいと考えています。商談が成立して成立したときに Salesforce で注文が作成されますが、バックエンドの ERP システムがデータマスターです。注文を Salesforce 商談レコードに保存する必要があります。また、注文が作成されたことを示すように商談の状況が変更されます。 次の制約が適用されます。 - 実装できるのは宣言型開発のみです。 - 商談が注文に変換された後に注文番号をすぐに通知する必要はありません。 - Salesforce Pub/Sub API を使用してプラットフォームイベントを登録できるように、gRPC と HTTP2 をサポートする機能があります。 この例は Salesforce プラットフォームイベントを使用して実装するのが最適ですが、ESB がプラットフォームイベントに登録する必要があります。 Salesforce 側: - プラットフォームイベントを開始するフローを作成します (商談の状況が商談成立に変更された場合など)。 - 商談の詳細を公開する新しいプラットフォームイベントを作成します。 リモートシステム側: - インテグレーションツール (ESB など) は、Pub/Sub API を使用して Salesforce Platform イベントに登録します。 - ESB は、商談が注文に変換されることを示す 1 つ以上の通知を受信します。 - 注文を作成できるように、ESB がメッセージをバックエンドの ERP システムに転送します。 - 注文が ERP システムで作成されると、別のスレッドが接続アプリケーションで OAuth 2.0 を使用して Salesforce にコールバックします。コールバックは、注文番号と状況で商談を更新します。このコールバックは、Salesforce Platform イベント、Salesforce SOAP API、REST API、Apex Web サービスなどのドキュメント化されたパターンソリューションを使用して実行できます。 この例は、次の内容を示しています。 - 非同期で呼び出されるリモートプロセスの実装 - エンドツーエンドの保証された配信 - レコードの状態を更新する Salesforce への後続のコールバック ## バッチデータ同期 **コンテキスト** CRM 実装を Salesforce に移行するときに、次のことを行う必要があります。 - 現在の CRM システムから取引先、取引先責任者、商談を抽出して変換し、データを Salesforce に読み込みます (初期データインポート)。 - 毎週 (継続的に) リモートシステムから顧客請求データを抽出、変換し、Salesforce に読み込みます。 - Salesforce から顧客活動情報を抽出し、週次 (継続) でオンプレミスデータウェアハウスにインポートします。 **問題** Salesforce へのデータのインポートと Salesforce からのデータのエクスポートは、営業時間中にエンドユーザーの業務に干渉し、大量のデータが含まれる可能性があることを考慮して、どのように行いますか? **勢力** このパターンに基づいてソリューションを適用するときには、さまざまな考慮が必要です。 - データは Salesforce に保存する必要がありますか?そうでない場合、アーキテクトが検討すべき他のインテグレーションオプション（例えば、マッシュアップ）があります。 - データを Salesforce に保存する必要がある場合、リモートシステムのイベントに応じてデータを更新する必要がありますか? - データをスケジュールに従って更新する必要がありますか? - データで主要なビジネスプロセスがサポートされているか? - このデータの Salesforce における利用可能性に影響を受ける分析（レポート）要件はありますか? **ソリューション** 次の表に、このインテグレーション問題のさまざまな解決策を示します。 | ソリューション | 適合 | データマスター | コメント | | ----------------------------------------- | ---------- | ---------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | サードパーティの ETL ツールを使用したレプリケーション | 最善 | リモートシステム | 外部システムで大量のデータを Salesforce に送信する必要がある場合は、サードパーティの ETL ツールを活用して、ソースデータに対して変更データキャプチャを実行できます。

このツールはソースデータセットの変更に対応し、データを変換してから、Salesforce Bulk API をコールして DML ステートメントを発行します。レコード数が少ない場合は、Salesforce REST API を使用して実装することもできます。 | | サードパーティの ETL ツールを使用したレプリケーション | 良い | Salesforce | ERP および Salesforce データセットに対して変更データキャプチャを実行できるようにするサードパーティの ETL ツールを活用します。

このソリューションでは、Salesforce がデータソースであり、個々の行の時間/状況情報を使用してデータを照会し、対象結果セットを絞り込むことができます。これは、一括 API 2.0 または標準 REST API (レコード数が少ない場合) を使用して実装できます。 | | Data 360 およびデータアクションと有効化 | 最善 | Data 360 | Data 360 アクションと有効化を使用して、組織間でデータを移動します。異なる組織からData 360にデータが取り込まれたら、データ アクションと有効化でデータを別の組織に同期できます。この方法は、Marketing Cloud 組織とのインテグレーションに非常に役立ちます。 | | Data 360、データグラフ、Connect API | 最善 | Data 360 | MuleSoft Anypoint を使用してデータを抽出および移動します。MuleSoft nypoint を使用して、Connect API とデータグラフ API を使用して Data 360 からデータを抽出し、別の Salesforce 組織に移動できます。Data 360 を使用しない場合、データを Data 360 で複製せずに組織間で移動する必要がある場合にも MuleSoft Anypoint を使用できます。 | | 複合グラフ API | 最善 | Salesforce | 複合グラフリソースでは、複合グラフ操作を送信できます。このリソースは、REST API バージョン 50.0 以降で使用できます。

複合グラフ API では、1 つのペイロードで最大 75 個のグラフ、1 つのグラフで最大 500 個のノードをサポートできます。 | | データインポートウィザードとデータローダー | 適合 | Salesforce/外部システム | データインポートウィザードとデータローダーを使用して、データをインポート、エクスポート、移行できます。データローダーコマンドは、データのインポートとエクスポートを自動化するためにスクリプトを作成することもできますが、コマンドラインインターフェースは Windows 専用です。どちらのツールもデータインテグレーション戦略のベースとして推奨されません。代わりに、データスチュワードシップおよびメンテナンス戦略を補完する必要があります。

詳細は、データローダの本ドキュメンテーションを参照してください。 | | リモートコールイン | 最適ではない | リモートシステム | リモートシステムがいずれかの API を使用して Salesforce にコールし、データの更新を必要に応じて実行できます。ただし、これにより 2 つのシステム間で大量のトラフィックが発生します。

エラー処理とロックをより重視する必要があります。このパターンは継続的に更新され、エンドユーザーのパフォーマンスに影響する可能性があります。 | | リモートプロセスの呼び出し | 最適ではない | Salesforce | Salesforce がリモートシステムにコールし、データの更新を必要に応じて実行できます。ただし、これにより 2 つのシステム間で大量のトラフィックが発生します。

エラー処理とロックをより重視する必要があります。このパターンは継続的に更新され、エンドユーザーのパフォーマンスに影響する可能性があります。 | **スケッチ** 次の図は、Salesforce がデータマスターであるこのパターンの一連のイベントを示しています。 ![Salesforce をデータマスターとするバッチデータ同期](https://architect.salesforce.com/ns-assets/integration-patterns-batch-sync-salesforce-master.png) 次の図は、Salesforce がデータマスターである場合のほぼリアルタイムのイベントの後続の同期を示しています。 ![ほぼリアルタイムのデータ同期](https://architect.salesforce.com/ns-assets/integration-patterns-near-realtime-sync.png) **結果** 次のシナリオでは、外部ソースのデータを Salesforce と統合できます。 - **外部システムは**データ マスターです。Salesforceは、単一ソース システムまたは複数のシステムによって提供されるデータのコンシューマーです。このシナリオでは、データを Salesforce にインポートする前にデータを集計するデータウェアハウスまたはデータマートを使用するのが一般的です。 - **Salesforce はデータマスター**です。Salesforce は特定のエンティティの記録システムであり、Salesforce 変更データキャプチャクライアントアプリケーションは Salesforce データへの変更を通知できます。 一般的な Salesforce インテグレーションシナリオでは、実装チームは次のいずれかを実行します。 - ソースデータセットに変更データキャプチャを実装します。 - 一連のサポートデータベース構造 (制御テーブル) を中間のオンプレミスデータベースに実装します。 ETL ツールでは、次のプログラムが作成されます。 - 制御テーブルを参照して、ジョブの最終実行時刻を判断し、必要な他の制御値を抽出します。 - 上記の制御値を検索条件として使用し、ソースデータセットを照会します。 - 入力規則、強化規則など、定義済みの処理ルールを適用します。 - ETL ツールの使用可能なコネクタ/変換機能を使用して、対象データセットを作成します。 - データセットを Salesforce オブジェクトに書き込みます。 - 処理が成功したら、制御テーブルの制御値を更新します。 - 処理に失敗した場合は、再起動と終了を有効にする値で制御テーブルを更新します。 **注意**: Salesforce にアクセスできない場合でも、ETL ツールがアクセスできる環境でコントロール テーブルと関連データ構造を作成することをお勧めします。これにより、十分なレベルの復元力が得られます。このプロセスでは Salesforce をスポークとして扱い、ETL インフラストラクチャをハブにします。 ETL ツールでデータ同期機能を最大限に活用するには、次の点を考慮してください。 - ETL ジョブをチェーニングおよび順序付けして、一貫性のあるプロセスを提供します。 - 両方のシステムの主キーを使用して、受信データを照合します。 - 特定の API メソッドを使用して、更新されたデータのみを抽出します。 - 主従関係または参照関係で子レコードをインポートする場合、ロックされないように、インポートしたデータをソースの親キー値を使用してグループ化します。たとえば、取引先責任者データをインポートする場合は、1 つの取引先の取引先責任者の最大数を 1 回の API コールで読み込むことができるように、必ず親取引先キーで取引先責任者データをグループ化してください。通常、インポートしたデータをグループ化しないと、最初の取引先責任者レコードが読み込まれ、その取引先の後続の取引先責任者レコードが API コールのコンテキストで失敗します。 - トリガーなどのインポート後の処理では、データのみを選択的に処理する必要があります。 - シナリオに大量のデータが含まれる場合は、この Trailhead モジュール「 [Best Practices for](https://developer.salesforce.com/page/Best_Practices_for_Deployments_with_Large_Data_Volumes) Deployments with Large Data Volumes 」のベストプラクティスに従ってください。 **エラー処理と回復** エラー処理と回復戦略は、ソリューション全体の一部として考慮する必要があります。最適な方法は、選択したソリューションによって異なります。 | エラーの場所 | エラー処理と回復戦略 | | ------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Salesforce から変更データキャプチャを使用して読み取る | | | Salesforce からサードパーティの ETL システムを使用してデータを読み取る | 操作は成功したが、失敗したレコードがある場合は、ジョブの即時再起動または後続の実行で問題に対処する必要があります。この場合、エラーの原因となっている可能性があるデータの優先順位付けと修正に時間を要するため、再起動を遅らせる方が適切な解決策になる可能性があります。 | | Salesforce への書き込み | 操作は成功したが、失敗したレコードがある場合は、ジョブの即時再起動または後続の実行で問題に対処する必要があります。この場合、エラーの原因となっている可能性があるデータの優先順位付けと修正に時間を要するため、再起動を遅らせる方が適切な解決策になる可能性があります。 | | 外部マスターシステム | エラーは、マスターシステムのベストプラクティスに従って処理する必要があります。 | **セキュリティに関する考慮事項** リモートシステムへのコールでは、要求の機密性、整合性、可用性を維持する必要があります。選択したソリューションに応じて、異なるセキュリティ上の考慮事項が適用されます。 - Salesforce APIへの認証済みAPIアクセスには、少なくともAPIのみのユーザー権限を持つLightning Platformライセンスが必要です。 - パスワードアクセスの安全性を維持するために、標準の暗号化を使用することをお勧めします。 - Salesforce API をコールするときは、HTTPS プロトコルを使用します。必要に応じて、オンプレミスセキュリティソリューションを介して Salesforce API へのトラフィックをプロキシすることもできます。 「[セキュリティの考慮事項](/docs/architect/ja-jp/fundamentals/guide/integration-patterns.html#appendix-b-security-considerations)」を参照してください。 **サイドバー** なし。 **適時性** このパターンでは適時性は重要ではありません。ただし、すべてのバッチ処理が指定されたバッチウィンドウで完了するようにインターフェースを設計する必要があります。 すべてのバッチ処理指向のオペレーションと同様に、バッチ処理ウィンドウ中にソースシステムと対象システムを切り離すことを強くお勧めします。営業時間中にバッチ読み込みを行うと競合が発生し、ユーザーの更新が失敗するか、より重大な場合にはバッチ読み込み（または部分的なバッチ読み込み）が失敗する可能性があります。 グローバルに業務を行っている組織では、システムが継続的に使用されている可能性があるため、すべての一括処理を同時に実行できない場合があります。このような場合は、レコードタイプやその他の検索条件を使用したデータセグメンテーション手法を使用して、データの競合を回避できます。 **状態管理** 2 つのシステム間で代理キーを使用して状態管理を実装できます。Salesforce エンティティ間で何らかの種別のトランザクション管理が必要な場合は、Apex を使用し[たリモート コールイン](/docs/architect/ja-jp/fundamentals/guide/integration-patterns.html#remote-call-in) パターンを使用することをお勧めします。 標準の楽観的レコードロックはプラットフォームで実行され、API を使用して更新する場合は、レコードを編集しているユーザーがレコードを更新してトランザクションを開始する必要があります。Salesforce API のコンテキストにおいて、楽観的ロックとは、次のような処理を指します: - Salesforce では、特定のユーザーが編集しているレコードの状態は保持されません。 - 参照時に、データが抽出された時刻が記録されます。 - ユーザーがレコードを更新して保存すると、Salesforce は別のユーザーがそのレコードを更新しているかどうかを確認します。 - レコードが更新されている場合、更新が行われたことがユーザーに通知され、ユーザーは更新を続行する前に最新バージョンのレコードを取得する必要があります。 **ミドルウェア機能** このパターンの実装に最も効果的な外部技術は、Informatica や MuleSoft などの従来の ETL ツールです。選択するミドルウェアツールで Salesforce Bulk API がサポートされていることが重要です。 ミドルウェアは、透かし用に内部または外部で正常に処理された最後のタイムスタンプを保存できる必要があります。最後に正常に処理されたタイムスタンプを使用して、最後に成功した実行以降の変更を消費する必要があります。 次の表は、このパターンに参加するミドルウェアシステムの望ましいプロパティを示しています。 | プロパティ | 必須 | 望ましい | 不要 | | :-------------------------------------------------------------------------------- | :---------------------------------------------- | :-------- | :----------- | | イベント処理 | | X | | | プロトコル変換 | | X | | | 翻訳と変換 | X | | | | キューイングとバッファリング | X | | | | 同期転送プロトコル | X | | | | 非同期転送プロトコル | | | X | | 仲介ルーティング | | X | | | プロセス振付とサービスオーケストレーション | X | | | | トランザクション性 (暗号化、署名、信頼性の高い配信、トランザクション管理) | | X | | | ルーティング | | X | | | 抽出、変換、読み込み | X | | | | ロングポーリング | X (Salesforce 変更データキャプチャに必要) | | | | gRPC サポート (Pub/Sub API 用) | X | | | **例** 公益事業会社は、見込み顧客を個人営業担当やチームに割り当てるメインフレームベースのバッチ処理を使用します。この情報は、夜間に 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 でのカスタマイズに対する許容範囲は? **ソリューション** 次の表に、このインテグレーションの問題に対するさまざまな解決策を示します。 | ソリューション | 適合 | コメント | | ------------------- | ------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | 複合 API | 最善 | Salesforce では、REST API である複合 API を提供しており、複合要求をサポートしています。これは、リモートシステムが次の目的で使用できるものです。同期 API — API コールが実行された後、リモートクライアントアプリケーションはサービスから応答を受信するまで待機します。

トランザクション/コミット動作 — デフォルトでは、一部のレコードがエラーでマークされている場合、複合 API では部分的な成功が許可されません。これは、「all or nothing」フラグを false としてマークすることで変更できます。これにより、部分的な成功が可能になります。

エラー処理: 適切なエラー処理では、HTTP 状況コードだけでなく、レスポンスボディを調べる必要があります。複合エンドポイントは、レスポンスボディ内でいずれかのサブリクエストが失敗し、トランザクションをロールバックする必要があることが示されていても、200 HTTP ステータスコードで応答します。 | | 複合グラフ API | 最善 | 複合グラフリソースでは、複合グラフ操作を送信できます。このリソースは、REST API バージョン 50.0 以降で使用できます。

複合グラフ API では、1 つのペイロードで最大 75 個のグラフ、1 つのグラフで最大 500 個のノードをサポートできます。 | | REST API | 最善 | アクセシビリティ — Salesforce では、リモートシステムで次の操作に使用できる REST API を提供しています。同期 API — API コールが実行された後、リモートクライアントアプリケーションはサービスから応答を受信するまで待機します。

REST API では、ログインユーザーのプロファイルに基づいて Salesforce で設定されたオブジェクトレベルおよび項目レベルセキュリティが適用されます。

REST はリソース (エンティティ/オブジェクト) を URI として公開し、HTTP 動詞を使用してこれらのリソースに対する CRUD 操作を定義します。SOAP とは異なり、REST API は定義済みの契約を必要とせず、応答に XML と JSON を使用し、型付けが緩やかです。REST API は軽量で、Salesforce を操作するためのシンプルな方法を提供します。その利点にはインテグレーションと開発の容易さが含まれ、モバイルアプリケーションや Web アプリケーションでの使用に最適です。

トランザクション/コミット動作 — デフォルトでは、各レコードは個別のトランザクションとして扱われ、個別にコミットされます。1 つのレコードの変更に失敗しても、他のレコードの変更はロールバックされません。この動作は、「全件成功または全件失敗」動作に変更することができます。REST API 複合リソースを使用して、1 回の API コールで一連の更新を行います。

一括データ — 2,000 件を超えるレコードが含まれるデータ操作は、Bulk API 2.0 で Bulk フレームワークを使用する非同期ワークフローの準備、実行、管理を正常に行うのに適しています。 | | Bulk API 2.0 | 一括処理に最適 | Bulk API 2.0 は、大規模なデータ操作を処理するための Salesforce の最新の合理化された API です。REST ベースの Bulk API 2.0 は、Salesforce org 内の大規模データセットに対する非同期的な挿入、アップサート、クエリ、および削除といった操作をプログラム上で実行するためのオプションを提供します。大量のデータを Salesforce に読み込んだり、組織のデータに対して一括クエリを実行したりする必要がある場合に、効率的に使用できるように設計されています。

Bulk API 2.0 では、バッチは常に並列で処理され、シリアルモードはサポートされません。つまり、次のようになります。Bulk API 2.0 の各バッチは、独自のトランザクションとして処理されます。つまり、次のようになります。SOAP API は大量のレコードの処理にも使用できますが、データセットに数十万から数百万のレコードが含まれている場合、SOAP API は最適ではありません。これは、オーバーヘッドが比較的大きく、パフォーマンス特性が低いためです。 | | GraphQL API | 最善 | 選択項目を含む複雑な複数オブジェクトの読み取りを伴うリモートコールインシナリオでは、GraphQL が REST API よりも優れたオプションです。 | | Pub/Sub API | 最善 | Pub/Sub API は、外部パブリッシャーがイベントバスでイベントを公開するための推奨方法です。

Pub/Sub API は、外部システムでプラットフォームイベントを公開できる gRPC ベースの API です。Pub/Sub API: | | プラットフォームイベント | 最善 | プラットフォームイベントは、Salesforce オブジェクトと同じ方法で定義されます。プラットフォームイベントは、REST API、Bulk API、SOAP API などのさまざまなメカニズムを使用して公開できます。

REST API を使用した行動の公開は、Salesforce レコードの作成と同じです。

エンドポイント形式: POST /services/data/vXX.X/sobjects/EventName__e/ Bulk API では、作成操作と挿入操作のみがサポートされます。一括処理内のイベントは、一括処理ジョブの処理時に Salesforce イベントバスに非同期で公開されます。

プラットフォームイベントは SObject であるため、標準 SOAP API 操作がサポートされています。 | | SOAP API | 最適ではない | アクセシビリティ — Salesforce は、リモートシステムで次の操作に使用できる SOAP API を提供します。同期 API — API コールが実行された後、リモートクライアントアプリケーションはサービスから応答を受信するまで待機します。Salesforce への非同期コールはサポートされていません。

生成された WSDL — Salesforce では、リモートシステムに次の 2 つの WSDL が用意されています。セキュリティ — SOAP API を実行するクライアントには、API コールを実行するための有効なログインとセッションの取得が必要です。API では、ログインユーザーのプロファイルに基づいて Salesforce で設定されたオブジェクトレベルおよび項目レベルセキュリティが適用されます。

トランザクション/コミット動作 — デフォルトでは、一部のレコードにエラーがマークされている場合、各 API コールで部分的な成功が許可されます。これは、エラーが発生した場合にすべての結果がロールバックされる「all or nothing」動作に変更できます。1 つのトランザクションを複数の API コールにまたがることはできません。この制限を克服するために、1 つの API コールで複数のオブジェクトに影響を与えることができます。

SOAP では、Salesforce オブジェクトモデル、API メカニズム、SOAP メッセージの処理に関する高度な Knowledge が必要です。これらの追加要素により、REST は SOAP よりも優先されます。 | | Apex Web サービス | 最適ではない | Apex クラスのメソッドは、Web サービスメソッドとして外部アプリケーションに公開できます。この方法は SOAP API の代替であり、通常は次の追加要件を満たす必要がある場合にのみ使用されます。Apex Web サービスを使用する利点は、Salesforce で維持する必要がある追加コードと天秤にかける必要があります。

イベント駆動型アーキテクチャではコンシューマーのトランザクション事前挿入ロジックが適用されないため、プラットフォームイベントには適用されません。イベントが発生したことを Salesforce 組織に通知するには、SOAP API、REST API、または Bulk API 2.0 を使用します。

SOAP では、Salesforce オブジェクトモデル、API メカニズム、SOAP メッセージの処理に関する高度な Knowledge が必要です。これらの追加要素により、REST は SOAP よりも優先されます。 | | Apex RESTサービス | 最適ではない | Apex クラスは、HTTP 動詞が定義された特定の URI に対応付けられた REST リソースとして公開できます（POST や GET など）。

REST API 複合リソースを使用して、1 つのトランザクションで複数の更新を実行できます。

SOAP とは異なり、クライアントがサービス定義/契約 (WSDL) を消費してクライアントスタブを生成する必要はありません。リモートシステムには、HTTP 要求を形成し、返された結果 (XML または JSON) を処理する機能のみが必要です。

イベント駆動型アーキテクチャではコンシューマーのトランザクション事前挿入ロジックが適用されないため、プラットフォームイベントには適用されません。イベントが発生したことを Salesforce 組織に通知するには、SOAP API、REST API、または Bulk API 2.0 を使用します。 | **スケッチ** 次の図は、外部イベントからの通知用の REST API または Salesforce オブジェクトを照会するための SOAP API のいずれかを使用してこのパターンを実装した場合のイベントの順序を示しています。REST API を使用する場合、イベントの順序は同じです。 **REST API を使用したリモートシステムによる Salesforce の照会** ![REST API を使用して Salesforce を照会するリモートシステム](https://architect.salesforce.com/ns-assets/integration-patterns-remote-soap-query.png) **REST API を介してイベントにより Salesforce に通知するリモートシステム** ![REST API を介してイベントにより Salesforce に通知するリモートシステム](https://architect.salesforce.com/ns-assets/integration-patterns-remote-rest-events.png) **結果** イベント駆動型アーキテクチャでは、リモートシステムは SOAP API、REST API、または Bulk API 2.0 を使用して Salesforce にコールし、イベントを Salesforce イベントバスに公開します。イベントをパブリッシュすると、すべての購読者に通知されます。イベント サブスクライバは、フロー、Lightning コンポーネント、Apex トリガーなどの Salesforce Platform 上に存在できます。イベント登録者は、Pub/Sub API 登録者など、Salesforce Platform の外部にすることもできます。 Salesforce オブジェクトを直接操作する場合、このパターンに関連するソリューションでは次のことができます。 - リモートシステムは、Salesforce API をコールしてデータベースを照会し、単一オブジェクト操作 (作成、更新、削除など) を実行します。 - 一連のオブジェクト操作を実行するために Salesforce REST API 複合リソースをコールするリモートシステム。 - マルチオブジェクトトランザクション操作とカスタム前/後処理ロジックをサポートできるカスタム組み込み Salesforce API (サービス) をコールするリモートシステム。 **呼び出しメカニズム** コールメカニズムは、このパターンを実装するために選択されたソリューションによって異なります。 | 呼び出しメカニズム | 説明 | | ----------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | SOAP API | リモートシステムは Salesforce Enterprise または Partner WSDL を使用してクライアントスタブを生成し、そのスタブを使用して標準 SOAP API を呼び出します。 | | REST API | Apex REST サービスにアクセスする前に、リモート システムを認証する必要があります。リモートシステムは、認証と承認に OAuth 2.0 を使用する必要があります。クライアントは、OAuth アクセストークンなどの適切な値を使用して認証 HTTP ヘッダーを設定する必要があります。

次に、リモートシステムは適切な動詞を使用して REST 呼び出し (HTTP 要求) を生成し、返された結果を処理します (JSON および XML データ形式がサポートされています)。 | | Apex Web サービス | リモートシステムはカスタム Apex Web サービス WSDL を使用してクライアントスタブを生成し、そのスタブを使用してカスタム Apex Web サービスを呼び出します。 | | Apex RESTサービス | REST API に従って、リソースの URI と該当する動詞は @RestResource、@HttpGet、および @HttpPost アノテーションを使用して定義されます。 | | Bulk API 2.0 | Bulk API 2.0 は REST ベースの API であるため、REST API と同じコールメカニズムが適用されます。 | | フローを呼び出すための REST API | REST API を使用して、呼び出し可能なカスタムアクションエンドポイントをコールし、自動起動フローを呼び出します。 | **エラー処理と回復** エラー処理と回復戦略は、ソリューション全体の一部として考慮する必要があります。 - エラー処理 — すべてのリモートコールインメソッド (標準 API またはカスタム API) では、タイムアウトや再試行の管理など、後続のエラーをリモートシステムで処理する必要があります。ミドルウェアを使用して、エラー処理と回復のロジックを提供できます。 - リカバリ — サービス品質の要件で必要な場合は、カスタム再試行メカニズムを構築します。この場合、最適な設計特性を確保することが重要です。プラットフォームイベントにより、登録者は再生 ID を使用して、メッセージの公開後一定期間内にメッセージを取得できます。 **Idempotent Design Considerations (無力な設計に関する考慮事項)** 冪等機能は、同一の呼び出しを繰り返しても安全であり、悪影響を及ぼさないことを保証します。イデムポテンシーが実装されていない場合、同じメッセージを繰り返し呼び出すと結果が異なる可能性があり、重複レコードの作成やトランザクションの重複処理など、データの整合性の問題が発生する可能性があります。 リモートシステムは、エラーやタイムアウトが発生した場合に複数の (重複する) コールを管理して、重複する挿入や冗長な更新を回避する必要があります (特にダウンストリームトリガーやワークフロールールが起動される場合)。これらの状況の一部は Salesforce 内で管理できますが (特にカスタム SOAP および REST サービスの場合)、エラー処理と適切な設計はリモートシステム (またはミドルウェア) で管理することをお勧めします。 **セキュリティに関する考慮事項** 選択したパターンソリューションに応じて、異なるセキュリティ上の考慮事項が適用されます。いずれの場合も、プラットフォームではログインユーザーのアクセス権 (プロファイル設定、共有ルール、権限セットなど) が使用されます。また、プロファイル IP 制限を使用して、特定の IP アドレス範囲で API へのアクセスを制限できます。 | ソリューション | セキュリティに関する考慮事項 | | :---------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | SOAP API | Salesforce では、トランスポート層セキュリティ (TLS 1.2 以上) プロトコルがサポートされています。暗号には 128 ビット以上の鍵長が必要です。 | | REST API | リモート システムで認可用の OAuth Trust を確立することをお勧めします。その後、HTTP 動詞を使用して特定のリソースに対して REST コールを実行できます。REST API をコールするクライアントは、コールごとに新しい OAuth トークンを取得するのではなく、パフォーマンスを最大化するために OAuth トークンをキャッシュして再利用することをお勧めします。 | | Apex Web サービス | リモート システムで認可用の OAuth Trust を確立することをお勧めします。 | | Apex RESTサービス | リモート システムで認可用の OAuth Trust を確立することをお勧めします。 | | Bulk API 2.0 | リモート システムで認可用の OAuth Trust を確立することをお勧めします。 | 「[セキュリティの考慮事項](/docs/architect/ja-jp/fundamentals/guide/integration-patterns.html#appendix-b-security-considerations)」を参照してください。 **サイドバー** なし。 **適時性** SOAP API と Apex Web サービス API は同期です。次のタイムアウトが適用されます。 - セッションタイムアウト — Salesforce 組織のセッションタイムアウト設定に基づいて活動がない場合、セッションはタイムアウトします。 - クエリタイムアウト — 各 SOQL クエリには 120 秒の個々のタイムアウト制限があります。 **データ量** データ量に関する考慮事項は、選択したソリューションとコミュニケーション種別によって異なります。 | ソリューション | コミュニケーション種別 | 制限 | | -------------------- | ------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | SOAP API または REST API | 同期 | | | Bulk API 2.0 | 非同期 | Bulk API 2.0 は、大量のデータを非同期でインポートおよびエクスポートできるように最適化されています。

2,000 件を超えるレコードを含むデータ操作は、Bulk API 2.0 で Bulk フレームワークを使用する非同期ワークフローを正常に準備、実行、管理するための適切な候補です。レコード数が 2,000 未満のジョブでは、REST (Composite など) または SOAP で「一括」同期コールを実行する必要があります。

Bulk API 2.0 は、一括処理要求と関連データを送信するときに同期されます。データの実際の処理は非同期で行われます。API およびバッチ処理の制限についての詳細は、「制限」を参照してください。 | **エンドポイントの機能と標準のサポート** エンドポイントの機能と標準サポートは、選択したソリューションによって異なります。 | ソリューション | エンドポイントに関する考慮事項 | | :---------------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | SOAP API | リモートシステムは、Salesforce によって事前定義されたメッセージ形式に基づいて、Salesforce SOAP API をコールできるクライアントを実装できる必要があります。リモートシステム (クライアント) は、Salesforce によって契約が提供される契約優先の実装 (Enterprise WSDL や Partner WSDL など) に参加する必要があります。 | | REST API | リモートシステムは、Salesforce (定義済みの REST サービス) を呼び出して XML または JSON の結果を処理する REST クライアントを実装できる必要があります。 | | Apex Web サービス | リモートシステムは、Salesforce で定義された定義済み形式の SOAP メッセージを呼び出すことができるクライアントを実装できる必要があります。リモート システムは、コード ファースト実装に参加する必要があります。コード ファースト実装では、Apex Web サービスの実装後に Salesforce から契約が提供されます。各 Apex Web サービスには、独自の WSDL があります。 | | Apex RESTサービス | REST API と同じエンドポイントの考慮事項が適用されます。 | **状態管理** システムを統合する場合、キー値は継続的な状態追跡で重要です。たとえば、リモートシステムでレコードが作成された場合、そのレコードの継続的な更新をサポートします。次の 2 つのオプションがあります。 - Salesforce は、リモートレコードのリモートシステムのプライマリまたは一意の代理キーを保存します。 - リモートシステムには、Salesforce の一意のレコード ID またはその他の一意の代理キーが保存されます。この同期パターンでのインテグレーションキーの処理には、特定の考慮事項があります。 | マスター | システムの説明 | | :------------ | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Salesforce | このシナリオでは、リモートシステムに Salesforce RecordId またはレコードの他の一意の代理キーが保存されます。 | | リモートシステム | このシナリオでは、Salesforce はリモートシステムに一意の識別子への参照を保存します。プロセスは同期であるため、外部 ID 項目を使用して同じトランザクションの一部としてキーを提供できます。 | **複雑なインテグレーションシナリオ** このパターンの各ソリューションでは、変換やプロセスオーケストレーションなどの複雑なインテグレーションシナリオを処理するときの考慮事項が異なります。 | ソリューション | 考慮事項 | | :------------------------------------ | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | SOAP API または REST API | SOAP API と REST API は、オブジェクトに対する簡単なトランザクションを提供します。集計、オーケストレーション、変換などの複雑なインテグレーションシナリオは、Salesforce では実行できません。これらのシナリオは、リモートシステムまたはミドルウェアで処理する必要があり、推奨方法としてミドルウェアが使用されます。 | | Apex Web サービスまたは Apex REST サービス | カスタム Web サービスでは、クロスオブジェクト機能、カスタムロジック、より複雑なトランザクションサポートを提供できます。このソリューションは慎重に使用する必要があり、変換、オーケストレーション、エラー処理ロジックに対するミドルウェアの適合性を常に考慮する必要があります。 | **ガバナ制限** Salesforce Platform のマルチテナントの性質上、API を使用する場合には制限があります。 | ソリューション | 制限 | | ---------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | SOAP API、REST API、およびカスタム Apex API | | | Bulk API 2.0 | 詳細は、「Data Volumes (データボリューム)」サイドバーを参照してください。 | | プラットフォームイベント | | **信頼性の高いメッセージング** 信頼性のあるメッセージングでは、個々のコンポーネント自体が信頼性が低い可能性があるリモートシステムへのメッセージの配信を保証するという問題を解決しようとします。Salesforce SOAP API と REST API は同期的であり、それ自体が信頼できるメッセージングプロトコル (WS-ReliableMessaging など) を明示的にサポートしません。 エラーとタイムアウトのシナリオが正常に管理されるように、リモートシステムに信頼性の高いメッセージングシステムを実装することをお勧めします。外部システムからのプラットフォームイベントの公開は Salesforce API に依存するため、SOAP API と REST API について同じ考慮事項が適用されます。 **ミドルウェア機能** 次の表は、次のパターンに関与するミドルウェアシステムの特性を示しています。 | プロパティ | 必須 | 望ましい | 不要 | | :-------------------------------------------------------------------------------- | :-------- | :------------------- | :----------- | | イベント処理 | | X | | | プロトコル変換 | | X | | | 翻訳と変換 | | X | | | キューイングとバッファリング | X | | | | 同期転送プロトコル | X | | | | 非同期転送プロトコル | | | X | | 仲介ルーティング | | X | | | プロセス振付とサービスオーケストレーション | | X | | | トランザクション性 (暗号化、署名、信頼性の高い配信、トランザクション管理) | X | | | | ルーティング | | | X | | 抽出、変換、読み込み | | X (一括 / バッチ) | | | gRPC サポート (Pub/Sub API 用) | | X | | **例** ある印刷用品およびサービス会社は、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 へのコールバック (以前に説明した要求/返信プラットフォームイベントパターンと一致)。 ## データの変更に基づく UI の更新 **コンテキスト** Salesforce を使用して顧客のケースを管理します。カスタマーサービス担当者が、ケースに取り組んでいる顧客と電話で話しています。顧客が支払を行い、カスタマーサービス担当者は支払処理アプリケーションからSalesforceアプリケーション内でリアルタイムの更新を確認し、顧客が注文の未払い金額を正常に支払ったことを示す必要があります。 **問題** Salesforce でイベントが発生したときに、画面を更新しなくても、作業を失うことなく Salesforce ユーザーインターフェースでユーザーに通知できる方法は? **勢力** このパターンに基づいてソリューションを適用するときには、さまざまな考慮が必要です。 - アクションの対象となるデータは Salesforce に保存する必要がありますか? - このデータを表示するカスタムユーザーインターフェースレイヤーを作成できますか? - カスタムユーザーインターフェースを呼び出すためのアクセス権をユーザーに付与しますか? **ソリューション** このインテグレーションの問題に対する推奨される解決策は、Salesforce でほぼリアルタイムのイベントを実現するプラットフォームイベントを使用することです。プラットフォームイベントは、Salesforce オブジェクトに依存しない構造化された柔軟なペイロードを提供します。また、再生期間が 72 時間の耐久性のあるトピックも確保されます。このウィンドウにより、オフラインコンシューマーが後で使用可能になった場合でも、イベントを使用できます。このソリューションは、次のコンポーネントで構成されます。 - トピックに関するプラットフォーム イベントをパブリッシュするロジックを含む Apex トリガーまたはフロー - Apex トリガーまたはフローからイベントをパブリッシュできるトピック - プラットフォームイベントを効率的に消費するための Pub/Sub API (gRPC および HTTP/2 に基づく) - Lightning コンポーネント - 静的リソースとして含まれる JavaScript ライブラリ **スケッチ** 次の図は、Salesforce ユーザーインターフェースに通知をストリーミングするための Pub/Sub API の実装方法を示しています。これらの通知は、Salesforce のレコードの変更によってトリガーされます。 **データ変更によってトリガーされる Salesforce の UI 更新** ![データの変更によってトリガーされる Salesforce の UI 更新](https://architect.salesforce.com/ns-assets/integration-patterns-ui-update-data-change.png) **結果** **利点** このパターンに関連するソリューションの適用には、次の利点があります。 - カスタムポーリングメカニズムを記述する必要がなくなる - ユーザーが開始するフィードバックループが不要 **サポートされていない要件** このソリューションには次の制限事項があります。 - 通知の配信は保証されません。 - 通知の順序は保証されません。 - 通知は、Bulk API によって行われたレコードの変更からは生成されません。 **セキュリティに関する考慮事項** 標準の Salesforce 組織レベルセキュリティに準拠しています。HTTPS プロトコルを使用してストリーミング API に接続することをお勧めします。「[セキュリティの考慮事項](/docs/architect/ja-jp/fundamentals/guide/integration-patterns.html#appendix-b-security-considerations)」を参照 **サイドバー** 最適なソリューションは、Salesforce でカスタムユーザーインターフェースを作成することです。カスタムユーザーインターフェースの表示に使用できる適切なユーザーインターフェースコンテナを考慮する必要があります。詳細は、『[Pub/Sub API Developer Guide](https://developer.salesforce.com/docs/platform/pub-sub-api/overview)』を参照してください。 **例** ある通信会社は、Salesforce を使用して顧客のケースを管理しています。カスタマーサービスマネージャーは、カスタマーサービス担当者の 1 人がケースを正常にクローズしたときに通知を受け取りたいと考えています。 このパターンで規定されたソリューションを実装する場合、顧客は次のことを行う必要があります。 - ステータスが「完了済み」、解決が「成功」となっているケースが保存されたときに、プラットフォームイベントを送信する Apex トリガーを作成します。 - カスタマーサービスマネージャーが使用できるカスタムユーザーインターフェースを作成します。このユーザーインターフェースは Pub/Sub API に登録し、プラットフォームイベントを消費します。 - そのマネージャーのカスタマーサービス担当が生成したアラートを表示するロジックをカスタムユーザーインターフェースに実装します。 ## データ仮想化 **コンテキスト** Salesforce を使用して、リードの追跡、パイプラインの管理、商談の作成、リードを顧客に変換する注文の詳細の取得を行います。ただし、Salesforce は注文を格納または処理するシステムではありません。注文は外部 (リモート) システムで管理されます。ただし、営業担当は、外部システムを学習したり使用したりすることなく、Salesforce でリアルタイムの注文情報を表示および更新したいと考えています。 **問題** Salesforce では、外部システムから Salesforce にデータを移動せずに、Salesforce の外部に保存されているデータを表示、検索、変更する方法は? **勢力** このパターンに基づいてソリューションを適用するときには、さまざまな考慮が必要です。 - Salesforce で宣言型/ポイント＆クリック型の送信インテグレーションまたは UI マッシュアップを構築したいですか？ - Salesforce 組織にコピーしたくない大量のデータがありますか? - 少量のリモートシステムデータにいつでもアクセスする必要がありますか? - 最新データへのリアルタイムアクセスが必要ですか? - データをクラウドまたはバックオフィスシステムに保存しますが、Salesforce 組織でそのデータを表示または処理する必要がありますか? - Salesforce への特定の種別のデータの保存に関してデータレジデンシーの懸念がありますか? **ソリューション** 次の表に、このインテグレーション問題のさまざまな解決策を示します。 | ソリューション | 適合 | コメント | | ---------------------------------------- | ---------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Salesforce Connect | 最善 | Salesforce Connectを使用して、Salesforceデータと共に外部ソースのデータにアクセスします。Salesforce でデータのコピーを作成せずに、SAP、Microsoft、Oracle などのシステム、Snowflake などのクラウドベースのシステムからリアルタイムにデータを取得します。

Salesforce Connect は、外部システムのデータテーブルを組織の外部オブジェクトに対応付けます。外部オブジェクトはカスタムオブジェクトと似ていますが、Salesforce 組織外のデータに対応付けられる点が異なります。Salesforce Connect では、外部データへのライブ接続を使用して、常に外部オブジェクトを最新の状態に保ちます。外部オブジェクトにアクセスすると、外部システムからデータがリアルタイムで取得されます。

Salesforce Connect では、次のことができます。Salesforce Connect を使用して外部システムに保存されているデータにアクセスするには、次のいずれかのアダプタを使用できます。 | | Data 360 とゼロコピー | 最善 | ERP などの外部システムでレコードを更新する場合、標準のコネクタを使用するか、MuleSoft などの API やプロコードツールを使用して、レコードの更新を Data 360 に同期できます。

ゼロコピーメカニズム (一部のプラットフォームで使用可能) を使用して、Data 360 でレコードを参照することもできます。Data 360 でデータが使用できるようになると、データを他の Salesforce 組織に同期するためにさまざまな標準インテグレーションメカニズムを使用できます。データは、Data Cloud One を使用して参照でアクセスできます。

有効化や他の API を使用して標準のコネクタを使用するか、MuleSoft Anypoint プラットフォームなどのプロコードツールを使用してデータを複製することもできます。

注意: Data 360 のデータは編集できません。これが要件の場合は、Salesforce Connect を使用します。 | | Data 360、Data Cloud One、Salesforce | 最善 | Data 360 と Data Cloud One を使用して、さまざまなソースのデータをハーモナイズします。Customer 360データ モデル、ID解決、データ統合、その他の機能によって、Data 360はSalesforceやその他の外部システムのデータを顧客の統合ビューに統合します。Data Cloud Oneを使用すると、他のSalesforce組織のユーザーは、Data 360から仮想的に共有されたデータに安全にアクセスできます。

注意: Data 360 のデータは編集できません。これが要件の場合は、Salesforce Connect を使用します。 | | 要求と返信 | 最適ではない | Salesforce Web サービス API を使用して、外部システムデータにアクセスして更新するためのアドホックデータ要求を実行します。このソリューションには、次のアプローチが含まれます。

Salesforce SOAP API を使用します。カスタムページまたはボタンは、同期方法で Apex REST/SOAP コールアウトを開始します。Salesforce では、WSDL を使用して、結果のプロキシ Apex クラスを生成できます。このクラスは、リモートサービスをコールするために必要なロジックを提供します。次に、ページでユーザーが開始するアクションは、このプロキシ Apex クラスを実行する Apex コントローラのアクションをコールして、リモートコールを実行します。ページには、Salesforce アプリケーションのカスタマイズが必要です。

Salesforce REST API を使用します。カスタムページまたはボタンは、同期方式で Apex HTTP コールアウト (REST サービス) を開始します。Salesforce では、標準の GET、POST、PUT、DELETE メソッドを使用して HTTP サービスを呼び出すことができます。

このソリューションについての詳細は、「Remote Process Invocation — Request and Reply (リモートプロセス呼び出し — 要求と応答)」を参照してください。 | **スケッチ** 次の図は、Salesforce Connect を使用して、Odata アダプタを使用して外部システムからデータを取り込む方法を示しています。 ![Salesforce Connect Odataアダプター アーキテクチャ](https://architect.salesforce.com/ns-assets/integration-patterns-salesforce-connect-odata.png) このシナリオの内容は次のとおりです。 - ブラウザーは AJAX コールを実行し、続いて対応する外部オブジェクトアダプターでアクションを実行します。 - アダプタはアクションを Odata 要求に変換し、インテグレーション層とサービス層を介してリモートシステムに対して HTTP GET 要求を実行します。 - リモートシステムはインテグレーションレイヤーとサービスレイヤーを介して JSON 応答を Salesforce に返します。 - 応答は Odata から外部オブジェクトに変換され、ブラウザに返されます。 **結果** このパターンに関連するソリューションの適用により、エンドユーザーにトランザクションの結果を表示するユーザーインターフェースの起動が可能になります。 **コールメカニズム** コールメカニズムは、このパターンを実装するために選択されたソリューションによって異なります。 | コールメカニズム | 説明 | | :------------------- | :---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | 外部オブジェクト | Salesforce Connect は、Salesforce 外部オブジェクトを外部システムのデータテーブルにマッピングします。組織にデータをコピーする代わりに、Salesforce Connect は必要なときにリアルタイムでデータにアクセスします。データが組織の外部に保存されていても、Salesforce ConnectはSalesforce Platformとのシームレスな統合を実現します。外部オブジェクトは、グローバル検索、参照関係、レコードフィード、Salesforce モバイルアプリケーションなどの Salesforce ツールで使用できます。外部オブジェクトはまた、Apex、SOSL、SOQL クエリ、Salesforce API、およびメタデータ API、変更セット、パッケージを介したリリースでも使用できます。 | | Lightning コンポーネント | リモートプロセスがユーザーインターフェースを含むエンドツーエンドのプロセスの一部としてトリガーされ、その結果を Salesforce レコードに表示または更新する必要がある場合に使用されます。たとえば、クレジットカード支払を外部支払ゲートウェイに送信し、ユーザーに表示される支払結果をすぐに返すプロセスです。ユーザー インターフェイス イベントからトリガーされるインテグレーションでは、通常、カスタムLightningコンポーネントを作成する必要があります。 | **エラーハンドリング** 全体的なソリューションの一部としてエラー処理を含めることが重要です。エラーが発生した場合（例外またはエラーコードが呼び出し元に返された場合）、呼び出し元がエラーハンドリングを管理します。[Salesforce Connect Validator](https://appexchange.salesforce.com/listingDetail?listingId=a0N3A00000EJHQ6UAP)は、一般的なクエリを実行し、エラーの種類と失敗の原因を把握できる無料のツールです。 **利点** Salesforce Connectソリューションを使用するメリットには、次のようなものがあります。 - このソリューションでは、Salesforce のデータストレージは消費されません。 - ユーザーは、外部システムと Salesforce 間で定期的にデータを同期することを心配する必要はありません。 - OData または 組織間アダプタを使用して、または カスタム Apex アダプタを使用して最小限のコードで迅速に実現できる宣言型設定。 - ユーザーは、外部オブジェクトの形式でカスタムオブジェクトとほぼ同じ機能を使用して外部データにアクセスできます。 - グローバル検索を使用して、接続された外部システムで統合検索を実行する機能。 - クラウドおよびオンプレミスのソースから外部データにアクセスするレポートを実行する機能。レポートに関する考慮事項を参照してください。 **Salesforce Connectの考慮事項** Salesforce Connectソリューションでは、次の考慮事項があります。 - 外部オブジェクトはカスタムオブジェクトのように動作しますが、一部の機能は外部オブジェクトでは使用できません。詳細は、「[Salesforce Compatibility Considerations for Salesforce Connect](https://help.salesforce.com/articleView?id=platform_connect_considerations_compatibility.htm&type=5&language=en_US)」を参照してください。 - 外部オブジェクトは、レポートのパフォーマンスに影響する可能性があります。詳細は、「[Report Considerations for Salesforce Connect](https://help.salesforce.com/s/articleView?id=platform.platform_connect_considerations_reports.htm&type=5) (Salesforce Connect のレポートに関する考慮事項)」を参照してください。 - Salesforce Connect アダプタの使用に関するその他の考慮事項については、「[Considerations for Salesforce](https://help.salesforce.com/s/articleView?id=platform.platform_connect_considerations.htm&type=5) Connect — All Adapters」を参照してください。 - 組織間アダプタの使用を検討している場合は、「[Considerations for Salesforce](https://help.salesforce.com/s/articleView?id=platform.xorg_considerations.htm&type=5) Connect — Cross-Org Adapter」(Salesforce Connect — 組織間アダプタに関する考慮事項)を参照してください。 - Odata アダプタの使用を検討している場合は、「[Considerations for Salesforce](https://help.salesforce.com/s/articleView?id=platform.odata_considerations.htm&type=5) Connect — Odata 2.0 and 4.0 Adapters」を参照してください。 - カスタム Apex アダプタの使用を検討している場合は、「[Considerations for Salesforce](https://help.salesforce.com/s/articleView?id=platform.apex_adapter_considerations.htm&type=5) Connect — Custom Adapter」を参照してください。 **セキュリティに関する考慮事項** このパターンのソリューションは、標準の Salesforce 組織レベルセキュリティに準拠する必要があります。HTTPS プロトコルを使用して任意のリモートシステムに接続することをお勧めします。詳細は、「[セキュリティの考慮事項](/docs/architect/ja-jp/fundamentals/guide/integration-patterns.html#appendix-b-security-considerations)」を参照してください。 Odata コネクタを使用している場合は、Odata 外部データソースのクロスサイト要求フォージェリ (CSRF) の特殊な動作、制限事項、推奨事項を理解してください。詳細については、「Salesforce Connect — Odata 2.0 および 4.0 アダプターに関する [CSRF の考慮事項](https://help.salesforce.com/s/articleView?id=platform.odata_considerations_csrf.htm&type=5)」を参照してください。 **サイドバー** なし。 **適時性** このパターンでは、タイミングが非常に重要です。次の点に留意してください。 - 通常、要求はユーザーインターフェースから呼び出されるため、このプロセスでユーザーを待たせてはなりません。 - 外部システムの可用性および外部システムへの接続によっては、外部データの取得に時間がかかることがあります。Salesforce では、外部システムからの応答を待機する最大タイムアウト値を 120 秒に設定できるようになっています。 - リモートプロセスは、タイムリーに実行され、Salesforce のタイムアウト制限内かつユーザーの期待に沿う形で完了する必要があります。 **データボリューム** このパターンは、タイムアウト値が小さく、Apex コール ソリューションの要求または応答の最大サイズが小さいため、主に少量のリアルタイム アクティビティで使用されます。メッセージにデータペイロードが含まれる一括処理活動では、このパターンを使用しないでください。 **エンドポイントの機能と標準のサポート** エンドポイントの機能と標準サポートは、選択したソリューションによって異なります。 | ソリューション | エンドポイントに関する考慮事項 | | ------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Salesforce Connect | Odata API — Open Data Protocolを使用して、Salesforceの外部に保存されているデータにアクセスします。外部データは、OData プロデューサー経由で公開されている必要があります。

その他のAPI — Apexコネクターフレームワークを使用して、使用可能な他のアダプタがニーズに適していない場合に自分のカスタムアダプタを開発できます。カスタムアダプターは、任意のソースからデータを取得できます。たとえば、一部のデータはコールアウトを介してインターネットから取得でき、他のデータはプログラムで操作したり生成したりできます。

Salesforce に接続 — Salesforce Platform REST API を使用して、他の Salesforce 組織に保存されているデータにアクセスします。

Connect via Middleware — Salesforce ConnectパートナーエコシステムはSalesforceと密接に連携し、ミドルウェアゲートウェイがサービスからODataエンドポイントを公開することで、Salesforceが追加のコードを記述せずに接続できるようにします。 | | 要求 & 返信 | Apex SOAP コールアウト -

エンドポイントは HTTP 経由で Web サービスコールを受信できる必要があります。

Apex HTTP コールアウト -

エンドポイントは HTTP コールを受信できる必要があります。

Apex HTTP コールアウトを使用して、標準の GET、POST、PUT、DELETE メソッドを使用して RESTful サービスをコールできます。 | **状態管理** システムを統合する場合、進行中の状態追跡では鍵が重要です。たとえば、レコードがリモートシステムで作成された場合、通常、レコードには継続的な更新をサポートする何らかの識別キーが必要です。鍵の保存には 2 つのオプションがあります。 - Salesforce は、リモートレコードの主サロゲートキーまたは一意のサロゲートキーを保存します。 - リモートシステムには、Salesforce の一意のレコード ID またはその他の一意の代理キーが保存されます。この同期パターンでのインテグレーションキーの処理には、特定の考慮事項があります。 | マスターシステム | 説明 | | :------------ | :----------------------------------------------------------------------------------------------------------------------------------------- | | Salesforce | リモートシステムには、Salesforce レコード ID またはレコードの他の一意のサロゲートキーが保存されます。 | | リモートシステム | リモートプロセスへのコールでアプリケーションから一意のキーが返され、Salesforce はそのキー値を一意のレコード項目に保存します。 | **複雑なインテグレーション** 場合によっては、このパターンで規定されたソリューションで複雑なインテグレーションシナリオの実装が必要になることがあります。これらのシナリオは多くの場合、ミドルウェアを使用して解決されます。 - 複数のシステムへのコールの集計とその結果 - 受信メッセージと送信メッセージの両方の変換 - 複数のシステムへのコール間でトランザクションの整合性を維持する - Salesforce と外部システム間のその他のプロセスオーケストレーション活動 **管理上の制限** アダプターごとに異なる制限が適用されます。詳細は、「[Salesforce Connect の一般](https://help.salesforce.com/s/articleView?id=platform_connect_general_limits.htm&type=5)的な制限」を参照してください。 **ミドルウェア機能** 次の表は、このパターンに参加するミドルウェアシステムの望ましいプロパティを示しています。 | プロパティ | 必須 | 望ましい | 不要 | | :-------------------------------------------------------------------------------- | :-------- | :-------- | :----------- | | イベント処理 | | X | | | プロトコル変換 | X | | | | 翻訳と変換 | X | | | | キューイングとバッファリング | X | | | | 同期転送プロトコル | X | | | | 非同期転送プロトコル | | X | | | 仲介ルーティング | | X | | | プロセス振付とサービスオーケストレーション | | X | | | トランザクション性 (暗号化、署名、信頼性の高い配信、トランザクション管理) | X | | | | ルーティング | | | X | | 抽出、変換、読み込み | | | X | | ロングポーリング | | | X | | gRPC サポート (Pub/Sub API 用) | | | X | **外部オブジェクトリレーション** 外部オブジェクトでは、18 文字の Salesforce レコード ID を使用して関連レコードを関連付ける標準参照関係がサポートされます。ただし、Salesforce 組織の外部に保存されたデータは、多くの場合レコード ID が含まれていません。そのため、外部オブジェクトでは、外部参照と間接参照という、2 つの特殊なタイプの参照関係を使用できます。 この表には、外部オブジェクトで使用できるリレーション種別がまとめられています。 | リレーション | 許可された子オブジェクト | 許可された親オブジェクト | レコードを照合する親項目 | | :-------------- | :------------------------- | :--------------------- | :--------------------------------------------------------------- | | 参照 | 標準、カスタム、外部 | 標準、カスタム | 18 文字の Salesforce レコード ID | | 外部参照 | 標準、カスタム、外部 | 外部 | 外部 ID 標準項目 | | 間接参照 | 外部 | 標準、カスタム | \[外部 ID] 属性と \[一意] 属性を持つカスタム項目を選択する | **Salesforce Connect: Odata 2.0 および 4.0 アダプタの高データボリュームに関する考慮事項** 組織が外部オブジェクトにアクセスするときにレート制限に達した場合、関連付けられた外部データソースで \[高データボリューム] オプションを選択することを検討してください。このオプションを選択すると、ほとんどのレート制限が迂回されますが、一部の特殊動作と制限は適用されます。詳細については、「[High Data Volume Considerations](https://help.salesforce.com/s/articleView?id=platform.odata_considerations_high_data_volume.htm&type=5) for Salesforce Connect (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 はバックエンドアプリケーションにリアルタイムコールアウトを実行します。 ## 付録 A: リソース **デベロッパードキュメンテーション** - [_Salesforce ヘルプ: インテグレーションユーザーへの API 限定アクセス権の付与_](https://help.salesforce.com/s/articleView?id=platform.integration_user.htm&type=5) - [_Pub/Sub APIの概要_](https://developer.salesforce.com/docs/platform/pub-sub-api/overview) - [_SOAP API 開発者ガイド_](https://developer.salesforce.com/docs/atlas.en-us.api.meta/api/sforce_api_quickstart_intro.htm) - [_REST API開発者ガイド_](https://developer.salesforce.com/docs/atlas.en-us.api_rest.meta/api_rest/intro_what_is_rest_api.htm) - [_ストリーミング API 開発者ガイド_](https://developer.salesforce.com/docs/atlas.en-us.api_streaming.meta/api_streaming/intro_stream.htm) - [_Bulk API 2.0 および Bulk API 開発者ガイド_](https://developer.salesforce.com/docs/atlas.en-us.api_asynch.meta/api_asynch/asynch_api_intro.htm) - [_Apex 開発者ガイド_](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_dev_guide.htm) - [_SOQL および SOSL リファレンス_](https://developer.salesforce.com/docs/atlas.en-us.soql_sosl.meta/soql_sosl/sforce_api_calls_soql_sosl_intro.htm) - [_Salesforce 開発者向け制限および割り当てクイックリファレンス_](https://developer.salesforce.com/docs/atlas.en-us.salesforce_app_limits_cheatsheet.meta/salesforce_app_limits_cheatsheet/salesforce_app_limits_overview.htm) - [_プラットフォームイベント開発者ガイド_](https://developer.salesforce.com/docs/atlas.en-us.platform_events.meta/platform_events/platform_events_intro.htm) - [_Salesforce Connect(ヘルプおよびトレーニング)_](https://help.salesforce.com/s/articleView?id=platform.platform_connect_about.htm&type=5) - [_Apex開発者ガイド: Salesforce Connect_](https://help.salesforce.com/s/articleView?id=platform.platform_connect_about.htm&type=5) - [Salesforce Connectについて](https://unofficialsf.com/understanding-salesforce-connect/) - [_プラットフォームイベントメッセージの耐久性_](https://developer.salesforce.com/docs/platform/pub-sub-api/guide/event-message-durability.html) - [指定ログイン情報 開発者ガイド](https://developer.salesforce.com/docs/platform/named-credentials/overview) - [Apex 開発者ガイド: 指定ログイン情報の使用](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_callouts_named_credentials.htm) - [指定ログイン情報 (ヘルプ & トレーニング)](https://help.salesforce.com/s/articleView?id=xcloud.named_credentials_about.htm&type=5) - [指定ログイン情報について](https://unofficialsf.com/understanding-named-credentials/) - [プライベートコネクト (ヘルプおよびトレーニング)](https://help.salesforce.com/s/articleView?id=xcloud.private_connect_overview.htm&language=en_US&type=5) - [プライベートコネクトの概要](https://unofficialsf.com/understanding-private-connect/) **Trailhead** - [_大規模データボリューム_](https://trailhead.salesforce.com/content/learn/modules/large-data-volumes) - [_プラットフォームイベントの基本_](https://trailhead.salesforce.com/content/learn/modules/platform_events_basics) - [_変更データキャプチャの基本_](https://trailhead.salesforce.com/content/learn/modules/change-data-capture) - [_クイックスタート: Salesforce Connect_](https://trailhead.salesforce.com/content/learn/projects/quickstart-lightning-connect) ## 付録 B: 従来の Salesforce インテグレーション製品 Salesforce は、より高速でイベント駆動型のアーキテクチャに移行しています。セキュリティと拡張性を維持するために、従来のインテグレーションツールからの移行が必要になりました。多くの古いツールでは、SOAP やロングポーリング (CometD) などの古いプロトコルが使用されているため、Pub/Sub API の効率的な gRPC ベースの配信や Flow Builder の自動化機能に対応できません。準備するには、まず既存のインテグレーションを監査してハードコードされた連動関係を見つけます。これは、Salesforce が Salesforce-to-Salesforce などの機能を廃止（Spring '27 までに完全に廃止）し、従来の認証方法を段階的に廃止し始めているため、特に重要です。移行を計画するときは、内部ビジネスロジックには「フローファースト」アプローチ、外部データストリームには「公開/サブファースト」アプローチを使用します。これにより、今日の AI 搭載プラットフォームのデータ要求に対応する柔軟で疎結合なアーキテクチャが提供されます。 Salesforce SOAP API の `login()` コールが廃止されます。API v65.0 以降ではすでに使用できません。新しい Salesforce 組織では`login()`がデフォルトで無効になり、既存の組織で引き続き使用するには新しい「任意の API 認証を使用」権限が必要です。最終期限はSummer '27で、SalesforceはすべてのAPIバージョン（31.0から64.0）で`login()`を完全に廃止します。 | 商品 | 状況 | 推奨の代替方法 | 移行戦略 | | ------------------------ | --------------------------------------------------------------------------------------------------- | --------------------------------- | ------------------------------------------------------------------------------------------------------------ | | アウトバウンドメッセージング | レガシー (サポート) | フロー + プラットフォームイベント | 再試行ロジックと最新の認証を強化するために、フローをトリガーとするプラットフォームイベントに置き換えます。 | | プロセスビルダー | [サポート終了](https://help.salesforce.com/s/articleView?id=001096524&type=1) | Flow Builder | 「フローに移行」ツールを使用して既存のプロセスを変換し、複雑なロジックをパフォーマンスに合わせてリファクタリングします。 | | Salesforce-to-Salesforce | [Spring '27 の廃止](https://help.salesforce.com/s/articleView?id=005103355&type=1) | Salesforce Connect または Pub/Sub API | MuleSoft を使用した Salesforce 変更データキャプチャ、Salesforce Connect、または Pub/Sub API への移行 | | Streaming API (ストリーミング API) | レガシー (サポート) | Pub/Sub API | Pub/Sub API に移行すると、スループットが向上し、サブスクリプション管理が簡素化された gRPC を利用できます。 | | SOAP API `login()` | [従来 (2027 年 6 月までサポート)](https://help.salesforce.com/s/articleView?id=005132110&type=1) | OAuth 2.0 フロー | 外部クライアントアプリケーションを使用して OAuth2.0 に移行します。 | ## 付録 C: セキュリティに関する考慮事項 エンタープライズポートフォリオの有効なメンバーになるには、すべてのアプリケーションを作成し、関連するセキュリティメカニズムと統合する必要があります。最新のIT戦略では、オンプレミスとクラウドベースのサービスを組み合わせて使用します。 通常、クラウド間サービスの統合は Web サービスと関連する認証に焦点が絞られますが、オンプレミスとクラウドサービスを接続すると複雑さが増します。このセクションでは、セキュリティツール、技術、Salesforce 固有の考慮事項について説明します。 **リバースプロキシサーバ** リバースプロキシは、Web サーバーの前に配置され、クライアント (Web ブラウザーなど) 要求をそれらの Web サーバーに転送するサーバーです。リバースプロキシは通常、セキュリティ、パフォーマンス、信頼性を高めるために実装されます。 これは、クライアントの代わりに 1 つ以上のサーバーからリソースを取得するプロキシサーバーの一種です。これらのリソースは、プロキシサーバー自体から取得されたかのようにクライアントに返されます。フォワードプロキシは、関連付けられたクライアントが任意のサーバーに接続するための仲介者ですが、リバースプロキシは、関連付けられたサーバーが任意のクライアントから接続するための仲介者です。 Salesforce 実装では、通常、このようなサービスは外部ゲートウェイ製品を介して提供されます。たとえば、Apache HTTP、lighttpd、nginx などのオープンソースオプションを使用できます。商用製品には、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 ログイン情報 (MuleSoft、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 への定期的な更新に基づく定期的なレビューが必要になるリスクのため、お勧めしません。 **その他のセキュリティに関する考慮事項** - **指定ログイン情報:**Salesforceは、接続とIDの懸念を明確に区別する2階層の指定ログイン情報モデルを導入して、認証アーキテクチャを刷新しました。Apex を使用してコールアウトを実行するときは必ずこれを使用し、独自の認証プロトコルを作成しないようにします。これにより、拡張性とセキュリティも向上します。外部認証情報は、このモデルの基礎となります。実際の認証の詳細を保存し、OAuth 2.0 クライアントログイン情報、JWT ベアラー、AWS 署名 V4 などの豊富なプロトコルをサポートすると同時に、プリンシパルのマッピング方法 (1 つの指定ユーザー (すべてのユーザーで共有) またはユーザーごとのプリンシパル (各ユーザーが独自の ID を使用して認証)) を定義します。次に、指定ログイン情報はエンドポイントレイヤーとして機能します。コールアウト URL を定義し、外部ログイン情報を参照して認証ハンドシェイクを処理し、エンドポイント設定をログイン情報管理から明確に分離します。ユーザーごとの認証フローを有効にするには、管理者は権限セットを適切な外部ログイン情報プリンシパルに対応付けて、適切な権限セット割り当てを持つユーザーのみが自分の ID でコールアウトを呼び出せるようにします。この2層設計により、セキュアなコールアウト設定が簡略化されるだけでなく、アーキテクトはSalesforceに接続されたシステム全体での認証方法に対し、はるかに高い柔軟性とガバナンス制御を実現できます。詳細については、[指定ログイン情報ドキュメント](https://help.salesforce.com/s/articleView?id=xcloud.named_credentials_about.htm&type=5)を参照してください。 - **OAuth 2.0:** OAuth 2.0 は業界標準の認証フレームワークです。ユーザーは、認証情報 (パスワードなど) を共有することなく、保護されたリソースへの制限付きアクセス権をサードパーティアプリケーションに付与できます。ユーザーは、パスワードを直接交換する代わりにアクセストークン要求を承認し、アプリケーションはこれを使用してリソースサーバーからユーザーのデータにアクセスします。このプロセスでは、クライアントアプリケーションをユーザーの ID とパスワードから分離し、リソースにアクセスするための一時的な範囲固有の「鍵」を提供することでセキュリティを強化します。詳細は、[OAuth 2.0 ドキュメント](https://help.salesforce.com/s/articleView?id=xcloud.remoteaccess_oauth_flows.htm&type=5)を参照してください。厳格な OAuth 2.1 準拠のエンドポイントの場合、アーキテクチャの第 3 層 (外部認証 ID プロバイダー) を使用して、2.1 準拠の方法で IDP とのやりとりを管理できます。 - **プライベートコネクト:** Salesforce組織をサードパーティのクラウドサービスでホストされるアプリケーションと統合する場合、HTTP/秒トラフィックを安全に送受信できることが不可欠です。プライベートコネクトでは、Salesforce 組織と AWS Virtual Private Cloud (VPC) の間に完全に管理された安全な接続を設定することにより、Amazon Web Services (AWS) インテグレーションでのセキュリティを強化できます。次に、クロスクラウドトラフィックを公開インターネットではなく接続を介して転送し、部外者のセキュリティ脅威にさらされるリスクを軽減します。プライベートコネクトは、AWS とのパートナーシップで AWS PrivateLink という機能を介して使用できます。プライベートコネクトは双方向で、受信トラフィックと送信トラフィックの両方を開始できます。受信接続では、標準 API を使用してトラフィックを Salesforce に送信できます。送信接続では、Apex コールアウト、外部サービス、外部オブジェクトなどの機能を介してトラフィックを Salesforce から送信できます。詳細については、[プライベートコネクトに関する本ドキュメンテーション](https://help.salesforce.com/s/articleView?id=xcloud.private_connect_overview.htm&type=5)を参照してください。 ## 付録 D: イベント駆動型アーキテクチャ プラットフォームイベント、変更データキャプチャ (CDC)、および Pub/Sub API を備えた Salesforce イベントバスを使用すると、企業はイベント駆動型スタイルアーキテクチャ (EDA) を作成できます。 EDA では、イベントメッセージのコンシューマー (登録者) がイベントメッセージのプロデューサー (公開者) から切り離されるため、拡張性と柔軟性が向上します。このドキュメントでは、関連する代替またはオプションを比較対照する既存のパターン構造の一部として特定のパターンを取り上げています。ただし、イベント駆動型アーキテクチャとパターンの相互作用について包括的に理解することで、ニーズに適したパターンを選択できます。 ## 著者について Khalid Mohamed は、Salesforce のプロフェッショナルサービスにおける優れたアーキテクトリーダーです。2015 年に Salesforce に入社して以来、エンタープライズアプリケーションとアーキテクチャに関する広範な専門知識を活用し、Salesforce での職務を果たすまでに多くの顧客変革を経験してきました。Khalid は、デリバリーアーキテクチャ委員会を統括し、認定テクニカルアーキテクトリーダーとしても高く評価されています。 Gulal Kumar は、Salesforce のソフトウェアエンジニアリングアーキテクトで、データおよびインテグレーションアーキテクチャに重点を置いています。インテグレーションと API、モダナイゼーションプログラム、セキュリティ、AIML イニシアチブで 21 年以上の経験があり、豊富な専門知識を備えています。Gulal は、ビジネス変革イニシアチブを推進し、セキュリティと耐障害性を強化し、アーキテクチャの卓越性を促進し、さまざまなドメインで AIML イニシアチブをリードしてきました。 Sushant Verma は、ソリューションアーキテクチャと Salesforce プラットフォームのエンドツーエンドの提供を専門とする Salesforce のテクニカルアーキテクトです。プラットフォームガバナンス、アプリケーション開発、インテグレーション、DevOps に関する深い専門知識を持ち、さまざまな業種の多数の顧客変革プログラムを率いてきました。Sushant は、卓越したデリバリーの実現と、スケールに優れたアーキテクチャの成果の達成に向けて邁進しています。