レイヤーアプローチを練習する

学習の目的

この単元を完了すると、次のことができるようになります。

• インテグレーションパターンの評価に使用する 3 つのレイヤーを特定する。
  
• 2 種類のタイミングと、それらが重要な理由を説明する。
  

レイヤーアプローチ

インテグレーションイニシアチブに応じて、パターンを評価するためのアプローチが異なります。このモジュールでは、アプリケーションインテグレーションの取り組みにおけるパターンの評価に、レイヤーアプローチを使用する方法を学習します。アプリケーションインテグレーションイニシアチブは、Salesforce Lightning プラットフォームにおける一般的なインテグレーションです。

4 つのディメンションを知る

レイヤーアプローチでは、次の 4 つのディメンションを使用してインテグレーションパターンとソリューションを評価します。各ディメンションは、どのソリューションがインテグレーションの問題を最もよく解決するかを理解するための基準を表しています。各ディメンションを確認し、結果をインテグレーション要件と比較します。

レイヤー: システム内のタスクの種別。

数量: 同期されるデータ量とシステム間の変換アクティビティの量。

タイミング: 通信のタイミングは非同期または同期のいずれかで、データがリアルタイム (またはできる限り速やか) にシステム間でやり取りされるか、後で送信するためにまとめて処理されます。

方向: ソースの方向。Salesforce から別のシステムへ、別のシステムから Salesforce へ、または双方向のいずれかです。

さまざまなレイヤーを知る

レイヤーアプローチでは、アプリケーションアーキテクチャの概念を論理的なカテゴリに分類します。各レイヤーは、システム内のタスクの分割を表します。タスクを分割する最も一般的な方法は、次の 3 つのレイヤーに分けることです。

• ユーザーインターフェースレイヤー
  
• ビジネスプロセスレイヤー
  
• データレイヤー
  

このタスクの分割により、類似したパターンとソリューションをグループ化できます。これらのレイヤーは分離していますが、互いに通信しています。

ユーザーインターフェースレイヤー

UI レイヤーでは、ユーザーとシステムのインタラクションに重点が置かれています。このレイヤーでは、サードパーティの Web アプリケーションを Salesforce に統合するためのコンポーネントを特定します。サードパーティアプリケーションに Salesforce の UI を表示するなど、複数のシステムの UI を組み合わせます。UI レイヤーはビジネスプロセスレイヤーとやり取りします。

• Salesforce キャンバス
  
• マッシュアップまたは Lightning Out
  

ビジネスプロセスレイヤー

ビジネスプロセスレイヤーは UI レイヤーの上に構築され、データを操作します。ビジネスロジックには、データ操作、検証、およびデータトランザクションの処理が含まれます。これらのトランザクションは、UI からのリアルタイムの呼び出しまたはデータを格納するデータベースに対するデータキャプチャイベントです。

このレイヤーに関連するインテグレーションソリューションの例を以下に示します。

• MuleSoft Anypoint Platform
  
• プラットフォームイベントバス (ストリーミング API を含む)
  
• フロー
  
• 送信メッセージング
  

データレイヤー

データレイヤーは、UI レイヤーとビジネスプロセスレイヤーをつなぐ接続部分です。プライマリデータソースと、システムの他のセグメントへの接続を対応付けて、識別します。このレイヤーでは、データ変換、移行、レプリケーションがよく行われます。このレイヤーに対応するコネクタとサービスは、ソリューション全体にデータが伝搬していく中で、データの正確性と整合性に重点を置いています。 

このレイヤーに関連するインテグレーションソリューションの例を以下に示します。

• Heroku Connect
  
• Salesforce Connect
  
• Apex
  
• REST API と SOAP API
  
• 複合 API
  
• Bulk API
  

各レイヤーについて詳しく学んだところで、次の表は Salesforce Lightning プラットフォームの各インテグレーションパターンに対応するレイヤーを示しています。

数量

数量では、伝達されるデータの量とメッセージのサイズに焦点を当てます。すべての Salesforce 組織には、厳格なガバナ制限と割り当てが適用されています。API コールなど、一部の割り当ては追加ライセンスを購入することで増やすことができます。DML ステートメントで更新できるレコード数など、厳格に設定されたガバナ制限は増やすことができません。ベストプラクティスは、必要なテクノロジー、コネクタ、サービスのみを使用し、使用可能なリソースをソリューションで不必要に消費しないようにすることです。

たとえば、一部の Salesforce Lightning プラットフォームのパターンには、少量のデータに適したソリューションがあります。これらのソリューションが適合する理想的なインテグレーションパターンは、リモートプロセス呼び出し — 要求と返信です。このパターンでは、システムが小規模な (または 1 つの) トランザクションを送信し、返信を必要とします。このパターンは、小規模なトランザクションに最適です。ただし、考慮すべきガバナ制限とライセンスの割り当てがあります。

一括データレプリケーションなど、一括データ処理に適したパターンもにあります。このようなパターンでは Heroku Connect を使用できます。このオプションは、制限を超えることなく大量のデータを一度に取得する場合に最適です。設計に利用可能なリソース制限を検討する際には、数量を把握することが重要です。

タイミング

インテグレーションソリューションを評価する際には、通信のタイミングと頻度が重要です。システムがほぼリアルタイムで通信を送信する必要があるか、それとも後で一括処理する必要があるかを検討します。実装するソリューションによって、通信のタイミングが決まります。

インテグレーションモードには、同期と非同期の 2 種類があります。

同期通信とは、クライアントがサーバーに要求を送信し、次の要求を発行する前に応答を待つことを意味します。たとえば、リモートプロセス呼び出し — 要求と返信インテグレーションパターンは同期通信です。アプリケーションはメッセージを送信し、処理を進める前に返信を待ちます。 

非同期通信とは、システムが返信を待たずに処理を続けることを意味します。アプリケーションがメッセージを送信すると、システムはリソースが使用可能になり次第、返信を返します。元のメッセージを送信したシステムは、返信を待たずにメッセージの送信を続行できます。返信メッセージの処理は個別に制御されます。

方向

方向は、2 つのシステム間のインタラクションを明確にします。このディメンションでは、プライマリソースシステムと対象システムを識別します。これは、システムがどのようにやり取りして接続するかに関するものであり、データが流れる方向に関するものではありません。

たとえば、あるインテグレーションソリューションがイベントをトリガーとして Salesforce から起動し、外部システムにコールアウトする場合を考えてみます。外部システムは、重要なデータを返すように設定されています。Salesforce がプライマリシステムであり、外部システムが対象システムであるため、方向は「Salesforce → システム」として記録されます。

どのパターンが設計に最適かを判断するために、方向を確認します。

• Salesforce → システム (または別の Salesforce 組織へ)
  
• システム → Salesforce
  

次の表は、各 Salesforce Lightning プラットフォームパターンの方向を示しています。インタラクションの方向についての詳細は、「インテグレーションパターンの概要」ドキュメントを参照してください。

セキュリティ要件

インテグレーションソリューションを設計する際、セキュリティは重要な考慮事項です。インテグレーション戦略の一環として、ユーザー ID、データマスキング、PII の保存などの側面を設計に組み込む必要があります。一般データ保護規則 (GDPR) は、ヨーロッパにおけるデータ保護とプライバシーに関する EU 法の規制です。米国を拠点とする企業の多くは、この法律をビジネスのベストプラクティスとして採用しています。

Salesforce → System の方向に従うインテグレーションパターンは、Shield Platform Encryption を設計に組み込むことで最大のメリットが得られます。Shield Platform Encryption では、お客様が管理する一意のテナントの秘密と、Salesforce が管理する主秘密を組み合わせて使用します。この 2 つを組み合わせることで、一意のデータ暗号化鍵が生成されます。設計に組み込む方法については、ヘルプの「Shield Platform Encryption によるデータのセキュリティの強化」を参照してください。

エラー処理と回復

インテグレーションでは、さまざまなエラーが発生します。エラーには、システムのしきい値 (ガバナ制限や API 割り当てなど)、ビジネスプロセスエラー (要求がビジネスルールに違反している場合)、ユーザー認証と承認の問題などがあります。全体的なソリューションの一部として、エラー処理と回復の戦略を組み込むことが重要です。

エラー処理

エラーが発生した (例外やエラーコードがコール元に返された) 場合、エラーはコール元が処理します。たとえば、エラーメッセージがエンドユーザーのページに表示またはテーブルに記録され、追加のアクションが求められます。

復旧

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

結合

複数のシステム間での通信では、同期が取れていない場合に遅延や信頼性の低下というリスクが生じます。各ソリューションでは、システム間にさまざまな連動関係があります。こうした連動関係には、テクノロジーの要件 (使用するサービスなど)、データ型の要件 (やり取りされる日付、番号、テキスト)、またはインタラクションスタイル (同期と非同期、タイミング) などが含まれます。

疎結合ソリューションのコンポーネントは、要件や連動関係が変化した場合に入れ替えることができます。たとえば、メッセージングは非同期通信で利用される場合に疎結合ソリューションとなります。密結合ソリューションには、インテグレーション戦略を再設計しない限り変更の柔軟性がほとんどありません。ソリューションのオプションを選ぶ際は、連動関係が壊れるリスクを減らすために、疎結合のオプションを選択してください。

次の単元では、このモジュールでここまでに学んだすべてのツールを使って、Salesforce Lightning プラットフォームのインテグレーションパターンを評価する練習をします。

リソース:

• MuleSoft: Error Handling from an Integration Patterns Perspective (インテグレーションパターンの観点からのエラー処理)
• MuleSoft: Applications Integration (アプリケーションインテグレーション)
• Salesforce Architecture Center: インテグレーションパターンの概要
• Enterprise Integration Patterns: Messaging Patterns Overview (メッセージングパターンの概要)