独自のカスタム アーカイブ シナリオを構築する

この記事では、カスタム テーブルのみを使用して完全なカスタム アーカイブ シナリオをゼロから構築する方法について説明します。 この方法を使用すると、Microsoft が管理するアーカイブ シナリオとは別に、カスタム ビジネス トランザクションをアーカイブできます。

Overview

このシナリオを使用して、Microsoft マネージド テーブルに関連しないカスタム トランザクション データをアーカイブします。 独自のジョブの種類、UI、およびアーカイブ スコープを使用して、完全な新しいアーカイブ シナリオを作成します。

関連するコンポーネント:

• カスタム ソース リンク テーブル (トランザクション ヘッダー)
• カスタム テーブル階層 (ヘッダー、行、詳細)
• カスタム履歴テーブル (ライブ テーブルごとに 1 つ)
• カスタム財務および運用データ エンティティ (ライブ テーブルごとに 1 つ)
• ジョブ コントラクト作成者クラス (2 つの個別のクラスが必要)
• サービスの種類の登録をアーカイブする
• 省略可能な UI コンポーネント

テーブル構造、ジョブ コントラクト、および型登録のための広範な X++ 開発。

前提条件

• Dynamics 365 財務および運用開発ツールを使用した Visual Studio へのアクセス
• アーカイブ フレームワークがデプロイされた開発環境
• アーカイブ フレームワークアーキテクチャの理解
• テーブルリレーションシップと階層設計の理解
• Dynamics 365 の財務および運用におけるシステム管理者の役割
• X++ プログラミングに関する知識

設計計画

開発を開始する前に、アーカイブ シナリオの構造を計画します。

• ソース リンク テーブルの識別 - ソース リンク テーブル は、アーカイブされる内容を定義するルート テーブルです。 これは、アーカイブ スコープの "ヘッダー" テーブルと考えてください。
• テーブル階層の設計 - テーブルリレーションシップをマップします。

CustomWorkflowHeader (Source Link)
├── CustomWorkflowLine (1-to-many)
│   └── CustomWorkflowLineDetail (1-to-many)
├── CustomWorkflowAttachment (1-to-many)
└── CustomWorkflowComment (1-to-many)

設計原則:

• RecId外部キーを介した親子リレーションシップ
• リレーションシップの基数を明示 (一対一、一対多)
• 循環依存関係なし

アーカイブ条件の定義

一般的な条件パターンは次のとおりです。

• 年齢ベース: 特定の日数、月数、または年数より古いレコード。
• 状態ベース: 完了済み、 終了済み、または 最終処理済みの状態の レコード。
• ボリューム ベース: 保持しきい値を超えるレコード。

条件の例:

// Workflow completed over 2 years ago
CompletedDate < (today() - 730)
&& WorkflowStatus == WorkflowStatus::Completed
&& DataAreaId == _selectedLegalEntity

ソース リンク テーブルを作成する

アーカイブ スコープを定義するルート テーブルを作成するには、次の手順に従います。

1. プロジェクトを右クリックし、[追加>新しいアイテム>Table] を選択します。
2. ソース リンク テーブルに名前を付けます。
   • 例： CustomWorkflowHeader
   • 例： IntegrationBatchHeader
   • 例： TelemetrySessionHeader

必須フィールドを追加する

必須フィールド:

• RecId (Int64、主キー) - 自動的に追加されたビジネス フィールド:
• トランザクション識別子 ( WorkflowId、 BatchId、 SessionIdなど)
• 状態フィールド (たとえば、 WorkflowStatus)
• 抽出条件の日付フィールド ( CreatedDate、 CompletedDateなど)
• その他の関連トランザクション データ

構造体の例:

CustomWorkflowHeader
├── RecId (Int64)
├── WorkflowId (String)
├── WorkflowType (Enum)
├── WorkflowStatus (Enum: Created, InProgress, Completed)
├── InitiatedBy (UserId)
├── CreatedDate (TransDate)
├── CompletedDate (TransDate)
├── DataAreaId (DataAreaId)
└── Partition (PartitionKey)

テーブル プロパティを構成する

1. Visual Studio で、ソース リンク テーブルを選択します。
2. [プロパティ] ウィンドウで、 ChangeTrackingEnabled を見つけます。
3. 値を [はい] に設定します。

アーカイブ条件インデックスを追加する

このインデックスは、アーカイブ ジョブクエリのパフォーマンスに 不可欠です 。

<AxTableIndex>
    <Name>ArchiveCriteriaIdx</Name>
    <Fields>
        <AxTableIndexField>
            <DataField>WorkflowStatus</DataField><!-- Criteria field -->
        </AxTableIndexField>
        <AxTableIndexField>
            <DataField>CompletedDate</DataField><!-- Date criteria field -->
        </AxTableIndexField>
    </Fields>
    <IncludedColumns>
        <AxTableIndexIncludedColumn>
            <DataField>RecId</DataField><!-- If not clustered -->
        </AxTableIndexIncludedColumn>
        <AxTableIndexIncludedColumn>
            <DataField>SysRowVersion</DataField>
        </AxTableIndexIncludedColumn>
        <AxTableIndexIncludedColumn>
            <DataField>SysDataStateCode</DataField>
        </AxTableIndexIncludedColumn>
    </IncludedColumns>
</AxTableIndex>

インデックスの設計規則:

• 最初のフィールド: プライマリ分離 (DataAreaId または Partition)
• 次のフィールド: 状態や日付など、WHERE 条件で使用される抽出条件フィールド
• 含まれる列: RecId (クラスター化されていない場合)、SysRowVersion、パフォーマンスのためのSysDataStateCode

長期保有のための調整インデックスを追加する

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

関連する子テーブルを作成する

テーブル階層内のすべてのテーブルを作成するには、次の手順に従います。

1. CustomWorkflowLineやCustomWorkflowAttachmentなど、適切な名前でテーブルを作成します。
2. WorkflowHeaderRecIdなど、外部キー フィールドを親に追加します。
3. 親と一致する DataAreaId や Partition などの分離フィールドを追加します。
4. ビジネス固有のフィールドを追加します。
5. ChangeTrackingEnabled各子テーブルにYesするように設定します。

親子リレーションシップを定義する

各子テーブルに親テーブルとの関連付けを追加します。

<AxTableRelation>
    <Name>CustomWorkflowHeader</Name>
    <RelatedTable>CustomWorkflowHeader</RelatedTable>
    <Cardinality>ZeroMore</Cardinality>
    <RelationshipType>Association</RelationshipType>
    <Constraints>
        <AxTableRelationConstraint>
            <Field>WorkflowHeaderRecId</Field>
            <RelatedField>RecId</RelatedField>
        </AxTableRelationConstraint>
    </Constraints>
</AxTableRelation>

各子テーブルに必要なインデックスを追加する

アーカイブ条件インデックス (外部キーを含む):

<AxTableIndex>
    <Name>ArchiveCriteriaIdx</Name>
    <Fields>
        <AxTableIndexField>
            <DataField>WorkflowHeaderRecId</DataField><!-- Foreign key for JOIN -->
        </AxTableIndexField>
    </Fields>
    <IncludedColumns>
        <AxTableIndexIncludedColumn>
            <DataField>RecId</DataField><!-- If not clustered -->
        </AxTableIndexIncludedColumn>
        <AxTableIndexIncludedColumn>
            <DataField>SysRowVersion</DataField>
        </AxTableIndexIncludedColumn>
        <AxTableIndexIncludedColumn>
            <DataField>SysDataStateCode</DataField>
        </AxTableIndexIncludedColumn>
    </IncludedColumns>
</AxTableIndex>

調整インデックス (すべてのテーブルで同じ):

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

履歴テーブルを作成する

アーカイブされたデータ ストレージの履歴テーブルを作成するには、次の手順に従います。

1. 対応する履歴テーブルを作成する
2. 名前: [LiveTableName]History
   • 例： CustomWorkflowHeaderHistory
   • 例： CustomWorkflowLineHistory

ライブ テーブルのすべてのフィールドをミラー化する

ライブ テーブルから次を 除くすべてのフィールドをコピーします。

• SysRowVersion (システム管理、移動時の変更)
• SysDataState (システム管理、移動時の変更)

他のすべてのフィールドが同じであることを確認します。

• 同じ名前
• 同じデータ型
• 同じ EDT
• 同じ長さ

履歴テーブルのプロパティを構成する

履歴テーブルごとに、ライブ テーブルから一意のインデックスをコピーしないでください (アーカイブされたデータには一意性は必要ありません)。

クエリ パフォーマンスのインデックスを追加する

外部キーと一般的に照会されるフィールドにインデックスを追加すると、アーカイブされたデータの効率的なクエリが可能になり、反転スケジューリングに必要になります。

財務データ エンティティと運用データ エンティティを作成する

長期保有のために Dataverse 仮想エンティティを有効にする財務データ エンティティと運用データ エンティティを作成するには、次の手順に従います。

1. プロジェクトを右クリックし、[ 追加>新しい項目>Data エンティティ] を選択します。
2. 名前を入力します。 [TableName]BiEntity
   • 例： CustomWorkflowHeaderBiEntity
   • 例： CustomWorkflowLineBiEntity

プライマリ データ ソースを構成する

1. データ ソースの設定:
   • プライマリ データ ソース: 対応するライブ テーブル
   • すべてのフィールドを含める
2. フィールドの表示設定:
   • すべてのフィールド = パブリック

必須エンティティ のプロパティを構成する

アーカイブと LTR には、次のプロパティが必要です。

rowversion のサポートを有効にする

各エンティティについては、「 エンティティ変更の追跡」を参照してください。

1. 変更の追跡をデータ ソースに追加します。
2. エンティティで rowversion を有効にします。
3. データ管理 ワークスペースのテスト エンティティ。

仮想エンティティを Dataverse に発行する

Dataverse for LTR でエンティティを使用できるようにするには、次のいずれかのソリューションを使用します。

• 自動発行 (推奨) - Auto Create を Yesに設定した場合:
  • 仮想エンティティは、エンティティの同期後に自動的に発行されます。
  • このプロセスには 24 ~ 48 時間かかる場合があります。
  • 特に何か操作をする必要はありません。

Dataverse でエンティティを確認する

1. Power Apps Maker ポータルに移動します。
2. 環境を選択し、[ テーブル] を選択します。
3. エンティティ (mserp_customworkflowheaderbientityなど) を検索します。
4. 階層内のすべてのエンティティが存在することを確認します。

仮想エンティティ メタデータを更新する (必要な場合)

階層内のエンティティのエンティティ メタデータを更新する必要がある場合は、次のいずれかのオプションを使用します。

高度な検索を使用した手動更新:

1. Dataverse 環境で [Advanced Find]\(高度な検索 \) に移動します。
2. [利用可能な財務エンティティと運用エンティティ] を選択します。
3. 名前 をフィルターして、エンティティ名 (例: customworkflowheaderbientity) を含めます。
4. 結果からレコードを開きます。
5. [ 最新の情報に更新 ] チェック ボックスをオンにします。
6. レコードを保存します。
7. 階層内のすべてのエンティティに対して繰り返します。

Power Apps Maker ポータルの使用:

1. Power Apps Maker ポータルに移動します。
2. [テーブル] に移動し、各エンティティを見つけます。
3. エンティティを開き、更新をトリガーします。
4. 階層内のすべてのエンティティに対して繰り返します。

詳細については、「 仮想エンティティの更新のトラブルシューティング」を参照してください。

変更の追跡と LTR を構成する

サード パーティ (ISV、パートナー、顧客) は、2 つの方法を使用して、長期的な保持のためにエンティティを構成できます。

手動構成 - この簡単なアプローチは、ほとんどの実装に適しています。 Power Apps Maker で各エンティティに対して変更の追跡と LTR を手動で有効にします。

1. Power Apps Maker ポータルに移動します。
2. 階層内の各仮想エンティティ（ソースリンクおよびすべての子エンティティ）:
   • エンティティ (たとえば、 mserp_customworkflowheaderbientity) を見つけます。
   • 変更の追跡を有効にします。
   • 長期保存を有効にする
3. テーブル階層内 のすべてのエンティティ に対して繰り返します。

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

• 長期的なリテンション期間のためにテーブルを有効にする
• エンティティの変更追跡の有効化

ソリューションの自動デプロイ (詳細)

このアプローチでは、複数の環境にわたる自動デプロイのためにエンティティ構成をパッケージ化する Dataverse ソリューションを構築する必要があります。 Dataverse ソリューションの構築とデプロイに関する完全な手順については、「 長期保有のための Dataverse の構成」を参照してください。

ジョブ契約クリエーターを作成（基本クラス）

アーカイブ スコープを定義する基本ジョブ コントラクト作成者を作成するには、次の手順に従います。

1. モデルに新しいクラスを作成します。
2. 名前: Custom[ScenarioName]ArchiveAutomationJobRequestCreator
   • 例： CustomWorkflowArchiveAutomationJobRequestCreator
3. 拡張： ArchiveAutomationJobRequestCreator

クラス構造を実装する

using Microsoft.Dynamics.Archive.Contracts;

/// <summary>
/// Creates archive job contracts for custom workflow scenario.
/// </summary>
public class CustomWorkflowArchiveAutomationJobRequestCreator extends ArchiveAutomationJobRequestCreator
{
    // Class implementation
}

createPostJobRequest メソッドを実装する

ビルダー API を使用してジョブ コントラクトをビルドするには、次のメソッドを使用します。

public ArchiveJobPostRequest createPostJobRequest(var _criteria)
{
    // Validate criteria
    if (!_criteria)
    {
        throw error(Error::wrongUseOfFunction(funcName()));
    }
    
    // Initialize builder
    ArchiveServiceArchiveJobPostRequestBuilder builder = 
        ArchiveServiceArchiveJobPostRequestBuilder::construct();
    
    // Set job metadata
    builder.setArchiveType(ArchiveType::[YourArchiveType]);  // Enum value for your scenario
    builder.setJobName(strFmt("Custom Workflow Archive - %1", _criteria.DataAreaId));
    
    // Add source link table (root of hierarchy)
    builder.addSourceLinkTable(
        ArchiveServiceSourceLinkTableConfiguration::newForSourceTable(
            tableStr(CustomWorkflowHeader),              // Live table
            tableStr(CustomWorkflowHeaderHistory)))      // History table
        
        // Add WHERE conditions (archive criteria)
        .addWhereCondition(
            fieldStr(CustomWorkflowHeader, DataAreaId),
            ArchiveServiceOperator::Equals,
            _criteria.DataAreaId)
        
        .addWhereCondition(
            fieldStr(CustomWorkflowHeader, CompletedDate),
            ArchiveServiceOperator::LessThan,
            _criteria.ArchiveBeforeDate)
        
        .addWhereCondition(
            fieldStr(CustomWorkflowHeader, WorkflowStatus),
            ArchiveServiceOperator::Equals,
            WorkflowStatus::Completed);
    
    // Add child tables
    this.addChildTables(builder);
    
    // Finalize and return
    return builder.finalizeArchiveJobPostRequest();
}

addChildTables メソッドを実装する

各子テーブルをアーカイブ スコープに追加します。

private void addChildTables(ArchiveServiceArchiveJobPostRequestBuilder _builder)
{
    // Add workflow lines
    _builder.addSourceTableForLongTermRetention(
        ArchiveServiceSourceTableConfiguration::newForSourceTable(
            tableStr(CustomWorkflowLine),
            tableStr(CustomWorkflowLineHistory),
            tableStr(mserp_customworkflowlinebientity),  // Dataverse entity name
            tableStr(CustomWorkflowHeader)))             // Parent table
        
        .addJoinCondition(
            fieldStr(CustomWorkflowLine, WorkflowHeaderRecId),
            ArchiveServiceOperator::Equals,
            fieldStr(CustomWorkflowHeader, RecId))
        
        .addWhereCondition(
            fieldStr(CustomWorkflowLine, DataAreaId),
            ArchiveServiceOperator::Equals,
            fieldStr(CustomWorkflowHeader, DataAreaId));
    
    // Add workflow line details
    _builder.addSourceTableForLongTermRetention(
        ArchiveServiceSourceTableConfiguration::newForSourceTable(
            tableStr(CustomWorkflowLineDetail),
            tableStr(CustomWorkflowLineDetailHistory),
            tableStr(mserp_customworkflowlinedetailbientity),
            tableStr(CustomWorkflowLine)))               // Parent is CustomWorkflowLine
        
        .addJoinCondition(
            fieldStr(CustomWorkflowLineDetail, WorkflowLineRecId),
            ArchiveServiceOperator::Equals,
            fieldStr(CustomWorkflowLine, RecId))
        
        .addWhereCondition(
            fieldStr(CustomWorkflowLineDetail, DataAreaId),
            ArchiveServiceOperator::Equals,
            fieldStr(CustomWorkflowLine, DataAreaId));
    
    // Add workflow attachments
    _builder.addSourceTableForLongTermRetention(
        ArchiveServiceSourceTableConfiguration::newForSourceTable(
            tableStr(CustomWorkflowAttachment),
            tableStr(CustomWorkflowAttachmentHistory),
            tableStr(mserp_customworkflowattachmentbientity),
            tableStr(CustomWorkflowHeader)))
        
        .addJoinCondition(
            fieldStr(CustomWorkflowAttachment, WorkflowHeaderRecId),
            ArchiveServiceOperator::Equals,
            fieldStr(CustomWorkflowHeader, RecId))
        
        .addWhereCondition(
            fieldStr(CustomWorkflowAttachment, DataAreaId),
            ArchiveServiceOperator::Equals,
            fieldStr(CustomWorkflowHeader, DataAreaId));
}

主要な実装規則

親テーブルの仕様:

• ソース リンク テーブルの場合: .newForSourceTable(liveTable, historyTable) を使用する (親なし)
• 子テーブルの場合: 使用 .newForSourceTable(liveTable, historyTable, entityName, parentTable)

JOIN 条件:

• 外部キーのリレーションシップと正確に一致する必要があります
• JOIN に対してサポートされている演算子 Equals のみ
• フィールド名は正確である必要があります (大文字と小文字が区別されます)

WHERE 条件:

• 親と一致する分離フィールドを含める
• 動的な値にフィールド参照を使用します。 fieldStr(ParentTable, FieldName)
• 静的条件にリテラル値を使用します。 WorkflowStatus::Completed

エンティティ名:

• Dataverse 仮想エンティティ名を使用する ( mserp_で始まる)
• すべて小文字を使用する
• 例： tableStr(mserp_customworkflowheaderbientity)

ジョブ契約書作成ツール (BI 拡張機能)

LTR 構成を追加する BI 拡張クラスを作成するには、次の手順に従います。

1. BusinessIntelligence モデル プロジェクトに切り替えます。
2. 新しいクラスを作成します。
3. 名前を Custom[ScenarioName]ArchiveAutomationJobRequestCreator_BI_Extension に設定します。
4. 拡張属性を追加します。

using Microsoft.Dynamics.Archive.Contracts;

[ExtensionOf(classStr(CustomWorkflowArchiveAutomationJobRequestCreator))]
public final class CustomWorkflowArchiveAutomationJobRequestCreator_BI_Extension
{
    // Extension logic
}

LTR 構成を使用して createPostJobRequest を拡張する

public ArchiveJobPostRequest createPostJobRequest(var _criteria)
{
    // Call base implementation (gets job contract with tables)
    ArchiveJobPostRequest postRequest = next createPostJobRequest(_criteria);
    
    // Add LTR configuration for source link table
    postRequest = this.addSourceLinkTableForLongTermRetention(postRequest, _criteria);
    
    return postRequest;
}

LTR 構成方法を実装する

private ArchiveJobPostRequest addSourceLinkTableForLongTermRetention(
    ArchiveJobPostRequest _postRequest,
    var _criteria)
{
    // Construct builder from existing contract
    ArchiveServiceArchiveJobPostRequestBuilder builder = 
        ArchiveServiceArchiveJobPostRequestBuilder::constructFromArchiveJobPostRequest(_postRequest);
    
    // Add LTR configuration for source link table
    builder.addSourceLinkTableForLongTermRetention(
        ArchiveServiceSourceLinkTableConfiguration::newForSourceTable(
            tableStr(CustomWorkflowHeader),
            tableStr(CustomWorkflowHeaderHistory),
            tableStr(mserp_customworkflowheaderbientity))  // Dataverse entity name
        
        // WHERE conditions must match base class criteria
        .addWhereCondition(
            fieldStr(CustomWorkflowHeader, DataAreaId),
            ArchiveServiceOperator::Equals,
            _criteria.DataAreaId)
        
        .addWhereCondition(
            fieldStr(CustomWorkflowHeader, CompletedDate),
            ArchiveServiceOperator::LessThan,
            _criteria.ArchiveBeforeDate)
        
        .addWhereCondition(
            fieldStr(CustomWorkflowHeader, WorkflowStatus),
            ArchiveServiceOperator::Equals,
            WorkflowStatus::Completed));
    
    // Finalize and return updated contract
    return builder.finalizeArchiveJobPostRequest();
}

なぜ2つの別々のクラス?

基底クラス (モデル内):

• アーカイブ スコープを定義します (どのテーブル)
• リレーションシップ (JOIN) を指定します
• 財務および運用データ エンティティ参照なし

Finance and Operations データ エンティティ拡張クラス (BusinessIntelligence モデル内):

• LTR 構成を追加します
• 財務データ エンティティと運用データ エンティティをテーブルにリンクする
• マネージド データ レイク アクセスを有効にします

この分離により、次のことが可能になります。

• 依存関係の管理をクリアする
• モデルレイヤーのベスト プラクティス
• アーカイブと LTR の独立したテスト

アーカイブ サービスの種類を登録する

アーカイブ フレームワークに表示されるようにカスタム アーカイブの種類を登録するには、次の手順に従います。

1. モデルに新しいクラスを作成します。
2. 名前: Custom[ScenarioName]ArchiveServiceTypeRegistration
3. ArchiveServiceTypeRegistration インターフェイスを実装する

登録ロジックを実装する

using Microsoft.Dynamics.Archive.Contracts;

/// <summary>
/// Registers custom workflow archive type with archive framework.
/// </summary>
public class CustomWorkflowArchiveServiceTypeRegistration implements ArchiveServiceTypeRegistration
{
    public void registerTypes()
    {
        ArchiveServiceTypeRegistry registry = ArchiveServiceTypeRegistry::singleton();
        
        // Register archive type
        registry.registerArchiveType(
            ArchiveType::[YourCustomArchiveType],        // Enum value (add to ArchiveType enum)
            classStr(CustomWorkflowArchiveAutomationJobRequestCreator),
            "@YourLabel:CustomWorkflowArchiveTypeLabel", // Label for UI
            "@YourLabel:CustomWorkflowArchiveTypeHelp"); // Help text for UI
    }
}

列挙型にアーカイブタイプを追加する

1. 列挙型 ArchiveType を拡張します
2. シナリオに新しい列挙値を追加します。
   • 名前: CustomWorkflow
   • ラベル: "カスタム ワークフロー アーカイブ"

起動時に登録が実行されるようにする

型の登録は、アプリケーションの起動時に実行する必要があります。 モジュールの起動時に登録します。

public class CustomWorkflowModule
{
    public static void initialize()
    {
        // Register archive type
        CustomWorkflowArchiveServiceTypeRegistration registration = new CustomWorkflowArchiveServiceTypeRegistration();
        registration.registerTypes();
    }
}

ビルドとデプロイ

ソリューションをビルドするには、次の手順に従います。

1. メイン モデル (テーブル、基本ジョブ作成者、型登録) を構築する
2. BusinessIntelligence モデルの構築 (財務および運用データ エンティティ、拡張クラス)
3. コンパイル エラーを解決する

データベースの同期

# Sync database to create tables and indexes
# Use Visual Studio: Dynamics 365 > Synchronize Database

環境にデプロイする

1. 配置可能なパッケージを作成する
2. ターゲット環境へのデプロイ
3. デプロイが正常に行われたことを確認します

エンティティを同期する

配置後:

1. データ管理 ワークスペースに移動します。
2. フレームワーク パラメーター>Entity 設定に移動します。
3. エンティティ リストの更新 を選択します。
4. 財務データエンティティと運用データ エンティティが表示されていることを確認します。

Dataverse で仮想エンティティを確認する

1. 自動発行 (または手動で発行) されるまで 24 ~ 48 時間待ちます。
2. Power Apps Maker にエンティティが表示されていることを確認します。
3. 各エンティティの変更追跡と LTR を構成します。

エンドツーエンドテスト

テスト データを作成するには、次の手順に従います。

1. ソース リンク テーブルにテスト ヘッダー レコードを作成します。
2. 関連する子レコード (行、詳細、添付ファイル) を作成します。
3. 分離フィールドが一致していることを確認します (DataAreaIdなど)。
4. アーカイブ条件を満たすように状態フィールドと日付フィールドを設定します。

アーカイブジョブの作成をテストします

1. アーカイブ ワークスペースに移動します。
2. カスタム アーカイブの種類を選択します。
3. テスト条件を使用してアーカイブ ジョブを作成します。
4. ジョブの詳細に正しいテーブル数が表示されていることを確認します。

アーカイブ ジョブの実行

1. アーカイブ ジョブを実行します。
2. ジョブの進行状況を監視します。
3. ジョブが正常に完了したことを確認します。

データ移動の検証

履歴テーブルを確認する:

-- Verify header moved to history
SELECT * FROM CustomWorkflowHeaderHistory WHERE WorkflowId = '[TestID]'

-- Verify child records moved
SELECT * FROM CustomWorkflowLineHistory WHERE WorkflowHeaderRecId = [TestHeaderRecId]

マネージド データ レイクを確認する:

• Dataverse マネージド データ レイクに移動します。
• すべてのテーブルの CSV ファイルを検索します。
• レコードが正しいデータと共に存在することを確認します。

ライブ テーブルのクリーンアップを確認します。

-- Confirm records removed from live tables
SELECT * FROM CustomWorkflowHeader WHERE WorkflowId = '[TestID]'  -- Should return no rows

復元操作のテスト

1. 反転ジョブを作成します。
2. 復元を実行します。
3. データがライブ テーブルに戻るかどうかを確認します。
4. 親子関係がそのままであることを検証します。

共通の問題と解決策

デプロイ前チェックリスト

運用環境にデプロイする前に、次の手順を実行します。

テーブル：

• すべてのフィールドで作成されたソース リンク テーブル。
• 外部キーを使用して作成されたすべての子テーブル。
• 親子リレーションシップはすべての子テーブルで定義されています。
• ArchiveCriteriaIdx すべてのテーブルに追加されます。
• すべてのテーブルに ArchiveSysVersionIdx を追加しました。
• 履歴テーブルは、 SysRowVersion と SysDataStateを除くすべてのライブ テーブルを反映します。
• 履歴テーブルには外部キー インデックスがあります。
• Microsoft マネージド テーブルへの参照はありません。

財務と運用のデータ エンティティ:

• ライブ テーブルごとに作成された財務および運用データ エンティティ。
• Auto CreateやAllow Retentionなど、必要なすべてのプロパティを設定します。
• すべてのエンティティで rowversion を有効にしました。
• Dataverse に発行された仮想エンティティ。
• すべての仮想エンティティで変更の追跡を有効にしました。
• Dataverse のすべての仮想エンティティで LTR を有効にしました。

コード：

• 基本ジョブ契約生成クラスを作成しました。
• createPostJobRequestにアーカイブ条件を実装しました。
• 正しい JOIN を持つすべての子テーブルを追加しました。
• BusinessIntelligence モデルで BI 拡張クラスを作成しました。
• ソース リンク テーブルの LTR 構成を追加しました。
• 型登録クラスを作成しました。
• ArchiveType列挙型にアーカイブの種類を追加しました。
• 型登録は起動時に実行されます。
• コンパイル エラーはありません。

テスト:

• すべてのテーブルのテスト データを作成しました。
• アーカイブ ジョブが正常に作成されました。
• ジョブ コントラクトには、すべてのテーブルが含まれます。
• アーカイブ ジョブは、データを履歴テーブルに移動します。
• マネージド データ レイクには、すべてのテーブルの CSV が含まれています。
• アーカイブ後にクリーンアップされたライブ テーブル。
• リバーサルジョブはデータを正しく回復します。
• 親と子のリレーションシップが維持されます。

関連資料

• アーカイブのカスタマイズの概要
• Microsoft マネージド テーブルにカスタム フィールドを追加する
• 標準シナリオにカスタム テーブルを追加する
• 長期保存のために Dataverse を設定する