You set up and manage application pickups and deliveries in communities. An application pickup specifies how Activator retrieves business documents from a back-end system for packaging and sending to partners. An application delivery specifies how Activator routes documents received from partners to a back-end system.
Application pickups and deliveries do not use message protocols like trading deliveries do. When you set up an application pickup or delivery, you simply select a transport method and messages are moved without packaging, encryption, or compression.
The following table lists the available transports for application pickups and deliveries. These are the supported application exchanges.
Transport |
Application |
Application |
|
|
|
File system with message metadata (see File system integration) |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Web Services API client (see Web Services API pickup and delivery configuration) |
|
|
Web Services API server (see Web Services API pickup and delivery configuration) |
|
|
|
|
A community needs at least one application pickup and one application delivery, but can have multiple application pickups and deliveries.
The file system with message metadata transport is configured the same as File system transport configuration, but is for when a community wants to produce message metadata documents to file system inbound integration. See these topics for information about using MMDs:
Application pickups and deliveries can be configured with conditions specifying senders and receivers, metadata attributes and rules for routing inbound messages to various integration exchanges. See: From address and To address tabs, Message attributes tab and Application delivery settings.
Multiple application deliveries
Community trading pickups and partner deliveries
If there are multiple application pickups, Activator checks all for outbound messages. What’s more, all communities share all application pickups. Activator determines the sender by parsing for the “from” address in the document. Alternately, you can set a fixed value for the “from” address so that all messages picked up from a particular exchange have a single community as the sender. For more information see From address and To address tabs. See Application pickups.
If a community has multiple application deliveries for routing received messages to back-end systems, you can set rules that specify when to use the deliveries based on conditions. This is useful when you want to route certain messages to a particular delivery. For configuration details see Add an application delivery
For example, when you set up default file system application deliveries, Activator uses MIME type rules to allocate inbound messages by document type (see Set up default file system integration).
To see the application deliveries for a community, click Application delivery on the navigation graphic at the top of the community summary page. The delivery at the top of the list is the default delivery. This means if an inbound message does not meet any of the conditions for other exchanges, the message is routed to this exchange. The following illustration shows an example of a file system exchange (c:\data\ediin
) with MIME rules that only EDI messages are allowed. However, the exchange, as indicated by “OR deliver by default,” also is the default exchange because it is at the top of the list.
If a community has multiple application deliveries, an exchange without delivery criteria is not used unless it is at the top of the list. A way to make sure that inbound message that do not meet the rules for other exchanges are delivered to a single exchange is to add an exchange with no delivery criteria and position it at the top of the exchange list.The following figure shows that a file system exchange is the default to use when inbound messages do not meet the criteria specified by the other exchanges. See Add an application delivery.
The user interface has a simulator for testing whether messages are being routed to the correct integration delivery exchanges. The simulator lets you pretend a community has received a message from a partner via a particular message protocol. You click a test button to see which exchange the community uses to send the “message” to integration.
If you have configured delivery criteria for an integration exchange, the simulator lets you test the configuration.For information about delivery criteria, see Message attributes tab and Application delivery settings.
To open the message simulator, select Trading configuration > Message simulator. There also is a link for opening the simulator page at the bottom of the page that list the integration delivery exchanges for a community. To open the exchange list, click Application delivery on the navigation graphic on a community summary page.
Before using the simulator, you need at least one community profile and one integration delivery exchange for the community. You do not have to add an exchange for the community to receive messages from partners to use the simulator.
The following describes the fields on the simulator page.
To run a test and change configuration information:
The messages produced by the simulator are not real and are used only for testing. Message Tracker does not keep records of simulated messages.