Problem solve Get help with specific problems with your technologies, process and projects.

Advanced trigger applications -- part 5

Advanced trigger applications -- part 5: How to use triggers to enhance and integrate two different software packages

Ron Turull

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.

More Information

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 packages

The 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:



This wraps up -- at least for now -- the coverage of triggers. As you think about these trigger applications, keep the following caveats in mind:

  • You can code fixed positions for the old and new record fields of the input buffer, but remember, if you change the file such that it results in a different record length, you will have to modify the trigger program code. Moreover, if you forget to modify the trigger code, you will not get a level check unless you are actually using the associated file in the trigger itself. However, you may get decimal data errors.

  • Although it is widely published that triggers can be called recursively, RPG still does not support recursion. So, don't set up a situation where an RPG trigger will cause itself to be called. Note: An RPG trigger program can call an internal procedure recursively, as long as that procedure doesn't cause the program to be called recursively.

  • When a file is opened, a lock is put on its trigger program objects. The lock is held until the file is closed. You can neither delete nor replace a trigger program while this lock is held.

  • The triggers presented were all written in OPM RPG to appeal to the broadest audience. If you are comfortable with ILE RPG, use it to code your triggers. Your trigger programs will be more efficient, especially if you base the externally-described data structure on a pointer; then, just position the pointer to the records in the incoming buffer instead of copying them.

    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.

  • Dig Deeper on iSeries Applications

    Start the conversation

    Send me notifications when other members comment.

    Please create a username to comment.