二重書き込みのカスタマイズに関するガイダンス

注記

コミュニティの関心グループが Yammer から Microsoft Viva Engage に移行されました。 Viva Engage コミュニティに参加し、最新のディスカッションに参加するには、「 Finance and Operations Viva Engage Community へのアクセスを要求する」フォームに入力し、参加するコミュニティを選択します。

デュアル書き込みでは、一部のビジネスプロセスに対応したすぐに使用できるマップが提供されます。ただし、追加のフィールド、マップ、または変換が必要になる場合があります。二重書き込みプラットフォームは拡張可能です。カスタムマップを作成し、既存のマップをカスタムフィールドで拡張して、財務アプリと運用アプリとMicrosoft Dataverseの間でデータを同期できます。この記事では、これらのカスタマイズのガイダンスとベストプラクティスについて説明します。

マップをカスタマイズする前に、「テーブルと列のマッピングをカスタマイズする」のタスクを理解しておいてください。

エンティティが財務と運用アプリおよび Dataverse の両方である場合のガイダンス

エンティティが両方の環境に存在する場合は、デュアル書き込みマップを作成します。

エンティティの統合キーは、両方の環境で一致する必要があります。どちらの側でもエンティティキーを使用できない場合は、エンティティキーを作成します。マップ内の統合キーフィールドを相互にマップします。
エンティティが法人固有の場合は、会社フィールドが既にキーの一部であるため、マッピングに会社フィールドを含めないでください。例については、顧客グループ (msdyn_customergroups) エンティティマッピングを確認します。
財務と運用環境または Dataverse 環境のいずれかにフィルターを追加し、特定の条件でのみ二重書き込みマップをトリガーします。 顧客 V3 - アカウントまたは CDS 連絡先 V2 (連絡先) マップには例として使用できる複数のフィルターがあります。

エンティティが財務と運用アプリのみである場合のガイダンス

エンティティが財務および運用アプリにのみ存在する場合は、Dataverse で新しいエンティティを作成し、マップを追加します。

財務および運用エンティティに法人固有のデータが含まれている場合は、新しい Dataverse エンティティ のcdm_companies にルックアップフィールドを追加します。財務と運用エンティティがグローバルの場合、会社のフィールドは Dataverse エンティティには必須ではありません。
Dataverse エンティティにキーを追加して、財務と運用エンティティキーを反映します。二重書き込みには、財務と運用の環境と Dataverse 環境の両方で同じエンティティキーが必要です。財務および運用アプリと Dataverse のキーフィールドを相互にマップします。マッピングに会社フィールドを追加しないでください。例については、仕入先 V2 - msdyn_vendors mappingを確認します。

エンティティが Dataverse のみである場合のガイダンス

エンティティが Dataverse のみである場合、新しいエンティティを財務と運用の環境で作成し、マップを追加します。

新しいエンティティを作成し、必要なすべてのフィールドを含めます。エンティティがデータ管理および公開に対して有効になっていることを確認して、OData (Open Data Protocol) で使用できるようにします。新しいエンティティの作成方法の詳細については、データエンティティの構築と使用を参照してください。
財務および運用アプリのデータが法人固有である必要がある場合は、Dataverse エンティティの cdm_companies にルックアップフィールドを追加します。財務と運用エンティティがグローバルの場合、会社のフィールドは Dataverse エンティティには必須ではありません。
両方のエンティティがエンティティキーフィールドを持っていることを確認します。二重書き込みには、財務と運用の環境と Dataverse 環境の両方で同じエンティティキーが必要です。財務および運用アプリと Dataverse のキーフィールドを相互にマップします。マッピングに会社フィールドを追加しないでください。例については、仕入先 V2 - msdyn_vendors mappingを確認します。

マッピングへの属性の追加

エンティティが両方の環境に存在しマップされている場合は、属性をマップに追加できます。詳細については、テーブルマッピングと列マッピングのカスタマイズを参照してください。

操作の作成と更新では、Dataverse への属性の同期はトリガーされません

場合によっては、エンティティが両方の環境に存在しますが、操作の作成および更新によって Dataverse への属性の同期はトリガーされません。財務と運用の仮想マシン (VM) でSQL を使用、またはテーブルブラウザーを使用して BusinessEventsDefinition テーブルに移動します。更新日 ( RefTableName フィールド内) とエンティティ名 ( RefEntityName フィールド内) を持つ影響を受けるテーブルの組み合わせのレコードがあることを確認します。次の図に例を示します。

影響を受けるテーブルとエンティティ名の組み合わせを示す BusinessEventsDefinition テーブルブラウザーのスクリーンショット。

エンティティが財務と運用アプリまたは Dataverse のいずれかで使用できない場合のガイダンス

どちらの環境にもエンティティが存在しない場合は、両方の環境にテーブルを作成し、次の手順に従ってアプリを作成します。

Dataverse で、必要なすべてのフィールドを含む新しいテーブルを作成します。カスタムテーブルの作成の手順に従います。テーブルに法人固有のデータを格納する必要がある場合は、新しい Dataverse テーブルの cdm_companies にルックアップフィールドを追加します。テーブルがグローバルデータを格納する場合、会社のフィールドは Dataverse テーブルには必須ではありません。
財務と運用アプリで、必要なすべてのフィールドを含む新しいエンティティを作成します。 OData で使用できるように、エンティティがデータ管理に対して有効であり、パブリックであることを確認します。新しいエンティティの作成方法の詳細については、データエンティティの構築と使用を参照してください。
テーブルマップの二重書き込みを有効にするには、Dataverse テーブルで代替キーを定義する必要があります。 Dataverse の代替キーの値は、財務および運用アプリで定義したキーと一致する必要があります。たとえば、財務と運用アプリでは、次の図で示すように CustomerAccount がアカウント テーブルのキーになります。

Dataverse では、次の図で示すように accountnumber がアカウント テーブルのキーとして定義されます。

顧客 V3 テーブルマップでは、accountnumber が CustomerAccount にマップされていることがわかります。

二重書き込みのベストプラクティス

変更がトランザクション内にあることを確認します。テーブルの設計に基づいて、トランザクションあたりのレコード数を評価します。また、トランザクションブロックが X++ のプロセスの一部としてどのように構造化されているかを評価します。次に 2 つの例を挙げます。
```
ttsbegin;
// Transaction start
table1record1.insert();
table1record2.insert();
table1record3.insert();
table1recordN.insert();
ttscommit;
// Transaction end
```
```
ttsbegin;
// Transaction start
while (// loop conditions// )
{
    table1recordN.insert();
}
ttscommit;
// Transaction end
```
次の項目はビジネスイベントで処理されません。したがって、デュアル書き込みではこれらの項目は処理されません。
- doUpdate メソッド
- doInsert メソッド
- セットベースの操作 (挿入および更新)
- skipBusinessEvents(true) がマークされているレコード
マップするデータソースのビジネスイベントを登録します。財務アプリと運用アプリでは、データソースを外部結合して読み取り専用としてマークした場合、データソースは追跡されません。
変更は、財務および運用アプリでマップされたフィールドを変更した場合にのみトリガーされます。 Costomer Engagement アプリでは、フィールドの変更はすべて二重書き込み同期をトリガーします。
すべてのフィルター評価で有効な結果が得られます。
データソースは、マップされたフィールドが 1 つも指定されていない場合は追跡されません。
財務と運用アプリのエンティティリレーションシップでは、2 つのエンティティがリンクされ、同じトランザクション内の 2 つのレコードの間にリレーションシップが存在していることを二重書き込みで指定する必要があります。両方の親レコードと子レコードが関連するエンティティで同じトランザクションの一部である場合、二重書き込みバッチ処理はレコード挿入の順番付けが明示的に定義され、考慮されるエンティティリレーションシップに依存しています。財務と運用アプリのビジネスプロセスに複数のエンティティが含まれ、Costomer Engagement アプリでバッチモードとして有効にされている場合、二重書き込みにはエンティティ上で識別され、定義されるためのリレーションシップが必要です。次の図は、販売注文ヘッダー V2 と販売注文行 V2 とのリレーションシップを示しています。
パフォーマンスの問題を防ぐために、レコードの変更に対して複数のイベントを発生させるデュアル書き込みデータテーブルで大量のデータソースを使用しないようにします。二重書き込みで不要なフィールドをマップしないようにし、テーブルおよびエンティティでの過剰なビジネスロジックを回避します。
財務と運用アプリのカスタムエンティティが会社固有の場合 (エンティティの主な会社コンテキストプロパティが DataAreaId になっている場合)、関連する Dataverse テーブルはキー列の 1 つとして会社ルックアップを持つ必要があります。共有エンティティと会社固有のエンティティの間でマップすることはできません。 Visual Studio アプリケーションエクスプローラーで entity プロパティを確認することにより、財務および運用アプリエンティティが共有されているか、会社固有であるかを判断できます。詳細については、会社間のデータエンティティの動作を参照してください。

マップのフィルターガイダンス

フォルターは、財務と運用エンティティと Dataverse テーブルの両方に適用できます。デュアルライトマップに表示されるフィールドにのみフィルターを適用します。二重書き込みマップに追加する前に、フィルターの結果を確認します。

財務エンティティと運用エンティティの場合は、X++ 実行可能クラスの次のコード例を使用して、フィルター式を確認します。式とエンティティ名を置き換え、クラスを実行します。

var entityName = "PROJECTENTITY";
var filterExpression = '(ParentProject == "")';
Query query = new Query();
query.literals(NoYes::Yes);
QueryBuildDataSource qbd =
query.addDataSource(tablename2id(entityName));
qbd.addRange(fieldname2id(qbd.table(),identifierStr(RecVersion))).
value(filterExpression);
qbd.addSelectionField(fieldname2id(qbd.table(),identifierStr(RecId)));
QueryRun qRun = new QueryRun(query);
// This provides the actual SQL statement to execute
var actualSqlStatement = query.getSQLStatement();
while(qRun.next())
{
    var rec = qRun.get(tableName2Id(entityName));
}

Dataverse テーブルの場合は、OData 式にフィルター条件として式を追加して、フィルター式を確認します。

https://<Env URL>/api/data/v9.0/<TableName>?$filter=<fieldname> eq <value>

フィルターとその他の例の詳細については、「フィルター処理の例とパターン」を参照してください。

フィードバック

このページはお役に立ちましたか?

Last updated on 2026-03-07