Extend and tune your flow configuration > Post-processing configuration details

Post-processing configuration details

You can perform post-processing commands on each inbound message immediately after Activator has received, 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. Relative paths are preferred if you export partner profiles files for back-up purposes.

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`
UNIX	`/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 <install directory>\conf. Activator checks this file to determine valid metadata for post-processing. The parameter numbers are shown for Windows and UNIX.

Windows	UNIX	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 integration 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.

See Post-processing configuration details

Adding post-processing elements

You can use other post-processing elements than those listed in the table in Post-processing message metadata.

Add the metadata elements you want to shellscriptmetadata.xml in <install directory>\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 server 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.
UNIX	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.

@echo off

echo on

rem

rem Batch file to move file to directory based on received files

rem MIME type.

rem set the default destination directory to

rem c:\dest\binary\ReceiverRoutingId\SenderRoutingId.

rem Where ReceiverRoutingId is the Routing Id of the Receiving Community,

rem and SenderRoutingId is the Sender Routing Id of the Sending Party.

REM set destdir=\\win03.cyclonesoftware.com\haboob\binary\%2\%1

set destdir=c:\dest\binary\%2\%1

rem If the MIME Type of the content is known, then override the destination

rem directory

rem if '%7' == 'application/EDI-X12' set destdir=\\win03.cyclonesoftware.com\haboob\x12

rem if '%7' == 'application/EDI-X12' set destdir=c:\dest\x12

if '%7' == 'X12' set destdir=c:\dest\x12

if '%7' == 'application/EDIFACT' set destdir=c:\dest\edifact

rem if '%7' == 'application/xml' set destdir=c:\dest\xml

if '%7' == 'XML' set destdir=c:\dest\xml

echo Moving %3\%4 to %destdir%

move %3\%4 %destdir%

Script example for UNIX

The following is an example of a post-processing script for UNIX. 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.

#!/bin/sh

# $Id: UNIXpostprocess.sh to test post-processing.

# This shell script does two things. It moves the received file

# to another directory. Then it appends into a log file all the

# information that CI makes available about that file.

mv "$3"/"$4" /home/cyclone/tmp

echo -----newfile info----- >> /home/cyclone/tmp/postprocess.log

date >> /home/cyclone/tmp/postprocess.log

echo The Sender Routing Id is "$1" >> /home/cyclone/tmp/postprocess.log

echo The Receiver Routing Id is "$2" >> /home/cyclone/tmp/postprocess.log

echo The Production directory is "$3" >> /home/cyclone/tmp/postprocess.log

echo The Production Filename is "$4" >> /home/cyclone/tmp/postprocess.log

echo The Consumption Filename is "$5" >> /home/cyclone/tmp/postprocess.log

echo The Control Id is "$6" >> /home/cyclone/tmp/postprocess.log

echo The Content MIME Type is "$7" >> /home/cyclone/tmp/postprocess.log

See Post-processing configuration details.

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 configuration details.

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.

See Post-processing configuration details.