Using the Dexterity Three Trigger Technique Part 1
When working with Dexterity triggers, the hardest part of the process is working out where to place the triggers. There are times where it seems impossible to get the trigger you need in the correct location. This post explains the concept of what I call the Three Trigger Technique. The technique involves using a trigger on an apparently unrelated function or procedure which executes at the appropriate point within the code of the function or procedure. Let me explain in more detail ...
The Theory
I have a function or procedure (Script A) which runs a series of commands. I need to trigger after the first half of the commands in Script A, but before the end of Script A. Using Source Code or Script Logging I can identify other functions and procedures which are called by Script A. I find a function or procedure (Script B) which runs around the location I would like my trigger to be placed. I can now register my trigger before or after the original code of Script B. This gives me the correct timing for the trigger.
However, this unrelated Script B could be called from other locations. So I need to ensure that my trigger is only executed when Script B is called from inside Script A. To achieve this I use a global system variable which is set and cleared by triggers before and after Script A respectively. The code in my trigger against Script B then checks this global system variable before continuing.
The final point is that I might need access to variables or table buffers that are not parameters to Script B, so I can either use my before Script A trigger or other additional triggers to capture the values or references to the parameters I need.
The Problem
I don't want to focus on the problem as this post is all about the techniques used, but a real life example is the best method to show how this method works.
I was working on a support case recently where the customer was using the Copier Series to duplicate a Purchase order with Non-Inventory items using a Unit of Measure other than "Each". There had been a previous issue with Blanket POs in version 10.0 and the code had been altered to not copy the Unit of Measure for Non-Inventory items. This was causing the customer pain as they wanted to use other Units of Measures with their Non-Inventory items and did not use Blanket POs.
I provided the partner with source code for a trigger based "fix" for this issue. Their developers then used this to provide the customer with a work around fix until the actual code can be changed.
The Solution
The solution to this problem required Cross Dictionary code as well as the use of the Three Trigger Technique and will be covered in the next part of this post, which will be available on the 30-Mar-2009.
David
