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

  • イベントを転送する場所の特定
  • その転送アクションを実行する
  • 転送されたイベントの受信
  • ログへの書き込み、エラーまたはリカバリプロセスの送信、追加メッセージの送信など、応答として何らかの適切なアクションを実行する

イベントハンドラーは最終的にイベントをイベントコンシューマーに転送できます。

ミドルウェアでのこの機能の一般的な用途は、一般的な「Publish/Subscribe (公開/登録)」または「pub/sub (公開/サブ)」機能に拡張できます。公開/登録シナリオでは、ミドルウェアは有効なデータイベントパブリッシャーからの有効なデータイベント登録者に要求またはメッセージを転送します。有効なリスナーを持つこれらのコンシューマーは、公開時にイベントを取得できます。
ミドルウェアを使用する Salesforce インテグレーションでは、ミドルウェアレイヤーがイベント処理の制御を引き受けます。同期または非同期のすべての関連イベントを収集し、Salesforce を含むすべてのエンドポイントへの配信を管理します。

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

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

多くの場合、ミドルウェアの翻訳および変換ツールには、従来のエンドポイントやその他の非標準エンドポイントのサービスの外観を作成する機能が含まれています。これらのサービス正面により、これらのエンドポイントはサービス対応可能であるように表示されます。

Salesforce インテグレーションでは、ミドルウェアレイヤーまたはエンドポイントによってそのような要件が満たされていることが前提となります。 データの変換は Apex でコーディングできますが、メンテナンスとパフォーマンスの考慮事項からお勧めしません。
キューイングとバッファリング 一般に、キューイングとバッファリングは、要求-応答アーキテクチャとは異なり、非同期メッセージパッシングに依存します。非同期システムでは、対象プログラムがビジー状態の場合や接続性が低下している場合に、メッセージキューによって一時的なストレージが提供されます。また、ほとんどの非同期ミドルウェアシステムは、メッセージキューをバックアップする永続的なストレージを提供します。

非同期メッセージプロセスの主な利点は、何らかの理由で受信者アプリケーションが失敗した場合でも、送信者が影響を受けずに続行できることです。送信されたメッセージは、受信者が再起動したときに後で処理できるようにメッセージキューに蓄積されます。
Salesforce では、ワークフローベースのアウトバウンドメッセージングの形式で明示的なキューイング機能のみを提供しています。オーケストレーション、プロセス振付、サービス品質など、他のインテグレーションシナリオで真のメッセージキューを提供するには、ミドルウェアソリューションが必要です。
同期転送プロトコル 同期転送プロトコルとは、「通話者の 1 つのスレッドが要求メッセージを送信し、応答メッセージを待機してブロックし、応答を処理する」活動をサポートするプロトコルです。応答を待機している要求スレッドは、1 つの未処理の要求のみが存在するか、この要求の応答チャネルがこのスレッドで非公開であることを意味します。
非同期転送プロトコル 非同期転送プロトコルとは、「通話者の 1 つのスレッドが要求メッセージを送信し、返信のコールバックを設定する」活動をサポートするプロトコルです。別のスレッドが返信メッセージをリスンします。返信メッセージが届くと、返信スレッドは適切なコールバックを呼び出して、通話者のコンテキストを再確立し、返信を処理します。この方法では、複数の未処理の要求で 1 つの返信スレッドを共有できます」
仲介ルーティング 仲介ルーティングは、コンポーネント間のメッセージの複雑な「フロー」の仕様です。たとえば、ミドルウェアベースのソリューションの多くはメッセージキューシステムに依存しています。実装によっては、メッセージングレイヤー自体でルーティングロジックを提供できますが、クライアントアプリケーションに依存してルーティング情報を提供したり、両方のパラダイムを混在させたりすることもできます。このような複雑なケースでは、ミドルウェア側で仲介することで、開発、インテグレーション、検証が簡素化されます。 ordinator (仲介者) は、適切なメッセージを適切な消費者に確実に届けることができます」
プロセス振付とサービスオーケストレーション プロセス振付とサービスオーケストレーションは、任意の数のエンドポイントと機能が調整される「サービス構成」の各形式です。

振付とサービスオーケストレーションの違いは次のとおりです。
  • 振付は、プロセスが自律的に作業できるようにする非同期アプローチとして定義でき、中央の権限を持たない個々のエンティティの相互作用のグループに起因する動作である連動関係に起因する問題を排除します。
  • オーケストレーションは、各マイクロサービスがオーケストレーターによって割り当てられた ToDo を実装できるようにすることで、クエリまたはプロセスの実行を可能にする同期アプローチとして定義できます。これは、一元的なコンダクターが互いに独立して ToDo を実行する個々のエンティティの動作を調整した結果の動作です。
さらに、オーケストレーションは各サービスの完全な動作を示し、コレオグラフィーは各サービスのインターフェース動作の説明を組み合わせます。
ビジネスプロセスの振付の一部は、Salesforce ワークフローで作成することも、Apex を使用して作成することもできます。Salesforce タイムアウト値とガバナ制限のため、特に真のトランザクション処理が必要なソリューションでは、すべての複雑なオーケストレーションをミドルウェアレイヤーに実装することをお勧めします。
トランザクション性 (暗号化、署名、信頼性の高い配信、トランザクション管理) トランザクション性は、必要な各リソースに対する必要なすべての操作を含むグローバルトランザクションをサポートする機能として定義できます。トランザクション性は、4 つの ACID プロパティ (原子性、一貫性、分離性、耐久性) すべてをサポートすることを意味します。原子性は、作業単位 (トランザクション) の結果がすべて揃うか、まったく揃わないかを保証するものです。

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

Salesforce インテグレーションでは、ミドルウェアレイヤーまたはエンドポイントによってそのような要件が満たされていることが前提となります。メッセージ ルーティングは Apex でコーディングできますが、メンテナンスとパフォーマンスの考慮事項からお勧めしません。
抽出、変換、読み込み 抽出、変換、読み込み (ETL) とは、次のプロセスを指します。
  • ソースシステムからデータを抽出する。通常、このプロセスには、複数のソースシステム、およびリレーショナル構造と非リレーショナル構造の両方のデータが含まれます。
  • 運用ニーズに合わせてデータを変換します。これには、データ品質レベルが含まれる場合があります。通常、変換フェーズでは、ソースから抽出されたデータに一連のルールまたは関数を適用して、最終対象に読み込むデータを派生します。
  • ターゲットシステムにデータを読み込み中。対象システムは、データベース、運用データストア、データマート、データウェアハウス、その他の運用システムなど、さまざまです。
厳密には必要ありませんが、ほとんどの成熟した ETL ツールには変更データキャプチャ機能があります。この機能は、前回の抽出以降に変更されたソースシステムのレコードをツールで識別するものであり、レコード処理量を削減します。

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

Salesforce ストリーミング API では、長時間のポーリングに Bayeux プロトコルと CometD が使用されます。
  • Bayeux は、主に HTTP を介して非同期メッセージを転送するためのプロトコルです。
  • CometD は、Comet と呼ばれる AJAX プッシュ技術パターンを使用するスケーラブルな HTTP ベースのイベントルーティングバスです。Bayeux プロトコルを実装しています。
## リモートプロセス呼び出し — 要求と返信 **コンテキスト** Salesforce を使用して、リードの追跡、パイプラインの管理、商談の作成、リードを顧客に変換する注文の詳細の取得を行います。ただし、Salesforce システムには注文は含まれず、処理されません。注文の詳細が Salesforce に取り込まれると、注文がリモートシステムに作成され、そこで完了までの注文が管理されます。 このパターンを実装すると、Salesforce はリモートシステムをコールして注文を作成し、正常に完了するまで待機します。成功すると、リモートシステムは注文状況と注文番号で同期応答します。同じトランザクションの一環として、Salesforce は注文番号と状況を内部で更新します。注文番号は、リモートシステムの後続の更新で外部キーとして使用されます。 **問題** Salesforce でイベントが発生したときに、リモートシステムでプロセスを開始し、必要な情報をそのプロセスに渡してリモートシステムから応答を受信し、その応答データを使用して Salesforce 内で更新を行うにはどうすればよいでしょうか? **勢力** このパターンに基づいてソリューションを適用するときは、次の点を考慮してください。 - リモートシステムへのコールで、処理を続行する前に Salesforce が応答を待機する必要がありますか?リモートシステムへのコールは同期要求-応答か非同期要求か? - リモートシステムへのコールが同期の場合、Salesforce は応答を最初のコールと同じトランザクションの一部として処理する必要がありますか? - メッセージサイズは小さいか大きいか? - インテグレーションは、Salesforce ユーザーインターフェースでのボタンのクリックなどの特定のイベントや DML ベースのイベントの発生に基づいていますか? - リモートエンドポイントは低遅延で要求に応答できますか?ピーク時にこのトランザクションを実行する可能性が高いユーザーの数は? **ソリューション** 次の表に、このインテグレーションの問題の解決方法を示します。
ソリューション 適合 コメント
外部サービスが REST API コールを呼び出す 最善 外部サービスでは、外部でホストされるサービスを宣言型で呼び出すことができます (コードは必要ありません)。この機能は、次の条件を満たす場合に最適です。
  • 外部でホストされるサービスは RESTful サービスであり、定義は OpenAPI 2.0、OpenAPI 3.0、または YAML スキーマ形式で使用できます。
  • 要求定義と応答定義には、Boolean、datetime、double、integer、string、またはプリミティブデータ型の配列などのプリミティブデータ型が含まれます。ネストされたオブジェクト種別と、HTTP 要求内のヘッダーなどの送信パラメーターがサポートされます。
  • トランザクションはフローから呼び出すことができます。
Salesforce Lightning：Lightning コンポーネントまたはページが同期 Apex REST または SOAP コールアウトを開始します。</

リモート エンドポイントが高レイテンシ応答のリスクになる場合(適用される制限については、最新の制限に関するドキュメントを参照してください)、同期Apexトランザクション ガバナ制限に達しないように、継続とも呼ばれる非同期コールアウトをお勧めします。 		最善 Salesforce では、WSDL を使用して、結果のプロキシ Apex クラスを生成できます。このクラスは、リモートサービスをコールするために必要なロジックを提供します。

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

Lightning ページでユーザーが開始するアクションは、このプロキシ Apex クラスを実行してリモート コールを実行する Apex コントローラ アクションをコールします。Lightning ページには、Salesforce アプリケーションのカスタマイズが必要です。
Salesforceデータの変更から呼び出される同期トリガーは、非同期Apex SOAPまたはHTTPコールアウトを実行します。 最適ではない Apexトリガーを使用して、レコード データの変更に基づいて自動化を実行できます。

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

1 つのバッチ実行で複数のトランザクションコンテキストを実行できます (通常は 200 レコード間隔)。ガバナ制限はトランザクションコンテキストごとにリセットされます。
**スケッチ** 次の図は、Apex コールを使用した同期リモートプロセス呼び出しを示しています。 **リモートシステムへの Salesforce コールアウト** リモートシステムへの Salesforce コールアウト 図のダウンロード
このシナリオの内容は次のとおりです。 - 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 (無力な設計に関する考慮事項)** Idempotent 機能は、繰り返しの呼び出しが安全であることを保証します。緊急性が実装されていない場合、同じメッセージを繰り返し呼び出すと結果が異なる可能性があり、データの整合性の問題が発生する可能性があります。潜在的な問題として、重複レコードの作成やトランザクションの重複処理などがあります。 コールされるリモートプロシージャが適切であることを確認することが重要です。ユーザーインターフェースによってコールが行われる場合、特に Salesforce が 1 回しかコールしない保証がない場合は、インテグレーションレイヤーで緊急性を考慮する必要があります。 最も典型的な受信者の作成方法は、コンシューマーが送信した一意のメッセージ識別子に基づいて重複を追跡することです。Apex Web サービスまたは REST コールは、一意のメッセージ ID を送信するようにカスタマイズする必要があります。 また、リモートシステムでレコードを作成する操作では、挿入する前に重複を確認する必要があります。Salesforce から一意のレコード ID を渡して確認します。リモートシステムにレコードが存在する場合は、レコードを更新します。ほとんどのシステムでは、この操作は更新/挿入操作と呼ばれます。 **セキュリティに関する考慮事項** リモートシステムへのコールでは、要求の機密性、整合性、可用性を維持する必要があります。次のセキュリティ上の考慮事項は、このパターンでの Apex SOAP および HTTP コールの使用に固有です。 - 一方向 SSL はデフォルトで有効になっていますが、クライアントとサーバーの両方の認証を維持するために、自己署名証明書と CA 署名証明書の両方で双方向 SSL がサポートされます。 - Apex コードを合理化し、認証済みコールアウトの設定を簡略化するには、コールアウト エンドポイントで指定ログイン情報を指定します。 - 外部システムと統合するための認証メカニズムとして OAUTH 2.0 を使用することを検討してください。 - 必要に応じて、要求の整合性を確保するために、Apex Crypto クラスのメソッドを使用して一方向ハッシュまたはデジタル署名を使用することを検討します。 - リモートシステムは、適切なファイアウォールメカニズムを実装して保護する必要があります。「[セキュリティの考慮事項](#付録-bセキュリティに関する考慮事項)」を参照してください。 - 現在、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 サービス標準は次のとおりです。
  • WSDL 1.1
  • SOAP 1.1
  • WSI-Basic Profile 1.1
**状態管理** システムを統合する場合、キーは継続的な状態追跡で重要です。2 つのオプションがあります。 次の表に示すように、インテグレーションキーの処理には、マスターレコードが含まれるシステムに応じて特定の考慮事項があります。
マスター システム 説明
Salesforce リモートシステムには、Salesforce RecordId またはレコードの他の一意の代理キーが保存されます。
リモートシステム リモートプロセスへのコールでアプリケーションから一意のキーが返され、Salesforce はそのキー値を一意のレコード項目に保存します。
**複雑なインテグレーションのシナリオ** 場合によっては、このパターンで規定されたソリューションで、いくつかの複雑なインテグレーションシナリオの実装が必要になることがあります。これは、ミドルウェアを使用するか、Salesforce に複合サービスをコールさせることが最適です。次のシナリオがあります。 **ガバナ制限** Apex の制限については、『Apex 開発者ガイド』の「_Execution Governors and Limits_」を参照してください。 **ミドルウェア機能** 次の表は、このパターンに参加するミドルウェアシステムの望ましいプロパティを示しています。
プロパティ 必須 望ましい 不要
イベント処理 X
プロトコル変換 X
翻訳と変換 X
キューイングとバッファリング X
同期転送プロトコル X
非同期転送プロトコル X
仲介ルーティング X
プロセス振付とサービスオーケストレーション X
トランザクション性 (暗号化、署名、信頼性の高い配信、トランザクション管理) X
ルーティング X
抽出、変換、読み込み X
long polling X
**例** ある公益事業会社は Salesforce を使用しており、顧客の請求情報を含む別のシステムを使用しています。注文プロセスの一環として、新しい請求取引先を請求システムで作成する必要があります。また、Salesforce は注文の有効化プロセス内で Billing 取引先番号を反映する必要があります。請求取引先の作成を許可し、応答として請求取引先番号を返す既存の Web サービスがあります。 この要件は、次の方法で達成できます。
  1. Salesforce は、Apex プロキシ クラスから Billing Account Service WSDL を使用します。
  2. カスタム Apex コントローラまたは外部サービスから外部 Web サービスに渡される顧客情報を使用して、Apex プロキシ クラスを実行します。
  3. 次に、カスタム コントローラは Apex コールアウトからの戻り値を解析し、その情報を salesforce オブジェクトに保存します。
この例は、次のことを示しています。 ## リモートプロセスの呼び出し — Fire and Forget (起動と忘れ) **コンテキスト** Salesforce を使用して、リードの追跡、パイプラインの管理、商談の作成、リードを顧客に変換する注文の詳細の取得を行います。ただし、注文管理プロセスの一環として、注文の請求システムで請求取引先を作成する必要があります。 このパターンを実装すると、Salesforce はリモートシステムをコールして請求取引先を作成しますが、通話の正常な完了は待機しません。必要に応じて、リモートシステムは個別のトランザクションで作成された新しい請求取引先で Salesforce を更新できます。 **問題** Salesforce でイベントが発生したときに、リモートシステムでプロセスを開始し、リモートシステムからの応答を待たずに必要な情報をそのプロセスに渡す方法は? **勢力** このパターンに基づいてソリューションを適用するときは、次の点を考慮してください。 **ソリューション** 次の表に、このインテグレーションの問題の解決方法を示します。
ソリューション 適合 コメント
フロー駆動型プラットフォームイベント 最善 プラットフォームイベントを実装するフローを宣言的に作成します。推奨される解決策は、挿入または更新イベントからリモートプロセスを呼び出すことです。

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

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

外部アプリケーションは、CometD を介してチャネルを登録することでイベントメッセージを聞くことができます。Lightningコンポーネントなどのプラットフォーム アプリケーションも、CometDを使用してイベント メッセージを登録できます。gRPC と HTTP/2 に基づく Salesforce PubSub Api もここで使用できます。

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

gRPC ベースの Pub/Sub API :
  • 外部アプリケーションからのプラットフォームイベントの公開と登録の両方をサポート
  • 適切な認証 (OAuth、JWT、またはセッショントークン) で使用可能

Salesforce でプラットフォームイベントが定義されると、内部消費者と外部消費者の両方が使用できるようになります。
変更データキャプチャ 最善 Change データキャプチャ (CDC) は、作成、更新、削除、復元操作に対応する Salesforce レコードの変更イベントを公開します。Salesforce での変更データキャプチャ (CDC) の有効化は、Apex コードを必要としない純粋な宣言型プロセスです。

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

たとえば、注文情報が ERP システムと Salesforce の両方にある場合、注文変更イベントを Salesforce からインテグレーションアプリケーションにストリーミングできます。次に、アプリケーションは ERP システムの変更を同期します。
Omnistudio インテグレーション手順 良い OmniStudio Integration Procedure を使用して、Salesforce と外部のサードパーティアプリケーション間のデータインタラクションを宣言して自動化します。Integration Procedure は、複雑なデータ変換、API コール、イベント駆動型の自動化を処理し、1 回のサーバーコールで複数のアクションを実行できます。

Integration Procedure は、実行中にユーザー操作が不要で、次の場合に使用します。
  • Salesforce と外部システム間のデータの取得、変換、送信
  • パフォーマンスと拡張性を向上させるために、処理をサーバーにオフロード
  • 1 つのサーバートランザクションに複数の操作をバンドル
  • 頻繁にアクセスされる情報のデータキャッシュを有効にする

Integration Procedure についての詳細は、こちらを参照してください
カスタマイズ駆動型プラットフォームイベント 良い フロー駆動型プラットフォームイベントに似ていますが、イベントは Apex トリガーまたはクラスによって作成されます。Apex または API を使用して、プラットフォーム イベントを公開および使用できます。

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

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

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

メッセージの受信時に、リモートサービスが肯定的な確認応答を返さない場合、Salesforce はメッセージの送信を再試行し、確実な配信を実現します。
Apex SOAP または HTTP 非同期コールアウトを開始するカスタム Lightning コンポーネント 最適ではない このソリューションは通常、ユーザーインターフェースベースのシナリオで使用されますが、カスタマイズが必要です。さらに、このソリューションでは、コード内のメッセージの保証された配信を処理する必要があります。

Remote Process Invocation — Request and Reply (要求および返信) パターンソリューションに似ています。Lightning コンポーネントと Apex コールアウトの使用を指定します。違いは、このパターンでは、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 からリモートシステムへのコールを示しています。このコールでは、レコードに対する操作を作成または更新するとコールがトリガーされます。 リモートシステムへの Salesforce コールアウト 図のダウンロード
このシナリオの内容は次のとおりです。
  1. リモートシステムがプラットフォームイベントに登録します。
  2. Salesforce の特定のレコードセットで更新または挿入が実行されます。
  3. 一連の条件が満たされると、Salesforce フローがトリガーされます。
  4. このフローでは、プラットフォームイベントが作成されます。
  5. リモートリスナーはイベントメッセージを受信し、メッセージをローカルキューに配置します。
  6. キューイングアプリケーションがメッセージをリモートアプリケーションに転送して処理します。
リモートシステムが Salesforce に対して操作を実行する必要がある場合は、省略可能なコールバック操作を実装できます。 **結果** このパターンに関連するソリューションの適用により、次のことが可能になります。 **コールメカニズム** コールメカニズムは、このパターンを実装するために選択されたソリューションによって異なります。
コールメカニズム 説明
フロー プロセス駆動型ソリューションとカスタマイズ駆動型ソリューションの両方で使用されます。イベントは Salesforce プロセスをトリガーし、その後、リモートシステムで登録するプラットフォームイベントを公開できます。
Pub / Sub API Pub/Sub API では、リアルタイムイベント監視イベントや変更データキャプチャチャイベントなどのプラットフォームイベントを 1 つのインターフェースで公開および登録できます。Pub/Sub API は、gRPC と HTTP/2 に基づいて、バイナリイベントメッセージを Apache Avro 形式で効率的に公開および配信します。
変更データキャプチャ Salesforce 変更データキャプチャは、Salesforce レコードへの変更を表す変更イベントを公開します。変更には、新規レコードの作成、既存のレコードの更新、レコードの削除、レコードの復元などがあります。
LightningコンポーネントおよびApexコントローラ Apex コールアウトを使用してリモート プロセスを非同期で呼び出すために使用される。
フロー駆動型アウトバウンドメッセージング アウトバウンドメッセージングソリューションでのみ使用されます。DML イベントを作成および更新すると、Salesforce ワークフロールールがトリガーされ、リモートシステムにメッセージを送信できます。
Apex トリガー トリガー駆動型プラットフォーム イベントおよびリモート プロセスの呼び出しに使用され、DML が開始するイベントからの Apex コールアウトを使用します。
Apex 一括処理クラス バッチモードでのリモートプロセスの呼び出しに使用されます。
**エラー処理と回復** エラー処理と回復戦略は、ソリューション全体の一部として考慮する必要があります。最適な方法は、選択したソリューションによって異なります。
ソリューション エラー処理と回復戦略
フロー
  • エラー処理 — 特定の条件では、フローの処理が完全に失敗する可能性があります。プロセスやフローインタビューが失敗すると、そのプロセスまたはフローを最後に変更したシステム管理者に詳細なメールが送信されます。失敗する可能性があるすべての要素に障害パスを追加して、デフォルトの動作を変更します。この動作は、ケースの作成や、監視および追跡できるカスタムオブジェクトへのエラーの書き込みなどのカスタム動作を組み込むように拡張する必要があります。
  • リカバリ ：このシナリオでは、リカバリがより複雑になります。Quality of Service 要件によってカスタム再試行メカニズムを作成する必要があります。
Apex コールアウト
  • エラー処理 — リモートシステムは終了プロセスの呼び出しを引き継ぐため、コールアウトではリモートサービスの最初の呼び出しの例外のみが処理されます。たとえば、リモートコールアウトから肯定的な確認応答を受信しなかった場合にタイムアウトイベントがトリガーされます。リモートシステムは、最初の呼び出しが非同期処理のために渡されたときに、後続のエラーを処理する必要があります。
  • リカバリ ：このシナリオでは、リカバリがより複雑になります。Quality of Service 要件によってカスタム再試行メカニズムを作成する必要があります。
変更データキャプチャ (CDC) / プラットフォームイベント
  • エラー処理 — イベントは事実上リモートシステムに引き継がれてさらに処理されるため、リモートサービスによってエラー処理を実行する必要があります。このパターンは非同期であるため、リモートシステムがメッセージのキュー、処理、およびエラー処理を処理します。また、プラットフォームイベントはデータベーストランザクション内で処理されません。そのため、公開されたプラットフォームイベントをトランザクション内でロールバックすることはできません。
  • 復旧 — このパターンは非同期であるため、リモートシステムはサービスの Quality of Service 要件に基づいて再試行を開始する必要があります。各イベントに関連付けられたリプレイ ID はアトミックで、公開イベントごとに増加します。この ID は、特定のイベントからストリームを再生するために使用します (たとえば、最後に正常にキャプチャされたイベントに基づきます)。大規模プラットフォームイベントメッセージは 72 時間 (3 日) 保存されます。CometD クライアントを使用してチャネルを登録すると、過去のイベントメッセージを取得できます。
**Idempotent Design Considerations (無力な設計に関する考慮事項)** プラットフォームイベントは 1 回のみバスに公開されます。Salesforce 側での再試行はありません。イベントの再実行の要求は ESB に任されます。リプレイでは、プラットフォームイベントのリプレイ ID は同じままで、ESB はリプレイ ID に基づいて重複メッセージを試行できます。 即時性は非同期であり、肯定的な確認が受信されなかったときに再試行が開始されるため、アウトバウンドメッセージングでは重要です。そのため、リモートサービスは Salesforce からのメッセージを適切に処理できる必要があります。 アウトバウンドメッセージングでは、メッセージごとに一意の ID が送信され、この ID は再試行で同じままです。リモートシステムは、この一意の ID に基づいて重複メッセージを追跡できます。更新される各レコードの一意のレコード ID も送信され、重複するレコードの作成を防止できます。 「Remote Process Invocation — Request and Reply (リモートプロセス呼び出し — 要求と返信)」パターンの設計上の考慮事項は、このパターンにも適用されます。 **セキュリティに関する考慮事項** リモートシステムへのコールでは、要求の機密性、整合性、可用性を維持する必要があります。選択したソリューションに応じて、異なるセキュリティ上の考慮事項が適用されます。
ソリューション セキュリティに関する考慮事項
Apex コールアウト リモートシステムへのコールでは、要求の機密性、整合性、可用性を維持する必要があります。次に、このパターンでの Apex SOAP および HTTP コールの使用に固有のセキュリティ上の考慮事項を示します。
  • 一方向 SSL はデフォルトで有効になっていますが、クライアントとサーバーの両方の認証を維持するために、自己署名証明書と CA 署名証明書の両方で双方向 SSL がサポートされます。
  • Salesforce では、Apex プロキシ クラスの生成時に WS-Security をサポートしません。
  • 必要に応じて、要求の整合性を確保するために、Apex Crypto クラスのメソッドを使用して一方向ハッシュまたはデジタル署名を使用することを検討します。
  • リモートシステムは、適切なファイアウォールメカニズムを実装して保護する必要があります。
変更データキャプチャ (CDC) / プラットフォームイベント プラットフォームイベントの場合、登録する外部システムは Salesforce ストリーミング API に対して認証できる必要があります。

プラットフォームイベントは、Salesforce 組織で設定されている既存のセキュリティモデルに準拠します。イベントに登録するには、ユーザーにイベントエンティティへの参照アクセス権が必要です。イベントを公開するには、ユーザーにイベントエンティティに対する「作成」権限が必要です。
「セキュリティの考慮事項」を参照してください **サイドバー** なし。 **適時性** タイムリーさは、火と忘れのパターンでは影響しません。制御は、リモートシステムへの引き継ぎが成功した直後に、または確認応答後にクライアントに渡されます。Salesforce アウトバウンドメッセージングでは、確認は 24 時間以内に行う必要があります (最大 7 日間まで延長できます)。それ以外の場合、メッセージは期限切れになります。プラットフォームイベントの場合、Salesforce はイベントをイベントバスに送信し、登録者からの確認や確認を待機しません。登録者がメッセージを受信しない場合、登録者はイベント返信 ID を使用してイベントの再実行を要求できます。大規模イベントメッセージは 72 時間 (3 日) 保存されます。過去のイベントメッセージを取得するには、CometD クライアントを使用してチャネルを登録します。 **データボリューム** データ量に関する考慮事項は、選択するソリューションによって異なります。各ソリューションの制限については、「Salesforce 制限クイックリファレンス」を参照してください **エンドポイントの機能と標準のサポート** エンドポイントの機能と標準サポートは、選択したソリューションによって異なります。
ソリューション エンドポイントに関する考慮事項
Apex SOAP コールアウト エンドポイントは HTTP 経由で Web サービスコールを処理できる必要があります。Salesforce が公開インターネット経由でエンドポイントにアクセスできる必要があります。このソリューションでは、リモートシステムが Salesforce でサポートされる標準と互換性がある必要があります。この記事の執筆時点で、Salesforce で Apex SOAP コールアウト用にサポートされている Web サービス標準は次のとおりです。
  • WSDL 1.1
  • SOAP 1.1
  • WSI-Basic Profile 1.1
  • HTTP
Apex HTTP コールアウト エンドポイントは HTTP コールを受信でき、Salesforce によってパブリックインターネットを介してアクセスできる必要があります。

Apex HTTP コールアウトを使用して、標準の GET、POST、PUT、DELETE メソッドを使用して RESTful サービスをコールできます。
変更データキャプチャ (CDC) / プラットフォームイベント
  • トリガー、プロセス、フローはイベントを登録できます。イベント通知は、公開方法に関係なく受信できます。
  • CometD を使用して、外部クライアントからプラットフォームイベントを登録します。独自の CometD クライアントを実装するか、コミュニティでサポートされるオープンソースのツールである EMP コネクタを使用します。EMP コネクタは、CometD への接続とチャネルのリッスンに関するすべての詳細を実装します。Salesforce は、プラットフォームイベントを受信した順序で CometD クライアントに順次送信します。イベント通知の順序は、イベントの再生 ID に基づきます。
**状態管理** システムを統合する場合、一意のレコード識別子は継続的な状態追跡で重要です。たとえば、リモートシステムでレコードが作成された場合、2 つのオプションがあります。 次の表に、このパターンの状態管理に関する考慮事項を示します。
マスター システム 説明
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』を参照してください。 **信頼できるメッセージング** 信頼性のあるメッセージングでは、個々のコンポーネントの信頼性が低いリモートシステムへのメッセージの配信を保証するという問題を解決しようとします。リモートシステムでメッセージを受信できるようにする方法は、選択したソリューションによって異なります。 Salesforce 変更データキャプチャの場合、Salesforce アプリケーションサーバーで捕捉されない変更のキャプチャや大量の変更の処理など、特殊な状況を処理するために変更イベント種別が用意されています。 場合によっては、Salesforce は変更イベントの代わりにギャップイベントを送信して、登録者にエラーを通知したり、変更イベントを生成できない場合に通知したりします。ギャップイベントには、変更種別やレコード ID など、ヘッダーの変更に関する情報が含まれます。レコード項目など、変更に関する詳細は含まれません。変更をより効率的に取得するために、しきい値を超える 1 つのトランザクションに対してオーバーフローイベントが生成されます。詳細については、こちらを参照してください。
ソリューション 信頼性の高いメッセージングに関する考慮事項
Apex コールアウト Salesforce では、信頼性の高いメッセージングプロトコル (WS-ReliableMessaging など) は明示的にサポートしていません。Salesforce メッセージを受信するリモートエンドポイントは、JMS や MQ などの信頼性の高いメッセージングシステムを実装することをお勧めします。このシステムにより、最終的にメッセージを処理するリモートシステムへの完全なエンドツーエンドの保証配信が保証されます。ただし、このシステムは Salesforce からコール元のリモートエンドポイントへの配信を保証しません。

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

イベントバスは分散システムであり、トランザクションデータベースと同じ保証はありません。そのため、Salesforce はイベント公開要求の同期応答を提供できません。イベントはキューに入れられてバッファリングされ、Salesforce はイベントを非同期で公開しようとします。まれに、初回またはその後の試行時にイベントメッセージが分散システムに保持されないことがあります。つまり、イベントは登録者に配信されず、復元できません。
**ミドルウェア機能** 次の表は、このパターンに参加するミドルウェアシステムの望ましいプロパティを示しています。
プロパティ 必須 望ましい 不要
イベント処理 X
プロトコル変換 X
翻訳と変換 X
キューイングとバッファリング X
同期転送プロトコル X
非同期転送プロトコル X
仲介ルーティング X
プロセス振付とサービスオーケストレーション X
トランザクション性 (暗号化、署名、信頼性の高い配信、トランザクション管理) X
ルーティング X
抽出、変換、読み込み X
long polling X (プラットフォームイベントで必要)
**ソリューションバリエーション — プラットフォームイベント:Publishing Behavior and Transactions (公開動作とトランザクション**) プラットフォームイベントメッセージがすぐに公開される場合、イベント公開では公開プロセスのトランザクション境界が考慮されません。イベントメッセージは、トランザクションが完了する前に、またはトランザクションが失敗した場合でも公開できます。この動作により、登録者が公開トランザクションで確定されたデータの検索を期待すると問題が発生する可能性があります。登録者がイベントメッセージを受信したときにデータが存在しない場合があります。この問題を解決するには、イベント定義でプラットフォームイベントの公開動作を \[コミット後に公開] に設定します。プラットフォームイベント定義で設定できる公開動作は次のとおりです。 **例** ある通信会社は、リード-to-商談プロセスを使用して取引先を作成するためのフロントエンドとして Salesforce を使用したいと考えています。商談が成立して成立したときに Salesforce で注文が作成されますが、バックエンドの ERP システムがデータマスターです。注文を Salesforce 商談レコードに保存する必要があります。また、注文が作成されたことを示すように商談の状況が変更されます。 次の制約が適用されます。 この例は Salesforce プラットフォームイベントを使用して実装するのが最適ですが、ESB がプラットフォームイベントに登録する必要があります。 Salesforce 側: リモートシステム側: この例は、次の内容を示しています。 ## 一括処理データ同期 **コンテキスト** CRM 実装を Salesforce に移行するときに、次のことを行う必要があります。 **問題** Salesforce へのデータのインポートと Salesforce からのデータのエクスポートは、営業時間中にエンドユーザーの業務に干渉し、大量のデータが含まれる可能性があることを考慮して、どのように行いますか? **勢力** このパターンに基づいてソリューションを適用するときには、さまざまな考慮が必要です。 **ソリューション** 次の表に、このインテグレーション問題のさまざまな解決策を示します。
ソリューション 適合 データマスター コメント
サードパーティの ETL ツールを使用したレプリケーション 最善 リモートシステム 外部システムで大量のデータを Salesforce に送信する必要がある場合は、サードパーティの ETL ツールを活用して、ソースデータに対して変更データキャプチャを実行できます。

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

このソリューションでは、Salesforce がデータソースであり、個々の行の時間/状況情報を使用してデータを照会し、対象結果セットを絞り込むことができます。これは、一括 API 2.0 または標準 REST API (レコード数が少ない場合) を使用して実装できます。
データインポートウィザードとデータローダー 適合 Salesforce/外部システム データインポートウィザードとデータローダーを使用して、データをインポート、エクスポート、移行できます。データローダーコマンドは、データのインポートとエクスポートを自動化するためにスクリプトを作成することもできますが、コマンドラインインターフェースは Windows 専用です。どちらのツールもデータインテグレーション戦略のベースとして推奨されません。代わりに、データスチュワードシップとメンテナンス戦略を補完する必要があります。

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

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

エラー処理とロックをより重視する必要があります。このパターンは継続的に更新され、エンドユーザーのパフォーマンスに影響する可能性があります。
**スケッチ** 次の図は、Salesforce がデータマスターであるこのパターンの一連のイベントを示しています。 図のダウンロード
次の図は、Salesforce がデータマスターである場合のほぼリアルタイムのイベントの後続の同期を示しています。 **結果** 次のシナリオでは、外部ソースのデータを Salesforce と統合できます。 一般的な Salesforce インテグレーションシナリオでは、実装チームは次のいずれかを実行します。 次に、ETL ツールを使用して次のプログラムを作成します。
  1. 制御テーブルを参照して、ジョブの最終実行時刻を判断し、必要な他の制御値を抽出します。
  2. 上記の制御値を検索条件として使用し、ソースデータセットを照会します。
  3. 入力規則、強化規則など、定義済みの処理ルールを適用します。
  4. ETL ツールの使用可能なコネクタ/変換機能を使用して、対象データセットを作成します。
  5. データセットを Salesforce オブジェクトに書き込みます。
  6. 処理が成功したら、制御テーブルの制御値を更新します。
  7. 処理に失敗した場合は、再起動と終了を有効にする値で制御テーブルを更新します。
**メモ**:Salesforce にアクセスできない場合でも、ETL ツールがアクセスできる環境で制御テーブルと関連データ構造を作成することをお勧めします。これにより、十分なレベルの復元力が得られます。このプロセスでは Salesforce をスポークとして扱い、ETL インフラストラクチャをハブにします。 ETL ツールでデータ同期機能を最大限に活用するには、次の点を考慮してください。 **エラー処理と回復** エラー処理と回復戦略は、ソリューション全体の一部として考慮する必要があります。最適な方法は、選択したソリューションによって異なります。
エラーの場所 エラー処理と回復戦略
変更データキャプチャを使用した Salesforce からの参照
  • エラー処理 — イベントは事実上リモートシステムに引き継がれてさらに処理されるため、リモートサービスでエラー処理を実行する必要があります。このパターンは非同期であるため、リモートシステムがメッセージのキュー、処理、およびエラー処理を処理します。また、変更データキャプチャはデータベーストランザクション内で処理されません。そのため、公開されたイベントをトランザクション内でロールバックすることはできません。
  • 回復 — このパターンは非同期であるため、リモートシステムはサービスの品質要件に基づいて再試行を開始する必要があります。各変更データキャプチャに関連付けられた再生 ID はアトミックであり、イベントが公開されるたびに増加します。この ID は、特定のイベント (たとえば、最後に正常にキャプチャされたイベントに基づく) からストリームを再生できます。大規模プラットフォームイベントメッセージは 72 時間 (3 日) 保存されます。CometD クライアントを使用してチャネルを登録すると、過去のイベントメッセージを取得できます。
サードパーティの ETL システムを使用した Salesforce からの参照
  • エラー処理 — 読み取り操作中にエラーが発生した場合、インフラストラクチャに関連しないエラーの再試行を実装します。繰り返し失敗する場合、制御テーブル/エラーテーブルを使用する標準処理を ETL 操作のコンテキストで実装して、次のことを行う必要があります。
    • エラーを記録する
    • 読み取り操作を再試行
    • 失敗した場合は終了
    • 通知の送信
  • Recovery — ETL プロセスを再起動して、失敗した読み取り操作から回復します。
操作は成功したが、失敗したレコードがある場合は、ジョブの即時再起動または後続の実行で問題に対処する必要があります。この場合、エラーの原因となっている可能性があるデータの優先順位付けと修正に時間を要するため、再起動を遅らせる方が適切な解決策になる可能性があります。
Salesforce への書き込み
  • エラー処理 — 書き込み操作中に発生したエラーは、アプリケーションのさまざまな要素の組み合わせによって発生する可能性があります。API コールでは、次の情報で構成される結果セットが返されます。この情報は、必要に応じて書き込み操作を再試行するために使用します。
    • レコード識別情報
    • 成功/失敗通知
    • 各レコードのエラーのコレクション
  • Recovery — ETL プロセスを再起動して、失敗した読み取り操作から回復します。
操作は成功したが、失敗したレコードがある場合は、ジョブの即時再起動または後続の実行で問題に対処する必要があります。この場合、エラーの原因となっている可能性があるデータの優先順位付けと修正に時間を要するため、再起動を遅らせる方が適切な解決策になる可能性があります。
外部マスターシステム エラーは、マスターシステムのベストプラクティスに従って処理する必要があります。
**セキュリティに関する考慮事項** リモートシステムへのコールでは、要求の機密性、整合性、可用性を維持する必要があります。選択したソリューションに応じて、異なるセキュリティ上の考慮事項が適用されます。 「セキュリティの考慮事項」を参照してください。 **サイドバー** なし。 **適時性** このパターンでは適時性は重要ではありません。ただし、すべての一括処理が指定された一括処理ウィンドウで完了するようにインターフェースを設計する必要があります。 すべてのバッチ指向の操作と同様に、バッチ処理ウィンドウ中にソースシステムと対象システムを分離することを強くお勧めします。営業時間中にバッチを読み込むと競合が発生し、ユーザーの更新に失敗するか、バッチの読み込み (または部分的なバッチの読み込み) に失敗する可能性があります。 グローバルに業務を行っている組織では、システムが継続的に使用されている可能性があるため、すべての一括処理を同時に実行できない場合があります。このような場合は、レコードタイプやその他の検索条件を使用したデータセグメンテーション手法を使用して、データの競合を回避できます。 **状態管理** 2 つのシステム間で代理キーを使用して状態管理を実装できます。Salesforce エンティティ間で何らかの種別のトランザクション管理が必要な場合は、Apex を使用したリモート コールイン パターンを使用することをお勧めします。 標準の楽観的レコードロックはプラットフォームで実行され、API を使用して更新する場合は、レコードを編集しているユーザーがレコードを更新してトランザクションを開始する必要があります。Salesforce API のコンテキストでは、楽観的ロックとは、次の状況のプロセスを指します。 **ミドルウェア機能** このパターンの実装に最も効果的な外部技術は、従来の ETL ツールです。選択するミドルウェアツールで Salesforce Bulk API がサポートされていることが重要です。 ミドルウェアツールで getUpdated() 関数がサポートされていることは有用ですが、重要ではありません。この関数は、Salesforce Platform の標準の変更データキャプチャ機能に最も近い実装を提供します。 次の表は、このパターンに参加するミドルウェアシステムの望ましいプロパティを示しています。
プロパティ 必須 望ましい 不要
イベント処理 X
プロトコル変換 X
翻訳と変換 X
キューイングとバッファリング X
同期転送プロトコル X
非同期転送プロトコル X
仲介ルーティング X
プロセス振付とサービスオーケストレーション X
トランザクション性 (暗号化、署名、信頼性の高い配信、トランザクション管理) X
ルーティング X
抽出、変換、読み込み X
ロングポーリング X (Salesforce 変更データキャプチャに必要)
**例** 公益事業会社は、見込み客を個々の営業担当やチームに割り当てるメインフレームベースの一括処理を使用します。この情報は、夜間に Salesforce にインポートする必要があります。 顧客が、市販の ETL ツールを使用してソーステーブルに変更データキャプチャを実装することを決定した。このソリューションは、次のように動作します。 ## リモートコールイン **コンテキスト** Salesforce を使用して、リードの追跡、パイプラインの管理、商談の作成、リードを顧客に変換する注文の詳細の取得を行います。Salesforce システムは内部で注文を作成し、そのデータを外部請求システムに転送してプロビジョニングと有効化を行います。請求注文は外部 (リモート) システムで管理されます。請求システム状況の注文または請求エンティティが変更された場合、そのリモートシステムは Salesforce で注文状況を更新する必要があります。 **問題** リモートシステムが Salesforce に接続して認証し、外部イベントについて Salesforce に通知したり、レコードを作成したり、既存のレコードを更新したりする方法は? **勢力** このパターンに基づいてソリューションを適用するときには、さまざまな考慮が必要です。 **ソリューション** 次の表に、このインテグレーションの問題に対するさまざまな解決策を示します。
ソリューション 適合 コメント
複合 API 最善 Salesforce は、基本的に REST API であり、複合要求をサポートする複合 API を提供します。これは、リモートシステムで次の目的で使用できます。
  • 1 回の通話で最大 25 件の要求を送信します。
  • JSON 要求を使用して Salesforce 組織でデータを照会、作成、変更する場合。

同期 API — API コールが実行された後、リモートクライアントアプリケーションはサービスから応答を受信するまで待機します。

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

エラー処理:適切なエラー処理では、HTTP 状況コードだけでなく、レスポンスボディを調べる必要があります。複合エンドポイントは、レスポンスボディ内にいずれかのサブ要求が失敗し、トランザクションをロールバックする必要があることが示されていても、200 HTTP 状況コードで応答します。
REST API 最善 アクセシビリティ — Salesforce では、リモートシステムで次の操作に使用できる REST API を提供しています。
  • Salesforce 組織に通知するイベントを公開
  • 組織のデータを照会する
  • データの作成、更新、削除
  • 組織に関するメタデータを取得する

同期 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 組織で大規模なデータセットを非同期で挿入、更新/挿入、クエリ、または削除するためのプログラムオプションが用意されています。大量のデータを Salesforce に読み込んだり、組織のデータに対して一括クエリを実行したりする必要がある場合に、効率的に使用できるように設計されています。

Bulk API 1.0 とは異なり、Bulk API 2.0 では常にバッチが並列で処理され、シリアルモードはサポートされません。つまり、次のようになります。
  • レコードは複数のスレッドで同時に処理される
  • バッチ間の処理順序は保証されません
  • パフォーマンスは高くなりますが、ロックの競合が発生する可能性もあります。

Bulk API 2.0 の各バッチは、独自のトランザクションとして処理されます。つまり、次のようになります。
  • 成功したバッチは個別にコミット
  • 失敗したバッチは成功したバッチに影響しません。
  • デフォルトでは、すべてのジョブに「オールオアナッシング」動作はありません。

SOAP API は大量のレコードの処理にも使用できますが、データセットに数十万から数百万のレコードが含まれている場合、SOAP API は最適ではありません。これは、オーバーヘッドが比較的大きく、パフォーマンス特性が低いためです。
  • イベント駆動型アーキテクチャ — プラットフォームイベントは、Salesforce オブジェクトの定義と同じ方法で定義されます。Bulk API 2.0 を使用した行動の公開は、Salesforce レコードの作成と同じです。作成操作と挿入操作のみがサポートされます。一括処理内のイベントは、一括処理ジョブの処理時に Salesforce イベントバスに非同期で公開されます。
Pub/Sub API 最善 Pub/Sub API は、外部パブリッシャーがイベントバスでイベントを公開するための推奨方法です。

Pub/Sub API は、外部システムでプラットフォームイベントを公開できる gRPC ベースの API です。Pub/Sub API:
  • 外部アプリケーションからのプラットフォームイベントの公開と登録の両方をサポート
  • 適切な認証 (OAuth、JWT、またはセッショントークン) で使用可能

Salesforce でプラットフォームイベントが定義されると、内部消費者と外部消費者の両方が使用できるようになります。
プラットフォームイベント 最善 プラットフォームイベントは、Salesforce オブジェクトと同じ方法で定義されます。プラットフォームイベントは、REST API、Bulk API、SOAP API などのさまざまなメカニズムを使用して公開できます。

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

エンドポイント形式:POST /services/data/vXX.X/sobjects/EventName__e/
  • Content-Type: application/json
  • 認証:ベアラートークン (OAuth)

Bulk API では、作成操作と挿入操作のみがサポートされます。一括処理内のイベントは、一括処理ジョブの処理時に Salesforce イベントバスに非同期で公開されます。

プラットフォームイベントは SObject であるため、標準 SOAP API 操作がサポートされています。
SOAP API 適合 アクセシビリティ — Salesforce は、リモートシステムで次の操作に使用できる SOAP API を提供します。
  • Salesforce 組織に通知するイベントを公開
  • 組織のデータを照会する
  • データの作成、更新、削除
  • 組織に関するメタデータを取得する
  • ユーティリティを実行して管理タスクを実行する

同期 API — API コールが実行された後、リモートクライアントアプリケーションはサービスから応答を受信するまで待機します。Salesforce への非同期コールはサポートされていません。

生成された WSDL — Salesforce では、リモートシステムに次の 2 つの WSDL が用意されています。
  • Enterprise WSDL - Salesforce 組織に固有の強く型指定された WSDL を提供します。
  • Partner WSDL (パートナー WSDL) - Salesforce 組織に固有ではない、型付けの緩い WSDL が含まれます。

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

トランザクション/コミット動作 — デフォルトでは、一部のレコードにエラーがマークされている場合、各 API コールで部分的な成功が許可されます。これは、エラーが発生した場合にすべての結果がロールバックされる「all or nothing」動作に変更できます。1 つのトランザクションを複数の API コールにまたがることはできません。この制限を克服するために、1 つの API コールで複数のオブジェクトに影響を与えることができます。
Apex Web サービス 最適ではない Apex クラスのメソッドは、Web サービスメソッドとして外部アプリケーションに公開できます。この方法は SOAP API の代替であり、通常は次の追加要件を満たす必要がある場合にのみ使用されます。
  • 完全なトランザクションサポートが必要です (たとえば、取引先、取引先責任者、商談をすべて 1 つのトランザクションで作成します)。
  • 確定する前に、カスタムロジックを Salesforce 側で適用する必要があります。

Apex Web サービスを使用する利点は、Salesforce で維持する必要がある追加コードと天秤にかける必要があります。

プラットフォームイベントには適用されません。これは、コンシューマーでのトランザクション事前挿入ロジックが イベント駆動型アーキテクチャ。イベントが発生したことを Salesforce 組織に通知するには、SOAP API、REST API、または Bulk API 2.0 を使用します。
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 を使用する場合、イベントの順序は同じです。 _SOAP API を使用したリモートシステムによる Salesforce の照会_ _REST API を介したイベントを使用した Salesforce へのリモートシステム通知_ **結果** イベント駆動型アーキテクチャでは、リモートシステムは SOAP API、REST API、または Bulk API 2.0 を使用して Salesforce にコールし、イベントを Salesforce イベントバスに公開します。イベントを公開すると、すべての登録者に通知されます。イベント サブスクライバは、フロー、Lightning コンポーネント、Apex トリガーなどの Salesforce Platform 上に存在できます。イベント登録者は、CometD 登録者などの Salesforce Platform の外部にすることもできます。 Salesforce オブジェクトを直接操作する場合、このパターンに関連するソリューションでは次のことができます。 **コールメカニズム** コールメカニズムは、このパターンを実装するために選択されたソリューションによって異なります。
コールメカニズム 説明
SOAP API リモートシステムは Salesforce Enterprise または Partner WSDL を使用してクライアントスタブを生成し、そのスタブを使用して標準 SOAP API を呼び出します。
REST API Apex REST サービスにアクセスする前に、リモート システムを認証する必要があります。リモートシステムは OAuth 2.0 またはユーザー名とパスワード認証を使用できます。いずれの場合も、クライアントは適切な値を使用して認証 HTTP ヘッダーを設定する必要があります (OAuth アクセストークンまたはセッション ID は SOAP API へのログインコールで取得できます)。

次に、リモートシステムは適切な動詞を使用して 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 を使用して、呼び出し可能なカスタムアクションエンドポイントをコールし、自動起動フローを呼び出します。
**エラー処理と回復** エラー処理と回復戦略は、ソリューション全体の一部として考慮する必要があります。 **Idempotent Design Considerations (無力な設計に関する考慮事項)** Idempotent 機能は、繰り返しの呼び出しが安全で、悪影響がないことを保証します。イデムポテンシーが実装されていない場合、同じメッセージを繰り返し呼び出すと結果が異なる可能性があり、重複レコードの作成やトランザクションの重複処理など、データの整合性の問題が発生する可能性があります。 リモートシステムは、エラーやタイムアウトが発生した場合に複数の (重複する) コールを管理して、重複する挿入や冗長な更新を回避する必要があります (特にダウンストリームトリガーやワークフロールールが起動される場合)。これらの状況の一部は Salesforce 内で管理できますが (特にカスタム SOAP および REST サービスの場合)、エラー処理と適切な設計はリモートシステム (またはミドルウェア) で管理することをお勧めします。 **セキュリティに関する考慮事項** 選択したパターンソリューションに応じて、異なるセキュリティ上の考慮事項が適用されます。いずれの場合も、プラットフォームではログインユーザーのアクセス権 (プロファイル設定、共有ルール、権限セットなど) が使用されます。また、プロファイル IP 制限を使用して、特定の IP アドレス範囲で API へのアクセスを制限できます。
ソリューション セキュリティに関する考慮事項
SOAP API alesforce は、Secure Sockets Layer v3 (SSL) および Transport Layer Security (TLS) プロトコルをサポートしています。暗号には 128 ビット以上の鍵長が必要です。

リモートシステムは、有効なログイン情報を使用してログインし、セッション ID を取得する必要があります。リモートシステムにすでに有効なセッション ID がある場合、明示的なログインなしで API をコールできます。これは、このドキュメントの前半で説明したコールバックパターンで使用され、前の Salesforce 送信メッセージには、後続の使用のためにセッション ID とレコード ID が含まれていました。

SOAP API をコールするクライアントは、コールごとに新しいセッション ID を取得するのではなく、パフォーマンスを最大化するためにセッション ID をキャッシュして再利用することをお勧めします。
REST API リモート システムで認可用の OAuth Trust を確立することをお勧めします。その後、HTTP 動詞を使用して特定のリソースに対して REST コールを実行できます。また、他の方法 (SOAP API をコールして取得されたセッション ID、またはアウトバウンドメッセージを介して提供されたセッション ID) で有効なセッション ID を使用して REST コールを実行することもできます。

REST API をコールするクライアントは、コールごとに新しいセッション ID を取得するのではなく、パフォーマンスを最大化するためにセッション ID をキャッシュして再利用することをお勧めします。
Apex Web サービス リモート システムで認可用の OAuth Trust を確立することをお勧めします。
Apex RESTサービス リモート システムで認可用の OAuth Trust を確立することをお勧めします。
Bulk API 2.0 リモート システムで認可用の OAuth Trust を確立することをお勧めします。
「セキュリティの考慮事項」を参照してください。 **サイドバー** なし。 **適時性** SOAP API と Apex Web サービス API は同期です。次のタイムアウトが適用されます。 **データボリューム** データ量に関する考慮事項は、選択したソリューションとコミュニケーション種別によって異なります。
ソリューション コミュニケーション種別 制限
SOAP API または REST API 同期
  • SOAP ログイン — SOAP ログイン要求サイズは 10 KB 以下に制限されています。ユーザーごとに 1 時間あたり最大 3,600 回の login() 関数の呼び出しを実行できます。この制限を超えると、API はエラーを返します。
  • 作成、更新、削除 — リモートシステムは一度に最大 200 件のレコードを作成、更新、削除できます。複数のコールを実行して合計 200 件を超えるレコードを処理できますが、各要求のサイズが 200 件に制限されます。
  • BLOB データ — SObject 基本情報、SObject 行、または SObject コレクション REST リソースを使用して、Salesforce 標準オブジェクトに BLOB データを挿入または更新できます。SObject 基本情報リソースまたは SObject 行リソースの場合、アップロードの最大ファイルサイズは ContentVersion オブジェクトで 2 GB、その他のすべての対象標準オブジェクトで 500 MB です。SObject コレクションリソースを使用する場合、1 つの要求に含まれるすべてのファイルの最大合計サイズは 500 MB です。
  • クエリ結果サイズ — デフォルトでは、クエリ結果オブジェクト (バッチサイズ) で返され、query() または queryMore() コールで返される行数は 500 に設定されています。返される最大行数は 2,000 行です。バッチサイズを明示的に設定できますが、要求されたバッチサイズが実際のバッチサイズになるとは限りません。これは、パフォーマンスを最大化するために行われます。返される行数がバッチサイズを超える場合は、queryMore() API コールを使用して複数のバッチを反復処理します。追加の規則が適用される可能性があるため、詳細を確認してください。
  • イベントメッセージ — イベントメッセージの最大サイズは 1 MB です。Salesforce API を使用してイベントを公開すると、標準 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 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
  • API 要求の制限 — Salesforce では、24 時間あたりの API コール数の制限が適用されます。この制限は、Salesforce のエディション種別とライセンス数に基づきます。たとえば、Unlimited Editionでは、Salesforce Platformライセンスあたり24時間あたり5,000のAPI要求が提供されます。詳細は、「Salesforce Developer Limits and Allocations Quick Reference (Salesforce 開発者の制限と割り当てクイックリファレンス)」を参照してください。
  • API クエリカーソルの制限 — ユーザーは一度に最大 10 個のクエリカーソルを開くことができます。それ以外の場合、10 個のカーソルのうち最も古いものがリリースされます。リモートアプリケーションがリリースされたクエリカーソルを開こうとすると、エラーが発生します。たとえば、インテグレーションユーザーのログイン情報を共有する場合、最大クエリカーソル数を考慮する必要があります。可能な限り、ミドルウェアは別のクエリを (順次) 実行する前に完全なクエリを完了するか、各アプリケーションで指定されたインテグレーションユーザーを使用する必要があります。または、ミドルウェアは「ラウンドロビン」方式で複数のユーザーにまたがる要求を実行する必要がある場合があります。
  • 通話制限 — 作成、更新、クエリの制限については、「データ量」サイドバーを参照してください。
Bulk API 2.0 詳細は、「データボリューム」サイドバーを参照してください。
プラットフォームイベント
  • イベント通知の制限 — 標準量プラットフォームイベントでは、1 時間あたり最大 100,000 件のイベントを公開できます。大規模使用量ベースのプラットフォームイベントでは、1 時間あたり最大 25 万件のイベントを公開できます。大規模イベントの使用状況を監視するには、REST API 制限リソースを使用します。
  • イベントメッセージサイズの制限 — イベントメッセージの最大サイズは 1 MB です。Salesforce API を使用してイベントを公開すると、標準 API の制限に含まれます。
**信頼できるメッセージング** 信頼性のあるメッセージングでは、個々のコンポーネント自体が信頼性が低い可能性があるリモートシステムへのメッセージの配信を保証するという問題を解決しようとします。Salesforce SOAP API と REST API は同期的であり、それ自体が信頼できるメッセージングプロトコル (WS-ReliableMessaging など) を明示的にサポートしません。 エラーとタイムアウトのシナリオが正常に管理されるように、リモートシステムに信頼性の高いメッセージングシステムを実装することをお勧めします。外部システムからのプラットフォームイベントの公開は Salesforce API に依存するため、SOAP API と REST API について同じ考慮事項が適用されます。 **ミドルウェア機能** 次の表は、次のパターンに関与するミドルウェアシステムの特性を示しています。
プロパティ 必須 望ましい 不要
イベント処理 X
プロトコル変換 X
翻訳と変換 X
キューイングとバッファリング X
同期転送プロトコル X
非同期転送プロトコル X
仲介ルーティング X
プロセス振付とサービスオーケストレーション X
トランザクション性 (暗号化、署名、信頼性の高い配信、トランザクション管理) X
ルーティング X
抽出、変換、読み込み X (一括/一括)
**例** ある印刷用品およびサービス会社は、Salesforce をフロントエンドとして使用して、プリンター用品と注文を作成および管理しています。プリンターを表す Salesforce 納入商品レコードは、クライアントサイトのプリンターを定期的に監視する社内プリンター管理システム (PMS) の印刷利用状況統計 (インク状況、用紙レベル) で定期的に更新されます。設定されたしきい値に達すると(インク残量が少なくなったり、用紙の空レベルが 30%未満になったりした場合など)、イベントに関連する複数のアプリケーション/プロセス(変数)に通知され、メールまたは Chatter アラートが送信され、注文レコードが作成されます。PMS には Salesforce ID が保存されます (Salesforce はアセットレコードマスターです)。 次の制約が適用されます。 この例は、Salesforce SOAP API または REST API を使用してイベントを公開し、Salesforce で宣言型自動化 (フロー) を実装するのに最適です。プラットフォームイベントを使用する主な理由は、変数と無制限の登録者数です。ただし、注文などのレコードの有限リストを簡単に更新する場合は、SOAP または REST API を使用してレコードを更新します。 Salesforce: リモートシステムの場合: プラットフォームイベントを使用すると、イベントバスで大規模プラットフォームイベントのイベントを 72 時間再生できます。ミドルウェアソリューションを使用してこれらのイベントを公開すると、公開側でエラー処理を組み込むことができます。ただし、より高い信頼性が必要な場合は、登録側でエラー処理を実装できます。 この例は、次の内容を示しています。 ## データの変更に基づく UI の更新 **コンテキスト** Salesforce を使用して顧客のケースを管理します。カスタマーサービス担当がケースについて顧客と電話している。顧客が支払を行い、カスタマーサービス担当者は支払処理アプリケーションから Salesforce アプリケーション内のリアルタイムの更新を確認し、顧客が注文の未払い金額を正常に支払ったことを示す必要があります。 **問題** Salesforce でイベントが発生したときに、画面を更新しなくても、作業を失うことなく Salesforce ユーザーインターフェースでユーザーに通知できる方法は? **勢力** このパターンに基づいてソリューションを適用するときには、さまざまな考慮が必要です。 - アクションの対象となるデータは Salesforce に保存する必要がありますか? - このデータを表示するカスタムユーザーインターフェースレイヤーを作成できますか? - カスタムユーザーインターフェースを呼び出すためのアクセス権をユーザーに付与しますか? **ソリューション** このインテグレーションの問題に対する推奨される解決策は、Salesforce でほぼリアルタイムのイベントを実現するプラットフォームイベントを使用することです。プラットフォームイベントは、Salesforce オブジェクトに依存しない構造化された柔軟なペイロードを提供します。また、再生期間が 72 時間の耐久性のあるトピックも確保されます。これにより、オフラインコンシューマーが後で使用可能になった場合でも、イベントを使用できます。このソリューションは、次のコンポーネントで構成されています。 - トピックに関するプラットフォーム イベントをパブリッシュするロジックを含む Apex トリガーまたはフロー - Apex トリガーまたはフローからイベントをパブリッシュできるトピック - ユーザー・インタフェースで使用できるBayeuxプロトコル（現在の CometD ）の JavaScript ベースの実装 - Lightning コンポーネント - 静的リソースとして含まれる JavaScript ライブラリ **スケッチ** 次の図は、Salesforce ユーザーインターフェースに通知をストリーミングするためのストリーミング API の実装方法を示しています。これらの通知は、Salesforce のレコードの変更によってトリガーされます。 _データ変更によってトリガーされる Salesforce の UI 更新_ **結果** **利点** このパターンに関連するソリューションの適用には、次の利点があります。 **サポートされない要件** このソリューションには次の制限事項があります。 **セキュリティに関する考慮事項** 標準の Salesforce 組織レベルセキュリティに準拠しています。HTTPS プロトコルを使用してストリーミング API に接続することをお勧めします。「セキュリティの考慮事項」を参照 **サイドバー** 最適なソリューションは、Salesforce でカスタムユーザーインターフェースを作成することです。カスタムユーザーインターフェースの表示に使用できる適切なユーザーインターフェースコンテナを考慮する必要があります。サポートされるブラウザーは、『Streaming API Developer Guide (ストリーミング API 開発者ガイド)』に記載されています。 **例** ある通信会社は、Salesforce を使用して顧客のケースを管理しています。カスタマーサービスマネージャーは、カスタマーサービス担当者の 1 人がケースを正常にクローズしたときに通知を受け取りたいと考えています。 このパターンで規定されたソリューションを実装する場合、お客様は次のことを行う必要があります。 ## データ仮想化 **コンテキスト** Salesforce を使用して、リードの追跡、パイプラインの管理、商談の作成、リードを顧客に変換する注文の詳細の取得を行います。ただし、Salesforce は注文を格納または処理するシステムではありません。注文は外部 (リモート) システムで管理されます。ただし、営業担当は、外部システムを学習したり使用したりすることなく、Salesforce でリアルタイムの注文情報を表示および更新したいと考えています。 **問題** Salesforce では、外部システムから Salesforce にデータを移動せずに、Salesforce の外部に保存されているデータを表示、検索、変更する方法は? **勢力** このパターンに基づいてソリューションを適用するときには、さまざまな考慮が必要です。 **ソリューション** 次の表に、このインテグレーション問題のさまざまな解決策を示します。
ソリューション 適合 コメント
Salesforce Connect 最善 Salesforce Connectを使用して、Salesforceデータと共に外部ソースのデータにアクセスします。Salesforce でデータのコピーを作成せずに、SAP、Microsoft、Oracle などのシステム、Snowflake などのクラウドベースのシステムからリアルタイムにデータを取得します。

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

Salesforce Connect では、次のことができます。
  • 外部システムのデータを照会します。
  • 外部システムのデータを作成、更新、削除する。
  • リストビュー、詳細ページ、レコードフィード、カスタムタブ、ページレイアウトを使用して外部オブジェクトにアクセスします。
  • 外部オブジェクトと標準オブジェクトまたはカスタムオブジェクト間のリレーションを定義して、さまざまなソースのデータを統合します。
  • 外部データに関するレポートを実行する (制限あり)。
  • Salesforce モバイルアプリケーションでデータを表示します。
Salesforce Connect を使用して外部システムに保存されているデータにアクセスするには、次のいずれかのアダプタを使用できます。
  • Odata 2.0 または Odata 4.0 アダプタ — Odata 2.0 または 4.0 プロデューサーによって公開されたデータに接続します。
  • 組織間アダプター — 別の Salesforce 組織に保存されているデータに接続します。組織間アダプタは、標準の Lightning Platform REST API を使用します。Odata とは異なり、組織間アダプタは仲介 Web サービスを必要とせずに別の組織に直接接続できます。
  • Apexを使用して作成されたカスタム・アダプタ：Odataおよび組織間アダプタがニーズに適していない場合は、Apexコネクタ・フレームワークを使用して独自のアダプタを開発します。
要求と返信 最適ではない 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 アダプタを使用して外部システムからデータを取り込む方法を示しています。 このシナリオの内容は次のとおりです。
  1. ブラウザーは AJAX コールを実行し、続いて対応する外部オブジェクトアダプターでアクションを実行します。
  2. アダプタはアクションを Odata 要求に変換し、インテグレーション層とサービス層を介してリモートシステムに対して HTTP GET 要求を実行します。
  3. リモートシステムはインテグレーションレイヤーとサービスレイヤーを介して JSON 応答を Salesforce に返します。
  4. 応答は Odata から外部オブジェクトに変換され、ブラウザに返されます。
**結果** このパターンに関連するソリューションの適用により、エンドユーザーにトランザクションの結果を表示するユーザーインターフェースの起動が可能になります。 **コールメカニズム** コールメカニズムは、このパターンを実装するために選択されたソリューションによって異なります。
コールメカニズム 説明
外部オブジェクト Salesforce Connect は、Salesforce 外部オブジェクトを外部システムのデータテーブルにマッピングします。組織にデータをコピーする代わりに、Salesforce Connect は必要なときにリアルタイムでデータにアクセスします。データが組織外に保存されていても、Salesforce Connect は Lightning プラットフォームとのシームレスなインテグレーションを提供します。外部オブジェクトは、グローバル検索、参照関係、レコードフィード、Salesforce モバイルアプリケーションなどの Salesforce ツールで使用できます。外部オブジェクトはまた、Apex、SOSL、SOQL クエリ、Salesforce API、およびメタデータ API、変更セット、パッケージを介したリリースでも使用できます。
照明コンポーネント リモートプロセスがユーザーインターフェースを含むエンドツーエンドのプロセスの一部としてトリガーされ、その結果を Salesforce レコードに表示または更新する必要がある場合に使用されます。たとえば、クレジットカード支払を外部支払ゲートウェイに送信し、ユーザーに表示される支払結果をすぐに返すプロセスです。ユーザー インターフェイス イベントからトリガーされるインテグレーションでは、通常、カスタムLightningコンポーネントを作成する必要があります。
**エラーハンドリング** 全体的なソリューションの一部としてエラー処理を含めることが重要です。エラーが発生した場合 (例外またはエラーコードがコール元に返された場合)、コール元がエラー処理を管理します。Salesforce Connect Validatorは、一般的なクエリを実行し、エラーの種類と失敗の原因を把握できる無料のツールです。 **利点** Salesforce Connect ソリューションを使用するメリットには、次のようなものがあります。 **Salesforce Connect の考慮事項** Salesforce Connect ソリューションでは、次の考慮事項があります。 **セキュリティに関する考慮事項** このパターンのソリューションは、標準の Salesforce 組織レベルセキュリティに準拠する必要があります。HTTPS プロトコルを使用して任意のリモートシステムに接続することをお勧めします。詳細は、「セキュリティの考慮事項」を参照してください。 Odata コネクタを使用している場合は、Odata 外部データソースのクロスサイト要求フォージェリ (CSRF) の特殊な動作、制限事項、推奨事項を理解してください。詳細については、「Salesforce Connect — Odata 2.0 および 4.0 アダプターに関する CSRF の考慮事項」を参照してください。 **サイドバー** なし。 **適時性** このパターンでは、タイミングが非常に重要です。次の点に留意してください。 **データボリューム** このパターンは、タイムアウト値が小さく、Apex コール ソリューションの要求または応答の最大サイズが小さいため、主に少量のリアルタイム アクティビティで使用されます。メッセージにデータペイロードが含まれる一括処理活動では、このパターンを使用しないでください。 **エンドポイントの機能と標準のサポート** エンドポイントの機能と標準のサポートは、選択したソリューションによって異なります。
ソリューション エンドポイントに関する考慮事項
Salesforce Connect Odata API — Open Data Protocolを使用して、Salesforceの外部に保存されているデータにアクセスします。外部データは、OData プロデューサー経由で公開されている必要があります。

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

Salesforceへの接続 — Lightning 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 Connect の一般的な制限」を参照してください。 **ミドルウェア機能** 次の表は、このパターンに参加するミドルウェアシステムの望ましいプロパティを示しています。
プロパティ 必須 望ましい 不要
イベント処理 X
プロトコル変換 X
翻訳と変換 X
キューイングとバッファリング X
同期転送プロトコル X
非同期転送プロトコル X
仲介ルーティング X
プロセス振付とサービスオーケストレーション X
トランザクション性 (暗号化、署名、信頼性の高い配信、トランザクション管理) X
ルーティング X
抽出、変換、読み込み X
ロングポーリング X
**外部オブジェクトリレーション** 外部オブジェクトでは、18 文字の Salesforce レコード ID を使用して関連レコードを関連付ける標準参照関係がサポートされます。ただし、Salesforce 組織の外部に保存されたデータは、多くの場合レコード ID が含まれていません。そのため、外部オブジェクトでは、外部参照と間接参照という、2 つの特殊なタイプの参照関係を使用できます。 この表には、外部オブジェクトで使用できるリレーション種別がまとめられています。
リレーション 許可された子オブジェクト 許可された親オブジェクト レコードを照合する親項目
参照 標準、カスタム、外部 標準、カスタム 18 文字の Salesforce レコード ID
外部参照 標準、カスタム、外部 外部 外部 ID 標準項目
間接参照 外部 標準、カスタム [外部 ID] 属性と [一意] 属性を持つカスタム項目を選択する
_Salesforce Connect — OData 2.0 および 4.0 アダプターに関する高データボリュームの考慮事項_ 組織が外部オブジェクトにアクセスするときにレート制限に達した場合、関連付けられた外部データソースで \[高データボリューム] オプションを選択することを検討してください。このオプションを選択すると、ほとんどのレート制限が迂回されますが、一部の特殊動作と制限は適用されます。詳細は、「High Data Volume Considerations for Salesforce Connect」を参照してください。 _Salesforce Connect のクライアント駆動ページングおよびサーバー駆動ページング — Odata 2.0 および 4.0 アダプタ_ 外部データの Salesforce Connect クエリで、大量の結果セットがバッチやページに分割されて示されることはよくあります。ページングの動作を外部システム (サーバ駆動) で制御するか、Salesforce Connect の Odata 2.0 または 4.0 アダプタ (クライアント駆動) で制御するかを決定します。外部データソースの \[サーバー駆動のページ設定] 項目は、クライアント駆動とサーバー駆動のどちらのページングを使用するかを指定します。外部データソースでサーバー駆動ページングを有効にすると、要求されたページサイズ (デフォルトの queryMore() バッチサイズである 500 行を含む) が無視されます。外部システムから返されたページによってバッチが決まりますが、各ページは 2,000 行を超えることはできません。ただし、その場合でも Salesforce Connect の OData アダプターの制限は適用されます。 **例** ある製造会社は、Salesforce を使用して顧客のケースを管理しています。カスタマーサービスエージェントは、バックオフィスの ERP システムからリアルタイムの注文情報にアクセスして、ERP でレポートを学習して手動で実行することなく、顧客の全体像を把握したいと考えています。 このパターンで規定されたソリューションを実装するには、次の作業を行う必要があります。 ## 付録 A:リソース **開発者ドキュメント** - [_Salesforce ヘルプ:インテグレーションユーザーへの API 限定アクセス権の付与_](https://help.salesforce.com/s/articleView?id=platform.integration_user.htm&type=5) - [_『SOAP API Developer Guide』_](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) - [_Apex 開発者ガイド:Salesforce Connect_](https://help.salesforce.com/s/articleView?id=platform.platform_connect_about.htm&type=5) **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:セキュリティに関する考慮事項 エンタープライズポートフォリオの有効なメンバーになるには、すべてのアプリケーションを作成し、関連するセキュリティメカニズムと統合する必要があります。最新の IT 戦略では、オンプレミスとクラウドベースのサービスを組み合わせて使用します。 通常、クラウド間サービスの統合は Web サービスと関連する認証に焦点が絞られますが、オンプレミスとクラウドサービスを接続すると複雑さが増します。このセクションでは、セキュリティツール、技術、Salesforce 固有の考慮事項について説明します。 **リバースプロキシサーバ** リバースプロキシは、Web サーバーの前に配置され、クライアント (Web ブラウザーなど) 要求をそれらの Web サーバーに転送するサーバーです。リバースプロキシは通常、セキュリティ、パフォーマンス、信頼性を高めるために実装されます。 これは、クライアントの代わりに 1 つ以上のサーバーからリソースを取得するプロキシサーバーの一種です。これらのリソースは、プロキシサーバー自体から取得されたかのようにクライアントに返されます。フォワードプロキシは、関連付けられたクライアントが任意のサーバーに接続するための仲介者ですが、リバースプロキシは、関連付けられたサーバーが任意のクライアントから接続するための仲介者です。 Salesforce 実装では、通常、このようなサービスは外部ゲートウェイ製品を介して提供されます。たとえば、Apache HTTP、lighttpd、nginix などのオープンソースオプションを使用できます。商用製品には、IBM WebSeal や Computer Associates SiteMinder などがあります。これらの製品は、内部要求者の代わりにすべての送信 Salesforce 要求をプロキシして管理するように簡単に設定できます。 **暗号化** 企業によっては、オンプレミスとクラウドベースのアプリケーションの組み合わせ間で、選択したトランザクションまたはデータ項目を暗号化する必要があります。組織が追加のコンプライアンス要件に準拠する必要がある場合、次のような代替方法を実装できます。 - Salesforce 独自の暗号化ゲートウェイサービス、CipherCloud、IBM DataPower、Computer Associates など、オンプレミスの商用暗号化ゲートウェイサービス。ソリューションごとに、暗号化ペイロードを送受信するか、HTTP (S) 要求が実行される前に特定のデータ項目を暗号化または復号化することで、暗号化エンジンまたはゲートウェイがトランザクション境界で呼び出されます。 - クラウド ベースのオプション(Salesforce Shield Platform Encryption など)。Shield Platform Encryption では、重要なプラットフォーム機能を保持しながらデータに新しいセキュリティ層が追加されます。選択したデータは、高度な鍵派生システムを使用して保存時に暗号化されます。これまで以上に安全にデータを保護できます。詳細は、Salesforce オンラインヘルプを参照してください。 **特殊な WS-\* プロトコルのサポート** セキュリティプロトコル (WS-\* など) の要件に対応するため、次の代替方法をお勧めします。 - セキュリティ/XML ゲートウェイ — WS-Security ログイン情報 (IBM WebSeal または Datapower、Layer7、TIBCO など) をトランザクションストリーム自体に挿入します。このアプローチでは、Salesforce からアプリケーションレベルの Web サービスや Web サービスを呼び出す必要はありません。Salesforce インストール全体でこのアプローチを再使用することもできます。ただし、既存のセキュリティゲートウェイアプローチへの適切な WS-Security インジェクションを管理するには、追加の設計、設定、テスト、メンテナンスが必要です。 - トランスポートレベルの暗号化 — 双方向 SSL および IP 制限を使用して通信チャネルを暗号化します。この方法では、WS-\* プロトコルを単独で直接実装することはありませんが、ユーザー名とパスワードを渡すことなく、オンプレミスアプリケーションと Salesforce 間の通信チャネルを保護します。また、Salesforce で生成されたクラスを変更する必要もありません。ただし、一部のオンプレミス Web サービスの変更が必要になる場合があります (アプリケーション自体またはミドルウェア/ESB レイヤー)。 - Salesforce カスタム開発 — WSDL2Apex ユーティリティを使用して、WS-Security ヘッダーを送信 SOAP 要求に追加します。これにより、内部サービスの呼び出しに使用される WSDL ファイルから Java に似た Apex クラスが生成されます。このアプローチでは、DMZ のバックエンド Web サービスや追加のコンポーネントを変更する必要はありませんが、次のものが必要です。 - ビルドおよびテスト作業の増加 - WS-Security 属性を手動でコーディングする比較的複雑なプロセス (Apex コード内の XML シリアライゼーションを含む) - 長期的なメンテナンス作業の増加 **メモ**:最後のオプションは、その複雑さと、Salesforce の定期的な更新に基づく定期的なレビューが必要になるリスクのため、お勧めしません。 **その他のセキュリティに関する考慮事項** - 指定ログイン情報:指定ログイン情報は、外部システムへの認証済み API コールアウトを保護して簡素化するために、コールアウトエンドポイントの URL とその必須認証パラメーターを 1 つの定義で指定します。Apex コードを合理化し、認証済みコールアウトの設定を簡略化するには、コールアウト エンドポイントとして指定ログイン情報を指定します。詳細については、[こちら](https://help.salesforce.com/s/articleView?id=xcloud.named_credentials_about.htm&type=5)を参照してください。 - OAUTH 2.0:OAuth 2.0 は、ユーザーがログイン情報 (パスワードなど) を共有することなく、サードパーティアプリケーションに保護リソースへの制限付きアクセス権を付与できる業界標準の認証フレームワークです。ユーザーは、パスワードを直接交換する代わりにアクセストークン要求を承認し、アプリケーションはこれを使用してリソースサーバーからユーザーのデータにアクセスします。このプロセスでは、クライアントアプリケーションをユーザーの ID とパスワードから分離し、リソースにアクセスするための一時的な範囲固有の「鍵」を提供することでセキュリティを強化します。詳細については、[こちら](https://help.salesforce.com/s/articleView?id=xcloud.remoteaccess_oauth_flows.htm&type=5)を参照してください。 - プライベートコネクト:Salesforce 組織をサードパーティのクラウドサービスでホストされているアプリケーションと統合する場合、HTTP/s トラフィックを安全に送受信できることが不可欠です。プライベートコネクトでは、Salesforce 組織と AWS Virtual Private Cloud (VPC) の間に完全に管理された安全な接続を設定することにより、Amazon Web Services (AWS) インテグレーションでのセキュリティを強化できます。次に、クロスクラウドトラフィックを公開インターネットではなく接続を介して転送し、部外者のセキュリティ脅威にさらされるリスクを軽減します。プライベートコネクトは、AWS とのパートナーシップで AWS PrivateLink という機能を介して使用できます。プライベートコネクトは双方向で、受信トラフィックと送信トラフィックの両方を開始できます。受信接続では、標準 API を使用してトラフィックを Salesforce に送信できます。送信接続では、Apex コールアウト、外部サービス、外部オブジェクトなどの機能を介してトラフィックを Salesforce から送信できます。VPC の詳細については、[こちら](https://help.salesforce.com/s/articleView?id=xcloud.private_connect_overview.htm&type=5)を参照してください。 ## 付録 C:イベント駆動型アーキテクチャ プラットフォームイベント、変更データキャプチャ (CDC)、および Pub/Sub API を備えた Salesforce イベントバスを使用すると、企業はイベント駆動型スタイルアーキテクチャ (EDA) を作成できます。 EDA では、イベントメッセージのコンシューマー (登録者) がイベントメッセージのプロデューサー (公開者) から切り離されるため、拡張性と柔軟性が向上します。このドキュメントでは、関連する代替またはオプションを比較対照する既存のパターン構造の一部として特定のパターンを取り上げています。ただし、イベント駆動型アーキテクチャとパターンの相互作用について包括的に理解することで、ニーズに適したパターンを選択できます。 ## 著者について Khalid Mohamed は、Salesforce のプロフェッショナルサービスにおける優れたアーキテクトリーダーです。2015 年に Salesforce に入社して以来、エンタープライズアプリケーションとアーキテクチャに関する広範な専門知識を活用し、Salesforce での職務を果たすまでに多くの顧客変革を経験してきました。Khalid は、デリバリアーキテクチャ委員会を統括し、認定テクニカルアーキテクトリーダーとしても認められています。 Gulal Kumar は、Salesforce のソフトウェアエンジニアリングアーキテクトで、データおよびインテグレーションアーキテクチャに重点を置いています。インテグレーションと API、モダナイゼーションプログラム、セキュリティ、AIML イニシアチブで 20 年以上の経験があり、豊富な専門知識を備えています。Gulal は、ビジネス変革イニシアチブを推進し、セキュリティと耐障害性を強化し、アーキテクチャの卓越性を促進し、さまざまなドメインで AIML イニシアチブをリードしてきました。 Sushant は Salesforce のテクニカルアーキテクトで、ソリューションアーキテクチャと Salesforce プラットフォームのエンドツーエンドの提供を専門としています。プラットフォームガバナンス、アプリケーション開発、インテグレーション、DevOps に関する深い専門知識を持ち、さまざまな業種の多数の顧客変革プログラムを率いてきました。Sushant は、優れたデリバリとスケーラブルなアーキテクチャの成果の実現に取り組んでいます。