今回は前回作成したフローの使いどころや拡張性を検証します。
もともと想定されている使い方は、BC-DataverseのIntegrationの同期の仕組みでは即時反映されないので、Power Automateをつかて即時反映するという使いかたです。
ビジネス シナリオによっては、新しいデータまたは既存のデータに対する更新を Business Central にすばやく取り込むことが重要です。 これは、eコマース システムへの統合を含むシナリオに特に当てはまります。 スケジュールされたデータ同期は、今日のペースの速い世界では基準を満たしていません。 この機能により、Business Central は Dataverse または Dynamics 365 Sales 内の追加または変更されたデータをすぐに取得できます。
Power Automate フローを使用して Dataverse エンティティの変更を Business Central に通知する | Microsoft Learn
BC-DataverseのIntegrationの同期の仕組みが「即時ではない」ということですが、どのくらいの間隔で同期されるか確認してみましょう。同期の仕組みはJob Queueを使用しており、Dataverse Connection Setup ページから Integration Table Mapping の画面から確認できます。例えばCustomerの同期のサイクルを確認したい場合はMapping>Job Queue Entryを選択します。

すると同期するためのJob Queue Entryが表示されるので、Viewで開きます。

次回の実行が4:41になっており、12時間間隔(720分間隔)と設定されていることがわかります。Log Entriesボタンを押すと実行ログが確認できます。

このようにAM4:41とPM4:41あたりに実行されていることがわかります。

Job Queue Entryの実行間隔を短くすれば「比較的即時に近い同期」は実現できますが、限界はあります。それがこのPower Automateを使った同期の存在意義です。

対象となるテーブルについても確認してみます。実はそれほど多くありません。初期設定だとContact(連絡先)とCustomer(得意先)とVendor(仕入先)の3つです。Power AutomateのTemplateにはCurrencyも含まれていますが、同期の方向(Direction)が”ToIntegrationTable”となっているため、Dataverse側で通貨を変更してもクラウドフローは動きません。ContactやCustomer、VendorはBiDirectionなのでDataverse->BCが可能であり、このクラウドフローが機能します。

同期のDirectionが”FromIntegrationTable”のテーブルが3つあります。Payment TermsとShipment MethodとShipping Agentです。一見するとこれらもこのクラウドフローの対象にできそうですが実はできません。理由はこれらのマスタがDataverseではオプション値だからです。

具体的にPayment Termsを見てみましょう。DataverseではAccountテーブルに”Payment Terms”という項目があり、この項目のオプション値がBCのPayment Termsテーブルのレコードに対応します。

このクラウドフローの最後のBCコネクタで更新対象テーブルにBCのPayment Termsテーブルを指定することはできるのですが、、

最初のDataverseコネクタが動作しません。なぜなら”Dataverseのレコードが変更された場合”というトリガーだからです。DataverseのPayment Termsはオプション値であり、オプション値が追加された場合はこのトリガーが引かれないということです。

全体的に使いどころが限定されている感じのクラウドフローテンプレートではありますが、BC-DataverseのIntegrationの制約をを外してあげれば“Dataverseのレコードが変更されたときBCのレコードを作成する”という構文は結構使えると思います。

例えばDataverseでカスタムテーブルとしてEmployee(従業員)を作ります。

トリガーの対象テーブルにEmployeeを指定し、、

最後のBCレコード作成アクションでBCのEmployeeテーブルを対象にします。APIカテゴリはV2.0にする必要があります。

こんな感じでBCのレコードが作成されます。

まあ、APIカテゴリを変更した時点で元々の新機能の話ではなくなるのですがw
BC-Dataverse連携だけでなくBC-Sales連携をセットアップしたら元々の新機能として紹介しているAPIカテゴリでも対象テーブルが少し増えと思います。注意点としてはPower Automateの実行回数を消費するので、あまりリソースを見ながら設計するのがよいかと思います。(BC-DataverseのIntegration方式を使えば消費しないので。)