Triggers

Instruction

The Trigger Instruction field contains either the LOG_MESSAGE or the executable/script path to be invoked, as well as arguments to be passed to the invoked executable/script.

Trigger instructions are based on Java Formatted Strings. The following link provides more information on formatted strings.

http://java.sun.com/j2se/1.5.0/docs/api/java/util/Formatter.html#summary

Trigger Types

Triggers are available in 3 types {LOG, EXEC, SYNC_EXEC}

• LOG - The instruction value is displayed as a log message in the logging system with the chosen arguments included when formatting.

• EXEC - The instruction value is considered a system executable and will be invoked as such.

• SYNC_EXEC - Differs from EXEC in the way it handles STDOUT. It is assumed, when setting SYNC_EXEC, that the executable will return a valid XML Object which is considered a synchronous return if the associated P-Mode has an MEP Binding of type sync.

It is critical to note the following when creating EXEC and SYNC_EXEC triggers:

1. Any system executable that is in the environment PATH is invokable.

2. The trigger executable MUST either be in the PATH or MUST be fully qualified. The executable must have execute mode set on UNIX systems.

3. The executable MUST return in a reasonable amount of time

4. The executable MAY return error messages to STDERR which will be displayed if the return value is greater than 0.

Executable Type

When Trigger Type EXEC or SYNC_EXEC is selected then an Executable Type should be selected. EXTERNAL is used by default if this argument is not provided.

• JEP - Instructs the Trigger mechanisms to utilize the built in JEP (Java Embedded Python) Script Engine. JEP is a JNI implementation of CPython, allowing a native interface to all CPython libraries.

• JYTHON - Instructs the Trigger mechanisms to utilize the built in Jython (Java Python) Script Engine. Jython is a Java implementation of Python, allows for a simple interface to Python but is limited to the core Python mechanisms. Utilizing third party libraries and imports is restricted when using Jython

• EXTERNAL - Instructs the Trigger mechanisms to invoke a system process enabling maximum compatibility however resulting in a high performance overhead while creating the process.

Trigger Points

Various points exist at which an assigned trigger will be invoked. These are identified as follows

• SEND. Triggers when a message is sent from the server or via a synchronous return as provided by a SYNC_EXEC trigger.

• RECEIVE. Triggers when a message is received on the server via a Pull Request or an Incoming Request.

• RESPONSE_SENT. This trigger fires after writing final signal response (Receipt or Error) for an incoming user message. It may be used for implementing twoWay MEPs by sending response for the 2nd leg of the twoWay MEP by using the messageID argument as the refToMessageID using the '-r' command line argument to the FMS AS4 Light Client. The Configuration Trigger arguments are as follows

  \ \ <tg:Trigger> \ <tg:identifier>SendResponse</tg:identifier> \ <tg:enabled>true</tg:enabled> \ <tg:type>SynchronousExecutable</tg:type> \ <tg:location>RESPONSE_SENT</tg:location> \ <tg:instruction>run/trigger/Response.sh %1$s %2$s %3$s %4$s %5$s %6$s %7$s \ \ %8$s %9$s %10$s %11$s %12$s %13$s</tg:instruction> \ \ <!-- messageID of the receipt or error return else nothing --> \ <tg:providedArguments>messageID</tg:providedArguments> \ <tg:providedArguments>service</tg:providedArguments> \ <tg:providedArguments>action</tg:providedArguments> \ <tg:providedArguments>processingMode</tg:providedArguments> \ <tg:providedArguments>event</tg:providedArguments> \ <tg:providedArguments>senderIdentifier</tg:providedArguments> \ <tg:providedArguments>recipientIdentifier</tg:providedArguments> \ <tg:providedArguments>replyMessageID</tg:providedArguments> \ <tg:providedArguments>conversationID</tg:providedArguments> \ <tg:providedArguments>agreementRef</tg:providedArguments> \ <tg:providedArguments>senderRole</tg:providedArguments> \ <tg:providedArguments>recipientRole</tg:providedArguments> \ <tg:providedArguments>submitted</tg:providedArguments> <!-- signal timestamp else nothing --> \ <tg:providedArguments>payload</tg:providedArguments> <!-- response signal if available else "null" --> \ <tg:executionType>External</tg:executionType> \ </tg:Trigger> \ \

• PULL_REQUEST. Triggers when a message is placed in an inbox for a specified MPC.

• PULL_REQUEST_EXPIRED. Triggers if a Pull Request life time has expired at the time of collection. The life time is defined by the retry interval multiplied by the amount of retries as defined in the configuration.

• ACK. Triggers when an Acknowledgement is returned to the server either as a response (synchronous) or a callback (asynchronous).

• NACK. Triggers when an Error is returned to the server either as a response (synchronous) or a callback (asynchronous).

Arguments

The system provides a list of arguments that could be available when a trigger is invoked. Certain arguments are only available at specific Trigger Points, if a specified argument is not available at the Trigger Point then a list of valid arguments will be logged.

In addition to the system provided arguments it is possible to specify custom arguments. These custom arguments are matched against the MessageProperties of a provided ProcessingMode Event.

When an embedded trigger type is selected such as JYTHON, JEP, or JSON-RPC the arguments (both provided and custom) will be set as environment variables within the embedded system.

Arguments may be referenced using the instruction field. The instruction field is interpreted using Java Formatted Strings and the supplied arguments. Arguments are referenced using the following string %1$s where the 1$ is the argument number (seen next to each argument) and the s denotes the value is a string.

The following link provides more information on formatted strings:

https://docs.oracle.com/javase/1.5.0/docs/api/java/util/Formatter.html#summary