今回は新しく追加された機能の中でも、ちょっと特殊な立ち位置である、Data Export Serviceを見ていきたいと思います。

※なお、設定手順があまりにも長過ぎたので、記事をわけました。

Microsoft Azure SQL データベースで Microsoft Dynamics 365 (オンライン) データを複製します。

Data Export Serviceって?

簡単に言ってしまえば、Dynamics 365に存在する任意のエンティティのデータをAzure SQLにそっくりそのまま同期するサービスです。

Dynamics 365のオンプレミスであれば、SQL Serverを覗くことができますが、あのようなデータベースをAzure SQLベースで確認・利用できます。

また、データだけでなく、Metadata、フィールドの追加や削除の情報も連携されますので、カスタマイズの変更を意識することなく、データを同期してもらえます。

Data Export Serviceって何が嬉しいの?

今までのDynamics 365(CRM)であれば、データを抽出するには、Dynamics 365の文脈(WEB APIやFetchXML)に沿う必要がありました。

また、既存のデータベースや別サービスのデータと横断した分析や連携を行いたい場合、Dynamics 365にデータを統合するか、もしくは出力してどこかかしらでマージの上、材料とする必要がありました。

もちろん、Dynamics 365では取引先企業マスタなどといったデータは基幹システム等と同期する必然性がありますが、分析材料のためだけ等に、Dynamics 365の文脈に沿って開発を行うことはそれなりにコストを要します。

ですが、Data Export Serviceを使えば、以下の2点がメリットと言えそうです。

・Power Userレベルで設定でき、かつ使い慣れたSQLベースを用いて、分析材料に繋げることができる(他のシステムからもAzure SQLにマージできれば尚良)

・他システムへの非同期・疎結合な連携を安易にする(昨今のWEB APIの流れを鑑みると、後者はあまり用途が薄いかもですが)

とまあ色々と書いてきましたが、結果としては以下のような感じで、SQLでデータの取得ができるようになりますので、あとは使いやすい形に煮るなり焼くなりお好きにしましょうという感じです。

【Dynamics 365上の取引先企業データ】

f:id:sugimomoto:20170102223748p:plain

【Data Export Serviceを利用してAzure SQLへ同期したデータ】

f:id:sugimomoto:20170102223757p:plain

アーキテクチャについて

このサービス、最終的にAzure SQLにいくだけに、結構面白いアーキテクチャをしています。

以下の通り簡単にまとめてみました。

f:id:sugimomoto:20170102223806p:plain

Service BusはDynamics 365が標準で連携機能を備えていますが、それをService Fablicで受け取って、Azure SQLの各テーブルへ連携しています。(テーブルの作成、Metadataの変更も自動で行います)

(たぶん完全にEntityFrameworksのコードファーストで構成されているのかなと思うとなかなか興味深いです。このような連携方式だとService Fablicが活かされそう)

それでは、ちょっと面倒な設定方法を見ていきたいと思います。

大まかに言えば、Azure側の設定とDynamics 365側の設定に別れます。今回の記事ではAzure側の設定まで記載しています。

前提条件および必要なアクセス許可

前提条件はMSDNからの抜粋ですが、以下のとおりです。

・[Microsoft Dynamics 365] システム管理者セキュリティ ロール システム管理者セキュリティ ロールを割り当てるユーザーだけが、[Microsoft Dynamics 365] データ エクスポート プロファイルを設定または変更することができます。

・[Microsoft Azure] サブスクリプション。

・[Microsoft Azure] サブスクリプションおよび [Microsoft Office 365] サブスクリプションは、同じテナントである必要があります。

引用元:https://technet.microsoft.com/library/a70feedc-12b9-4a2d-baf0-f489cdcc177d#Prereq_DES

Azureのサブスクリプションを持っているのは当たり前ですが、3つ目に注意です。Azureのテナントは同じOffice365のテナントでなければいけません。なので、別契約の別テナントにあるAzure SQLには接続できないみたいです。(なんでだろう? 自動的に構成されるServiceBusとかのせい?)

なお、Azureサービスの中でもユーザーが構成する必要があるサービスと自動的に作成・構成されるサービスがあります。

ユーザーが作成する必要がある(=お金がかかる)Azureのサービスは以下のとおり。

・Azure SQL

・Azure Key Vault

Data Export Serviceが自動的に構成してくれるサービスは以下のとおりです。

・Azure Service Bus

・Azure Service Fablic

・Azure Storage

Azure SQLの構成

それでは、実際にAzure SQLから構成していきたいと思います。

基本は何も変わりませんので、簡単に進めます。

Azure の管理画面にログインし、SQLデータベースを追加します。

f:id:sugimomoto:20170102223814p:plain

リージョンやリソースグループは任意のもので構成します。

注意する点は照合順序くらいでしょうか。今回は日本語の環境を連携するので、とりあえず「Japanese_CI_AS」としました。ここは各環境、ニーズ、他システムとの連携に合わせて構成してください。

f:id:sugimomoto:20170102223819p:plain

あと、注意する必要があるのは、構成完了後の「Azure サービスへのアクセスを許可」です。

初期状態でONみたいですが、既存のAzure SQLを利用する場合は、しっかりとチェックしておきましょう。

f:id:sugimomoto:20170102223828p:plain

あとは接続文字列を取得して、作業完了です。

接続文字列をAzure Key Vaultへ設定

続いて、Azure Key Vaultを設定します。すいません、私もなんのことかわかりませんでした。

Azure Key Vault は、クラウド アプリケーションやサービスで使用される暗号化キーとシークレットをセキュリティで保護するために役立ちます。 Key Vault を使用すると、キーとシークレット (認証キー、ストレージ アカウント キー、データ暗号化キー、PFX ファイル、パスワードなど) をハードウェア セキュリティ モジュール (HSM) で保護されたキーを使用して暗号化できます。 さらに安心感を高めたい場合には、HSM でキーのインポートや生成を行うことができます。 その場合、FIPS 140-2 Level 2 適合の HSM (ハードウェアおよびファームウェア) でマイクロソフトがお客様のキーを処理します。 引用元:https://docs.microsoft.com/ja-jp/azure/key-vault/key-vault-whatis

通常、プログラムの設定ファイルなどに埋め込む接続文字列などの機密文字列をKey Vaultが代わりに隠蔽してくれて、プログラム実行側はKey Vaultが生成したURIを元に利用することができるサービスみたいです。

Key Vaultの方で接続文字列を管理しているので、接続先の切り替えや、不審なアクセスがあった場合のシャットアウトなども、このKey Vaultベースでできるのかな、という解釈です。(まだ自分自身もちゃんと使っていないので、あくまで解釈です。間違っていたら、誰かご指摘ください……。)

で、Azure Key Vaultですが、以下のMSDNにPower Shellのコマンドサンプルが載っていますので、それに必要情報を入力して、実行するだけです。

https://msdn.microsoft.com/ja-jp/library/mt744592.aspx#SetupAzureKV

必要な情報は、以下の通り。

パラメータ 設定内容
$subscriptionId AzureサブスクリプションのID。後述します。
$keyvaultName Azure Key Vaultの任意の名称
$secretName Azure Key Vaultの任意のシークレット名称
$resourceGroupName Azureのリソースグループ名。
$location Azure Key Vaultのロケーション。West USなど
$connectionString 先程取得したAzure SQLの接続文字列
$organizationIdList 接続するDynamics 365の組織名。後述します。
$tenantId AzureのテナントID。後述します。

サブスクリプションIDとテナントIDはPower Shellから「Login-AzureRmAccount」を実行すれば、取得できます。

f:id:sugimomoto:20170102223838p:plain

organizationIdはDynamics 365の「設定」→「カスタマイズ」→「開発者向けリソース」で以下の通り確認できます。

f:id:sugimomoto:20170102223846p:plain

あとは、PowerShellにはっつければ、以下の通り設定が進みます。

f:id:sugimomoto:20170102223853p:plain

最終的に以下のようなURLが取得できますので、控えておきます。

https://*.vault.azure.net:443/secrets//d60c1ffc2c224ac1bc847b093003def6

これでAzure周りの設定は完了です。

次回、Dynamics 365周りの設定方法を記載していきます。