Salesforceシステム連携のデザイン考察 3（仮想シナリオから考える連携デザイン） - TECH BLOG

はじめに

第2回では、最もニーズが多いと思われる「ビジネスロジック連携／データ連携の検討ポイント」に焦点をあて、外部システムと連携させるための検討ポイントをお伝えしました。

最終回となる第3回は、これまでに携わった案件から比較的よくあるニーズをブログ用に脚色した「仮想シナリオ」をベースに、「ビジネスロジック連携／データ連携」の具体的なデザイン、その選択理由、留意事項などをお伝えしたいと思います。

※ ここでお伝えするデザインは一例で、常に正解となるものではありません。参考としてご覧ください。

仮想シナリオ

企業情報

会社名

株式会社オフィス・テラス（OT社）

特徴・取り扱い商品

オフィス・テラス社は、オフィス用品ネット販売大手です。10年以上のビジネスの中、BtoBでオフィス用品をネット販売し、注文から最短で即日配送される利便性の高さ、提供するポイント制度や各種クーポンの高い評判から業績が急成長しています。今後はBtoBの経験と実績から、BtoCの領域にも進出していくことを検討し、ビジネスの拡大を目指しています。

売上高・従業員数

売上高：2500億

従業員数：1000名

オフィス・テラス社 CIOのシステム化構想

OT社のCIOは、業績が急成長を遂げるなか、ビジネスの変化に柔軟に拡張性を持って対応できるよう、既存システムの刷新を検討しています。そして、「顧客との関係強化／サプライヤとの関係強化」を重点施策とし、それを実現できるプラットフォームを検討しています。

顧客との関係強化

顧客との関係強化を図るため、既存のコールセンターの仕組みを刷新することとします。コールセンターの仕組みをリプレースする主な目的は以下の4つになります。

1.老朽化対応

現在のコールセンターの仕組みは導入から5年近く経過しました。このシステムは必ずしもカスタマイズ性が高いとは言えず、システムの柔軟性に現場は不満を持っています。

2.新たなチャネルへの対応

現在のコールセンターは電話受付を主体に行っています。メールやWebからの問合せも受け付けますが、システムとは直接連携されていません。また、新たなチャネルとしてTwitterやFacebookの投稿に関するサポートの必要性も強く感じています。

3.業務安定・効率化

コール量の増大に伴い、オペレータのスキルレベルのバラつきによるサポートレベルの低下を危惧しています。そのためナレッジの整備／共有を推し進めると共に、コールセンター部門、調達部門、商品企画部門など部門を超えたタイムリーな情報共有の必要性も感じています。

4.顧客クレームの低下

お客様の過去の問合せ履歴を含め、お客様の特徴や対応時の注意事項等をオペレータは速やかに確認し、適切な回答ができることが求められています。また、商品の発送に関する問い合わせが多いため、それらを集中的に管理する基幹系システム（SAP）とのシームレスな情報参照が欠かせません。

サプライヤとの関係強化

現在、サプライヤとの発注～納期回答～出荷～仕入計上の一連を情報共有できるポータル機能を提供しています。ただし、1日3回（朝、昼、夕）のバッチによるデータ連携のため、リアルタイム性に欠け、在庫不足による機会損失の低減は重要課題です。また、業績向上に伴う、サプライヤの増加、取扱商品の増加、トランザクション量の増加に対応するうえで、将来的なシステムの処理能力に不安を感じています。

1.業務のシームレスな連携

これまでもサプライヤ向けのポータル機能により、発注～納期回答～出荷～仕入計上のデータ連携を提供していましたが、1日3回（朝、昼、夕）から最低でも1時間に1回のデータ連携へ、将来的にはリアルタイムな連携を実現したいと考えています。

2.新たなコミュニケーション

これまでサプライヤとOT社調達部門では、コミュニケーションの手段として担当者間でのメールが主な手段でした。調達部門からサプライヤに対して、共同でキャンペーンの企画、有益な情報のタイムリーな伝達、そしてコミュニケーションロスを抑えるため、新たなコミュニケーション手段を望んでいます。

想定するデータ量

OT社が新システムを稼働させた場合に想定する初期データ、月間／年間データ量、および保存期間です。

データ	初期件数	月間件数	年間件数	保存期間
顧客	600万件	1万件	12万件	永年
サプライヤ	1500件	5社	60社	永年
問合せ	500万件	30万社	360万件	3年間
注文	移行しない	10万件	120万件	0.5年間

システム化要件

OT社の考えるシステム化要件です。なお、この要件には「ビジネスロジック連携／データ連携」以外の要件も含まれています。そのため、システム全体像を考えると共に、この要件のなかから「ビジネスロジック連携／データ連携」に相当する要件を抽出し、アーキテクチャーを考えてみたいと思います。

既存システム

1. 顧客情報／サプライヤ情報はSAPをマスタとして管理します。

2. 顧客からの注文に関する情報はOT社が開設する注文サイトを介しSAPで管理されます。

3. SAPは厳重に管理されインターネットからの直接アクセスは不可です。

4. 注文情報のI/FとしてFTPでCSVを提供する機能があり、この機能は継続利用することを考えています。

5. FTPで通信する場合はセキュリティが確保されることが必要です。

6. セキュリティを保証できる場合、SAPのBAPIによるI/Fも限定的に可能とします。

7. FTPによるI/Fは将来的にはWebサービス化しリアルタイム性を高めたいと考えています。

8. 初期導入においてSAPに対する改修は原則実施しないこととします。

9. 社内のユーザはActive Directoryで管理され、シングルサインオンできることが望まれます。

コールセンター

1. 初期リリースでは、問合せのチャネルとして電話、E-mail、Webを想定します。

2. 問合せチャネルには、将来的にSNSも対応する方針で考えています。

3. 顧客からの電話による問い合わせ時は顧客情報が自動表示されることとします。

4. オペレータはSAPで持つクーポン情報、ポイント情報をシームレスに参照を行います。

5. オペレータはSAPが持つ在庫情報、注文ステータス、注文履歴をシームレスに参照を行います。

サプライヤポータル

1. SAPで持つサプライヤに対する発注情報は1時間に1回連携することとします。

2. 発注情報には単なる発注だけでなく、数量変更、商品変更、キャンセルも含まれます。

3. サプライヤは発注情報に対する納期回答～出荷の報告をポータル上で行います。

4. サプライヤが回答した納期回答、出荷情報はSAPに対して1時間に1回連携することとします。

5. 発注情報の連携が行われる前までに、事前にサプライヤ情報が新システムに連携されている必要があります。

システム全体像

オフィス・テラス社CIOのシステム化構想およびシステム化要件から想定したシステム全体像になります。

使用するライセンス

システムの利用者のうち、社員（コールセンター利用者）にはService Cloudとしました。サプライヤに対しては、Chatterコミュニティ for パートナーとしました。（※Chatterコミュニティ for カスタマーでも要件は満たせるかも知れません。。）

シングルサインオン（SSO）

シングルサインオンの要件に対しては、ADFS（Active Directory Federation Service）を IdP（Identity Provider）、SalesforceをSP（Service Provider）としたシングルサインオン環境としました。なお、サプライヤはSalesforceが提供するログインページからログインすることを想定しています。

新たなチャネルへの対応

顧客からの問合せのうち、WebとメールはそれぞれWeb to Case、Mail to CaseのSalesforce標準機能を使用します。将来的なSNSへの対応は、AppExchangeで提供される「Salesforce for Twitter and Facebook」としました。

システム連携

システム連携は、連携ミドルウェアを配置し、全てのインターフェースのハブとして中継するアーキテクチャーとしました。連携ミドルウェアを配置した理由、連携ミドルェアとSalesforce／外部システム間のインターフェース方式の選択理由や留意事項等は後述します。

ビジネスロジック連携／データ連携のアーキテクチャー

Bulk APIの利用

対象データ

・顧客情報

・サプライヤ情報

・発注情報

選択理由

顧客情報、発注情報はデータ量が多いことが想定されます。そのため、大量データの更新に最も高いパフォーマンスを発揮するBulk APIの使用を想定しました。また、連携は1時間に1回のバッチであるためBulk APIでよいと考えました。また、SAPからFTPにより提供されるデータ形式はCSVです。Salesforceに取り込むための加工の必要性は考慮が必要ですが、Bulk APIではCSV形式のデータが取り込めることも採用する理由の一つです。

留意事項

Bulk APIの使用とした場合、24時間あたりのBulk APIジョブ数が制限に抵触しないか、1回のリクエストで転送可能なファイル容量／レコード数の制限に抵触しないか（抵触する場合、CSVファイルを適切な容量／レコード数に分割が必要）、注文情報に含まれる注文変更、キャンセル等のロジックの複雑さになります。

Bulk APIを第１に選択しましたが、発注情報の連携を通常考えた場合、Salesforce上では「発注ヘッダ／発注明細」のように正規化されたオブジェクト構成が想定されます。そのため、連携時の要件として、Salesforceに発注情報を書き込む際、発注ヘッダと発注明細は常に整合性が取れた状態、例えば「連携処理中であっても発注ヘッダのみが一時的に登録されているような状態は許容されない」とした場合には、Bulk APIでの対応は困難でしょう。

この場合、第２回連載でお伝えした、Bulk API + Temporaty Table + Batch Apex のアーキテクチャーを検討する、あるいはSOAP APIの「AllOrNoneHeader」の設定とSOAP APIの複数オブジェクトに対する同時書き込みによる対応などが代替案として考えられます。

SOAP APIの利用

対象データ

・サプライヤからの納期回答

・サプライヤからの出荷情報

選択理由

今回の要件では、Salesforce上に登録された発注情報に対してサプライヤが納期回答や出荷情報の更新を行い、1時間に1回更新されたデータを最終的にSAPに戻す必要があります。

そのため、直近にインターフェースされた以降の差分データをSOAP APIを使用して取得することとしました。具体的には、SOAP APIのqueryサービスで最終更新日時を条件に差分データを取得することを想定します。

留意事項

SOAP APIの使用とした場合、24時間あたりのSOAP APIコール数が制限に抵触しないかは留意が必要です。

SOAP APIを第1に選択しましたが、このアーキテクチャーを採用する結果、外部システムはSalesforceのデータ更新有無に関わらず、定期的にポーリングする形態となります。

そのため、将来的なリアルタイム性を考えた場合、Outbound Messageも選択肢になります。ただし、Outbound MessageのSOAPメッセージを受信するためのインターネットに公開されたサーバが必要、またOutbound Messageには追加・更新されたオブジェクトのIDしか含まれないため、結果的に外部システムはSOAP API等を使用したレコードの取得が必要という点から、今回はメリットが少ないと考えました。

Salesforceがクライアントに対して通知するAPIとして、Streaming APIもありますが、扱うデータの重要性から、通知が届かなかった場合の影響度を考慮して、今回は採用を見送りました。

結論としてリアルタイム性を最優先に考えたなら、「Visualforce + Apex Controller + Apex SOAP or Apex HTTP」、あるいは「Apex Trigger + @future + Apex SOAP or Apex HTTP」の適用を検討すると思います。

Visualforce＋Apex HTTP(s)の利用

対象データ

・SAP上の注文履歴、注文ステータス、在庫情報

・SAP上のクーポン情報、顧客ポイント情報

選択理由

SAP上に持つ、注文履歴や注文ステータス、在庫情報はコールセンターでお客様からの問合せ時に必要に応じて参照できればよい情報になります。また、これらSAP上に持つすべての大量なデータをSalesforceに保持するのは、ストレージを大量に消費する点からもデータ連携を行って重複して保持する必要性はないと考えました。

そのため、Salesforce上の取引先（顧客）ページなどに、注文履歴や注文ステータスを参照するためのカスタムボタンを設け、その実装にVisualforce＋Apex HTTP(s)を使用してSAPに対して問合せを行い、情報を参照できるようにします。

留意事項

Visualforce＋Apex HTTP(s)でSAPに対して問合せを行うこととしたものの、SAPはF/Wの内側にあり厳重なセキュリティで管理されています。そのため、SalesforceのサーバからApex HTTP(s)でコールアウトするにも、直接通信は行えないことが予想されます。また、仮にSAPのBAPIが呼びさせたとしても、エンジニアがSAPのBAPIにも精通しているとは限りません（Salesforceには精通していても）。そういった、SAPのBAPIに対する仕様面やスキル面での不安が残ります。

連携ミドルウェアの利用

対象データ

・SalesforceとSAP間を流通する全てのデータ

選択理由

今回の要件では、SalesforceとSAP間でデータを流通させる過程で、プロトコル変換、各種データソース対応、SalesforceのAPI、SAPのBAPIへの対応が含まれます。それらを連携ミドルウェアが持つコンポーネント群で吸収したいと考えました。また、1時間に1回のバッチ実行をスケジューリングする必要がありますが、連携ミドルウェアには通常スケジューリング実行の機能が含まれます。

さらに、発注情報を連携させる前提として、「事前にサプライヤが連携されていること」という制約や発注情報には注文変更やキャンセル情報が含まれます。これらは、連携を実施する上での順序が重要であることを意味します。そのため、連携ミドルウェアに通常含まれるフロー制御の機能も使用したいところです。

また、各インターフェース単位にスクラッチで開発することを考えた時、開発生産性や稼働後のメンテナンス性、将来的なリアルタイム性を求めた機能拡張、新たな外部システムとのインターフェース、障害発生ポイントの局所化などを考慮し、あらゆる連携を中継するハブとしての連携ミドルウェアという位置付けも考えたいところです。

留意事項

連携ミドルウェアの採用には、やはり費用対効果の評価が必要でしょう。

また、連携ミドルウェアにはクラウドサービスとして提供するタイプのもの、オンプレミスで提供するタイプのものがあり、何れの形態を採用するかの検討が必要でしょう。

特にSAPのBAPIを呼び出すうえで、クラウドサービスとして提供するタイプを採用した場合には、セキュリティを確保するためにVPNなどによる接続形態に考慮が必要でしょう。逆に、オンプレミスタイプを採用した場合には、連携ミドルウェアをDMZに配置し、Salesforceのサーバからのみ通信を許可したり、連携ミドルウェアからF/Wを通過してSAPとの通信を許可するような対応が必要になります。