Generic MMDs

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

For messages consumed from partners and delivered to the back end, Activator generates MMDs for the consumed documents. When you create the file system delivery, you must select the file system with message metadata option to have Activator generate the MMDs.

For messages originating in the back end, 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 application pickup.

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 ebXMLmessage protocol, refer to the specific protocol in Work with protocols, formats and standards. 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:

  • ebXML support

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

Outbound messages

You must decide what message metadata accompanies payloads consumed from the back end and forwarded to trading partners. Custom metadata values can be included. Activator parses and adds metadata elements 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 custom metadata, there are some minimum requirements:

  • The value of the protocol attribute of the Message Metadata 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.
  • 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.

Note   Use the optional SubjectHeader attribute to set the subject line of outbound messages sent via AS2 message protocols. For outbound messages, the subject line value can be set by adding SubjectHeader as a message attribute on application pickup exchanges or adding it to outbound MMDs. Activator sets the attribute and value on inbound email and EDIINT messages.
  • 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 partner or community.
  • Metadata name="To" – The name of the receiver partner or community.
  • 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
    • HTTP
    • FTP
    • 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 application delivery via JMS. Your community must use a file system with the file system with message metadata option selected, 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

Related Links