Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.
Force.com
システム連携のデザイン考
察
Salesforce DUG Japan
自己紹介
 所属
株式会社テラスカイ
取締役 ソリューション本部 部長
 名前
今岡 純二(いまおか じゅんじ)
 salesforce.com認定資格ほか
 主な業務
 導入コンサル
 アーキテクチャーデザイン
 Apex、VF...
Force.comとの連携とは?
Force.comと何をつなげる?
Force.comとつなぐアプローチ
セキュリティ・ID連携
UI(User Interface)連携
ビジネスロジック連携
データ連携
本日の重点テーマ
 ビジネスロジック連携
 データ連携
ビジネスロジック/データ連携の検討ポ
イント
• ソース/ター
ゲット
• プロトコル/
API
• データソース連携対象
• ロジック連
携
• データ連携
連携タイプ
• リアル/バッ
チ
• 同期/非同期
連携タイミン
グ
• 少量/大量...
Force.com → 外部システム
リアル
タイム
同期
非同期
Visualforce +
Apex Controller +
Apex SOAP or HTTP
Apex Trigger +
@future +
Apex SOAP or ...
外部システム → Force.com
ビジネス
ロジック
連携
トランザクション管
理あり or 複雑なロ
ジックあり
少量
デー
タ
Apex Web Service or
Apex REST Service
大量
デー
タ
Bulk API...
Mobile → Force.com
Force.comのデータ追加・更新
REST API
Mobile
SDK
独自ログイン画面&添付
ファイルの扱いには注意!
Force.com → Mobile
Force.com(通知) → Mobile(Native)
Streaming API
Push Notification
SDK2.0リソース:Push Notifications for Salesf...
ユースケースから
連携のデザインを考える
仮想シナリオ
 会社名
 株式会社オフィス・テラス(OT社)
 特徴・取り扱い商品
 注文から即日~翌日配送
 オフィス用品ネット販売最大手
 売上高・従業員数
 2500億円
 1000名
OT社CIOのシステム化の構想 1/2
顧客との関係強化
コンタクトセンター
• 老朽化対応
• 新たなチャネルへの対応
• 業務安定・効率化
• 顧客クレーム/離反率低下
OT社CIOのシステム化の構想 2/2
サプライヤとの関係強化
サプライヤポータル
• 業務のシームレスな連携
• 新たなコミュニケーション
• 需要予測精度の向上
想定データ量
データ 初期件数 月間件数 年間件数 保存期間
顧客 600万件 1万 12万 永年
サプライ
ヤ
1500件 5社 60社 永年
問合せ 500万件 30万件 360万件 3年間
注文 移行しない 10万件 120万件 0.5年間
システム化要件
既存システム
1. 顧客情報/サプライヤ情報はSAPで管理
2. 注文に関する情報は注文サイトを介しSAPで管理
3. SAPは厳重に管理されインターネットからの直接アクセスは不可
4. 注文情報のI/FとしてFTPでCSVを提...
システム化要件
コンタクトセンター
1. 問合せのチャネルとして電話、E-mail、Webを想定
2. 将来的にはSNSも対応する方針
3. 電話問い合わせ時は顧客情報が自動表示されること
4. SAPが持つクーポン情報、ポイント情報を参照でき...
システム化要件
サプライヤポータル
1. SAPからの発注情報は1時間に1回連携する
2. 発注情報には数量変更、商品変更、キャンセルを含む
3. 発注情報に対する納期回答~出荷をポータル上で行う
4. サプライヤが回答した情報はSAPに1時間...
システム全体図
社内ポータル
FTPサーバ
連携ミドルウェア
ADFS
社員
サプライ
ヤ
Bulk API
Visualforce +
Apex Controller +
Apex Http(s)顧客
AppExchange
AD
CSV
X...
BulkAPIの利用
対象データ
• 顧客情報/サプライヤ情報
• 発注情報
選択理由
• FTPによるCSVを前提としたI/F
• データ量/パフォーマンス
留意事項
• 24時間あたりのBulk APIジョブ数
• 1回のリクエストで転送可...
SOAP APIの利用
対象データ
• サプライヤからの納期回答
• サプライヤからの出荷情報
選択理由
• SFDCでは大量の更新データをプッシュする手段が
ない
• BAPIによるI/Fはリクエストの集中が懸念された
留意事項
• 24時間...
Visualforce + Apex HTTP(s)の利用
対象データ
• SAP上の注文履歴、注文ステータス
• SAP上のクーポン情報、顧客ポイント情報
選択理由
• SFDCに持った場合ストレージを大量に消費する
• 問合せ内容に応じて必...
連携ミドルウェアの利用
対象データ
• SAPとSFDC間を流通するすべてのデータ
選択理由
• プロトコル変換、データソース対応、SFDCのAPI対
応
• スケジューリング実行、高い生産性/メンテナン
ス性
• 障害発生ポイントの局所化
留...
まとめ
 システム連携のニーズは多い
 システム連携の目的は多岐に渡る
 連携の種類や複雑さにより方式を決定する
 ミドルウェアの使用も検討する
おまけ
TerraSky Tech Blog
http://www.terrasky.co.jp/blog/
今回の講演に関するブログ
• Salesforceシステム連携のデザイン考察 1(ニーズとアプローチ)
http://www.terr...
ありがとうございました
Nächste SlideShare
Wird geladen in …5
×

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

4.444 Aufrufe

Veröffentlicht am

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

  • Login to see the comments

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

  1. 1. Force.com システム連携のデザイン考 察 Salesforce DUG Japan
  2. 2. 自己紹介  所属 株式会社テラスカイ 取締役 ソリューション本部 部長  名前 今岡 純二(いまおか じゅんじ)  salesforce.com認定資格ほか  主な業務  導入コンサル  アーキテクチャーデザイン  Apex、VF開発  テクニカルライティング  著書
  3. 3. Force.comとの連携とは?
  4. 4. Force.comと何をつなげる?
  5. 5. Force.comとつなぐアプローチ セキュリティ・ID連携 UI(User Interface)連携 ビジネスロジック連携 データ連携
  6. 6. 本日の重点テーマ  ビジネスロジック連携  データ連携
  7. 7. ビジネスロジック/データ連携の検討ポ イント • ソース/ター ゲット • プロトコル/ API • データソース連携対象 • ロジック連 携 • データ連携 連携タイプ • リアル/バッ チ • 同期/非同期 連携タイミン グ • 少量/大量 • 常時/定期 データ量・頻 度 ミドルウェアの必 要性検討 Salesforceが備え る機能/APIの検討 Salesforceの制限 事項の検討
  8. 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. 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. 10. Mobile → Force.com Force.comのデータ追加・更新 REST API Mobile SDK 独自ログイン画面&添付 ファイルの扱いには注意!
  11. 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. 12. ユースケースから 連携のデザインを考える
  13. 13. 仮想シナリオ  会社名  株式会社オフィス・テラス(OT社)  特徴・取り扱い商品  注文から即日~翌日配送  オフィス用品ネット販売最大手  売上高・従業員数  2500億円  1000名
  14. 14. OT社CIOのシステム化の構想 1/2 顧客との関係強化 コンタクトセンター • 老朽化対応 • 新たなチャネルへの対応 • 業務安定・効率化 • 顧客クレーム/離反率低下
  15. 15. OT社CIOのシステム化の構想 2/2 サプライヤとの関係強化 サプライヤポータル • 業務のシームレスな連携 • 新たなコミュニケーション • 需要予測精度の向上
  16. 16. 想定データ量 データ 初期件数 月間件数 年間件数 保存期間 顧客 600万件 1万 12万 永年 サプライ ヤ 1500件 5社 60社 永年 問合せ 500万件 30万件 360万件 3年間 注文 移行しない 10万件 120万件 0.5年間
  17. 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. 18. システム化要件 コンタクトセンター 1. 問合せのチャネルとして電話、E-mail、Webを想定 2. 将来的にはSNSも対応する方針 3. 電話問い合わせ時は顧客情報が自動表示されること 4. SAPが持つクーポン情報、ポイント情報を参照できること 5. SAPが持つ注文履歴、注文ステータスを参照できること
  19. 19. システム化要件 サプライヤポータル 1. SAPからの発注情報は1時間に1回連携する 2. 発注情報には数量変更、商品変更、キャンセルを含む 3. 発注情報に対する納期回答~出荷をポータル上で行う 4. サプライヤが回答した情報はSAPに1時間に1回連携する 5. 発注情報の連携は事前にサプライヤ情報が連携されて いること
  20. 20. システム全体図 社内ポータル FTPサーバ 連携ミドルウェア ADFS 社員 サプライ ヤ Bulk API Visualforce + Apex Controller + Apex Http(s)顧客 AppExchange AD CSV XML SOAP API SAML
  21. 21. BulkAPIの利用 対象データ • 顧客情報/サプライヤ情報 • 発注情報 選択理由 • FTPによるCSVを前提としたI/F • データ量/パフォーマンス 留意事項 • 24時間あたりのBulk APIジョブ数 • 1回のリクエストで転送可能なファイル容量/レ コード数 • 注文変更、キャンセル等のロジック上の複雑さ
  22. 22. SOAP APIの利用 対象データ • サプライヤからの納期回答 • サプライヤからの出荷情報 選択理由 • SFDCでは大量の更新データをプッシュする手段が ない • BAPIによるI/Fはリクエストの集中が懸念された 留意事項 • 24時間あたりのSOAP APIコール数
  23. 23. Visualforce + Apex HTTP(s)の利用 対象データ • SAP上の注文履歴、注文ステータス • SAP上のクーポン情報、顧客ポイント情報 選択理由 • SFDCに持った場合ストレージを大量に消費する • 問合せ内容に応じて必要時に参照できればよい情 報 留意事項 • SAPのBAPIに対する仕様/スキル • F/Wの内側にあるSAPのBAPIへのアクセス手段
  24. 24. 連携ミドルウェアの利用 対象データ • SAPとSFDC間を流通するすべてのデータ 選択理由 • プロトコル変換、データソース対応、SFDCのAPI対 応 • スケジューリング実行、高い生産性/メンテナン ス性 • 障害発生ポイントの局所化 留意事項 • 費用対効果 • 提供形態(クラウド/オンプレミス)
  25. 25. まとめ  システム連携のニーズは多い  システム連携の目的は多岐に渡る  連携の種類や複雑さにより方式を決定する  ミドルウェアの使用も検討する
  26. 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. 27. ありがとうございました

×