強力なインテグレーションプラットフォームは、データが持っているパワーを解放し、企業のデジタル化を促進します。そのパワーは企業規模に縛られません。IT 部門から事業部門の全員に、インテグレーションから API管理までのすべてに影響を与えます。
Salesforce 連携のユースケースは増え続けています。MuleSoft は、Salesforce のデータか否かを問わず、あらゆるシステムのデータを開放、統合、保護することで、Salesforce の Customer 360 の機能を最大限に活用し、完全につながりあるエクスペリエンスの実現をサポートします。
この記事では、Salesforce 連携を実装しているチームのベストプラクティスを紹介します。
前提条件
通常、プロジェクトの中核となるチームは、MuleSoft と Salesforce を担当できるチームで構成され、双方のアーキテクトおよび開発者が参加しています。
MuleSoft の担当チームは、Salesforce workbenchをはじめ、組織、オブジェクト、プロパティ、オブジェクトの親子関係といった基礎知識を理解していなければなりません。一方、Salesforce の担当チームは、MuleSoft、API 主導の接続性、API の再利用、Salesforce の連携パターンについて、基本的な知識を持っている必要があります。
ベストプラクティスとレコメンデーション
1. エンド・ツー・エンドの要件を理解する
Salesforce と MuleSoft の両チームに加えて、顧客や関係者も交えたディスカバリーセッションと要件を洗い出すためのセッションを計画します。これらのセッションでは、「解決しようとしている問題」「業務のユースケース」「インテグレーションのユースケース」「期待される SLA （Service Level Agreement）」の明確化に取り組むとともに、インテグレーションパターンの方針に合意するように努めます。
下図の中の項目は、プロジェクトの計画・設計フェーズにおいて、工数見積もりを開始する前に定義しておくことが必須です。
2. 責任の分担
どのデータおよびインテグレーション要件を、Salesforce チームと MuleSoft チームのどちらが担当すべきかを理解しておくことは極めて重要です。全体的なデータフローを描き、その中でデータが変換されるポイントを明確に定義します。
たとえば次のようになります。
- MuleSoft はサードパーティシステムからデータを取得し、そのデータ形式を JSON に変換して、Salesforce オブジェクトに挿入または上書きします。
- Salesforce は、MuleSoft が保存したデータの処理を自動化します。
3. Salesforce – MuleSoft 間のセキュリティ設定の最終確認
Salesforce と MuleSoft の連携方法には、MuleSoft が提供する Salesforce アダプタを使う、Salesforce 内で MuleSoft の API を呼び出す、プラットフォームイベントを介するなど複数あります。どんな方法であっても、組織のセキュリティポリシーに適したレベルを選択してください。
下図は、MuleSoft の Salesforce コネクタに必要なセキュリティメソッドの例を示しています。OAuth 2.0 は基本認証と比較して、より優れたセキュリティやセキュリティを提供します。
Salesforce のコードから MuleSoft API を呼び出す際にも、できる限り高いセキュリティレベルを選択しましょう。MuleSoft には、さまざまなセキュリティオプションが存在します。
セキュリティは最重要事項です。Salesforce 担当と MuleSoft 担当の両チームだけでなく、顧客や情報セキュリティグループの全関係者がレビューし、承認するようにしてください。基本的には、できる限り高いセキュリティレベルを選択するとよいでしょう。
4. Salesforce CRM から MuleSoft 環境へのマッピング
Mule 環境と Salesforce CRM および外部システムに、どのように接続されているのかを示す図を作成します。これによりデータの流れを明確にし、潜在的な問題を洗い出すことが可能になります。
下のダイアグラムは、お客様の MuleSoft 環境は 3 つしかないのに Salesforce の外部システムは 4 つある、という問題を明示しています。このようなダイアグラムは、システムの相互作用について計画を立てることに役立ちます。
5. プロパティマッピングテーブル
外部システムと Salesforce のプロパティを一覧で表示するマッピングテーブルを作成することは、最も大切なステップの 1 つです。下のマッピングテーブルは、MuleSoft のスコープ、オーケストレーション、データまたは DataWeave の変換ロジックが定義されています。
このテーブルは Salesforce と MuleSoft の両チームで共有し、主な関係者や顧客にも確認・承認してもらいましょう。そうすることで、データの完全性と品質を担保できるようになります。
プロパティマッピングテーブルの例
6. 変換ロジックの責任分担
どの変換ロジックを、MuleSoft と Salesforce のどちらが処理するかを定義します。
MuleSoft API を他のシステムで再利用するかどうかを、まず判断します。再利用する場合は、Salesforce ではなく MuleSoft が変換処理を担当します。そうすることで、すべてのクライアントが一貫性のある応答を受信できるようになります。さらに、将来、外部システムを交換することも容易になります。
7. ビジネスロジック
MuleSoft と Salesforce のどちらかを選ぶとしたら、すべてのビジネスロジックを Salesforce に置くことが理想的でしょう。ビジネスロジックを MuleSoft に置くと、ビジネスロジックが変更された場合に、コードやデプロイが変わってしまう可能性があります。ビジネスロジックが Salesforce に設定されていれば、Salesforce の管理者設定画面でコントロールできます。Salesforce の開発者が、カスタムメタデータを使って設定可能なインタフェースを提供することも可能です。設定可能なインタフェースなら、ビジネスユーザーでもコードを触ることなく、ビジネスロジックを柔軟に変更できます。
Salesforce のメタデータの設定例には、API（エンドポイント、URL、バージョン、資格情報、他）、タイムアウト、ヘッダー、コンテンツタイプなど存在しています。これらは外部でも使用できるよう Salesforce で適切に設定し、簡単に変更可能です。
8. イベントログ
通常の MuleSoft ログ（主に技術チーム向け）とは別に、Salesforce の主要なイベントをログに記録することは有益です。これはデバッグログではなく、API やバッチの処理中に発生した主要なイベントやマイルストーンを記録するものです。一般的なロギングユーティリティを使用しコード内から呼び出すことで、主要なイベントを記録することができます。これには、リクエストの受信、外部システムの呼び出し、Salesforce でのデータ保存、プロセスで発生したエラーなどが含まれます。
このようなイベントログは、Salesforce の管理者が表示されたステータスを見て、MuleSoft API でどういったアクションが実行されたか、フローのどの段階でどのような問題が発生したか、を把握するのに役立ちます。一度記録されたイベントログは Salesforce の顧客アカウントで利用できるようになり、非技術系ユーザーも閲覧・監視することができます。
9. テスト
他のプロジェクトやユニットもそうであるように、インテグレーションにおいてもパフォーマンステストは必須です。応答時間を計測して、SLA に準拠しているかを確認します。実際のデータでテストし、バッチ処理により MuleSoft やサーバーのパフォーマンスをテストすることもできます。Selenium などのテスト自動化はとても役立ちます。
詳しくは、Salesforce 統合ソリューションをご覧ください。