The connection to a back-end file system is a popular method for Activator to pick up messages to send partners and deposit messages received from partners. The following topics describe some file system integration management methods.
Use this procedure to create default file system application exchanges for all document types (EDI, XML and binary). The default method creates three application pickups and three application deliveries.
c:\data
). You can type the path or click the Browse button to select a directory. Activator creates the top level directory if it does not exist, as well as the document type-specific sub-directories.
c:\ |
data\ |
binaryin |
|
|
binaryout |
|
|
ediin |
|
|
ediout |
|
|
xmlin |
|
|
xmlout |
c:\ |
data\ |
binaryin\ |
sender A ID\ |
receiver ID |
|
|
|
sender B ID\ |
receiver ID |
|
|
|
sender C ID\ |
receiver ID |
Once the default integration exchanges have been created, there are additional setup tasks for some exchanges. The following describes binary exchanges. If applicable, see xmlout exchange.
Creating binaryout subdirectories named for the routing IDs of the sender and receiver is recommended. These subdirectories can be made to correspond to metadata attributes that already have been set up for you. This makes it possible for Activator to determine the sender and receiver of binary messages.
In the file system, create binaryout subdirectories named for the routing IDs of your community and of each partner to whom you plan to send binary messages. The following is an example of the structure on Windows.
c:\ | data\ | binaryout\ | sender ID\ | receiver A ID |
receiver B ID | ||||
receiver C ID |
Your back-end system needs to write outbound messages to the lowest level binaryout directory for a specific community and partner pair. For example:
c:\data\binaryout\senderID\receiver A ID
Activator, upon picking up a message, uses the names of the sender and receiver routing ID subdirectories as values for sender and receiver metadata attributes. How this works is explained in Message attributes tab.
Once the default integration exchanges have been created, there are additional setup tasks for some exchanges. The following describes xmlout exchanges. If applicable, see binaryout exchange.
Setting up sender and receiver XPaths is recommended. This enables Activator to locate the sender and receiver information in outbound XML messages. This is not applicable for ebXML messages.
BizTalk from and to XPaths are set up by default. If you need XPaths other than BizTalk, do the following:
Use file system to set metadata values
Post-processing to route inbound messages
Multiple application deliveries
You can use a directory hierarchy in your file system that dictates values of metadata elements associated with messages picked up through file system exchanges. For instance, the directory hierarchy can specify a document’s sender, receiver or values for any number of other metadata elements.
For configuration details see Message attributes tab.
Set up default file system integration
Post-processing to route inbound messages
You can use a post-processing script to route inbound binary messages and inbound messages based on MIME type. The following is a sample script for Windows that examines a message’s content to determine where it should be moved after it is unpackaged. The script uses c:\dest as a sample root directory for receiving inbound messages; you should replace this with a location suitable for your installation. If you are running a multiple computer cluster, the destination should be a directory on a shared network drive.
In the sample script, Activator examines a message’s MIME type. If the MIME type is known, the message is routed to an appropriate directory. If the MIME type is not known, the message is considered binary and routes to a directory based on the community routing ID and the partner routing ID.
You must manually create all target directories before using the post-processing script.
|