23 August 2013
When adding triggers into a BPS/AEF based application, one typically do this by adding business object(s) of type eService Trigger Program Parameters.
This program then follows a common naming convention (also revision) in order to be registered correctly. For example registering a trigger program that should react when a Part with policy "EC Part" is released, the Type / Name / Revision for this trigger program should be:
eService Trigger Program Parameters
PolicyECPartStateApprovedPromoteAction
TransferDataToERP
The attributes of this object should as a minimum be the following:
| Attribute | Value |
|---|---|
eService Program Name |
TIFTrigger |
eService Method Name |
newJob OR newExclusiveJob |
eService Program Argument 1 |
${OBJECTID} |
eService Program Argument 2 |
tvc:jobcfg/NameOfJob.xml |
| Use "newExclusiveJob" as "eService Method Name" if you want to trigger the job only if there is no other uncompleted job triggered with the same combination of object id and job configuration. |
The first argument must be the object-id of the object in question. The use of the macro ${OBJECTID} is replaced at runtime with the actual id by the BPS/AEF trigger framework.
The second argument is the name of the job configuration to be used for this integration job. Note that this is the name of a configuration that exists on the TIF server. Note that this is a standard TVC resource file and you can arrange your configurations into packages/domains in the same way as you do with other TVC configuration files. You may omit the tvc:jobcfg/ part of the name, TIF will automatically assume that this is a job configuration and use the default namespace.
You may provide more arguments on this trigger, however, that is not required. These optional parameter/arguments are described below:
| Attribute | Value |
|---|---|
eService Program Argument 3 |
<queue name> |
eService Program Argument 4 |
custom_arg_1=value_1 |
eService Program Argument 5 |
custom_arg_2=value_2 |
eService Program Argument 6 |
custom_arg_3=value_3 |
The "3rd argument" contains the name of the queue, which this integration job will be bound to. Note that you may setup several queues and configure the TIF server to listen on these queues. There might be several different reasons for setting up several queues, one could be to distribute the load another could be to use different queues for different tasks and setup several TIF server instances where each of these are listening to different queues.
If you want to use the default queue, you should leave this field empty (although the name of the default queue is "tif:default:queue").
You may use the macro ${SITE} as a part of the queue name. This will then resolve to the current user’s default site as obtained via the MQL call: print person <name> select site dump
|
Any argument at position 4 or greater are so called custom arguments that is passed further to TIF. Note that the format of the value for these attributes must follow the naming convention "<name> = <value>". Depending on what integration job you are processing, these custom parameters may be used in various places. For now, it’s just enough to remember that this possibility exists.