A trigger function is a type of LANSA function which will be invoked automatically when a specific type of I/O operation occurs to a table and when a specific set of conditions are met.
For example, when an application developer defines the "Cancel of an Order" via the RDML command DELETE FROM_FILE(ORDHDR) WITH_KEY(#ORDNUM), they have initiated an "event", which may automatically cause other functions to be "triggered".
When the order is canceled it may "trigger" the following:
|
Activity A |
Flag Order Historical Details |
|
Activity B |
Print Outstanding Credit Invoices |
|
Activity C |
Send a Message to the Sales Department |
Additionally, the list of activities that happen when an order is canceled can be added to or changed at any time without having to change or even recompile the original DELETE FROM_FILE(ORDHDR) function.
A trigger function allows a business activity to be associated directly with a database table (i.e. the "object"). When a specified event happens to information in the table, then the trigger(s) will be automatically invoked.
For example, if the business rules stated that when an order is canceled you must also perform activities A, B and C, then a "traditional design" would include A, B and C as direct logic (or calls) into the interactive function called "Cancel an Order".
In fact there may be several sources from which an Order may be canceled:
|
Source 1 |
The typical interactive "Cancel an Order" transaction. |
|
Source 2 |
Monthly Batch Automatic Canceling of Unfilled Orders. |
|
Source 3 |
Requests arriving via LANSA Open transactions from sales people using dial up PC systems. |
and the most "dangerous" source of all:
|
Source X |
The transaction that will be defined by someone else in 2 years time. |
You have to remember to include the A, B and C activities (or at least the initiation of it) into sources 1 through 3 now.
In fact it is often the last case, "Source X", that will cause the most problem when the new designer fails to realize that the A, B and C logic exists, or even to understand fully how and when it is used.
Triggers solve all these problems because they link the activities A, B and C to the "object" Order, and thus are always invoked, no matter what the "source" of the event is.
And best of all, you can add new activities D, E and F to Order, at any time, without having to change any of the event "sources" in any way.
Sensible use of triggers may transform the way that an application is designed. The user interface can be fully designed, and then the complexities and rules can be introduced later by using data dictionary validation rules and database trigger functions.
The resulting design is much more in the "object oriented" style.
Triggers separate "business function" from "user interface" in a much clearer and easier way.
