There are a number of design principles for trigger functions, as well as some rules for LANSA triggers. Following are some important design considerations for triggers:
Encapsulation:
The trigger function should be designed to encapsulate all the rules into one, and only one, place. For example, if you design a trigger function to calculate payroll tax, then you should have all the calculations logic in one place only. This means that you only need to update one function when the "method" of calculation changes.
Deferment:
The details of a "method" do not have to be defined, or even known about, during initial system design. This also means that a "method" can be introduced into an application design at any time. For instance, the payroll tax calculation method does not have to be defined first, before the applications that create or update employees are defined and tested. When the payroll tax trigger is created and defined, it will immediately begin to affect the processing of all existing applications.
Re-usability:
The trigger must be designed bearing in mind that it is, (or might be in the future) reused by any application. In the payroll tax example the trigger could be activated from a normal IBM i NPT device via an "Employee Maintenance" function, or from a PC application via the LANSA Open facility.
Transparency:
The fact that the calculate payroll tax logic is present and being used must be invisible and immaterial to an RDML builder creating an "Employee Maintenance" function.
Separation of the "method" from the "event":
The trigger function must define what to do when an "event" happens (i.e: the "method"), but it does not have to detect the occurrence of the event. The occurrence of the event must be detected by the trigger points and conditions in the data dictionary.
