Previous Topic: Typical Trigger ImplementationNext Topic: CA 2E Trigger Limitations

IBM i Database Trigger Support › Implementing Triggers › CA 2E Trigger Implementation

CA 2E Trigger Implementation

The CA 2E trigger implementation replaces multiple user-written, file-specific trigger programs with a single, generic file-independent Trigger Router that you can specify as the trigger program for any trigger over any database file. The Trigger Router uses a rule-based system held in a Trigger References File to call one or more further Trigger Functions that have previously been created in the CA 2E model. These functions are called either directly or asynchronously through a separate Trigger Server. You can specify each Trigger Function to perform any user-defined processing.

The parameters passed from the Trigger Router to a Trigger Function are simplified file-specific individual parameters. They represent the various elements of the trigger buffer parameter that was passed from DM to the Trigger Router. This simplification allows a test-harness to be generated in CA 2E very easily.

This implementation is also flexible enough to allow additional trigger functionality to be added, changed and tested very easily, simply by creating new Trigger Functions and updating the Trigger References File to link the Trigger Function to the trigger.

Note: If the Trigger Router routes a Trigger Function to the Trigger Server, the server cannot return an error code to the Trigger Router (and thence to the application program). Consequently, any processing within such Trigger Functions must be non-critical, since any failure within this processing will not be able to roll back the database change.

The following diagram shows the structure of a CA 2E trigger showing how the various components interact.

Trigger Implementation

The processing sequence for a CA 2E trigger is as follows:

  1. An application program (APP) executes an INSERT, UPDATE or DELETE statement, resulting in a low-level call to i OS Data Management (DM).
  2. DM calls the Trigger Router (RTR) specified for the trigger.
  3. RTR checks the Trigger References File to see if there are any Trigger Functions (FUN) to call for this trigger. There may be more than one FUN that should be called for a trigger. For each FUN record, if the FUN calling method is 'CALL', process steps 3.1. through 3.3. If the FUN calling method is 'DTAQ', process steps 3.4. through 3.5.
    1. RTR calls FUN directly, passing the pre-determined setoff parameters specific to the database file being processed
    2. FUN performs user-defined processing and returns control to RTR. If processing is unsuccessful, FUN returns error code to RTR
    3. If RTR receives an error code from FUN, it does not process any more FUN records, but returns the error code to DM. Otherwise, RTR returns to step 3 to process any subsequent FUN records in the Trigger References File
    4. RTR places an entry on the Trigger Data Queue. The data queue entry contains the same parameters as would be passed in a CALL to FUN.
    5. RTR returns to step 3 to process any subsequent FUN records in the Trigger References File.
  4. If DM receives an error code from TRG, it does not update the file and instead sends the error code back to APP. Otherwise, it updates the file.

There are three separate sections to the CA 2E trigger support: