Salesforceシステム連携のデザイン考察1（ニーズとアプローチ）

Salesforceと外部システムとの連携をしたことはありますか？
Salesforceの利用領域がその導入効果により広がるなか、外部システムとSalesforceを連携させたいというニーズはとても多いと思います。

一方、Salesforceがクラウドサービスであるため、これまでの開発で培った経験や知見をそのまま有効に使えるのか？といった悩みや不安を感じる開発者の方もいらっしゃることでしょう。

今回は、これまでの経験から、具体的に外部システムと連携させるための検討ポイントや、Salesforceが備える機能を有効に活用し、具体的なアーキテクチャーをどう考えるかを3回に分けてお伝えしたいと思います。


・第1回は「Salesforceとシステム連携のニーズとアプローチ」です。
・第2回は「ビジネスロジック連携／データ連携の検討ポイント」です。
・第3回は「仮想シナリオから考える連携デザイン」の予定です。

Salesforceとシステム連携を考えた場合、大きく3つの連携対象がニーズとして多いでしょう。

SAPやOracle EBSなどのERPやJava/.netなどで開発された、基幹系システムを含む社内アプリケーションとの連携です。

ニーズは非常に多く、また最も身近な連携対象でしょう。F/Wの内側にあるアプリケーションと連携を行うという点が特徴的であり、課題にもなります。

Heroku、Amazon web services、Windows Azure、Google App EngineといったクラウドサービスとSalesforceとの連携も増えています。

また、代理店と自社、海外拠点と日本といった、異なるSalesforce組織間を連携させるケースもあります。（Salesforce標準機能では Salesforce to Salesforce という機能が提供されています。）

最近では、TwitterやFacebookといったSNS上のデータを分析、あるいはアクティブサポートを行うといったニーズからの連携も増えていることでしょう。

iPhone、iPad、Androidといったスマートデバイスを活用したいニーズは非常に多く、これらデバイスとの連携は欠かせません。

Salesforceとの連携を考えた時、そこには目的や期待効果があり、大きく4つの連携に大別されます。

Active DirectoryやLDAPといった認証基盤との連携です。企業は多くのシステムを抱え、システム管理者はユーザ管理やアクセス管理が負担になっていることでしょう。

また、エンドユーザも異なるシステムのそれぞれのID・パスワードを管理するのは負担であり、利便性も悪く感じることでしょう。そのため、IDを一元的に管理し、統合された認証が望まれています。

Salesforceでは、SAML（Security Assertion Markup Language）や代理認証、OAuthによる認証を行う仕組みが提供されています。

また、昨年のDreamforce（だったと思いますが）で、Salesforce Identityが発表されました。このニーズ多さ、および重要性の表れでしょう。

Salesforce上に構築したユーザインターフェースと外部システムのユーザインターフェースを統合する連携です。統合するアプリケーション自体に全く、あるいはほとんど変更を加えることなく統合することを基本的な考え方とします。

ユーザインターフェースを統合することにより、ユーザは異なるシステム毎にアプリケーションを起動したり、ウィンドウを切り替えたりする煩わしさから解放され、生産性の向上が期待されます。

ユーザインターフェース連携とは異なりますが、Salesforceが提供するServiceCloudコンソールもユーザインターフェースを統合することによる生産性向上を期待した機能になります。

Salesforceが提供する機能としては、Webタブやカスタムリンク／カスタムボタンを使って実装します。Salesforceの取引先の住所情報から、Googleの地図情報を取引先ページに埋め込んだり、ワンクリックで表示するといった事例がよくあります。

ビジネスロジックやプロセス、あるいはトランザクションが複数のシステム間をまたがる連携になります。 ビジネスロジックやプロセスの一貫性を保つ必要がある連携が対象となります。

この連携は設計、実装、例外処理への対応を十分検討する必要があり、一般的に複雑な連携になります。

例えば、注文を処理する仕組みをSalesforceで作成し、決済は金融機関のクレジット決済、在庫は基幹システムで管理されているとします。注文を最終確定する過程には、クレジットで決済可能であることが確認され、注文保存時に在庫引き当てができた場合を注文確定にするといったケースをイメージしてもらうとわかり易いと思います。

データ層でアプリケーションを統合し、複数システム間でデータを同期させる連携です。もっとも一般的で馴染みがある連携ではないでしょうか？

社内の基幹システムが持つ取引先をSalesforce上の取引先と同期させたり、Salesforceの商談と基幹システムの受注情報を同期させるなどの連携になります。

この連携の特徴は、複数システム間でほぼ同等なデータを重複した状態で保持することになります。そのため、重複した状態であることに意味がある場合に採用される連携です。一方で、大量データを同期させて保持することによるストレージの消費、連携対処データを双方向に連携する場合の複雑さ、新たな連携先が増えた場合に同等な連携を新たに開発する必要性などから、費用対効果の見極めは重要になるでしょう。

第1回ではSalesforceとの連携ニーズとそのアプローチについてお伝えしました。

第2回では、最もニーズの多いと思われる「ビジネスロジック連携／データ連携」の検討するポイントや具体的なアーキテクチャーをこれまでの経験からお伝えします。