Serviceを見ていきたいと思います。※なお、設定手順があまりにも長過ぎたので、記事をわけました。SQLにそっくりそのまま同期するサービスです。SQLベースで確認・利用できます。データだけでなく、Metadata、フィールドの追加や削除の情報も連携されますので、カスタマイズの変更を意識することなく、データを同期してもらえます。APIやFetchXML)に沿う必要がありました。365にデータを統合するか、もしくは出力してどこかかしらでマージの上、材料とする必要がありました。365の文脈に沿って開発を行うことはそれなりにコストを要します。Serviceを使えば、以下の2点がメリットと言えそうです。APIの流れを鑑みると、後者はあまり用途が薄いかもですが)とまあ色々と書いてきましたが、結果としては以下のような感じで、SQLでデータの取得ができるようになりますので、あとは使いやすい形に煮るなり焼くなりお好きにしましょうという感じです。SQLにいくだけに、結構面白いアーキテクチャをしています。以下の通り簡単にまとめてみました。SQLの各テーブルへ連携しています。(テーブルの作成、Metadataの変更も自動で行います)(たぶん完全にEntityFrameworksのコードファーストで構成されているのかなと思うとなかなか興味深いです。Fablicが活かされそう)それでは、ちょっと面倒な設定方法を見ていきたいと思います。365側の設定に別れます。今回の記事ではAzure側の設定まで記載しています。前提条件はMSDNからの抜粋ですが、以下のとおりです。プロファイルを設定または変更することができます。サブスクリプションは、同じテナントである必要があります。引用元:https://technet.microsoft.com/library/a70feedc-12b9-4a2d-baf0-f489cdcc177d#Prereq_DESAzureのサブスクリプションを持っているのは当たり前ですが、3つ目に注意です。Azureのテナントは同じOffice365のテナントでなければいけません。SQLには接続できないみたいです。自動的に構成されるServiceBusとかのせい?)なお、Azureサービスの中でもユーザーが構成する必要があるサービスと自動的に作成・構成されるサービスがあります。ユーザーが作成する必要がある(=お金がかかる)Azureのサービスは以下のとおり。Serviceが自動的に構成してくれるサービスは以下のとおりです。SQLから構成していきたいと思います。基本は何も変わりませんので、簡単に進めます。管理画面にログインし、SQLデータベースを追加します。リージョンやリソースグループは任意のもので構成します。注意する点は照合順序くらいでしょうか。今回は日本語の環境を連携するので、とりあえず「Japanese_CI_AS」としました。ここは各環境、ニーズ、他システムとの連携に合わせて構成してください。サービスへのアクセスを許可」です。SQLを利用する場合は、しっかりとチェックしておきましょう。あとは接続文字列を取得して、作業完了です。Vaultを設定します。すいません、私もなんのことかわかりませんでした。アプリケーションやサービスで使用される暗号化キーとシークレットをセキュリティで保護するために役立ちます。保護されたキーを使用して暗号化できます。キーのインポートや生成を行うことができます。マイクロソフトがお客様のキーを処理します。Vaultが生成したURIを元に利用することができるサービスみたいです。Vaultベースでできるのかな、という解釈です。(まだ自分自身もちゃんと使っていないので、あくまで解釈です。間違っていたら、誰かご指摘ください......。Shellのコマンドサンプルが載っていますので、それに必要情報を入力して、実行するだけです。https://msdn.microsoft.com/ja-jp/library/mt744592.aspx#SetupAzureKV必要な情報は、以下の通り。AzureサブスクリプションのID。Azureのリソースグループ名。Vaultのロケーション。