Use generic MMDs

In file system integration with a back-end system, Activator supports use of message metadata documents (MMDs) as the interface between it and the back-end. MMDs are XML documents that point to documents on a file system and contain information Activator or a back-end system uses for processing.

For messages received from partners and delivered to integration, Activator generates MMDs for the inbound documents. You must use the file system with message metadata integration delivery option to have Activator generate MMDs for inbound documents.

For outbound messages, your back-end system must generate the MMDs that tell Activator where to pick up the documents to send to partners. The MMDs must be written to a file system integration pickup directory.

For information about setting up file system pickup and deliveries, see File system transport configuration.

Depending on the message protocol your community uses to exchange messages with partners, different rules apply for using MMDs. For most trading protocols, follow the guidelines in this topic. However, if you trade via the ebXML, RosettaNet or web services message protocol, see the chapter or topic for that protocol. The MMDs described here are known as generic MMDs because they can be used in conjunction with most message protocols, except the three noted.

See the following for information about using MMDs with these protocols:

• AS4 metadata
• Web Services message protocol
• ebXML
• RosettaNet

The following topics describe how generic MMDs are used for outbound and inbound messages.

Outbound messages

You must decide what message metadata accompanies outbound payloads. Any arbitrary metadata values can be included. Metadata elements are parsed and added as message attributes to a consumed message. The following is an example:

<Metadata name="MyItem">SomeValue</Metadata>

In this example, an attribute named MyItem with the value SomeValue would be added to the created message.

In addition to arbitrary metadata, there are some minimum requirements:

• The value of the protocol attribute of the MessageMetadata Document element must be generic. The value of the protocolVersion attribute does not matter; Activator ignores it.
• The MMD must specify values for From and To. From is a community routing ID and To is a partner routing ID.
• For each document to pick up, the MMD must specify a payload ID, Mime content ID and the file path for the document. The MMD can specify multiple documents.

The following describes elements for a generic MMD for an outbound message. All except RemovePayloadAfterProcessing are required.

• MessageMetadataDocument – This element has the following attributes.
  • documentId – A unique identifier for the MMD.
  • protocol – Always should be generic.
  • protocolVersion – The value of this attribute can be anything. Activator ignores it.
• Metadata name="From" – The name of the sender. This is a community routing ID.
• Metadata name="To" – The name of the receiver. This is a partner routing ID.
• MessagePayloads – One or more payloads can be listed under this element.
• Payload id – A unique identifier for the outbound document. This element has the following children.
  • MimeContentId – An identifier of the payload content.
  • MimeContentType – The MIME type of the payload. For example, application/xml.
  • Location type – The path and file name of the payload. Payloads can be on a file system or an HTTP or FTP server, as the following examples illustrate:
  • File system
    

  • <Location type="filePath">C:\smallxmlPO.xml</Location>

  • HTTP
    

  • <Location type="xs:anyURI">http://www.oasis-open.org/committees/ebxml-cppa/schema/cpp-cpa-2_0.xsd</Location>

  • FTP
    

  • <Location type="xs:anyURI">ftp://acme:acme@cfoster-dell.cyclonecommerce.com:4021/mailbox/foo.dat</Location>

  • In the FTP example, acme:acme in the URL represents the user name and password for connecting to the FTP server. Using an email address as the password is not supported.
  • RemovePayloadAfterProcessing – Indicates (true or false) whether Activator deletes the payload from the file system after processing the message. (MMDs always are deleted after processing.)
  • Use of this element is optional. If not used, the payload is not deleted, which is the same behavior as using the element with a value of false. If RemovePayloadAfterProcessing is true, payloads are deleted after being picked up.
  • This also works for the resubmit case in which payloads are retrieved from the backup directory.

You can build an MMD based on the example shown here which demonstrates the minimum requirements. The example of generic MMD for outbound message follows:

Inbound messages

Each MMD contains all metadata associated with the document received from the partner. This is similar to how metadata are handled for integration delivery via JMS. Your community must use a file system with message metadata integration delivery option to have Activator generate MMDs for inbound documents.

The following code is an example of a generic MMD generated by Activator for an inbound message:

Related topics

• File system transport configuration
• AS4 messages
• Web Services message protocol
• ebXML
• RosettaNet