Setup at implementation time

Note that these assumptions are not mandatory. For example, the user can use other, more descriptive ASCII file and field names, which reduces the transformations in the trigger. However, in that case, the limitations of the Exchange module must be taken into account. More specifically, the ASCII file and field names cannot be greater than eight characters in length and the ASCII file names will always be in lowercase.

Audit is switched on for the tables involved: whwmd215 and tdsls400. For details about Audit Management, refer to the Web Help and to the Infor10 ERP Enterprise Server (LN) Technical Manual (U8172 US).

A single exchange scheme is created to pick up the relevant changes. As a result, the job for each of these situations runs at the same frequency, which results in less overhead. If the frequency for checking the changes must differ for the tables, you can create multiple batches or exchange schemes.

The batch includes the two batch lines, covering the following table fields:

Control character, separator, and enclosing character are irrelevant because no file is created.

Field Type, Start Position, Length, and so on are irrelevant, because no ASCII file is created.

If required, to implement optimizations, you can move conditions from the Trigger to the Exchange scheme. For example, you can create a range for batch line 20 ( tdsls400) on the corg (origin) column to only include sales orders created by means of EDI. This reduces the number of XML events that the Exchange module creates. Note, however, that the Exchange export cannot filter on action type, in this example, only include inserts, skip updates, and deletes.

To perform the implementation, you must customize the function(s) that check the credit limit of a Business Partner, which is used in the sales order related program scripts. The customization adds a check to see whether 80 percent of the credit limit is exceeded. If so, the function creates an event and invokes a trigger.

If the trigger you invoke is not in use for any other events, no conditions must be defined. The action that you must take is to create a file that contains the XML event.

Assume that a library exists that contains a function to check the credit limit. Further assume that the following variables are available in that function:

The original version of the library function contains the following code:

if new.credit.in.use > credit.limit then
        return(true) | credit limit exceeded
    else
        return(false) | credit limit not exceeded
endif

In a customized version of library, if the usual credit limit check is passed, the 80 percent check is carried out:

if new.credit.in.use > credit.limit then
        return(true) | credit limit exceeded
    else
        if new.credit.in.use > 0.8 * credit.limit and
           old.credit.in.use <= 0.8 * credit.limit
        then
            generate.credit.trigger(invoice.to.bp,
                        order.number,
                        credit.limit,
                        old.credit.in.use,
                        new.credit.in.use)
        endif
        return(false) | credit limit not exceeded
endif

At the end of the DLL, the following function is added:

function generate.credit.trigger(
            domain  tccom.bpid  i.invoice.to.bp,
            domain  tcorno  i.order.number,
            domain  tcamnt  i.credit.limit,
            domain  tcamnt  i.old.credit.in.use,
            domain  tcamnt  i.new.credit.in.use)
{
#pragma used dll odatrgapi
#pragma used dll odatrgevent

#define MY_TRIGGER  "credit"
#define ERR_IF_NONZERO(value)
^           if value <> 0 then
^               | here some error logging can be implemented, 
^               | for example
^               return
^           endif

    long    event       |tree containing trigger event
    long    retl            |return value to be checked
    string  error.mess(256) |error message from trigger
    string  error.details(256)  |error details from trigger

    |add event to trigger
    retl = datrgevent.simpleevent.create("Customer", 
                    "creditLimitIsNear", event)
    ERR_IF_NONZERO(retl)
    retl = datrgevent.simpleevent.set.value(event,
            "customerID", i.invoice.to.bp)
    ERR_IF_NONZERO(retl)
    retl = datrgevent.simpleevent.set.value(event,
            "orderNumber", str$(i.order.number))
    ERR_IF_NONZERO(retl)
    retl = datrgevent.simpleevent.set.value(event,
            "creditLimit", str$(i.credit.limit))
    ERR_IF_NONZERO(retl)
    retl = datrgevent.simpleevent.set.value(event,
            "creditInIse", str$(i.new.credit.in.use))
    ERR_IF_NONZERO(retl)
    retl = datrgevent.simpleevent.set.old.value(event,
            "creditInUse", str$(i.old.credit.in.use))
    ERR_IF_NONZERO(retl)

    |invoke trigger
    retl = datrgapi.trigger.do(MY_TRIGGER, event, 
                    error.mess, error.details)
    ERR_IF_NONZERO(retl)
}

In the trigger conditions, you do not have to check the class or table code. If a single trigger was used for multiple classes, you must include the class condition, and you must have the same action performed for each class.

The following conditions are defined:

Trigger wf_salesorder:

Trigger wf_inventory:

Trigger wf_creditlimit will not have any conditions specified, because the conditions are checked in the application.

For each trigger, a create XML file action is specified. The local path, file transfer program, and target path are defined.

Additionally, if required, a transformation script is defined that translates the generic event into an event that the workflow engine can understand.

The minimum requirement will likely be simply to rename the event type into a specific event to enable the workflow engine to detect what event occurred. Note that the class and standard event type are insufficient. The event type will always be Create, Change, or Delete, and the class is not unique because two changes on the same table/class can result in two different workflow processes. If you do not rename the event, the workflow engine must duplicate the conditions as defined for the triggers.

In addition, the attributes must be renamed to UDAs that the workflow engine knows. The previous values can be moved to give the values a unique name. For more information, refer to "XML used at runtime," later in this chapter for examples.

Finally, rather than use the standard event structure, the transformation script can build up a new event structure.