| # トリガーを設定するには 概要 準備 トリガーを設定する前に、要件/設計を指定する必要があります。何をいつ行う必要があるか考えます。たとえば、新しい販売オーダが Infor LN で作成された場合、アプリケーション X に通知します。または、特定状況フィールドが値活動中を受信した場合、アプリケーション Y に通知します。 加えて、通信する必要がある情報を明確にしてください。言い換えると、何をイベントメッセージの内容にしますか。たとえば、オーダ番号のみ、またはオーダ日や販売先取引先 (顧客) ID など、オーダの他の属性です。 トリガーの実装方法を選択します。たとえば、交換を使用して、またはアプリケーションのカスタマイズによって行います。さらに、実行する処理を定義する必要があります。 これらの設定を指定するとき、パフォーマンス関連の問題を考慮する必要があります。対象アプリケーションにイベントについて通知されるまで、プロセスにはどれくらいの時間がかかるでしょうか。イベントはどれほどの頻度で発生しますか。 その後、実際の実装を実行できます。 実際の実装の概要 トリガーの実装プロセスは、次の手順で構成されています。 交換スキームやアプリケーションのカスタマイズなどのトリガーソースを構成します。詳細は、この章で後述する ｢トリガーソースを設定するには｣ を参照してください。 条件や処理など、トリガーを定義します。詳細は、この章で後述する ｢トリガーを定義するには｣ を参照してください。 トリガーをテストします。必要なプロセスを開始し、実行時にプロセスを管理します。詳細は、この章で後述する ｢実行時タスク｣ を参照してください。 トリガーソースを設定するには トリガーソース 前述のとおり、イベントは次のように複数の方法で生成できます。 アプリケーションベース: Infor ERP LN 6.1 をカスタマイズしてトリガーイベントを生成します。 交換ベース: 交換モジュールを使用して、変更されたデータベース行またはデータベース行の完全なセットを 1 つ以上のテーブルから収集します。 タイマーベース: 間隔またはカレンダーに従ってイベントを定期的に生成します。 アプリケーションベースのトリガー アプリケーションでは、イベントメッセージを生成してトリガーを呼び出すコードを追加します。このコードは、たとえばライブラリやプログラムスクリプトに追加できます。 次の 2 つの API を使用して、このコードを追加できます。 イベントを作成する API 関数は、datrgevent ライブラリで使用できます。 トリガーを呼び出す API 関数は、datrgapi ライブラリで使用できます。 詳細は、これらのライブラリの仕様を参照してください。 注意 ライブラリの仕様は、ライブラリオブジェクトから取得できます。オペレーティングシステムレベルでは、explode6.2 を使用してライブラリオブジェクトを検索してから、-eu オプション付きで bic_info6.2 を使用します。 例: `$ 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 のマッピングが存在する場合、次の手順で説明するように交換スキームの大部分を生成できます。必要に応じて、定数や計算値を出力に追加できます。計算済/変換済の値には、スクリプトが必要である点に注意してください。 交換スキームは、次の方法で簡単に設定できます。 交換スキーム (daxch0501m000) セッションで、メインエンティティを作成し、交換スキーム属性を定義します。 交換スキーム (daxch0501m000) セッションで、特定メニューの ASCII Filesをクリックして ASCII ファイル (daxch0102m000) セッションを開始します。 ASCII ファイルのテーブルコードを使用するときは、新しい ASCII ファイルを作成します。定義ファイルフィールドを空のままにすることができます。複数のテーブルが必要な場合、複数のエントリを作成します。 特定メニューで、ASCII ファイルの作成... をクリックして ASCII ファイルフィールドと関係の作成 (daxch0203m000) セッションをクリックします。 ASCII ファイルの必要な範囲を選択します。 次のチェックボックスがオンになっていることを確認します。 テーブル定義を基に作成 バッチを作成。チェックボックスに対応するフィールドに作成されるバッチのコードと説明を入力します。 エクスポート関係を作成 プロセスを開始すると、必要な交換スキームの内容が生成されます。 Field Relations (Export) セッションおよび ASCII ファイルフィールド (daxch0503m000) セッションから対応する行を削除して、不要なフィールドを削除します。 交換の設定が完了したら、エクスポートプログラムの作成 (daxch0228m000) セッションを実行し、交換スキームで定義されているとおりに設定を実装する実行時プログラムを作成します。 交換の詳細は、Web Help を参照してください。 交換スキームは、監査にもとづいている必要があります。このため、構成スキームでテーブルの監査構成を生成する必要があります。これには、監査構成の生成 (daxch1201m000) セッションを使用します。監査管理の詳細は、Web Help を参照してください。 交換スキームとトリガーを設定したら、それら 2 つの間の関係を定義する必要があります。言い換えると、1 つ以上のトリガーを交換スキームにリンクする必要があります。これらのトリガーをリンクするには、エクスポートトリガー (daxch0135m000) を使用します。このセッションの詳細は、Web Help を参照してください。 交換ベースのトリガー (完全エクスポート) 作成、削除、または変更されたデータに関係なく完全なデータセットを発行する必要がある場合、完全交換エクスポートを使用できます。 この場合、設定はこの章で後述する ｢交換ベースのトリガー (変更)｣ と同じですが、次の例外があります。 交換スキームが監査にもとづいている必要はありません。 監査の設定は必要ありません。 タイマーベースのトリガー タイマーベースのトリガーには、特定の設定は必要ありません。この章で後述する ｢トリガーを定義するには｣ にあるように、トリガーを定義する必要があります。その後、この章で後述する ｢実行時タスク｣ にあるようにプロセスを開始できます。 トリガーを定義するには トリガーモジュールでは、必要に応じてトリガーの条件や処理など、トリガーを定義する必要があります。トリガーは、トリガー (datrg1100m000) セッションで作成できます。このセッションには、条件および処理ロジックを生成できる構成インターフェイスが存在します。複数のタイプのイベントに同じトリガーを使用できるだけでなく、複数のソースから同じトリガーを使用できます。 適切な場合は、トリガーの条件を定義できます。条件により、トリガー処理が実行されるイベントの数が限定されます。条件は、トリガー条件の構成 (datrg1110m000) セッションを使用して定義できます。このセッションでは、クラス、イベントタイプ、または属性値の条件を作成または更新できます。 このセッションで使用できる機能では必要な条件を作成できない場合、複雑な条件を含むスクリプトを添付できます。詳細は、オンラインマニュアルのトピック ｢添付の条件スクリプトを構成するには｣ を参照してください。 さらに、トリガーの処理を定義する必要があります。定義する必要がある処理のタイプは、トリガーに選択した処理テンプレートによって異なります。 散開処理: トリガーが複数の処理 (連続するトリガー) を同時に呼び出す必要がある場合は、この処理テンプレートを使用します。 XML ファイル処理: イベントを含むファイルを作成することによりトリガーが処理する必要がある場合の設定が含まれます。 ユーザインターフェイスの機能では要件を満たすことができない場合、ユーザはトリガー処理を実装するコード (スクリプト) を添付することにより特定の構成を実装できます。詳細は、オンラインマニュアルのトピック ｢添付の条件スクリプトを構成するには｣ を参照してください。 トリガーを定義した場合、実行時プログラムが自動的に生成されます。トリガー、またはトリガーの条件や処理を変更しても、プログラムが自動的に再生成されます。さらに、トリガー (datrg1100m000) セッションのプログラムを生成をクリックして、実行時プログラムを再生成できます。 実行時タスク 概要 実行時、トリガーを開始するインターフェイスがトリガーモジュールにより用意されます。その場合の入力は、イベントを記述する XML 構造です。ユーザは、交換モジュール、アプリケーション、またはジョブタイマーによるトリガーの開始 (datrg1200m000) セッションからこのインターフェイスを呼び出すことができます。アプリケーションまたは交換プロセスからこのインターフェイスを呼び出さない場合、プロセスは指定されたトリガーに処理が定義されているかどうかをチェックし、対応するトリガー関数を実行します。 次のサブセクションでは、実行時にプロセスを管理する方法について説明します。 トリガー管理 トリガー自体には、他の処理は必要ありません。トリガーは受動的です。したがって、トリガーはいずれかのトリガーソースがトリガーを呼び出すまで待機するだけです。トリガーが正常に機能しない場合、トリガーをデバッグできます。詳細は、トリガー (datrg1100m000) セッションのオンラインヘルプを参照してください。 注意 トリガーが存在しない場合、これはエラーとして報告されません。たとえば、あるアプリケーションは複数の会社で実行できますが、トリガー呼出時に 1 つの会社からのみ実行できる処理があるとします。この場合、トリガーが 1 つの会社のみで定義されている場合は同じアプリケーションを実行できます。 アプリケーションベースのトリガー アプリケーションベースのトリガーの場合も、実行時に処理は必要ありません。トリガーの呼出はアプリケーションロジックに含まれるため、対応するアプリケーション状況になると自動的にトリガー呼出が実行されます。 交換ベースのトリガー 交換ベースのトリガーを使用するには、エクスポートプロセスを定期的に実行する必要があります。カレンダーまたは事前定義された間隔に従って実行されるジョブに、データのエクスポート(標準) (daxch0234m000) セッションを追加できます。 このジョブにより、交換スキームは定期的に監査証跡から変更を取り出すか、データベーステーブルからデータを取り出し、対応するトリガーを呼び出すようになります。詳細は、交換のオンラインヘルプを参照してください。 実際には、エクスポートプロセスが正常に完了するために必要な時間より間隔を短くすることはできない点に留意してください。間隔を短くする必要がある場合 (1 分や数分など)、選択された間隔が実現可能かどうかを事前にチェックしてください。エクスポートプロセスの長さは、処理する変更またはデータの量と定義されたトリガー処理によって大きく異なります。 交換スキームの実行に必要なすべての通常管理アクティビティを実行する必要があります。たとえば、場合によってはエクスポートプロセスにより生成されたデータを消去することがあります。交換には、プロセスが正常に実行されているかどうかをチェックするログ記録機能が用意されています。 監査機構を使用して変更イベントを検出する場合、データが必要なくなれば、監査証跡を定期的に消去する必要があります。 最後に、監査の設定はパフォーマンスに影響を与える点に注意してください。システムのサイズが適切で、監査が正しく構成されている場合、オーバーヘッドは通常数パーセント以下であるため、影響は最小限になります。監査データは、ボトルネックになる可能性がないディスクに置くことを強くお勧めします。さらに、ディスクストライピングを展開してパフォーマンスを上げることができます。 タイマーベースのトリガー ジョブタイマーによるトリガーの開始 (datrg1200m000) セッションを実行して、事前定義されたイベントを定期的に生成します。詳細は、Web Help を参照してください。 対象アプリケーション 最後に、イベントを受信するアプリケーションに注目する必要があります。たとえば、このアプリケーションは処理後に受信したファイルを消去する必要があります。 交換特有の制限 交換ベースのトリガーには、次の制限が適用されます。 テーブルレベル対ビジネスオブジェクトレベル 交換からイベントを使用した場合、トリガーはビジネスオブジェクトレベルではなくテーブルレベルで定義されます。他のテーブルからの情報を含めることができますが (スクリプトオプションを使用可能)、これにはプログラミングが必要です。ただし、オブジェクトの主キーが必要な唯一の属性である場合、複数のテーブルから同じイベントを生成できます。たとえば、必要に応じて、オーダヘッダの変更とオーダラインの変更の両方により同じイベントを生成することができます。 プログラミング (交換スキームのいわゆる条件スクリプト) なしで定義できないイベントの例は、｢オーダラインの数量が変更され、オーダヘッダの状況が ｢オープン｣ の場合に承認プロセスを開始します｣ です。 未変更テーブルフィールド 行がテーブルで作成されたか、テーブルから削除された場合、交換エクスポートにより生成されるイベントには定義されたすべての ASCII フィールドが含められます。ただし、行が変更された場合、デフォルトでは主キーフィールドと変更されたフィールドだけが含められます。 たとえば、オーダ番号、ライン番号、品目、数量、価格で構成されるオーダラインのイベントを処理する場合、価格が変更されると、品目と数量がイベントで使用できなくなります。トリガーを定義し、最終的にトリガーを受け取るアプリケーションでイベントを処理する場合は、この点を考慮に入れる必要があります。数量のトリガー条件は、数量が使用可能な場合のみ満たされます。つまり、行が作成または削除された場合や、数量値が変更された場合です。 このデフォルトの動作を変更するには、変更スキームの監査プロファイルでテーブルフィールドの監査タイプを変更する必要があります。 2 つの監査タイプが存在します。 常時: フィールドの内容、または他の監査済フィールドの内容が変化するたびにフィールドがログに記録されます。これは、すべての主キーフィールドのデフォルト設定です。 変更時: フィールド自体の内容が変化したときにのみフィールドがログに記録されます。これは、主キーに属さないすべてのフィールドのデフォルト設定です。 テーブルフィールドが常に監査証跡にログ記録されるようにするには、フィールドの監査タイプを ｢常時｣ に変更する必要があります。これを行うには、次の手順に従います。 監査プロファイル (ttaud3110m000) セッションを開始し、監査スキームに属する監査プロファイル (監査構成の生成 (daxch1201m000) セッションを使用して生成した監査プロファイル) を選択します。 特定メニューでプロファイル別テーブル設定をクリックします。プロファイル別監査テーブル (ttaud3120m000) セッションが開始されます。テーブルのリストが表示されます。 監査設定を変更するテーブルを選択し、特定メニューでテーブル別監査フィールドをクリックします。テーブル別監査フィールド (ttaud3125m000) セッションが開始されます。このセッションでは、テーブルフィールドごとに監査タイプを変更できます。目的の監査タイプ (たとえば、 ｢常時｣ など) をリストから選択できます。 監査定義のランタイムの作成 (ttaud3200s000) セッションを実行し、新しい実行時監査定義を生成します。このセッションは、監査プロファイル (ttaud3110m000) セッションの特定メニューを使用して開始できます。 仮想マシン (bshell) を再起動します。 注意 監査管理の詳細は、Web Help と Infor Enterprise Server 8.6 Technical Manual (U8172 US) を参照してください。 イベントタイプ 永続的なデータの変更という観点で定義可能なイベントのみ処理できます。イベントは、次の観点で説明する必要があります。 テーブル イベントタイプ (処理): Create Change Delete 属性値 監査にもとづいて交換から生成可能なイベントの例は次のとおりです。 新しい品目行が追加されました。 品目行の数量が変化しました。 品目行の数量が増加しました。トリガーユーザインターフェイスでは、この条件を直接構成できない点に注意してください。ただし、オンラインマニュアルのトピック ｢添付の条件スクリプトを構成するには｣ で説明されているように、生成されたトリガー実装関数をカスタマイズすることでこの条件を構成できます。 品目グループが ｢ハードウェア｣ の品目行が作成、変更、または削除されました。ただし、前述のように、品目行が変更されても品目グループが変更されない場合、イベントは条件を満たしません。 交換から生成できないイベントの例は、次のとおりです。 abcde1234m000 セッションを使用して品目行が変更されました。 品目行がユーザ ｢john｣ によって変更されました。 その他の交換特有の制限 交換からは、(複数行) テキストが XML イベントに含められません。テキスト番号は含めることができます。 交換から生成されるイベントでは、ASCII ファイル名/フィールド名が構成要素名/属性名として使用されます。これは、イベントが最大 8 文字であることを示しています。 日付は、交換スキーム (daxch0501m000) セッションの交換スキームプロパティや、ASCII ファイルフィールド (daxch0503m000) セッションの ASCII ファイル形式プロパティで指定された日付フォーマットに従ってフォーマットされます。 列挙型定数には、定数の名前ではなく定数の数値を使用する必要があります。たとえば、トリガー条件では、tdsls400.corg = tdsls.corg.eop ではなく tdsls400.corg = 3 を使用する必要があります。 XML イベントに保存されたマルチバイト文字列値では、マルチバイト変換が実行されません。 |