Create Trigger

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:

Type

eService Trigger Program Parameters

Name

PolicyECPartStateApprovedPromoteAction

Revision

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 are 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.

You can in a custom argument include the ID of the current business object by using the macro $(OBJECTID).

Example:

Attribute eService Program Argument 4 with value CustomObjectId=$(OBJECTID).

The reason why the macro in this case is using a different format than normal is to avoid interfering with the emxTriggerManager logic.

Skip ID Validation on TIF Server

Per default the TIF server will validate the source object id in the Job request, if present, when TIF is picking up new jobs from an ENOVIA/3DEXPERIENCE queue. If the ID is referring to a non-existing or invalid object / relationship, the job is marked as failed.

In some cases it may be of interest to be able to perform some custom action although the object does not exist anylonger. To by-pass this check, then you can add the following job parameter:

tif.skipIdValidation=true

Note that when this id validation is skipped, TIF cannot resolve the source object information since that potentially could cause an exception when trying to select data from an invalid object identifier.

To also include a validation of the ID and update the source object identifier correctly, you can add this Job Event listener:

<Events>
    <Validate>
        <ValidateExists />
    </Validate>
</Events>

The <ValidateExists> element can be customized using the below attributes:

<ValidateExists resolution="Invalid source object"
                failIfNotExists="true"
                resolve="true"/>

This event listener will per default if the object does not exist, mark the job as failed AND resolved with the resolution set to "Source object invalid".