Re: Anyone using Triggers to enforce data validation & business rules?

On 9/19/2014 3:22 PM, Charles Wilt wrote:

You have to
- catch the exception (in a monitor block for instance) in your RPG or
client app
- determine the error was due to a trigger
- looking for the original error thrown by your trigger

Ideally, you'd be using user defined messages rather than a generic
CPF9898.

The redbook in question shows a Java example in 10.8.2 (pp 335 - 337)

Charles

Let me add to Charles' answer, which is spot on. The Aha! moment for me
was when I began to think of triggers as APIs. Not an API that your
code calls, but an API that the database manager code calls.

If you owned both sides of that API interface, you could put in a
parameter to pass back status or error messages. But you're writing an
API that IBM code will be calling, so you need to conform to their
interface. The IBM interface for status and error messages is messages.

Say your API / trigger is one that validates an order. Imagine that
there's a rule that if the quantity on hand is insufficient to fill the
quantity ordered your trigger will reject the item. Your order entry
program does a WRITE or INSERT, which in turn tells the database manager
to call your trigger. When your trigger sends an escape message, the
database manager forwards it to your OE program which then needs to do
something about it.

You can design your OE trigger to generate a single error message with
multiple return codes as replacement text, or you can generate multiple
error messages, each meaning something unique. You can capture that
message in multiple ways, depending on the programming language. In RPG
you might try a MONITOR block around the WRITE, and then call the
Receive Message API to pull the message out of the job log.

Anyway, the key is that because your trigger is called by IBM code, you
need to send messages in order to tell the caller (your OE program that
did the WRITE which fired the trigger, whew!) what has happened.
--buck

On Fri, Sep 19, 2014 at 2:34 PM, Nathan Andelin wrote:

Several pages in the new "modernization" redbook cover this topic. Rules
are written only once rather than embedding them in multiple applications
(ILE, Java, PHP, Ruby, .Net). The system enforces them, so you can't get
around them via utilities (such as DFU).

This idea makes sense to me from an architectural perspective. But I'm
struggling with exception handling.

I'm following Trigger coding examples from the following redbook:

http://www.redbooks.ibm.com/redbooks/pdfs/sg246503.pdf

Examples show using the QMHSNDPM API to signal *ESCAPE type messages. That
was causing a spooled program DUMP with every data validation exception - I
finally figured out how to prevent that.

I seems harsh to signal an exception which abnormally ends the Trigger
program - just for data validation errors. Error message appear in job
logs. But how do you get them to appear on the user's screen?

Nathan.