アーカイブのカスタマイズ

注

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

この記事では、Microsoft Dynamics 365 finance および Operations アプリのアーカイブ機能でカスタマイズがどのようにサポートされるかについて説明します。アーカイブフレームワークは拡張可能であり、サポートされている機能シナリオ内にカスタムテーブルフィールドとカスタムテーブルを含めることができます。

カスタマイズシナリオ

アーカイブフレームワークでは、次の 3 つのカスタマイズシナリオがサポートされています。

標準アーカイブシナリオで Microsoft マネージドテーブルにカスタムフィールドを追加します。たとえば、一般会計や販売注文などです。
標準のアーカイブシナリオにカスタムテーブルを追加します。
カスタムテーブルを使用して独自のカスタムアーカイブシナリオを構築します。

注

独自のカスタムアーカイブシナリオを作成する場合は、カスタムテーブルのみを使用します。カスタムシナリオでは、結合または参照の依存関係としてでも、Microsoft マネージドテーブルを参照することはできません。

アーカイブオブジェクトを作成する

アーカイブのカスタマイズを実装するには、相互接続された複数のオブジェクトを作成して構成します。

依存関係が正しく確立されていることを確認するには、次の手順に従います。

Dynamics 365 の財務および運用の表。ライブテーブルは、アクティブなビジネスデータを含むソーストランザクションテーブルです。
ChangeTrackingEnabled プロパティをすべてのソース (ライブ) テーブルでYesに設定して、アーカイブ操作の変更追跡を有効にします。
アーカイブされた履歴データを格納するミラーテーブル。これらのテーブルには、最終処理されたアーカイブデータが格納されますが、アクセス、レポート、分析の頻度が低い場合でも必要です。履歴テーブルでは、ライブテーブルと比較して、使用されるストレージの最適化とインデックス作成の削減が少なくなります。
フィールドミラーリング - SysRowVersion と SysDataState を除き、ライブテーブルのすべてのフィールドを含める必要があります (プラットフォームはこれらのフィールドを管理します)。
名前付け規則 - ライブテーブル名と "履歴" サフィックス (例: SalesTable → SalesTableHistory)。

履歴テーブルの条件フィールドにインデックスがない場合、この条件により、取り消しジョブのスケジュールが禁止されます。フレームワークは、取り消し操作を許可する前に、これらのインデックスが存在することを検証します。

ライブテーブルのインデックス

アーカイブジョブに参加するすべてのソース (ライブ) テーブルには、最適なパフォーマンスと適切なフレームワーク操作のために 2 種類のインデックスが必要です。

アーカイブ条件インデックス - アーカイブジョブのフィルター処理、データ取得を最適化し、アーカイブ条件を満たすレコードの効率的な識別と処理を可能にします。

ルートテーブルまたは親テーブルの構造要件:

このテーブルの WHERE 条件で使用されるすべてのフィールドを含める
プライマリ分離フィールド (DataAreaId、 Ledger) を最初のフィールドとして配置する
含まれる列 (インデックスフィールドではなく) として追加する: RecId、 SysRowVersion、 SysDataStateCode

子テーブルの構造要件:

JOIN 条件で使用されるフィールドを親テーブルに含める
このテーブルの WHERE 条件で使用されるフィールドを含める
含まれる列として追加する: RecId、 SysRowVersion、 SysDataStateCode

適切な抽出条件インデックスがない場合、アーカイブジョブはジョブの作成時に検証チェックの実行が不十分であるか、失敗します。

調整インデックス (ArchiveSysVersionIdx) - 長期的な保持に必要であり、データを Dataverse に移動する準備が整ったときに、LTR マーキングステージで効率的な調整が可能になります。

必要条件

すべてのテーブル (LTR シナリオに参加するルートテーブルと子テーブルの両方) に存在する必要があります
正確なフィールドの順序 - SysDataStateCode に続いて SysRowVersion
インデックスの種類 - 非クラスター化インデックス
名前付け - 一貫性のために ArchiveSysVersionIdx を使用する

<AxTableIndex>
    <Name>ArchiveSysVersionIdx</Name>
    <Fields>
        <AxTableIndexField>
            <DataField>SysDataStateCode</DataField>
        </AxTableIndexField>
        <AxTableIndexField>
            <DataField>SysRowVersion</DataField>
        </AxTableIndexField>
    </Fields>
</AxTableIndex>

このインデックスがない場合、LTR 調整操作でパフォーマンスが著しく低下し、アーカイブジョブがタイムアウトまたは失敗する可能性があります。

Dataverse 統合のための財務および運用データエンティティ

財務データエンティティと運用データエンティティは、Dataverse でテーブルデータを仮想エンティティとして公開するデータエンティティです。仮想エンティティを使用することで、Dataverse は Dynamics 365 の財務および運用データにアクセスできます。アーカイブデータを Dataverse に格納して、SQL Server のフットプリントを最小限に抑えて長期的なリテンション期間を確保できます。

エンティティの名前付け規則 - [TableName]BiEntity。たとえば、SalesTableBiEntity、CustomModuleHeaderBiEntity。

財産	必須の値	Purpose
`IsPublic`	はい	Dynamics 365 の財務および運用の外部でエンティティを使用できるようにします。
`PublicEntityName`	エンティティ名	外部システムに公開される名前。
`PublicCollectionName`	エンティティ名 + 's'	OData エンドポイントのコレクション名。
`Allow Retention`	はい	長期的な保持機能を有効にします。
`Allow Row Version Change Tracking`	はい	増分同期の変更追跡を有効にします。
`Auto Create`	はい	Dataverse で仮想エンティティを自動的に作成します。
`Auto Refresh`	はい	Dataverse とメタデータの同期を維持します。

ジョブコントラクト作成者クラス

アーカイブジョブ要求の作成者 - アーカイブする内容を指定するアーカイブジョブコントラクトを構築する X++ クラス。このコントラクトは、処理するテーブル、関連するテーブル、フィルター処理に使用する条件、および Dataverse に使用するエンティティをアーカイブサービスに指示します。

適切なレイヤーを作成するには、次の 2 クラスパターンを使用します。

モジュールの基本クラス
- アーカイブシナリオのビジネスロジックが含まれています
- テーブルのリレーションシップを定義します
- 基準の検証を管理する
- 循環依存関係を回避するためにエンティティ名を参照しない
BusinessIntelligence モデルの拡張クラス
- コマンドチェーンを使用して基底クラスを拡張する
- 財務および運用データエンティティ参照を追加します
- Dataverse 統合を構成する
- ArchiveServiceArchiveJobPostRequestBuilder API を使用する

BusinessIntelligence モデルはデータエンティティを参照し、基本モジュールは BusinessIntelligence に依存しないようにする必要があります。この階層化アプローチは、循環依存関係を防ぎ、クリーンなアーキテクチャを維持します。

キービルダーメソッド

addSourceTableForLongTermRetention() - 履歴テーブルと財務および運用データエンティティを使用して、アーカイブスコープにテーブルを追加します。
addWhereCondition() - 日付範囲や状態などのフィルター条件を追加します。
addJoinCondition() - 親子テーブルのリレーションシップを定義します。
setJobCriteriaKey() - 並列実行のパーティションキーを設定します。
finalizeArchiveJobPostRequest() - 最終的なコントラクトをビルドします。

親子リレーションシップ

ルートテーブルには親が指定されていません。
子テーブルでは、親テーブル名を指定する必要があります。
フレームワークは、リレーションシップが存在することを検証します。
JOIN 条件は、実際の外部キーリレーションシップと一致する必要があります。

Dataverse の構成

Dynamics 365 のすべての財務オブジェクトと運用オブジェクトを作成した後、長期的なリテンション期間を有効にするように Dataverse を構成します。 2 つのオプションがあります。手動構成 (より簡単) または自動化されたソリューションのデプロイ (複数の環境の場合)。

完全な構成手順と考慮事項については、「長期保有のための Dataverse の構成」を参照してください。

開発ワークフローの概要

デザインフェーズ - テーブル、リレーションシップ、アーカイブの条件を特定します。
ライブテーブルの作成 - 既存のテーブルを拡張するか、適切なフィールドを使用して新しいテーブルを作成します。
履歴テーブルの作成 - 適切なインデックスを使用してライブテーブルをミラー化します。
インデックスの追加 - ライブテーブルに抽出条件と調整インデックスの両方を追加します。
財務データエンティティと運用データエンティティを作成する - 構成されたすべての必須プロパティを含めます。
エンティティの発行 - Auto Create を使用して Dataverse に自動的に発行するか、手動で発行します。
ジョブコントラクトの作成 - 基本クラスに加えて、財務および運用データエンティティ拡張機能。
Dataverse の構成 - CT と LTR を有効にします (手動またはソリューションベース)。
テスト - テストアーカイブジョブを作成し、データ移動を確認します。

実装手順の詳細については、次の記事を参照してください。

実装シナリオ

カスタマイズのニーズに合ったシナリオを選択します。

Microsoft マネージドテーブルにカスタムフィールドを追加する - テーブルとエンティティの拡張機能を通じてカスタムフィールドを追加することで、General ledger や Sales order などの既存のアーカイブテーブルを拡張します。詳細については、「詳細な実装ガイドを表示する」を参照してください。
標準シナリオにカスタムテーブルを追加する - General ledger にリンクされたカスタム決済テーブルなど、既存の Microsoft アーカイブシナリオに関連データとしてカスタムテーブルを追加します。このオプションは、Microsoft マネージドテーブルとの外部キーリレーションシップを持つカスタムテーブルがある場合に使用します。詳細については、「詳細な実装ガイドを表示する」を参照してください。
カスタムアーカイブシナリオの構築 - Microsoft のシナリオに関係なく、カスタムビジネスデータ用の新しいアーカイブシナリオを作成します。このオプションは、Microsoft テーブルに関連しないスタンドアロンのカスタムトランザクションデータがある場合に使用します。詳細については、「詳細な実装ガイドを表示する」を参照してください。

重要

カスタムシナリオには、 カスタムテーブルのみを含める必要があります。カスタムシナリオでは、結合または参照の依存関係としても、Microsoft マネージドテーブルをまったく参照しないでください。

長期保持用に Dataverse を構成する

Dynamics 365 の財務および運用でカスタムテーブル、エンティティ、およびインデックスを作成した後、長期保有を有効にするように Dataverse を構成します。サードパーティ (ISV、パートナー、顧客) には、次の 2 つのオプションがあります。

手動構成 (より簡単) - Power Apps Maker ポータルから変更の追跡と LTR を手動で有効にします。
自動ソリューション (高度) - エンティティ構成を含む Dataverse ソリューションを構築してデプロイします。

手動構成 - ほとんどのシナリオに推奨

この方法の方が簡単で、ソリューション管理の専門知識は必要ありません。 Power Apps Maker ポータルで各エンティティを手動で構成します。

エンティティを構成するには、次の前提条件が必要です。

Auto Create = Yesを使用して Dynamics 365 の財務および運用から仮想エンティティを発行する必要があります。
環境で長期的な保持が有効になっている必要があります。
Power Apps には適切なアクセス許可が必要です。

エンティティを手動で構成するには、次の手順に従います。

Power Apps Maker ポータルに移動します。
ターゲット環境を選択します。
テーブルに移動します。 使用可能な財務エンティティと運用エンティティでフィルター処理します。
カスタム仮想エンティティ (たとえば、 mserp_customtablebientity) を検索します。
エンティティごとに、変更の追跡と長期的な保持を有効にします。
アーカイブスコープ内のすべてのエンティティに対して繰り返します。

詳細については、以下を参照してください:

ソリューションの自動デプロイ

このアプローチでは、環境間での自動デプロイのためにエンティティ構成をパッケージ化する Dataverse ソリューションを作成する必要があります。

必須の前提条件:

Dataverse ソリューションの理解
ソリューション作成用の開発環境
ソリューション配布用のデプロイパイプライン

新しい Dataverse ソリューションを作成する

新しい Dataverse ソリューションを作成するには、次の手順に従います。

Power Apps に移動します。
開発環境を選択します。
ソリューション>新しいソリューションに移動します。
ソリューションの詳細を入力します。
- 表示名 - [Your Company] Archive Solution (たとえば、"Contoso WHS アーカイブソリューション")。
- 名前 - 技術名 (例: ContosoWHSArchive)。
- 発行元 - 組織のカスタム発行元を選択または作成します。
- バージョン - 1.0.0.0 から始めます。
を選択してを作成します。

仮想テーブルの追加と設定の構成

ソリューションを開いてください。
[ Add existing>Table>Virtual table] を選択します。
財務データテーブルと運用データテーブルを検索して選択します。
アーカイブスコープに関連するすべてのテーブルを追加します。
各テーブルについて:
- テーブル設定>Advanced オプションに移動します。
- [ 変更の追跡] を有効にします。
- このテーブルの長期保持を有効にします。
すべての変更を保存します。

注

手順 5. を完了すると、Power Apps はソリューションの Customizations.xml ファイルを変更追跡と LTR メタデータで自動的に更新します。高度な自動化パイプラインを構築する場合や、UI 構成をバイパスする場合を除き、XML ファイルを手動で編集する必要はありません。

Customizations.xml について (リファレンス)

Power Apps UI (手順 5) を使用して変更の追跡と LTR を有効にすると、システムはソリューションの Customizations.xml ファイルにこれらの設定を格納します。このセクションでは、参照とトラブルシューティングの目的でファイルに含まれる内容を示します。

Customizations.xml ファイルには、次の 2 つの重要なセクションが含まれています。

エンティティ変更追跡の構成 - 各エンティティの変更の追跡を有効にします
LTR メタデータ構成 - 各エンティティの長期的な保持を有効にします

Customizations.xml 構造体の例:

<?xml version="1.0" encoding="utf-8"?>
<ImportExportXml xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <Entities>
    <!-- Configure change tracking for each entity -->
    <Entity>
      <Name LocalizedName="Custom Workflow Header (mserp)" OriginalName="Custom Workflow Header (mserp)">mserp_customworkflowheaderbientity</Name>
      <EntityInfo>
        <entity Name="mserp_customworkflowheaderbientity">
          <ChangeTrackingEnabled>1</ChangeTrackingEnabled>
        </entity>
      </EntityInfo>
    </Entity>
    <Entity>
      <Name LocalizedName="Custom Workflow Line (mserp)" OriginalName="Custom Workflow Line (mserp)">mserp_customworkflowlinebientity</Name>
      <EntityInfo>
        <entity Name="mserp_customworkflowlinebientity">
          <ChangeTrackingEnabled>1</ChangeTrackingEnabled>
        </entity>
      </EntityInfo>
    </Entity>
    <!-- Add more entities as needed -->
  </Entities>
  
  <!-- Other standard solution sections -->
  <Roles />
  <Workflows />
  <FieldSecurityProfiles />
  <Templates />
  <EntityMaps />
  <EntityRelationships />
  <OrganizationSettings />
  <optionsets />
  <CustomControls />
  <SolutionPluginAssemblies />
  <SdkMessageProcessingSteps />
  <EntityDataProviders />
  
  <!-- Configure LTR metadata for each entity -->
  <metadataforarchivals>
    <metadataforarchival extensionofrecordid.logicalname="mserp_customworkflowheaderbientity">
      <isavailableforarchival>1</isavailableforarchival>
      <iscustomizable>1</iscustomizable>
      <name>mserp_customworkflowheaderbientity</name>
      <statecode>0</statecode>
      <statuscode>1</statuscode>
    </metadataforarchival>
    <metadataforarchival extensionofrecordid.logicalname="mserp_customworkflowlinebientity">
      <isavailableforarchival>1</isavailableforarchival>
      <iscustomizable>1</iscustomizable>
      <name>mserp_customworkflowlinebientity</name>
      <statecode>0</statecode>
      <statuscode>1</statuscode>
    </metadataforarchival>
    <!-- Add more entities as needed -->
  </metadataforarchivals>
  
  <EntityAnalyticsConfigs />
  <Languages>
    <Language>1033</Language>
  </Languages>
</ImportExportXml>

主要な XML 要素:

要素	価値	Purpose
`<ChangeTrackingEnabled>`	`1`	エンティティの変更の追跡を有効にします
`<isavailableforarchival>`	`1`	エンティティの LTR 機能を有効にします
`<iscustomizable>`	`1`	カスタマイズを許可する
`<statecode>`	`0`	アクティブな状態
`<statuscode>`	`1`	アクティブな状態

次の条件で Customizations.xml を手動で編集します。

エンティティをプログラムで構成する必要がある CI/CD パイプラインの構築
UI を使用せずに多数のエンティティを一括構成する
ソリューションのデプロイに関する問題のトラブルシューティング
正確な XML 構造のバージョン管理を必要とする高度な ALM シナリオ

ソリューションをエクスポートしてパッケージ化する

ソリューションで、[エクスポート] を選択 します。
[マネージド ソリューション] を選択します (運用環境のデプロイに推奨)。
[ 次へ ] を選択し、エクスポートが完了するまで待ちます。
ソリューションファイル (.zip) をダウンロードします。

ターゲット環境へのデプロイ

Power Apps のターゲット環境に移動します。
ソリューション>インポートに移動します。
ソリューション .zip ファイルをアップロードします。
インポートウィザードに従います。

バージョン管理と更新

アーカイブソリューションを更新する必要がある場合:

ソリューションのバージョンをインクリメントします (たとえば、1.0.0.0 → 1.1.0.0)。
Dynamics 365 ファイナンスおよびオペレーション環境のエンティティに必要な変更を行います。
Dataverse で仮想エンティティを同期します。
ソリューションをマネージドとして再度エクスポートします。
更新されたソリューションをターゲット環境にインポートします。

アーカイブフレームワークとの統合

カスタムソリューションは、次の方法でアーカイブフレームワークと統合されます。

仮想エンティティ - アーカイブフレームワークは、ジョブコントラクトで仮想エンティティを参照するときに、仮想エンティティを自動的に検出して使用します。
型の登録 - あなたのX++型の登録はあなたのエンティティを参照しています。
ジョブコントラクト - ArchiveAutomationJobRequestCreator クラスは、財務および運用データエンティティを名前で参照します。
コードの変更は不要 - アーカイブフレームワークでは、外部ソリューションを認識するための変更は必要ありません。

パートナーソリューション構造の例

ContosoWHSArchiveSolution (Managed)
├── Tables (Virtual Entities)
│   ├── mserp_whsloadtableentity (Change Tracking: On, LTR: Enabled)
│   ├── mserp_whsloadlineentity (Change Tracking: On, LTR: Enabled)
│   ├── mserp_whsshipmenttableentity (Change Tracking: On, LTR: Enabled)
│   └── ... (additional entities)
├── Publisher: Contoso (prefix: contoso_)
├── Dependencies
│   └── Archive Service (msdyn_ArchiveService)
└── Version: 1.0.0.0

テーブルの名前付けリファレンス

ライブ、履歴、財務および運用のデータエンティティ、および Dataverse レイヤー間での Microsoft が提供するテーブル名の完全なマッピングについては、「アーカイブテーブルの名前付けリファレンス」を参照してください。このリファレンスは、カスタマイズを実装し、アーカイブジョブコントラクトのエンティティ名を確認する場合に役立ちます。

フィードバック

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

Last updated on 2026-03-26