編集中。裴さんとの会話メモ。
TODO★日本語変じゃないか？品質チェック
TODO★インテグレーションパターンもう少し読む
https://developer.salesforce.com/docs/atlas.ja-jp.252.0.integration_patterns_and_practices.meta/integration_patterns_and_practices/integ_pat_remote_process_invocation_fire_forget.htm
TODO★データ移行時に重複排除のケース 具体的に
【問題①】SalesforceとERP、どちらにどの機能をどのように持つべきか？
以下機能分担について考える。
・請求書発行
・請求書発行時のメール送信（対顧客）
・請求書情報参照画面（対顧客）
ERPとは？Salesforceとは？
まず、ERPとは、性質として会社の資産・財務を管理するもので、1円もずれてはならないシステムです。
当然、お客さんが直接操作したりするものではないですし（外部に出すものではない）、1行ずれたら会計が狂うので、社内で厳密に管理されるべきものです。
↓イメージはお城のように、門番がいて、そう簡単には入れないもの。お城からは定期的に武器（請求書）が、倉庫（ファイルサーバ）に対して吐かれる。
一方Salesforceのような情報系システムは、鮮度や便利さが大事で、ネットワークを介してお客さんがPCやモバイルを使って操作できるもので、Salesforceのような情報系システムと、ERPのような基幹系システムは、性質が真逆のものとなります。
↓お客さんが直接触る
※昨今、規模の小さいクラウドERPなどがありますが、本話題については大企業で使っているエンタープライズ向けのERPであると前提を置きます。（SAPなど）
ERPは、上述の通り、社外から闇雲に触らせるようなことはできないシステムですので、Salesforceとのシステム連携においては、基本的にETLを使い、定期的な夜間バッチなどでERPからSalesforceに対し、請求書データを一括連携するのがよいかと思います。
↓ETLは馬車のイメージ。瞬時に動くものではなく、夜間に1回など武器（請求データ）をまとめて運ぶ。
### ミドルウェアに関して
少しETLとESBの話に脱線しますが、ESBとは、イベント駆動で、まるで誰かから電話みたいにかかってきたら即時動く、という挙動をします。
（対向システムからAPIを叩かれて（Callされて）、処理を即時実行する、という流れ。）
即時動くことに強みを持つミドルウェアですので、大量データを扱うことには向いていません。
尚、ESBからシステムに対してポーリングするようなこともできますが、ポーリングは常にネットワークの一部領域を占有する形になりますので、ずっとスタンバイしているとリソース消費しますので、闇雲に使えるものではないと思われます。
一方、大量データや複雑なデータを扱うことに特化しているのはETLになります。ESBのように瞬間的に反応したり、瞬間的な性能はよくありませんが、定期スケジュールを行い、大量のデータ量を送ることは得意です。
ETLの裏はJavaのプログラムで、ETLのツール（例えばDataSpider）は、Salesforceへのコネクタやクレンジング処理などラップして提供しております。（もともと機能がラップされて提供しているため、１からJavaでプログラムを作らずローコードで設定できたりします。）
ですので、ETLはデータ移行やアーカイブ、負荷がかかる複雑なバッチ処理に向いていると考えられます。
### ではどのような機能配置とし、システム連携を行うか？
今までの話から、クライアント操作に関する画面や処理は、極力Salesforceが持ったほうがいいでしょう。
ですので、
・請求書発行
・請求書発行時のメール送信（対顧客）
・請求書情報参照画面（対顧客）
は、夜間にETLで、ERPからSalesforceに対して請求データを送り、Salesforce内でメール送信や請求情報を見せる、必要に応じて帳票ツールを導入し、請求書PDFを発行するのがよいでしょう。
### インテグレーションパターン
ところが、インテグレーションパターンを見ると、
SalesforceからERPへのファイア＆フォーゲットでの注文データのニアリアル連携であったり、SalesforceConnectでの注文情報の表示がベストプラクティス例として書かれています。
https://developer.salesforce.com/docs/atlas.ja-jp.252.0.integration_patterns_and_practices.meta/integration_patterns_and_practices/integ_pat_remote_process_invocation_fire_forget.htm
この場合、以下のようなアーキ前提を置いていると推察します。
壁（FW）が登場します。
特定のIP・ドメインをホワイトリストとして登録し、通信可能とするわけです。
（もちろんそのほかにそもそもネットワークはTLS/SSLで、認証を行い、不正ログとるためにShiledのイベントモニタリングや長期ログ、暗号化、リアルタイムイベントログアラートなどいろいろ・・・。システム連携の際にはESBでログの集中管理やモニタリングも実施・・・もしなんか不正アクセス・侵入があったらDNSは切り離す／不正に晒すわけです。）
上記前提があり、セキュリティ要件を突破できる場合に限り、
・請求書発行 →ＳＦからファイア＆フォーゲットで注文データを連携（ＥＳＢのＡＰＩをＣａｌｌ）し、ＥＳＢからＥＲＰのＡＰＩをＣａｌｌし、請求書発行ができる。
・請求書発行時のメール送信（対顧客）
・請求書情報参照画面（対顧客） →SalesforceConnectで、ReadOnlyでSalesforce上でデータ参照可能。
【問題②】MDMは必要か？
・MDMとは、データ採番システムである。横断的に顧客情報など番号を採番することができる。ただし、例えばグローバルで複数のCRMを使っており、それぞれの顧客を必ずMDMで採番する場合、MDMが止まるとまずい・影響甚大なので、MDM②などバックアップをしたりする。
・MDMは古いやりかたで、昨今は持たないケースが多い。
・そもそもMDMとは本来的に最初に導入すべきものだが、実態として会社が大きくなってから導入を検討するケースが多い。
・MDMを持つのは金融機関など、同じ業務・役割を行う支店をたくさん持つ場合。
（兜町支店の田中さん、八重洲本店の田中さんなどのデータケース）
・異なる業務をいろいろな部署で行う場合、MDMは適さない。
例）マーケターのようなリードを扱う場合、顧客番号の採番は必要なのか？在庫管理をしている部署に、顧客情報の採番は必要なのか？（そもそも顧客情報に触れないが、顧客／顧客番号が起点ならＭＤＭが関係してしまうが業務しづらくなる）
・仮に大企業が導入するとなると、ありとあらゆるシステムにつなぎ直しや古いデータの採番が必要になる。
なので、例えばSalesforceだと自動で採番され、ユニークにするような機能が標準で備わっているので、そもそもMDMを入れず、Salesforceが１Orgの場合は以下のように採番をしてしまう。（ERPの顧客情報は重複排除せずそのまま入れて、親レコードもしくはAccountの自己参照でラッピングする。そうすれば関連する顧客がわかり、紐づく注文データなども横断的にみることができ、360度ビューを見ることができる）
→仮にマルチOrgの時は、連携が難しくなるが、Org間で双方向連携し、双方に顧客データをもって見ることができるようにする。
