トリガーを設定するには

トリガーを設定する前に、要件/設計を指定する必要があります。何をいつ行う必要があるか考えます。たとえば、新しい販売オーダが LN で作成された場合、アプリケーション X に通知します。または、特定状況フィールドが値活動中を受信した場合、アプリケーション Y に通知します。

加えて、通信する必要がある情報を明確にしてください。言い換えると、何をイベントメッセージの内容にしますか。たとえば、オーダ番号のみ、またはオーダ日や販売先取引先 (顧客) ID など、オーダの他の属性です。

トリガーの実装方法を選択します。たとえば、交換を使用して、またはアプリケーションのカスタマイズによって行います。さらに、実行する処理を定義する必要があります。

これらの設定を指定するとき、パフォーマンス関連の問題を考慮する必要があります。対象アプリケーションにイベントについて通知されるまで、プロセスにはどれくらいの時間がかかるでしょうか。イベントはどれほどの頻度で発生しますか。

その後、実際の実装を実行できます。

アプリケーションでは、イベントメッセージを生成してトリガーを呼び出すコードを追加します。このコードは、たとえばライブラリやプログラムスクリプトに追加できます。

詳細は、これらのライブラリの仕様を参照してください。

例:

$ explode6.2 odatrgevent

/mybse/application/myvrc/odatrg/otrgevent

$ bic_info6.2 -eu /mybse/application/myvrc/odatrg/otrgevent

このコマンドにより、イベント処理関数のマニュアルが表示されます。

この方法により、関数名、タイプ、パラメータとそのタイプを含む、ライブラリ内の関数のプロトタイプ、関数とその入出力の記述、および事前条件と事後条件を得ることができます。

次の例は、アプリケーションのカスタマイズからイベントを作成し、トリガーを実行する方法を示しています。

#pragma used dll odatrgevent    |event handling functions
#pragma used dll odatrgapi  |triggering api

#define CHECK_RETURN(retval)    if retval <> 0 then
^                                 ... |implementation depending|on context
^                               endif

long    my.event                |XML event used for triggering
long    retl                    |return value to be checked
string  exception.message(512) mb   |message if an error occurs
string  exception.details(512) mb   |details on exception message

if curr.inventory.on.hand < threshold.value and prev.inventory.on.hand >= threshold.value
then
    |low inventory, invoke trigger
    retl = datrgevent.simpleevent.create("Inventory", "LowInventory", my.event)
    CHECK_RETURN(retl)
    retl = datrgevent.simpleevent.set.value(my.event, "item", curr.item)
    CHECK_RETURN(retl)
    retl = datrgevent.simpleevent.set.value(my.event, "warehouse", curr.warehouse)
    CHECK_RETURN(retl)
    retl = datrgevent.simpleevent.set.value(my.event, "inventoryOnHand", 
                        curr.inventory.on.hand)
    CHECK_RETURN(retl)
    retl = datrgevent.simpleevent.set.old.value(my.event, "inventoryOnHand", 
                        prev.inventory.on.hand)
    CHECK_RETURN(retl)
    retl = datrgapi.trigger.do("mytrigger", my.event, exception.message, exception.details)
    CHECK_RETURN(retl)
endif

1 つの構成要素のみで構成されるイベントを作成するため、簡単なイベント関数が用意されています。クラス名 (エンティティ)、イベントタイプ (処理)、および属性名と各属性の値を指定するだけです。さらに、必要に応じて、以前の属性値も追加できます。他のイベント関数を使用すると、ヘッダおよび行構成要素で構成されるマルチレベルイベントなど、より複雑なイベントを作成できます。詳細は、第 3 章 ｢Event handling｣ を参照してください。

交換ベースのトリガーを使用するには、ASCII ファイルおよびフィールド、バッチ、テーブル関係 (エクスポート)、フィールド関係 (エクスポート) など、交換スキームを定義する必要があります。トリガーの場合、物理的な ASCII ファイルが作成されないという意味では、ASCII ファイルおよびフィールドは関連しないことがあります。ただし、これらのファイルおよびフィールドは、イベントの内容を定義するため関連があります。ASCII ファイルはオブジェクト (または構成要素) を表し、フィールドはイベントに含まれる属性を表します。

テーブルと列へのイベントおよびイベントの必須属性のマッピングは、明確にする必要があります。列とトリガーの必須属性の間に 1 対 1 のマッピングが存在する場合、次の手順で説明するように交換スキームの大部分を生成できます。必要に応じて、定数や計算値を出力に追加できます。計算済/変換済の値には、スクリプトが必要である点に注意してください。

交換の設定が完了したら、エクスポートプログラムの作成 (daxch0228m000) セッションを実行し、交換スキームで定義されているとおりに設定を実装する実行時プログラムを作成します。

交換の詳細は、Web Help を参照してください。

交換スキームは、監査に基づいている必要があります。このため、構成スキームでテーブルの監査構成を生成する必要があります。これには、監査構成の生成 (daxch1201m000) セッションを使用します。監査管理の詳細は、Web Help を参照してください。

交換スキームとトリガーを設定したら、それら 2 つの間の関係を定義する必要があります。言い換えると、1 つ以上のトリガーを交換スキームにリンクする必要があります。これらのトリガーをリンクするには、エクスポートトリガー (daxch0135m000) を使用します。このセッションの詳細は、Web Help を参照してください。

作成、削除、または変更されたデータに関係なく完全なデータセットを発行する必要がある場合、完全交換エクスポートを使用できます。

タイマーベースのトリガーには、特定の設定は必要ありません。この章で後述する ｢トリガーを定義するには｣ にあるように、トリガーを定義する必要があります。その後、この章で後述する ｢実行時タスク｣ にあるようにプロセスを開始できます。

トリガーモジュールでは、必要に応じてトリガーの条件や処理など、トリガーを定義する必要があります。トリガーは、トリガー (datrg1100m000) セッションで作成できます。このセッションには、条件および処理ロジックを生成できる構成インターフェイスが存在します。複数のタイプのイベントに同じトリガーを使用できるだけでなく、複数のソースから同じトリガーを使用できます。

適切な場合は、トリガーの条件を定義できます。条件により、トリガー処理が実行されるイベントの数が限定されます。条件は、トリガー条件の構成 (datrg1110m000) セッションを使用して定義できます。このセッションでは、クラス、イベントタイプ、または属性値の条件を作成または更新できます。

このセッションで使用できる機能では必要な条件を作成できない場合、複雑な条件を含むスクリプトを添付できます。詳細は、オンラインマニュアルのトピック ｢添付の条件スクリプトを構成するには｣ を参照してください。

トリガーを定義した場合、実行時プログラムが自動的に生成されます。トリガー、またはトリガーの条件や処理を変更しても、プログラムが自動的に再生成されます。さらに、トリガー (datrg1100m000) セッションのプログラムを生成をクリックして、実行時プログラムを再生成できます。

実行時、トリガーを開始するインターフェイスがトリガーモジュールにより用意されます。その場合の入力は、イベントを記述する XML 構造です。ユーザは、交換モジュール、アプリケーション、またはジョブタイマーによるトリガーの開始 (datrg1200m000) セッションからこのインターフェイスを呼び出すことができます。アプリケーションまたは交換プロセスからこのインターフェイスを呼び出さない場合、プロセスは指定されたトリガーに処理が定義されているかどうかをチェックし、対応するトリガー関数を実行します。

トリガー自体には、他の処理は必要ありません。トリガーは受動的です。したがって、トリガーはいずれかのトリガーソースがトリガーを呼び出すまで待機するだけです。トリガーが正常に機能しない場合、トリガーをデバッグできます。詳細は、トリガー (datrg1100m000) セッションのオンラインヘルプを参照してください。

アプリケーションベースのトリガーの場合も、実行時に処理は必要ありません。トリガーの呼出はアプリケーションロジックに含まれるため、対応するアプリケーション状況になると自動的にトリガー呼出が実行されます。

交換ベースのトリガーを使用するには、エクスポートプロセスを定期的に実行する必要があります。カレンダーまたは事前定義された間隔に従って実行されるジョブに、データのエクスポート (標準) (daxch0234m000) セッションを追加できます。

このジョブにより、交換スキームは定期的に監査証跡から変更を取り出すか、データベーステーブルからデータを取り出し、対応するトリガーを呼び出すようになります。詳細は、交換のオンラインヘルプを参照してください。

実際には、エクスポートプロセスが正常に完了するために必要な時間より間隔を短くすることはできない点に留意してください。間隔を短くする必要がある場合 (1 分や数分など)、選択された間隔が実現可能かどうかを事前にチェックしてください。エクスポートプロセスの長さは、処理する変更またはデータの量と定義されたトリガー処理によって大きく異なります。

交換スキームの実行に必要なすべての通常管理アクティビティを実行する必要があります。たとえば、場合によってはエクスポートプロセスにより生成されたデータを消去することがあります。交換には、プロセスが正常に実行されているかどうかをチェックするログ記録機能が用意されています。

監査機構を使用して変更イベントを検出する場合、データが必要なくなれば、監査証跡を定期的に消去する必要があります。

最後に、監査の設定はパフォーマンスに影響を与える点に注意してください。システムのサイズが適切で、監査が正しく構成されている場合、オーバーヘッドは通常数パーセント以下であるため、影響は最小限になります。監査データは、ボトルネックになる可能性がないディスクに置くことを強くお勧めします。さらに、ディスクストライピングを展開してパフォーマンスを上げることができます。

ジョブタイマーによるトリガーの開始 (datrg1200m000) セッションを実行して、事前定義されたイベントを定期的に生成します。詳細は、Web Help を参照してください。

最後に、イベントを受信するアプリケーションに注目する必要があります。たとえば、このアプリケーションは処理後に受信したファイルを消去する必要があります。

交換ベースのトリガーには、次の制限が適用されます。

交換からイベントを使用した場合、トリガーはビジネスオブジェクトレベルではなくテーブルレベルで定義されます。他のテーブルからの情報を含めることができますが (スクリプトオプションを使用可能)、これにはプログラミングが必要です。ただし、オブジェクトの主キーが必要な唯一の属性である場合、複数のテーブルから同じイベントを生成できます。たとえば、必要に応じて、オーダヘッダの変更とオーダラインの変更の両方により同じイベントを生成することができます。

プログラミング (交換スキームのいわゆる条件スクリプト) なしで定義できないイベントの例は、｢オーダラインの数量が変更され、オーダヘッダの状況が ｢オープン｣ の場合に承認プロセスを開始します｣ です。

行がテーブルで作成されたか、テーブルから削除された場合、交換エクスポートにより生成されるイベントには定義されたすべての ASCII フィールドが含められます。ただし、行が変更された場合、デフォルトでは主キーフィールドと変更されたフィールドだけが含められます。

たとえば、オーダ番号、ライン番号、品目、数量、価格で構成されるオーダラインのイベントを処理する場合、価格が変更されると、品目と数量がイベントで使用できなくなります。トリガーを定義し、最終的にトリガーを受け取るアプリケーションでイベントを処理する場合は、この点を考慮に入れる必要があります。数量のトリガー条件は、数量が使用可能な場合のみ満たされます。つまり、行が作成または削除された場合や、数量値が変更された場合です。

このデフォルトの動作を変更するには、変更スキームの監査プロファイルでテーブルフィールドの監査タイプを変更する必要があります。