Salesforceシステム連携のデザイン考察 2（ビジネスロジック連携／データ連携の検討ポイント）

【連携対象を検討する理由】

連携対象を調査する大きな理由の一つは、「連携ミドルウェアの必要性」の検討になります。連携ミドルウェアは連携に特化しており、Javaや.netで開発を行うよりも高い生産性を発揮します。そのため、連携インターフェース数や連携項目数、変換・加工数が多い場合には、連携ミドルウェアの適用も検討します。さらに、連携ミドルウェアにはプロトコル変換するためのコンポーネントや、各種ファイル形式（CSV、XML、固定長など）の読み書き用コンポーネント、各種データベース製品用コンポーネント等が備わっていたり、後述する連携タイミングを柔軟に設定することができます。また、Salesforceとの連携を謳う製品には、Salesforceが標準提供する多くのAPIを容易に操作できるコンポーネントを持ち、Salesforce固有の制限事項をコンポーネント内でハンドリングできる製品もあります。

【連携タイプ／連携タイミングを検討する理由】

連携タイプおよび連携タイミングを検討する理由は、「Salesforceが備える機能やAPIのどれを使用するか」の検討のベースになります。Salesforceは標準機能として外部システムと連携するための機能、Apexを使用した外部システムと連携するための機能、APIを使用した連携を行うことができます。連携でよく使われるAPIだけでも、SOAP API、REST API、Bulk APIがあり、これら機能のどれを選択して連携に使用するは重要で、そのため連携タイプ／連携タイミングの検討は欠かせません。

【データ量・実行頻度を検討する理由】

データ量、実行頻度を検討する理由は、「Salesforceの制限事項への抵触」の可能性を検討するためです。Salesforceでは外部システムと連携するための多くの機能が提供されていますが、それぞれに制限事項が設けられています。それら制限事項を理解し、データ量と実行頻度から制限に抵触する可能性を注意深く検討します。制限に抵触する可能性が出た場合には、本来最適と思われた連携方式以外の方式を採用するケースも起こりえるでしょう。

★その他の要検討ポイント：双方向連携

Salesforceと外部システムとのデータ連携を行う時、連携対象システム間で重複して保持するデータを双方向に連携する場合があります。例えば、社内の基幹システムが持つ取引先の更新をSalesforceに対して連携し、Salesforceでも取引先の更新を行った場合には、基幹システムに対して連携するケースです。この連携をバッチで行なっていた時、同一の取引先が双方のシステムで更新され、コンフリクトが発生するケースがあり、その扱いは課題となります。

このような課題を考えた時、双方のシステムで編集可能とする項目は本当に分離することができないのか？を最優先に検討します。例えば、基幹システムが持つ取引先の与信情報はSalesforceに連携を行うが、Salesforceでは参照のみが行えればよく、Salesforceで編集可能として基幹システムに戻す項目は、Salesforceでのみ編集可能とします。この場合、ユーザにとっての利便性を損なう可能性はありますが、業務的な観点とデータ整合性から、まずは分離可能であるかを検討した方がよいでしょう。（コンフリクトが頻繁に発生する可能性が予見されるなら、それは業務フローとして課題を抱えている可能性もあります。）

とはいえ、結果的に完全に分離できないケースもあります。この場合は、システム的な解消ルールと運用の決め事になると思います。ルールとしては、双方のシステムが持つレコードの最終更新日時をベースに、最も直近の更新を優先して上書きするなどです。この時、コンフリクトしたデータを別途ユーザに通知し確認できるようにする等の運用対処も併せて施すケースもあります。