累積データ同期

この製品では、1つのエンティティに対して行われた複数の変更を累積して単一のメッセージとして外部システムに送信するというデータ同期方法がサポートされています。

この機能の要点をまとめると、次のようになります。

エンティティが追加、変更または削除されるとき、そのエンティティのデータの変更前のスナップショットが、1つ以上の同期要求上で取得されます(そのデータをインタフェースする必要がある外部システムごとに1つずつ)。この更新前スナップショットは、それ以降に加えられたすべての変更を、外部システムへのメッセージ送信の時点で検出するためのベース・ラインとして使用されます。
同期要求は、次回のモニター・バッチ・プロセスによって処理されます。
同期要求の処理には一般的に、更新前のスナップショットをエンティティの現在のコンテンツと比較してすべての変更を検出するためのビジネス・ルールが含まれます。変更が行われていた場合は、同期メッセージの送信に進むかどうかをロジックで決定でき、送信に進まない場合は要求が破棄されます。これらのルールでは、外部システムとの通信中に発生したエラーの処理も行われ、必要に応じて再試行が管理されます。

この機能をサポートするロジックは、基本ビジネス・オブジェクト「同期要求」(F1-SyncRequest)で提供されます。各エッジ・アプリケーションでは、その製品でサポートされている特定の同期シナリオごとに、このビジネス・オブジェクトに適切な子ビジネス・オブジェクトを提供していることに注意してください。次の機能の一部は、フレームワークで提供される親ビジネス・オブジェクトの構成を使用して遂行され、その他の機能は子ビジネス・オブジェクトによって提供されます。さらに、特定の製品統合によってサポートされる、より複雑なユース・ケースが存在する場合があります。詳細は、使用しているアプリケーションの同期要求ビジネス・オブジェクトのライブラリ、および特定の製品の統合に関するドキュメントを参照してください。

次の各項では、このデータ同期方法の主な側面について説明します。

変更の取得

基本製品には、変更データ取得(メンテナンス・オブジェクト監査)アルゴリズムF1-GCHG-CDCPが用意されており、この方法で同期する必要があるメンテナンス・オブジェクトに使用できます。このアルゴリズムでは、変更されたレコードごとに「同期要求」レコードが作成され、メンテナンス・オブジェクト・コードおよび主キーが取得されます。ただしこれが行われるのは、同じレコード(および同じビジネス・オブジェクト)に対する既存の同期要求が初期状態では見つからない場合です。使用される同期要求ビジネス・オブジェクトは、変更されたレコードのメンテナンス・オブジェクトの「同期要求ビジネス・オブジェクト」オプションで定義されているオブジェクトです。そのようなオプションが複数存在する場合は、複数の同期要求が作成されます。

特定の製品では、さらに高度な例を提供するために、追加の監査アルゴリズムを導入する場合もあります。

同期要求レコードを作成する場合は、通常、同期要求ビジネス・オブジェクトには、変更前のレコードのデータのスナップショットを取得する前処理プラグインがあります。これは、外部システムに変更を通知する必要があるかどうかを検証するために後続のステップで使用されます。

同期が必要かどうかの確認

同期要求を取得した後は、外部システムに情報を送信する前に、実行する複数のステップがあります。

注意: ここでは主要なステップのみを示します。完全な機能の全体像は、ビジネス・オブジェクトの構成、そのライフサイクルおよびアルゴリズムを参照してください。

同期要求レコードが作成されると、バッチ・モニターで処理するようにその初期状態(保留)が構成されます。このようにして、レコードは1日を通して同期要求表に追加されますが、すべては一緒に処理されます。メンテナンス・オブジェクト監査アルゴリズムでは、(同じビジネス・オブジェクトの)指定されたメンテナンス・オブジェクトと主キーの組合せについて、保留中のレコードがすでに存在する場合は、新しい同期要求が作成されないようにします。ただし、そのメンテナンス・オブジェクトと主キーの組合せのレコードは、後続する最終以外(「承認待ち」など)に存在する可能性があります。この状態には、その状態をチェックして別のレコードが存在する場合は遷移をスキップするためのモニター・アルゴリズムが含まれます。これは、この新しいレコードが処理される前に、既存のレコードが完全に処理されるようにするために実行されます。
ライフサイクルの次の状態は「同期化が必要かどうかを決定」です。このステップでは、アルゴリズムを使用してデータのスナップショット(最終スナップショットと呼ばれる)を取得し、レコードが作成されたときに取得した初期スナップショットと比較します。アルゴリズムのロジックに基づいて、進行(「要求の送信」に遷移)するか、中止(「破棄済」に遷移)するかを決定します。

外部システムへの伝達

同期の発生を確認した後は、メッセージを外部システムに送信する必要があります。次に基本機能について説明します。

「要求の送信」状態にリンクされたアルゴリズム。このアルゴリズムが情報を外部システムに適切にルーティングするアウトバウンド・メッセージを作成することが想定されます。アルゴリズムは、外部システムおよび使用するアウトバウンド・メッセージ・タイプを判別する必要があります。同期要求のビジネス・オブジェクトでは、このアルゴリズムに使用する外部システムおよびアウトバウンド・メッセージ・タイプを定義するビジネス・オブジェクト・オプションをサポートしています。
アウトバウンド・メッセージがトリガーされると、レコードは「承認待ち」ステータスに遷移します。この状態を使用して、外部システムからの応答を受け取るまで、同期要求の状態を遷移しないようにします。このステップは、外部システムからの応答メカニズムの実装に依存することに注意してください。情報の時系列的な流れを管理するのに役立つため、応答を実装することをお薦めします。製品では、肯定応答を受け取った場合は次のデフォルトの状態(この場合は「同期化済」状態)、否定応答を受け取った場合は「拒否」遷移条件に関連付けられている状態(この場合は「エラー」状態)のいずれかに同期要求を遷移するビジネス・サービスF1-UpdateSyncRequestを提供しています。さらに、この状態は、タイムアウト制限に達したことを検出するモニター・アルゴリズムとともに構成できます。
「エラー」状態に入るレコードの場合は、作業予定登録を作成するアルゴリズムを構成して、問題を誰かに通知することをお薦めします。詳細は、統合のドキュメントを参照してください。状態は、状態を終了するときに作業予定を完了するためのアルゴリズムとともに事前に構成されています。
最終状態の「同期化済」は、正常な同期をマークするために使用されます。ただし、より複雑なユース・ケースでは、この状態を使用して追加の処理をトリガーできます。詳細は、特定の製品の統合に関するドキュメントを参照してください。