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

はじめに

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

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

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

・第1回は「Salesforceとシステム連携のニーズとアプローチ」です。

・第2回は「ビジネスロジック連携／データ連携の検討ポイント」です。

・第3回は「仮想シナリオから考える連携デザイン」の予定です。

Salesforceと何をつなげる？

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とつなぐアプローチ

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

セキュリティ・ID連携

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

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

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

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

ユーザインターフェース連携

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

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

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

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

また、Summer'13で正式リリースされたForce.com Canvasもこのアプローチに分類されるでしょう。Force.com Cnavasについては、「10分で分かる！使える！Force.com Canvas」が参考になります。

ビジネスロジック連携

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

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

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

データ連携

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

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

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