CDT の概要とガイドライン

IBM Sterling® Order Management System は、クラウド環境での構成データの移行を可能にする Configuration Deployment Tool (CDT) を提供します。 このツールにより、データ保全性が確保され、データを転送するためのシステムのダウン時間が短縮され、正確性を確保するために必要な労力が最小限に抑えられます。

Sterling™ Order Managementシステムのインクリメンタルコンフィギュレーションでは、変更は通常テスト環境で開発され、その後本番環境にロールアウトされます。 構成データのマイグレーションは、煩雑で時間がかかることがあります。

構成デプロイメント・ツールは、標準の日常操作の一環として変更されるデータのマイグレーションを目的として設計されています。 構成デプロイメント・ツールは、アップグレードの結果として構成データをデプロイするために使用されます。 ただし、データのアップグレード自体は実行しないでください。

サポートされる機能

  • データベースから XML ファイルへ、または XML ファイルからデータベースへデータを転送します。
  • ネットワーク構成に基づいて、2 つの環境で異なる IP アドレスやポート番号などの特定のデータを変換します。
  • 2 つのデータベース間で CDT を使用する選択レコードをデプロイまたは無視します。

CDT を使用した選択レコードのデプロイまたは無視

環境固有の値は、PLT_PROPERTY や YFS_COMMON_CODE などのテーブルでデプロイまたは無視することができ、CDT がソースからターゲットにデプロイされるときにオーバーライドされません。 詳しくは、 CDT 使用時の選択レコードのデプロイおよび無視を参照してください。

CDT を使用したデータの変換

CDT を使用すると、ターゲットにデプロイする前にソース・データに対して実行する変換を指定できるため、これらのデータ・エレメントをターゲットに適した値に自動的に変換できます。

開発環境と実稼働環境で、サーバー名や IP アドレスなどのネットワーク設定の値が異なることはよくあります。 Sterling Order Management System の一部の構成データ・テーブルには、ホスト名、IP アドレス、および URL が保管されます。 これらはソース環境に対して有効ですが、このデータをターゲット環境にデプロイする場合は、ターゲット環境に適用可能な対応する値で構成を更新する必要があります。

CDT を使用したデータのインポートに関するベスト・プラクティス

CDT を介してソースからターゲットにデータをインポートする際、ターゲット・データはソース・データと同期します。 これは、既存のソース・データのターゲット・データが更新されることを意味します。 追加のターゲット・データが削除され、完全なデータ保全性が確保されます。

「無視」モードと「 AppendOnly 」モードを使用して、CDT データをインポートできます。 ただし、これらのモードは整合性を保証しないため、注意して使用する必要があります。 外部環境の代わりに他のクラウド環境を使用することもできます。

ただし、これは一部のシナリオでは機能しない可能性があります。 そのため、「無視」モードと「 AppendOnly 」モードを使用できます。

無視

CDT のデプロイメント中に、デプロイメント中に一部の選択テーブルを無視するように設定することができます。

テーブルまたはドライバー・エンティティーを無視すると、従属テーブルもすべて自動的に無視されます。 ただし、複数のドライバー・エンティティーのデータを保管し、複数のグループに存在するテーブルがあります。 例えば、パイプライン、サービス、およびステータスのデータを含む YFS_GRAPH_UI テーブルです。 これらのテーブルのいずれかが無視されると、CDT は対応するレコードに誤って削除のマークを付けます。

AppendOnly

一部のテーブルが他の環境で部分的に保守されている場合は、テーブルのデプロイメントを AppendOnly モードにするための設定を指定します。 AppendOnly モードでは、保全性の問題があるデータが多数存在する可能性があります。

AppendOnly 表の場合、従属表は無視されません。 表に AppendOnly というマークを付けることは、ターゲット・データベース内の数行のみがソース・システム上で維持され、その他の行は外部でインポートされることを意味します。 ソース・システムと外部システムに存在するデータが重複していないことを確認してください。 例えば、配送ノードをソース・データベースで維持し、ストア情報をターゲットに直接インポートする場合は、ソース・データベースにストアがあってはなりません。 含まれていると、予測できない結果が生じます。

注意:
CDT で Ignore 機能または AppendOnly 機能を使用しても、外部データの整合性は保証されません。 データ保全性を確保するために、CDT は構成データへの完全なアクセス権限を持っている必要があります。
<preferences>
    <configsynch>
        <Settings ReportsDir="">
            <AuditDeployment ValidateLockid="y" ValidateOldValues="y" ValidateRecordExistsBeforeDelete="y"/>
        </Settings>
        <SourceTargetPrefs>
            <SourceTargetPrefs>
                <SourceTargetPair SourceDatabase="DEFAULTXMLDB" TargetDatabase="SYSTEMDB">
                    <Transformations>
                    </Transformations>
                    <Ignore>
				<Table Name="YFS_USER"/>
	   		    <Table Name="YFS_USER_GROUP_LIST"/>
                     </Ignore>
                    <AppendOnly>
				<Table Name="YFS_CUSTOMER"/>
				<Table Name="YFS_CUSTOMER_ADDNL_ADDRESS"/>
                     </AppendOnly>
                </SourceTargetPair>            
            </SourceTargetPrefs>
        </SourceTargetPrefs>
    </configsynch>
</preferences>

YFS_PERSON_INFO レコードの引き渡し

YFS_PERSON_INFO レコードは、CDT での特別な処理を必要とします。 YFS_PERSON_INFO から繰り返しレコードを読み取る場合、CDT は YFS_PERSON_INFO テーブルの照会を必要としません。 このような場合、YFS_PERSON_INFO と関係のあるすべての親テーブルからレコードが算出されます。 その後、すべての表を読み、これらの表からすべての PERSON_INFO キーを累積した後、PERSON_INFO キーに対応する PERSON_INFO レコードを読み取ります。 つまり、通常の CDT 実行では、構成テーブルまたはマスター・テーブルに関連する PERSON_INFO レコードが読み取られ、デプロイされます。 ただし、トランザクション表に関連するレコードは処理されません。