Extend and tune your flow configuration > Post-processing configuration

Post-processing configuration

You can perform post-processing commands on each inbound message immediately after Interchange has consumed, processed and written it to an application delivery. You also can execute post-processing commands after sending messages to partners. Interchange 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 Interchange 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 or clone partner profiles in a peer network environment.

Interchange 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. Interchange 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 Interchange 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 and attributes.

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 Interchange 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

Post-processing events

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

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.