File system integration

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.

Set up default file system integration

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.

  1. At the bottom of a community summary page, click Add default application exchanges to open the Add default application exchanges wizard.
  2. Click Next.
  3. Use the suggested top-level directory for the default directories or specify one (for example in Windows, 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.
  4. Click Finish to create the application exchanges and the file system directories.
  5. To check the application exchanges, click Application delivery or Application pickup on the navigation graphic at the top of the community summary page.
  6. Note: For additional setup tasks based on your exchanges, see binaryout exchange and xmlout exchange.
  1. You can check the file system for the directories that have been created. The following is an example of the default file system directory structure on Windows.
  2. c:\

    data\

    binaryin

     

     

    binaryout

     

     

    ediin

     

     

    ediout

     

     

    xmlin

     

     

    xmlout

  1. Directories with a suffix of “out” are where your back-end system writes messages for Activator to pick up and then package and send to partners.
  2. Directories with a suffix of “in” are where Activator routes messages from partners based on the content MIME type of the inbound messages. For inbound binary messages, Activator takes the further step of creating binaryin subdirectories named for the routing IDs of the sender and receiver. Activator creates these directories upon parsing sender and receiver information in the headers of inbound binary messages. The following is an example of the binaryin structure on Windows. You do not have to create these subdirectories yourself.
  3. c:\

    data\

    binaryin\

    sender A ID\

    receiver ID

     

     

     

    sender B ID\

    receiver ID

     

     

     

    sender C ID\

    receiver ID

binaryout exchange

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.

xmlout exchange

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:

  1. Click Application pickup on the navigation graphic at the top of the community summary page.
  2. Click the xmlout file system exchange to open the maintenance page.
  3. Select the from address tab.
  4. Make sure the following are selected:
  5. Always parse for the address
  6. If the document is XML, use XPaths to locate the address
  7. Select a document type or click XPath wizard and point the wizard to the sender address in a sample XML document.
  8. Click Finish to close the wizard.
  9. On the from address tab, click Save XPaths and Save changes.
  10. Select the to address tab and do the same procedure to select the receiver XPath.

Related topics

Use file system to set metadata values

Post-processing to route inbound messages

Multiple application deliveries

Use file system to set metadata values

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.

Related topics:

Set up default file system integration

Post-processing to route inbound messages

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.

@echo off

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.

 

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

 

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

rem directory.

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

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

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

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

 

echo Moving %3\%4 to %destdir%

move %3\%4 %destdir%

Related topics:

Set up default file system integration

Use file system to set metadata values