In our third example trigger application, we'll take a closer look at how useful and powerful triggers can be when we use one to not only enhance a software package but also to integrate two different software packages , which could even be from two different vendors.
Here's the situation: You have two software packages and the vendors (publishers) do not offer the source code for them. The first package is an accounting package. It contains an inventory system that has an inventory file similar to the one we saw in our first example trigger (see "trigger applications – part 3"), and you use it for the same purpose (i.e., to keep track of your raw materials).
Your accounting package does not offer an EDI feature, so you purchase a separate EDI package from another vendor. Now you want to integrate the two packages so that -- just like in the first example -- orders are sent out automatically throughout the day when inventory level drop below a set reorder point. But, alas, you discover another problem: The inventory system in the accounting package does not contain a place to store reorder levels.
Solution -- part I: Use a trigger to add a new feature to a purchased software package
The first part of the solution involves setting up a little system where you can store reorder levels for your inventory items. For this, we create the INVREORD file, the source for which is shown here . This file references the main inventory file in the accounting package for the definitions of its fields.
Now, we need to create a trigger for the main inventory file in the accounting package. We need an after insert trigger that will prompt the user for a reorder level when a new inventory record is created. The trigger then needs to create the associated INVREORD record. The code for the REORDTRG.RPG. trigger is shown here.
Note: You should code and attach a delete trigger program to the same inventory file that will delete the appropriate INVREORD record when its associated main inventory record is deleted. This exercise is left to the reader. (Hint: Copy or just modify the REORDTRG program.)
Solution -- part 2: Use a trigger to integrate two different purchased software packagesThe trigger program shown here is nearly identical to the trigger we created in part 3 of this series. The only real difference is that the EDI program is now purchased instead of developed in-house, so you will probably need to code different parameters for the call to it, or you may have to interface with it in a different manner.
The two triggers can be added to the inventory file as usual:
ADDPFTRG FILE(ACCTG_PKG/INVNTRY) TRGTIME(*AFTER) TRGEVENT(*INSERT) PGM(UCG/REORDTRG) ADDPFTRG FILE(ACCTG_PKG/INVNTRY) TRGTIME(*AFTER) TRGEVENT(*UPDATE) PGM(UCG/EDITRIG)
This wraps up -- at least for now -- the coverage of triggers. As you think about these trigger applications, keep the following caveats in mind:
Finally, you can use the Print Trigger Programs (PRTTRGPGM) OS/400-iSeries command to print a list of trigger programs on your system and the files to which they are attached. Also, the Display File Description (DSPFD) command provides a fairly comprehensive list of information about the triggers that are associated with a specific file (specify *TRG or *ALL for the TYPE parameter).
About the author: Ron Turull is editor of Inside Version 5. He has more than 20 years' experience programming for and managing AS/400-iSeries systems.