一般化データ・エクスポート

一般化データ・エクスポート方法では、ファイルベースのエクスポートによりJSON形式でデータが提供されます。この方法を使用したメンテナンス・オブジェクトのデータのエクスポートでは、エンティティのデータ全体の初期エクスポートの後、時間の経過に伴って加えられた変更の進行中エクスポートが実行されます。これらのプロセスを次の図に示します。

全体的なプロセスには、次のステップが含まれます。

「一般化エクスポート・ダッシュボード」ポータルでエクスポートに対してエンティティを有効にします。一度に多数のエンティティを有効にすることができます。このステップでは、これらのエンティティの進行中エクスポートを有効にすることもできます。
「一般化初期エクスポート・イニシエータ」(F1-GEXPI)バッチ・プロセスを発行して、有効にしたすべてのエンティティの現在の内容をエクスポートします。このステップでは、エクスポートに対して有効にしたエンティティごとに個別のバッチ・プロセスが発行されます。
「一般化進行中エクスポート」(F1-GEEXO)バッチ・プロセスを定期的に実行するようにスケジュールします。

次の各項では、一般化データ・エクスポート方法に関連する概念およびガイドラインについてさらに説明します。

適用

ほとんどのエンティティは一般化データ・エクスポートに適格ですが、すべてというわけではありません。次に、その一般的な理由をいくつか示します。

エンティティが非常に大量のデータを管理します。このようなエンティティへの変更を追跡すると、管理対象データの量が2倍になり、全体的なパフォーマンスに影響します。
エンティティが非常に頻繁に更新されます。このようなイベントを追跡すると、全体的なパフォーマンスに影響する可能性があります。
エンティティが製品のインフラストラクチャおよび運用プロセスで使用されます。このようなエンティティは異なる方法で保守され、一般化データ・エクスポート方法の対象にすることはできません。

デフォルトでは、「データ・エクスポート・クラス」オプションによって明示的にマークされていないかぎり、メンテナンス・オブジェクトは一般化データ・エクスポート方法に適格です。このオプションを使用して、エンティティをいかなるタイプのエクスポートについても許可しないか、特殊エクスポートについてのみ許可するようにマークできます。このような明示的なオプションがないことは、メンテナンス・オブジェクトが一般化エクスポートに適格であることを意味します。

注意: エンティティが一般化データ・エクスポートに適格でないとして明示的にマークされている場合は、それだけの理由があるため、その構成を変更しないでください。

汎用的な方法

一般化データ・エクスポート方法は、パフォーマンス上の問題も考慮に入れて汎用的に多くの適格なメンテナンス・オブジェクトに対応するように設計されています。そのため、この方法はエンティティ固有のフィルタリング・オプションもカスタム・ルールも種類を問わずサポートしていません。

この方法を使用してエクスポートできるすべてのエンティティに、次のルールが適用されます。

データ全体がエクスポートされます。
- "キー"表と"ログ"表(ある場合)を除く、メンテナンス・オブジェクトに属するすべての表のすべてのフィールドがエクスポートされます。
- 通常、メンテナンス・オブジェクトのログ表には有用なビジネス情報は含まれていないため、パフォーマンスおよびデータ量の理由でエクスポートから除外されます。ただし、ログ・レコードで分析値が提供されるエンティティがあります。該当する場合は、「エクスポート・ログ表」オプションを使用して、特定のメンテナンス・オブジェクトのログ表を明示的に含めてください。
すべてのエンティティに同じデータ構造と書式が使用されます。詳細は、「レコードの書式」の項を参照してください。
データはファイルにのみエクスポートされます。詳細は、「ファイルのみへのエクスポート」の項を参照してください。
すべての変更が取得されます。カスタム・ビジネス・ルールに基づいて、進行中エクスポートの対象として追跡されないように一部の変更を除外することはできません。
データが変更されると、ターゲット側での大量のデータ・マージを回避するために、そのエンティティに関連するデータの完全なスナップショットがエクスポートされます。
エンティティが削除されると、削除されたことが示されるとともに、エンティティの主キーのみがエクスポートされます。

注意: 論理タイム・ゾーン機能に依存するエンティティについては、エクスポートがサポートされていません。このタイプの定義は一般的に使用されず、これには、少なくとも1つのフィールドが「論理標準時」に格納されるように定義されているメンテナンス・オブジェクトが含まれます。

ファイルのみへのエクスポート

初期エクスポート・プロセスと進行中エクスポート・プロセスの両方の直接の宛先は、顧客指定の場所にあるファイルです。クラウド・インストールでは、顧客所有のオブジェクト・ストレージにファイルが作成されます。

ビジネス要件に基づいて、データ・レイクなどのダウンストリーム・アプリケーションでこれらのファイルをさらに使用できます。

データ・エクスポートの有効化

適格なメンテナンス・オブジェクトについてデータ・エクスポートを有効にするには、「データ・エクスポート管理」レコードを作成する必要があります。このレコードには、メンテナンス・オブジェクトの初期エクスポートが完了したかどうか、およびエンティティに加えられた変更を継続的に追跡してエクスポートする必要があるかどうかの指定が記録されます。指定されたポータルを使用すると、多数のメンテナンス・オブジェクトについて一般化データ・エクスポートを一度に有効にしたり、それらの現在のエクスポート・ステータスを一目でモニターすることができます。詳細は、「一般化エクスポート・ダッシュボード」ポータルを参照してください。

注意: エクスポートに対するエンティティの有効化と無効化は、「一般化エクスポート・ダッシュボード」ポータルまたは「データ・エクスポート管理」ポータルを介してのみ行い、構成が有効かつ完全であることを確認する必要があります。

注意: 該当する場合は、エンティティの初期エクスポート・バッチ・プロセスを発行する前に、進行中データ・エクスポートを有効にする必要があります。これにより、初期エクスポート中に加えられた変更が適切に追跡されるようになります。

進行中エクスポートのオプションは、様々なオンラインおよびバッチ・キャッシュにキャッシュされます。これらのオプションが有効になって、オンラインまたはバッチ・プロセスによって加えられたエンティティの変更が追跡されるようにするには、これらのオプションが変更されたときに、様々なキャッシュが適切にフラッシュされる必要があります。指定されたポータルを使用して、エクスポートに対してエンティティを有効にすると、キャッシュの'グローバル'・フラッシュがトリガーされます。グローバル・フラッシュが要求されるとキャッシュがリフレッシュされるようにバッチ・スレッド・プール・ワーカーが構成された場合、これが必要な唯一のステップです。そうでない場合は、F1–FLUSHバッチ・ジョブも発行されて、バッチ処理で使用されるキャッシュをリフレッシュする必要があります。詳細は、「キャッシュの概要」を参照してください。

初期データ・エクスポート

一般化データ・エクスポート方法に適格なそれぞれのメンテナンス・オブジェクトは、「エクスポート・バッチ管理」オプションを使用して、メンテナンス・オブジェクトで参照される初期データ・エクスポート・バッチ管理に関連付けられます。エンティティのデータ全体をファイルにエクスポートするために、これらのすべてのバッチ管理で共通の同じバッチ・プログラムが使用されます。このプロセスはマルチスレッドであり、デフォルトではスレッドごとに1つのファイルを生成します。オプションのバッチ・パラメータを使用すると、それぞれのファイルに書き込まれるレコード数に制限を設定することで、スレッドごとに複数の小さいファイルが生成されるようにすることができます。詳細は、「ファイル・サイズ」の項を参照してください。

エクスポートに対して有効にしたそれぞれのメンテナンス・オブジェクトの一般化初期エクスポート・バッチ・プロセスを手動で発行するかわりに、F1-GEXPI「一般化初期エクスポート・イニシエータ」バッチ・プロセスを発行して、自動的にそれらすべてを一度に発行します。

それぞれのメンテナンス・オブジェクトの初期エクスポート・プロセスでは、このプロセスが開始されたことを示すようにメンテナンス・オブジェクトの対応するデータ・エクスポート管理レコードが更新され、完了時にそれが再度更新されます。これにより、有効なすべてのエンティティにわたる初期エクスポートの全体的なステータスを「一般化エクスポート・ダッシュボード」ポータルで表示できます。

イニシエータ・バッチ・プロセスは、有効なメンテナンス・オブジェクトのうち、データ・エクスポート管理レコードに従って、初期エクスポートがまだ開始されていないものについてのみバッチ・プロセスを発行します。1つ以上のエンティティを再度エクスポートする必要がある場合は、それらのデータ・エクスポート管理レコードに示されている初期エクスポート・ステータスをリセットし、イニシエータ・バッチ・プロセスを再発行してください。

初期エクスポート・ファイル名は次のように構成されます。

INIT_EXPORT[_file prefix(optional)]_[maintenance object]_[batch run]_[thread]_[thread count]_[timestamp][_file sequence].json.gz

ファイル名の"file sequence"部分は、スレッドごとに複数のファイルが作成される場合にのみ使用されます。シーケンス・サフィックスは、_2のように、2番目のファイルから移入されます。

詳細は、個々の一般化初期エクスポート・バッチ管理のいずれかおよびイニシエータ・バッチ管理を参照してください。

日付による初期エクスポートの制限

デフォルトでは、初期データ・エクスポート・バッチ・プロセスによってエンティティのデータ全体がエクスポートされます。状況によっては、通常は大量の履歴データを避けて、エクスポートを最近のデータ(過去数か月のデータなど)に制限することが必要になることがあります。

初期エクスポート・バッチ・プロセスでは、エクスポートするデータの範囲を制限するために使用できるオプションのバッチ・パラメータ「日付による制限」がサポートされています。このパラメータは、営業日より前の日数に関して日付フィールドおよび要求時間枠を参照します。詳細は、F1-GEIXP「一般化初期エクスポート・テンプレート」バッチ管理を参照してください。

注意: エクスポートからレコードを除外すると、除外されたデータが他のエクスポートされたエンティティで参照されている場合にデータの差異が発生する可能性があるため、慎重に検討する必要があります。

注意: このオプションは、適格な参照日を持つ特定のエンティティにのみ適用でき、エクスポートの時間枠は顧客ごとに異なる場合があります。したがって、この新しいパラメータは、文書化を目的としたテンプレート・バッチ管理を除いて、基本製品の初期エクスポート・バッチ管理には追加されていません。特定のエンティティについて基本製品のバッチ管理をクローンし、ビジネス・ニーズに応じてこのパラメータを追加できます。

進行中データ・エクスポート

データの変更は、「進行中エクスポートの変更の取得」(F1-MO-REGCHN)メンテナンス・オブジェクト監査アルゴリズムによって追跡されます。このアルゴリズムは、変更されたエンティティの主キーを、エクスポート対象の変更されたエンティティのキューとして機能する、指定された「データ・エクスポート更新」表に記録します。このキューは、進行中データ・エクスポート・バッチ・プロセスによって後で処理されます。

注意: メンテナンス・オブジェクト監査プラグイン・スポットは、アプリケーションの任意のレイヤーによってエンティティに加えられた変更を追跡できます。ダイレクトSQLを使用して変更を加えると、このメカニズムはバイパスされるため、回避する必要があります。

対応するデータ・エクスポート管理レコードで進行中データ・エクスポート・オプションを有効にすると、監査ルールがメンテナンス・オブジェクトに追加されます。同様に、進行中エクスポート・オプションを無効にすると、監査ルールがメンテナンス・オブジェクトから削除されます。

注意: エンティティが最初にエクスポートされる前に、そのデータ・エクスポート管理レコードで進行中エクスポート・オプションを有効にする必要があります。これにより、初期エクスポート・プロセスの進行中に加えられた変更が欠落することがなくなります。

適格なメンテナンス・オブジェクトごとにバッチ管理を定義する必要がある初期エクスポート・バッチ・プロセスとは異なり、単一のバッチ・プロセスを使用して、すべてのエンティティに加えられた進行中の変更がエクスポートされます。

次に、進行中エクスポート・バッチ・プロセスの概要を説明します。

「データ・エクスポート更新」表でキューに入れられたすべての変更が、指定された進行中エクスポート・ファイルにエクスポートされます。詳細は、「大きなバックログの管理」の項を参照してください。
ターゲット側での大量のデータ・マージを回避するために、変更されたエンティティに関連するデータの完全なスナップショットがエクスポートされます。
エクスポートされると、「データ・エクスポート更新」表からレコードが削除されます。

このプロセスはマルチスレッドであり、デフォルトではスレッドごとに個別のファイルが生成されます。オプションのバッチ・パラメータを使用すると、それぞれのファイルに書き込まれるレコード数に制限を設定することで、スレッドごとに複数の小さいファイルが生成されるようにすることができます。詳細は、「ファイル・サイズ」の項を参照してください。

注意: 「データ・エクスポート更新」表に大量のレコードが蓄積されることを回避するために、進行中エクスポート・バッチ・プロセスを十分に頻繁に実行するようにスケジュールすることが重要です。表を小さく維持するほど、変更データ取得メカニズムによるレコードの追加が高速化されます。

進行中エクスポート・ファイル名は次のように構成されます。

INC_EXPORT_[batch run]_[thread]_[thread count]_[timestamp][_file sequence].json.gz

詳細は、「一般化進行中エクスポート」(F1-GEEXO)バッチ管理を参照してください。

ファイル・サイズ

初期エクスポート・バッチ・プロセスでは、デフォルトでスレッドごとに1つのファイルが生成されます。大規模なエンティティについては、管理できないほどファイルが大きくなることがあります。特定のエンティティについて複数の小さいファイルを生成するには、エンティティに定義された初期エクスポート・バッチ管理で対応するパラメータを設定して、それぞれのファイルに書き込まれるレコード数を制限します。初期エクスポート・イニシエータ・バッチ・プロセスの発行時にも同じパラメータを指定できますが、この場合、イニシエータの値は、対応する値がエンティティの特定のバッチ管理レコードで定義されていない場合にのみ使用されます。

同様に、進行中エクスポート・バッチ・プロセスでも、デフォルトでスレッドごとに1つのファイルが生成されます。複数の小さいファイルを生成するには、バッチ管理で対応するパラメータを設定して、それぞれのファイルに書き込まれるレコード数を制限します。

単一のバッチ実行で過度に多くのファイルが作成されることを回避するために、実行ごとに約500ファイルという最大限度がシステムによって設定されます。要求されたファイル当たりのレコード数によって、生成されるファイルの数がシステム制限を超えると判断された場合は、システム制限を満たすように、実際に使用される値が調整されます。

大きなバックログの管理

なんらかの理由で変更の大きなバックログが進行中エクスポート・キューに蓄積されると、次のバッチでエクスポートに時間がかかり、ダウンストリームのインポート・ステップが遅延します。バックログを小分けにして消去し、それらが使用可能になったときにダウンストリーム・プロセスでインポートできるようにすることをお薦めします。

「スレッド処理制限」バッチ・パラメータを使用して、バッチ・プロセスでエクスポートされるレコード数を制限できます。指定すると、それぞれのスレッドによってエクスポートされるレコード数は、指定した制限までとなり、残りのレコードはそのまま残され、後続のバッチ実行によって処理されます。次のスケジュール済バッチ実行を待機するかわりに、新しいバッチ・プロセスが自動的に発行されるようにすることもできます(自動バックログ消去バッチ・パラメータを使用して、明示的にそのように要求します)。

バックログが徐々に消去され、キューが適時に標準サイズに戻るようにすることが重要です。したがって、キューの適切な消去を促進する適切な値を使用して処理制限を設定する必要があります。そのためには、すべてのスレッドにわたって、キューの少なくとも20%、100,000レコード以上が各バッチ実行によって処理されるようにする必要があります。指定した制限が最小消去要件を満たしていない場合は、処理制限が適宜調整されます。

レコードの書式

パフォーマンス上の理由から、データは一括読取り操作でデータベースから直接フェッチおよびエクスポートされます。そのため、使用される構造は、エンティティの論理データ・モデルではなく、表の物理リストを反映しています。特定のインスタンスのデータは、表に続いてそれぞれの表の行別に編成され、それぞれの行のデータは、JSON形式によるそのフィールドのリストです。

次に、使用される書式と構造について説明します。

{
"OBJ": "<mo name>",
"TIMESTAMP": "<export time in ISO format for example 2019-07-25T11:06:04.740615Z>",
"PK1": "<mo pk1 value>",
"PK2": "<mo pk2 value if any>",  ← PK2-5 should only be included when applicable
"PK3": "<mo pk3 value if any>",
"PK4": "<mo pk4 value if any>",
"PK5": "<mo pk5 value if any>",
"DELETED": true,  ← should only be included when the entity is deleted
"DATA": 
{
"<MO table name 1>":
[
{<name value pairs of all fields in row 1 in that table>},
{<name value pairs of all fields in row 2 in that table>},...
{<name value pairs of all fields in row n in that table>},...
],
"<MO table name 2>":
[
{<name value pairs of all fields in row 1 in that table>},
{<name value pairs of all fields in row 2 in that table>},...
{<name value pairs of all fields in row n in that table>}
],...
 "<MO table name n>":
[
 {<name value pairs of all fields in row 1 in that table>},
{<name value pairs of all fields in row 2 in that table>},...
{<name value pairs of all fields in row n in that table>}
]
}

フィールドの値および書式に関する注意:

フィールドが空またはnullの場合でも、行のすべてのフィールドが含まれます。
すべての文字列値で末尾の余分なスペースが切り捨てられますが、フィールドが空の場合は、nullではなく、空の文字列""としてエクスポートされます。
エンティティのレコードが表に存在しない場合、空の配列が表ノードに使用されます。
日時情報はUTCタイム・ゾーンに変換され、ISO形式でエクスポートされます(例: 2019-07-25T11:06:04.740615Z)。
削除については、ヘッダーに明示的なインジケータがあります。

ファイルの処理順序

データの一貫性を確保するために、進行中の変更ファイルを適用する前に、メンテナンス・オブジェクトのすべての初期エクスポート・ファイルを適用することが重要です。

次に、一般化データ・エクスポート・ファイルを処理するための推奨手順を示します。

進行中エクスポート・ファイルの前に、すべての初期データ・エクスポート・ファイルを適用します。
メンテナンス・オブジェクトの初期ファイルを実行番号順に適用します。
進行中エクスポート・ファイルを実行番号順に適用します。
新しい初期エクスポートが使用可能な場合は、ファイルの処理手順を一時的に次のように変更する必要があります。
- 進行中エクスポート・ファイルの処理を停止します。
- 新しい初期エクスポート・ファイルを適用します。
- 進行中エクスポート・ファイルの処理を再開します。

失われた進行中エクスポート・ファイルからのリカバリ

進行中エクスポート・バッチ・プロセスでは、特定のバッチ実行でエクスポートされたすべてのエンティティ・キーのバックアップが指定のバックアップ表に保持されます。進行中エクスポート・ファイルが処理される前に削除されるか、破損するというまれな状況では、そのバックアップ表を使用して、欠落している変更を識別して再度エクスポートすることができます。

この状況からリカバリするには、「一般化エクスポート・キーのリストア」(F1-GERST)バッチ・プロセスを使用します。このプロセスでは、指定したバッチ実行中にエクスポートされたエンティティが識別され、バックアップ表から進行中の変更キューに追加して戻されます。次の進行中エクスポートが実行されると、それらのエンティティが再度エクスポートされます。失われた元のファイルの正確な内容は再現できないため、この方法ではリストアされません。かわりに、このプロセスでは、失われたファイルに含まれていたエンティティが確実に再度エクスポートされます。

注意: パフォーマンス上の理由から、バックアップ・レコードは週次保持ポリシーに従います。これらは、ファイル・リカバリの近い将来の状況をサポートするためのものであり、履歴変更データ取得ログではありません。