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.
|
%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:
|
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.
Related topics