Post-processing of consumed messages

This topic comprises the following sections:

About post-processing

You can perform post-processing commands on each inbound message immediately after Activator has consumed, processed and written it to an application delivery. You also can execute post-processing commands after sending messages to partners. Activator can initiate any executable or batch file or script you specify. The batch file or script is applied to all messages passed through the exchange that calls it. Batch files or scripts can be used with several or all application deliveries or partner deliveries, but they must be called separately. You cannot specify a global batch file or script.

The post-processing script must be on a drive that Activator can access and has permission to execute.

There are two places in the user interface where you can enter the name of a post-processing script.

  • On a community summary page: Click Application delivery on the navigation graphic at the top of the page. Then click the name of an application delivery to open the maintenance page. Click the Advanced tab. Type the path for the script file in the post-processing script field. Click Save changes.
  • On a partner summary page, click Partner delivery on the navigation graphic at the top of the page. Then click the name of an outbound transport to open the maintenance page. Click the Advanced tab. Type the path for the script file in the post-processing script field. Click Save changes.

When entering the path for a post-processing script in the user interface, we recommend using a relative path rather than an absolute path, and that the path is at a secure location on the file system. For upgrade purposes, we recommend that you use “../site/bin”. To maintain system security, this script path is kept in filereg.xml. The entry called “postProcessingScriptsPath” is the root folder where scripts are assumed to be kept. You can change this location if you desire. Or, if system security is not critical, and want to put your scripts in many different places, you can remove the entry from filereg.xml. Note that the UI will let you define any path for the script, but at trading time the scripts won’t run and an error will be logged if the script resides outside of the path specified in filereg.xml.

Activator by default passes seven items of message metadata to the post process. Your script can use any or all of them. An example of the syntax of a command that is executed against an inbound message is:

Windows

c:\directoryname\myfile.bat

Linux

/directoryname/myscript.sh

Post-processing message metadata

The default message metadata for post-processing are described in the following table. These match the default post-processing metadata elements in the shellscriptmetadata.xml file in <Activator_install_directory>\Activator\conf. Activator checks this file to determine valid metadata for post-processing. The parameter numbers are shown for Windows, and Linux.

Windows

Linux

Message metadata

Description

%1

$1

SenderRoutingId

The routing ID of the sender of the message.

%2

$2

ReceiverRoutingId

The routing ID of the receiver of the message.

%3

$3

ProductionUrl

The path of the file if the message was written to a File System application delivery exchange. Otherwise, it is the URL of the destination.

%4

$4

ProductionFilename

The file name used when Activator wrote the file.

%5

$5

ConsumptionFilename

The file name included in the MIME header, probably the original file name from the sender, if the message was EDIINT. Otherwise, the name of the file as when retrieved from the file system or FTP server.

%6

$6

EdiControlId

The control ID of an EDI message. Otherwise, the ID is XML or BINARY

%7

$7

DocumentClass

The document class of the message payload (for example, X12, XML).

If you are writing a post-processing script in Perl, you cannot use $ in the parameter number. You must use $ARGV[n], where[n] is the argument number. For example, in the preceding table, the parameter for SenderRoutingId is $1; for Perl it is $ARGV0 (notice counting starts at zero). Likewise, the parameter for ReceiverRoutingId is $2, but $ARGV1 for Perl.

Add post-processing elements

You can use other post-processing elements than those listed in the table in Post-processing message metadata. Other metadata elements are documented in Message metadata. - getting th

Add the metadata elements you want to shellscriptmetadata.xml in <Activator_install_directory>\Activator\conf. Follow the format as shown for the default elements already in the file. Pay attention to the order in which the metadata elements are listed. This is important for the corresponding parameter numbers.

After editing shellscriptmetadata.xml, restart Activator for the changes to become effective. All post-processing script invocations are affected by changes to this file.

Methods for writing scripts

You can use the following methods for writing post-processing scripts:

Operating system

Languages

Windows

Compiled languages (for example, Java, Visual BASIC, C++, Delphi). Also, .cmd and .bat files.

Linux

Any language. For example, shell script, Java, C or Perl.

Script example for Windows

The following is an example of a post-processing script for Windows. This script re-directs an inbound file to a local directory and writes activity to an external log file. This example is provided solely to illustrate the correct format for such scripts.

Script example for Linux

The following is an example of a post-processing script for Linux. This script re-directs an inbound file to a local directory and writes activity to an external log file. This example is shown solely to illustrate the correct format for such scripts.

Post-processing events

Activator generates the following events when performing post processing.

  • Messaging_Transport_PostProcessing_Initiated – This event is published before the script is invoked.
  • Messaging_Transport_PostProcessing_Completed – This event is published after the script has been invoked.
  • Messaging_Transport_PostProcessing_Failure – This event is published if there was an error invoking the script (for example, script not found).

See Post-processing of consumed messages.

Post-processing points to consider

Consider the following points when performing post processing:

  • There is no feedback from the post-processing script. The standard and error output streams of the process are silently discarded.
  • The return code is not checked.
  • Errors are not published and the document is not rejected if any problems occur within the script.
  • Post processing is not reliable. The script is not retried in case of failure.

Related topics

Related Links