トリガー・ファンクションとは?
トリガー・ファンクションは、ファイルに対して特定タイプのI/O操作が実行された場合および特定の一連の条件に適合した場合に自動的に呼び出される一種のLANSAファンクションです。
例えばある在庫管理システムで、DELETE FROM_FILE(ORDHDR) WITH_KEY(#ORDNUM)というRDMLコマンドにより「注文の取り消し」処理を行うと、所定の「イベント」が発生し、その結果自動的にあるファンクションに「トリガー」がかかります。
具体的には次のような処理が走ることになるでしょう。
|
処理A |
注文明細の履歴欄に「取り消された」旨の印をつける |
|
処理B |
貸付残高伝票を印刷する |
|
処理C |
販売部門に通知する |
また、注文が取り消されたときに実行される処理のリストは、元のDELETE FROM_FILE(ORDHDR)ファンクションを変更したり再コンパイルしたりしなくても、いつでも追加または変更することができます。
このように、トリガー・ファンクションには、業務処理とデータベース・ファイル(すなわち「オブジェクト」)を直接関連付ける働きがあります。所定のイベントが発生すると、自動的にトリガーがかかります。
例えば、業務上の規則で、注文が取り消された場合に処理A、B、およびCも実行しなければならないことが規定されている場合、「従来の設計」では、A、B、およびCを直接的なロジック(または呼び出し)として「注文の取り消し」という対話型ファンクションに組み込んでいました。
実際、注文取り消し元として考えられるソースは複数あります。
|
ソース1 |
一般的な対話方式による「注文の取り消し」トランザクション |
|
ソース2 |
毎月行われる未完成注文のバッチ自動取り消し |
|
ソース3 |
ダイヤルアップPCシステムを使用して営業担当者からLANSA Openトランザクションを介して到着した要求 |
また、最も「危険」なソースとして以下があります。
|
ソースX |
2年後に他の誰かによって定義されるトランザクション |
今すぐ処理A、B、およびCをソース1〜3に組み込む(または少なくともその作業を開始する)ことを忘れないでください。
また、実際、新しい設計者がA、B、およびCロジックの存在に気付かなかった場合、またはこのロジックをいつどのように使用するかを十分に理解していなかった場合に、最も大きな問題を引き起こすのは、最後の「ソースX」です。
トリガーは、処理A、B、およびCを注文という「オブジェクト」に関連付け、イベントの「ソース」が何であろうと、これらの処理が必ず呼び出されようにするため、このような問題をすべて解決します。
何より、イベントの「ソース」をまったく変更することなく、いつでも新しい処理D、E、およびFを注文に追加することができます。
適切に使えば、アプリケーション設計の方法が一変するかも知れません。まずユーザー・インターフェースを完全に設計し、業務処理本体は、データ・ディクショナリの妥当性規則やトリガー・ファンクションの形で後から組み込む、という手順も可能になるのです。
その結果、より「オブジェクト指向」の考え方に沿った設計になるでしょう。
業務処理本体とユーザー・インターフェースを明確に分割する働きが、トリガーにはあるからです。