今回は前回作成したクラウドフローを解析して解説します。
まずは一つ目のコネクタです。Dataverseのレコードの変更を検知しています。”Show Advanced Options”をクリックして展開。
フィルター条件が記述されていますので解析します。
“customertypecode”はAccountテーブルの”Relationship Type”の技術名称です。DisplayNameの”Relationship Type”をクリックします。
フィルタ条件には”3 or 11″と書いてありました。Customer(得意先)とVendor(仕入先)です。
フィルタ条件の後半の”statecode”も同様に調べるとActiveステータスのレコードに限定していることがわかります。
2つ目のコネクタもDataverseです。これはユーザーテーブルから条件を絞ってレコードを取得しています。”modifiedby_value”が何かというと、、
一つ目のコネクタで検知した変更レコードの更新ユーザーです。
続けて条件式が記述されています。マウスオーバーすると条件式が見れるのですが、”メールアドレスにcontoso.comを含むか” と “名前にBusiness Centralを含むか”を気にしているようです。
この条件式の意図を理解するため、ユーザーテーブルのデータを見てみます。Exportするなり、Edit in Excelをダウンロードするなりします。
ユーザー一覧を見ると1レコードだけ “メールアドレスにcontoso.comを含み” かつ “名前にBusiness Centralを含む”ユーザーが見つかります。 このユーザーは何でしょう？
答えはBCのDataverse Connection Setにあります。Dataverse Integration Userをクリックすると、、
先ほどのユーザーが表示されます。つまり、BCとDataverseのIntegrationを実行するシステムユーザーなのです。
あらためて条件式を見直してみます。変更ユーザーがこのユーザーの場合（If Yesの場合）に”何もしないで正常終了する”となっています。一瞬、逆じゃないか？と思うのですがこれが正しいです。このフローがなくてもBCとDataverseのIntegrationは動きます。BC側側の変更をDataverseに伝えるのはこの”Business Central･･･”という名前の”john@contoso.”のユーザーです。このユーザがDataverseのレコードを変更したときは無視してあげないと無限ループします。
それにしても、この条件はテンプレートそのまま使うには少し危険です。うっかり間違って条件を満たすユーザーを作ったら連携が漏れる可能性があります。 実戦投入する場合は “or”条件を”and”条件にするなり専用のユーザーを作るなりして、Integrationのシステムユーザーを一意に特定できるようにすべきかと思います。まあ、テンプレートですからね、テンプレートは悪くないです。自分たちで手直しすべきです。
さて、最後のコネクタを見てみましょう。Integration用ユーザー以外のユーザーによる変更を検知した場合、BCのレコードを作成するアクションです。Table name = “dataverseEntityChanges” で entityName = “account”になっています。これは何でしょう。
BCに該当のテーブルが存在するか探します。URL中に”&page=9174″を指定することでオブジェクトの一覧画面を開くことができます。ここでObject Nameに”Dataverse”を含むオブジェクトを検索します。すると”Dataverse Entity Change”を含むオブジェクトが見つかります。テーブルIDは5395だと判ります。
このテーブルの項目名も確認しておきます。同じくURLに”&Page=9806″を指定してテーブル項目一覧画面を開きます。”Entry No.”と”Entity Name”とシステム項目（作成者、作成日など）のシンプルなテーブルだと判ります。Dataverseで変更した項目の値とかが入っているかと思ったのですが、、拍子抜けするくらいシンプルです。
このテーブルのデータも見てみましょう。URLに”&Table=5395″を埋め込んでEnterを押すとTableID:5395のデータを見ることができます。この実験環境だと27行のレコードがすでに存在することが判ります。さて、このテーブルはDataverseでレコードを変更した際にどのようにふるまうのでしょうか。
Dataverseでレコードを変更してみます。
BCのTableID=5395(DataverseEntityChange)の一覧画面に戻ってF5ボタンを押してリフレッシュすると1行追加されていることがわかります。Entity Nameは”Acccount”となっています。このテーブルはこのフローのために用意されたテーブルでしょうか？それともBC-DataverseのデータIngegrationのために用意されたテーブルでこのフローでも使っているのでしょうか？
クラウドフローをOffにしてBC-DataverseのIntegrationを実施するという実験をします。クラウドフローをOffにして、、
DataverseのAccountの任意のレコードを変更し、、
BC側でDataverseの変更を同期します。
BC側に変更が反映されました。
TableID:5395のレコードは増えません。つまり、BC-DataverseのIntegrationには関係なく、”Dataverseの変更を検知してBCに反映させるクラウドフロー”のためのテーブルだということが推測できます。
ちなみにDataverse-AccountテーブルにはDataverseの変更が反映されています。こちらはBC-Dataverse Integration用のテーブルということが言えます。（まあ、もともとそうですが。）
最後のコネクタのところはDataverseEntityChangeの構造が単純すぎるので、本当の挙動はソースコードから読み取るしかないと思います。が、挙動とかテーブル構造からの何となくの推測としてはデータの更新の仕組み自他はIntegrationの仕組みを流用しており、”DataverseEntityChange”テーブルを使用して「即時変更反映するための催促」をしているのではないかと思います。
次回はこのクラウドフローの拡張性－何に使えるか？－を検証しようと思います。
1件のコメント