Salesforce と MuleSoft Anypoint Platform の相性は抜群です。Salesforce と連携する方法は多数あります。そのなかで MuleSoft の Salesforce コネクターこそが、インテグレーションのための包括的な方法を提供しています。インテグレーションを効率的に実装したい場合、 Salesforce を単なるエンドポイントとして扱いたくなるでしょう。しかし、より良い成果を得るためには Salesforce への理解を深めることが大切です。
Salesforce 連携のソリューションを最大限に活用する
各組織や各アプリケーションはそれぞれ異なります。しかし、Salesforce 連携ソリューションを設計するときには、アーキテクチャレベルで検討することを推奨します。以下にその理由を記します。
1. Salesforce 組織（Org）の構築戦略を念頭に置く
「Salesforce 組織（Org）」とは、Salesforce のインスタンスです。多くの企業では、異なる事業部門で複数の Salesforce 組織が使用されています。多くの場合、異なる Salesforce 組織を連携させることが求められます。技術的にはさまざまな方法で連携できます。しかし戦略的観点から、Salesforce 組織の統合または継続的な分離といった長期的な計画を見据えなければなりません。MuleSoft ではこれを「Org 戦略」と呼んでいます。
大抵の場合、この「Org 戦略」を立てるための十分な時間を取ることはできません。しかし、これを考える時間を設けることは、以下の項目を検討する重要なきっかけとなります。
- Salesforce 組織 (インスタンス) の扱いに、どのような戦略を持っているか？現在のアーキテクチャ構造は自社のビジネスをサポートしているか？邪魔となっていないか？インテグレーションの取り組みが、根本的な問題を隠していないか？
- AppExchange にあるソリューションや、優れたビジネスケースが Salesforce プラットフォームに存在するにもかかわらず、インテグレーションの問題を解決しようとしていないか？
- Salesforce 組織との連携を開始することで大きなビジネスメリットを得られる可能性があるにもかかわらず、連携プロジェクトに着手しようとしていないのではないか？
2. アーキテクチャに「ガバナ制限」を組み込む
ガバナ制限とは、Salesforce が MuleSoft のマルチテナントアーキテクチャで全テナントの正常動作を確保するために使用するガードレールのことです。つまりガバナ制限は、トランザクションごとのクエリ数、実行時間の長い API のコールアウト、受信 API リクエストなど、Salesforce 組織 (Org) 内のリソース消費に関する Salesforce アプリケーションの境界を提供しています。
ガバナ制限に違反すると、ビジネスプロセスが失敗することが多くなります。そのため、シナリオをモデル化して潜在的な違反シナリオを理解できるように、特定のインテグレーションに関連するガバナ制限を理解しなければなりません。機能以外の要件は、ガバナ制限に対して潜在的なソリューションを実行するのために重要です。採用しているアーキテクチャ手法に基づいて、それらを適切に把握することは必須です。
Anypoint Platform にはさまざまな対処方法が用意されています。たとえば、Salesforce の外部でデータをキャッシュに保存または複製すると、モバイルアプリのようなトラフィックの多いアプリケーションにガバナ制限が適用されることを軽減できます。また、スロットリングポリシーを使用して Salesforce 組織を保護する方法もあります。
場合によっては、制限を拡張するために容量を追加購入することもありますが、この追加の費用はソリューション全体で考慮する必要があります。
3. Apex はミドルウェアではないことを認識する
Apex はオブジェクト指向のプログラミング言語です。既成の機能だけではニーズを満たせない場合に、カスタムロジックを使用して Salesforce 組織 (Org) の機能拡張を可能にしてくれます。企業は Apex を利用することで、Salesforce 組織内でカスタム型 API を作成したり、サードパーティが作成した API を呼び出して、実装したい機能を構築することができます。このため多くの開発者が、Anypoint Platform のような専門的インテグレーション基盤を使わず、ミドルウェアのような機能のコーディングに使用したいと考えています。これは、Apex の本来的な用途範囲を超えています。
Apex は、ミドルウェアアプリケーションが必要とするような複雑な処理向けに設計かつ最適化されていません。そのため、本来の目的に従って定義・設計されている ガバナ制限 の対象となってしまいます。以下のような問題を解決するために Apex を使用している場合は、設計を再検討してください。
- Salesforce とサードパーティシステムの独自フォーマット間のデータ変換
- 異なるサードパーティエンドポイント間のルーティングまたはエンリッチメント
- 複数のシステムにまたがるサービスの複雑なオーケストレーション
- アプリケーション間のメッセージ待ち行列機能の提供
4. データを Salesforce に移動させるタイミングを理解する
Salesforce と連携するときのもうひとつの考慮事項は、ソースアプリケーションから Salesforce 組織 (Org) にデータを移動する (または移動しない) ことです。この考慮事項には、コンプライアンスや規制、データの即時性など、実装に影響を与えるビジネス要因が多くあります。表面的には、Salesforce 組織内でレコードを作成するオプションや、OData 経由でリモートシステムにアクセスするオプションがあります。もちろん、どちらも Anypoint Platform で実行できます。
その他にも考慮しなければならない点がいくつかあります。以下をご確認ください。
- Salesforce 組織内のデータ容量はバージョンやライセンス数に基づいて割り当てられていること。追加のストレージを購入することも可能ですが、キャパシティプランニングとアーカイブ計画を立てておくことを強くお勧めします。これは、重要なデータを Salesforce に移動させるときに特に重要です。
- ユースケースに Salesforce の大量のレコード (数百万レコード) が含まれる場合、大量のデータを伴うデプロイメントのベストプラクティスを参照すること。
- 主に、外部データを Salesforce 内のデータと連携させレポートに使用する場合で、ダッシュボードとボリュームが重要なときは Einstein Analytics などの補助ツールを検討してください。これらのツールは充実したビジネス分析機能を提供するだけでなく、分析のユースケースをサポートするように設計されたデータ移管機能を備えており、Saleforce 組織内のライブデータと統合できます。
- データの即時性が重要かつ不安定な場合、 Salesforce Connect と OData を介してリモートデータにアクセスすること。たとえば、在庫や注文のステータスがそれに当たります。外部オブジェクトはカスタムオブジェクトに似ています。しかし、リモート接続に固有のレイテンシがあるため、ユースケースに応じてユーザーエクスペリエンスに影響を与える可能性があります。
5. 設定オプションを把握する
Salesforce にはコードを記述することなくデータ連携できるオプションが用意されています。これらはシンプルに連携したいというニーズに適した選択肢となります。連携要件を満たしている場合は、時間、費用、労力を大幅に削減することが可能性です。
Salesforce to Salesforce は、事前に設定されたリンクを介してレコードを一方から他方にコピーするだけで、2 つの異なる Salesforce 組織 (Org) 間でレコードを共有できるようにします。これは Salesforce を使用しているパートナー企業と協働するときに便利です。しかし、ある程度のフィールドマッピングは可能ですが、大幅に異なるデータ構造を軽減するような複雑な変換はできません。この方法では遠隔オブジェクトのローカルコピーが作成されるため、受信側の Salesforce 組織内のデータ割り当てが消費されます。
Salesforce Connect の Cross-Org Connector にも同様の効果があります。コピーを作成するのではなく、遠隔でデータにアクセスすることで、別の Salesforce 組織からのデータを表示できます。これは OData を使用する場合と似ています。ただし、この方法ではプロバイダー側の Salesforce 組織で API コールが消費されるため、前述のように、関連するボリュームに応じてガバナ制限が作動することがあります。
すべてをまとめる
MuleSoft Anypoint Platform と Salesforce は、優れた顧客エクスペリエンスと販売者エクスペリエンスをサポートするため、かつ、インテグレーションの複雑な問題を解決するために必要となる優秀なパートナーです。適切なアーキテクチャ計画により、組織は導入しているツールから獲得できる価値を最大化させることが可能です。つまり IT 部門は、柔軟なITアーキテクチャのもと、事業部門の計画と期待に合わせて拡張可能なインテグレーションを実装することができるのです。