水面下で：システムによって BOD が生成される方法

以下は BOD を生成する際にシステムで行われる手順です。

  1. このアプリケーションでは、各 BOD を生成するためにレプリケーションエンジンを使用します。以下の 2 つの個別の処理によって BOD の生成をトリガできます。
    • テーブル生成：テーブルに UpdateCollection 要求をトリガする変更が行われる。
    • 関数生成：リモートメソッドコールをトリガするビジネスイベントがシステムで発生する。

    これらはいずれも BOD 発生統合ポイントとみなされています。BOD を生成するビジネスイベントは、 [レプリケーション文書アウトバウンド相互参照] フォームで一覧されます。

    例 1 - テーブル生成：レプリケーションカテゴリにテーブル名を追加すると、そのテーブル内のレコードに変更を加えるたびに BOD 生成がトリガされます。その設定が一般的すぎる場合、つまり、そのテーブル内の何かに何かが触れるたびに BOD が生成されてしまうことがないようにする場合は、[フィルタ] 属性を使用して、テーブルへの変更による BOD 生成のトリガの可否を決定するフィルタを定義して、BOD 生成を制限することができます。フィルタと一致するレコードのみが BOD に取り込まれます。テーブルに対する変更の区分に基づいて BOD 生成を制限するために使用できるチェックボックスには、以下の 3 種類あります。[挿入を無視]、[更新を無視]、および [削除を無視]。これらは全て [レプリケーションカテゴリ] フォームで行うことができます。

    例 2 - 関数生成：簡単なテーブル更新ベースのトリガでは不十分な場合は、このテクニックを使用します。たとえば、新しい購買オーダが作成されたときに BOD をトリガしたい場合があります。購買オーダは階層データであり、行数もリリース数も任意なので、BOD 生成をトリガする単一のテーブルを特定することは不可能です。つまり、いつ最後の行やリリースが挿入されたか知る方法はありません。

    また、テーブルの更新とは全く関係のない一定のアプリケーションイベントの発生時に BOD 生成をトリガしたい場合もあります。その場合は、「関数」トリガを使用して BOD 更新をプログラムでトリガすることができます。 [レプリケーションカテゴリ] フォームで指定した「関数」名は、必ずしも実際のストアドプロシージャと一致しておらず、今後もおそらく一致することはありません。実際のところ、この関数名は、最終的に BOD 生成をトリガするレプリケーションストアドプロシージャの 1 つに渡されるパラメタであるにすぎません。このストアドプロシージャの名前は、RemoteMethodForReplicationTargetSp です。このストアドプロシージャは、トリガ、別のストアドプロシージャ、または IDO 拡張クラスからも呼び出すことができます。

    上記の購買オーダトリガを説明すると、以下のようになります。ユーザが [購買オーダレポート] を使用して新しい購買オーダを作成します。実行される論理の一部として、ストアドプロシージャ TriggerPurchaseOrderSyncSp に対してリモートメソッドコールが行われ、これによって BOD 生成レプリケーション論理がトリガされます。

    リモートメソッドコールによって呼び出されるストアドプロシージャは、データベースに存在する実際のストアドプロシージャではありません。呼び出しでは、パラメタを渡す場合も渡さない場合もあります。呼び出しでパラメタが渡される場合は、レプリケーション文書フォームがそれらのパラメタを順番に参照します。つまり、[P1] で 1 番目のパラメタを参照し、[P2] で 2 番目のパラメタを参照するというように続きます。以下のコードの抜粋は、TriggerPurchaseOrderSyncSp へのリモートメソッドコールによって渡された 2 つのパラメタを示します。 

    
 EXEC @Severity  = dbo.RemoteMethodForReplicationTargetsSp                          
   @IdoName        = 'SL.ESBSLPos'
 , @MethodName = 'TriggerPurchaseOrderSyncSp'
 , @Infobar           = @Infobar OUTPUT
 , @Parm1Value   = @PoPoNum
 , @Parm2Value   = @Infobar
  2. [レプリケーションカテゴリ] フォームでは、カテゴリごとに、システムの特定領域のレプリケーションに必要なテーブルと関数が含まれます。[ESB] という名のデフォルトカテゴリには、定義済みの全てのリモートメソッドコールが含まれるか、または Infor BOD 形式の XML を必要とする他のアプリケーションへの統合ポイント用にレプリケーション文書によって参照されたオブジェクト名が含まれます。たとえば TriggerPurchaseOrderSyncSp は ESB カテゴリにリストされます。

    汎用 XML 文書（つまり、Infor BOD 形式でない XML を必要とするアプリケーション向け文書)の場合は、適切なリモートメソッドコールまたはオブジェクト名を含む別個のレプリケーションカテゴリを作成する必要があります。

  3. カテゴリが ESB に設定されているローカルサイトと Infor ESB サイト間に[レプリケーションルール]が存在する場合は、統合ポイントのあるビジネスイベントまたはテーブルの変更が ローカルサイトで起きるたびに、システムによってレプリケーションテーブルにエントリが追加されます。

    汎用 XML 文書の場合は、ローカルサイトとアプリケーション用に定義されたサイト間のレプリケーションルールを作成します。ただし、そのサイトは、HTTP トランスポートプロトコルを使用するように定義されたイントラネット上に設定する必要があります。

  4. レプリケータがレプリケーションテーブルから行を選び、それらを MSMQ に配置します。
  5. ReplQListener が MSMQ からそれらの行を選び、それらが他の BOD 対応アプリケーション用にバインドされている行であると判定します。次に、ReplQListener によって、ビジネスイベントまたはテーブルの変更に対して BOD が生成されます。上述のように、パラメタはイベントによって渡されることがあります。

    上記の例 2 では、ユーザが [購買オーダレポート] を実行し、それによって TriggerPurchaseOrderSyncSp が呼び出されます。このストアドプロシージャが定義されているカテゴリにはルールが存在するので、システムによってレプリケーション文書が構築されます。システムは、適用先メソッドが TriggerPurchaseOrderSyncSp である PurchaseOrder.Sync へのレプリケーション相互参照を見つけ、PurchaseOrder レプリケーション文書テンプレートを取得し、BOD XML 文書を構築します。その際、 [レプリケーション文書アウトバウンド相互参照] フォームから名詞と動詞が使用され、 [レプリケーション文書] フォーム、 [レプリケーション文書要素] フォーム 、 および [レプリケーション文書属性] フォームで定義された要素と属性の情報も使用されます。

    またこの例では購買オーダ番号が 1 番目のパラメタ (P1) として渡されます。レプリケーション文書はフィルタでこの情報を使用するので（PoNum=FP(P1)）、生成された BOD には指定された購買オーダのみのデータが含まれます。

  6. ReplQueueListener が生成された BOD XML を [レプリケーション文書送信箱] に入れます。

    汎用 XML 文書は、送信箱ではなく、非トランザクションレプリケーション用に定義されたイントラネット URL に送信されます。

関連トピック