Salesfroce/Force.comを外部システムと連携させるための検討ポイントや、Salesforceが備える機能を有効に活用し、具体的なアーキテクチャーをどう考えるか。

1. Force.com
システム連携のデザイン考
察
Salesforce DUG Japan

2. 自己紹介
 所属
株式会社テラスカイ
取締役 ソリューション本部 部長
 名前
今岡 純二（いまおか じゅんじ）
 salesforce.com認定資格ほか
 主な業務
 導入コンサル
 アーキテクチャーデザイン
 Apex、VF開発
 テクニカルライティング
 著書

3. Force.comとの連携とは？

4. Force.comと何をつなげる？

5. Force.comとつなぐアプローチ
セキュリティ・ID連携
UI（User Interface）連携
ビジネスロジック連携
データ連携

6. 本日の重点テーマ
 ビジネスロジック連携
 データ連携

7. ビジネスロジック／データ連携の検討ポ
イント
• ソース／ター
ゲット
• プロトコル／
API
• データソース連携対象
• ロジック連
携
• データ連携
連携タイプ
• リアル／バッ
チ
• 同期／非同期
連携タイミン
グ
• 少量／大量
• 常時／定期
データ量・頻
度
ミドルウェアの必
要性検討
Salesforceが備え
る機能／APIの検討
Salesforceの制限
事項の検討

8. Force.com → 外部システム
リアル
タイム
同期
非同期
Visualforce +
Apex Controller +
Apex SOAP or HTTP
Apex Trigger +
@future +
Apex SOAP or HTTP
Outbound Message
Apex Batch
(Database.AllowsCallouts)
Apex SOAP or HTTP
Streaming API
ビジネス
ロジック
連携
バッチ 非同期
データ連
携

9. 外部システム → Force.com
ビジネス
ロジック
連携
トランザクション管
理あり or 複雑なロ
ジックあり
少量
デー
タ
Apex Web Service or
Apex REST Service
大量
デー
タ
Bulk API +Temporary
Table + Batch Apex
トランザクション管
理なし and 複雑なロ
ジックなし
少量
デー
タ
Bulk API or SOAP API
or REST API
大量
デー
タ
Bulk API
データ
連携
マスタデータが
Salesforce
マスタデータが
外部システム
SOAP API
(query、getUpdated)
Bulk API

10. Mobile → Force.com
Force.comのデータ追加・更新
REST API
Mobile
SDK
独自ログイン画面＆添付
ファイルの扱いには注意！

11. Force.com → Mobile
Force.com（通知） → Mobile（Native）
Streaming API
Push Notification
SDK2.0リソース：Push Notifications for Salesforce Mobile Apps with Urban Airship
LoadMa
p
Force.comのデータ取得
REST API
RecentlyViewedオブジェクト
SOQL：FOR VIEW、FOR REFERENCE句
Mobile
SDK

12. ユースケースから
連携のデザインを考える

13. 仮想シナリオ
 会社名
 株式会社オフィス・テラス（OT社）
 特徴・取り扱い商品
 注文から即日～翌日配送
 オフィス用品ネット販売最大手
 売上高・従業員数
 2500億円
 1000名

14. OT社CIOのシステム化の構想 1/2
顧客との関係強化
コンタクトセンター
• 老朽化対応
• 新たなチャネルへの対応
• 業務安定・効率化
• 顧客クレーム／離反率低下

15. OT社CIOのシステム化の構想 2/2
サプライヤとの関係強化
サプライヤポータル
• 業務のシームレスな連携
• 新たなコミュニケーション
• 需要予測精度の向上

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

17. システム化要件
既存システム
1. 顧客情報／サプライヤ情報はSAPで管理
2. 注文に関する情報は注文サイトを介しSAPで管理
3. SAPは厳重に管理されインターネットからの直接アクセスは不可
4. 注文情報のI/FとしてFTPでCSVを提供する機能は継続利用
5. FTPで通信する場合はセキュリティが確保されること
6. セキュリティが保証できる場合SAPのBAPIによるI/Fも限定的に可
能
7. I/Fは将来的にはWebサービス化しリアルタイム性を高めたい
8. 初期導入においてSAPに対する改修は原則実施しないこととする
9. 社内のユーザはADで管理され、SalesforceもSSOが望ましい

18. システム化要件
コンタクトセンター
1. 問合せのチャネルとして電話、E-mail、Webを想定
2. 将来的にはSNSも対応する方針
3. 電話問い合わせ時は顧客情報が自動表示されること
4. SAPが持つクーポン情報、ポイント情報を参照できること
5. SAPが持つ注文履歴、注文ステータスを参照できること

19. システム化要件
サプライヤポータル
1. SAPからの発注情報は1時間に1回連携する
2. 発注情報には数量変更、商品変更、キャンセルを含む
3. 発注情報に対する納期回答～出荷をポータル上で行う
4. サプライヤが回答した情報はSAPに1時間に1回連携する
5. 発注情報の連携は事前にサプライヤ情報が連携されて
いること

20. システム全体図
社内ポータル
FTPサーバ
連携ミドルウェア
ADFS
社員
サプライ
ヤ
Bulk API
Visualforce +
Apex Controller +
Apex Http(s)顧客
AppExchange
AD
CSV
XML
SOAP API
SAML

21. BulkAPIの利用
対象データ
• 顧客情報／サプライヤ情報
• 発注情報
選択理由
• FTPによるCSVを前提としたI/F
• データ量／パフォーマンス
留意事項
• 24時間あたりのBulk APIジョブ数
• 1回のリクエストで転送可能なファイル容量／レ
コード数
• 注文変更、キャンセル等のロジック上の複雑さ

22. SOAP APIの利用
対象データ
• サプライヤからの納期回答
• サプライヤからの出荷情報
選択理由
• SFDCでは大量の更新データをプッシュする手段が
ない
• BAPIによるI/Fはリクエストの集中が懸念された
留意事項
• 24時間あたりのSOAP APIコール数

23. Visualforce ＋ Apex HTTP（s）の利用
対象データ
• SAP上の注文履歴、注文ステータス
• SAP上のクーポン情報、顧客ポイント情報
選択理由
• SFDCに持った場合ストレージを大量に消費する
• 問合せ内容に応じて必要時に参照できればよい情
報
留意事項
• SAPのBAPIに対する仕様／スキル
• F/Wの内側にあるSAPのBAPIへのアクセス手段

24. 連携ミドルウェアの利用
対象データ
• SAPとSFDC間を流通するすべてのデータ
選択理由
• プロトコル変換、データソース対応、SFDCのAPI対
応
• スケジューリング実行、高い生産性／メンテナン
ス性
• 障害発生ポイントの局所化
留意事項
• 費用対効果
• 提供形態（クラウド／オンプレミス）

25. まとめ
 システム連携のニーズは多い
 システム連携の目的は多岐に渡る
 連携の種類や複雑さにより方式を決定する
 ミドルウェアの使用も検討する

26. おまけ
TerraSky Tech Blog
http://www.terrasky.co.jp/blog/
今回の講演に関するブログ
• Salesforceシステム連携のデザイン考察 1（ニーズとアプローチ）
http://www.terrasky.co.jp/blog/?p=2149
• Salesforceシステム連携のデザイン考察 2（ビジネスロジック連携／データ連携の検討
ポイント）
http://www.terrasky.co.jp/blog/?p=2151
• Salesforceシステム連携のデザイン考察 3（仮想シナリオから考える連携デザイン）
http://www.terrasky.co.jp/blog/?p=2237

27. ありがとうございました