AS4 metadata

Interchange supports a standard set of metadata that can be attached to AS4 messages.

Some of the metadata attributes can be used in Message Metadata Documents (MMDs). Example MMDs are described in this chapter.

Metadata are exchanged between Interchange and a back-end system through the following application transports:

  • JMS (consume from and produce to the back end)
  • File system (consume from the back end)
  • File system with message metadata (produce to the back end)
  • Web services API server (consume from the back end)
  • Web services API client (produce to the back end)

This chapter contains the following sections:

Metadata descriptions

The following table lists and describes the metadata attributes that can be used with AS4 messages. When the attribute can be managed from a Message Metadata Document (MMD), the MMD element name is given.

Metadata attribute MMD element name Description
Standard Metadata
SenderRoutingId From Routing ID of the sender party.
SenderRoutingIdType type attribute in <From> element

ebXML routing ID type of the sender participant.
ReceiverRoutingId To Routing ID of the receiver participant.
ReceiverRoutingIdType type attribute in <To> element

ebXML routing ID type of the receiver participant.
ebXML Metadata
FromRole FromRole

The ebXML from role is used together with the "from" attribute. The role attribute indicates the role the party is playing in the business transaction, such as the "buyer" role.

This attribute is required for AS4 user messages.
ToRole ToRole

The ebXML to role is used together with the "to" attribute. The role attribute indicates the role the party is playing in the business transaction, such as the "seller" role.

This attribute is required for AS4 user messages.
Service Service

References the upper business-level collaborative business process.

This attribute is required for AS4 user messages.
ServiceType type attribute in <Metadata name="Service"> element An option of the service element of the ebXML message. Only required if the trading partners require a "type" in order to properly identify the service.
Action Action

Specifies the action of the overall upper-level business process. An action is typically an individual business transaction of a collaborative business process.

This attribute is required for AS4 user messages.
ConversationId ConversationId

Correlates all messages belonging to a collaborative business process. The conversation ID is required in an ebXML message.

This attribute is required for AS4 user messages.
ebXML.PModeId PModeId Optional attribute that specifies the association of the message with a P-Mode.
ebXML.AgreementRef AgreementRef String value that identifies the agreement that governs the exchange.
ebXML.AgreementRefType type attribute in <Metadata name="AgreementRef"> element Optional attribute that specifies how the sender and receiver interpret the value of the reference.
ebXML.MessageProperty MessageProperty.[PROPERTY_NAME] Defines user-specific properties or meta-data that qualifies or abstracts the payload data.
ebXML.Payload.PartProperty <PartProperty name=[PROPERTY_NAME]> element as child element of <Payload> Defines user-specific properties or meta-data.
ebXML.Payload.SchemaVersion[NUM] <Schema version=[SCHEMA_VERSION] …> element as child element of <Payload> Defines the version of schema(s) that can be used for validating the document identified by PartInfo element.
ebXML.Payload.SchemaNamespace[NUM] <Schema namespace=[SCHEMA_NAMESPACE] …> element as child element of <Payload> Defines the namespace of schema(s) that can be used for validating the document identified by PartInfo element.
ebXML.Payload.SchemaLocation[NUM] <Schema location=[SCHEMA_LOCATION] …> element as child element of <Payload> Defines the location of schema(s) that can be used for validating the document identified by PartInfo element.
Signal-processing Metadata
ebxml.SignalType

SignalType

Value can be any of following :

  • ebXML.PullRequest
  • ebXML.Receipt
  • ebXML.Error

Specifies the type of signal message the message represents.

This attribute is required for AS4 signal messages.
ebXML.Error.Code Error.Code Unique identifier for the ebms error type.
ebXML.Error.Category Error.Category Identifies type of error related to a particular origin. For example: Content, Packaging, Unpackaging, Communication, Internal process.
ebXML.Error.Severity Error.Severity The severity of the error.
ebXML.Error.Description Error.Description Short description of the error.
ebXML.Error.Detail Error.Detail Additional details about the context in which the error occurred.
Pull-related Metadata
message.WaitForPull message.WaitForPull

Default=false.

When set to true, stops a message for being processed in the action tree and moves it to a wait for pull state.

message.WaitForPull.MaxRewindAttempts message.WaitForPull.MaxRewindAttempts

Default=3

Specifies the number of times a message can rewind back to a wait for pull state.
message.WaitForPull.RewindAttempts message.WaitForPull.RewindAttempts Tracks the number of times a message is rewound to a "wait for pull" state.
ebXML.MessagePartitionChannel MessagePartitionChannel Identifies the Message Partition Channel where the message is queued.
AS4.ResponseProcessingExchangePoint AS4.ResponseProcessingExchangePoint Indicates the friendly name of an AS4 trading pickup to correctly apply the business protocol settings when processing response user messages.
AS4.ProcessedUsingExchangePoint ––

For information only. Do not override.

Set on the UM received as response to a pull request when it has been processed using specific exchange point settings.

PollingCycleMaximumRequests PollingCycleMaximumRequests Maximum number of pull requests per cycle.
PollingCycleExecutedRequests ––

For information only. Do not override.

Displays current executed pull request for the current sequence.

Incremented whenever a new pull request is generated in the current polling cycle.
PollingCycleRequestsId ––

For information only. Do not override.

Displays the cycle ID of the polling cycle for a pull request generated from an AS4 polling client exchange.

PollingCycleRequestsExchange ––

For information only. Do not override.

Displays the AS4 exchange point used for polling .
Splitting-related Metadata
SplitMessage SplitMessage

Default=false

When set to "true", triggers AS4 splitting on the message being processed.
FragmentSize FragmentSize

Default= Value of System Property "as4.fragmentSize".

Overrides the global system property "as4.fragmentSize".
SplitCompressionAlgorithm SplitCompressionAlgorithm Defines the type of compression to be applied before splitting the MIME envelope
SplitCompressedMessageSize --

For information only. Do not override.

Specifies the size (in bytes) of the compressed MIME envelope .

Shown in the UI, for internal use, not to be overwritten by customers .

FragmentJoiningInterval ––

Default=Value of Interchange system property "as4.joinExpirationCheck.interval

Specifies the maximum time to expect and process additional fragments after the first fragment is received. Used to override the global system property "as4.joinExpirationCheck.interval"

ebXML.FragmentCount ––

For information only. Do not override.

Specifies the number of fragments the MIME envelope was fragmented into.
ebXML.FragmentNum ––

For information only. Do not override.

Specifies the current fragment's sequence .

ebXML.MessageSize ––

For information only. Do not override.

Indicates the size (in bytes) of the message after reassembly .

AS4.SplitterAction ––

For information only. Do not override.

Used to display split status in tracker for the fragmented user message.

Metadata used by processing
UserMessage ––

For information only. Do not override.

Displays the copy of UserMessage element.
NonRepudiationInformation ––

For information only. Do not override.

Displays the copy of NonrepudiationInformation element .

Metadata to control message validation
CheckAllCommunitiesForDuplicate ––

Default=true

Enables duplicate checks across communities or within a community
SkipSchemaValidation ––

Default=true

Enables ebXML schema validation on the received message. Since ebXML schemas generally have few issues, schema validation is skipped default.

Required metadata

According to AS4 specifications, an AS4 user message must have, as a minimum, the following four metadata attributes:

  • FromRole – identifies the authorized role of the party who is sending the message.
  • Service – is a string that identifies the service that acts on the message and it is specified by the designer of the service.
  • Action – is a string that identifies an operation or an activity within a Service.
  • ToRole – identifies the authorized role of the party who is receiving the message.

If any of the attributes are missing, the AS4 message will fail to package. You can assign the values of your choice to these metadata attributes. The AS4 standards provide the following default values:

  • FromRole = http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/ns/core/200704/initiator
  • ToRole = http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/ns/core/200704/responder
  • Service = http://docs.oasis-open.org/ebxml-msg/as4/200902/service
  • Action = http://docs.oasis-open.org/ebxml-msg/as4/200902/action

For a detailed description of AS4 metadata attributes, see AS4 metadata.

When you develop Agreements, there are two common methods that you can use to attach metadata attributes to the messages you handle:

  • Use a map to set metadata attributes

Message Metadata Documents (MMD)

Interchange supports AS4 business processes using Message Metadata Documents (MMDs) as the interface between it and the back-end. MMDs are XML documents that point to an AS4 document on a file system, and contain information Interchange uses to process documents.

You can use MMDs to initiate AS4 message push and pulls, as well as to build and deposit AS4 messages into message queues for client pull consumption.

MMDs are used only with file system integration, although the same type of metadata are transported when integration transports such as JMS or web services API are used.

MMD examples

Example 1: Initiate a push

The following is an example of an MMD for initiating an AS4 push to a remote partner.

In this MMD:

  • Push sender is: AS4BUYER
  • Push receiver is: AS4SUPPLIER
  • Pushed payload file is: PurchaseOrder.xml
  • Location of the payload file on the sender network is: C:\Axway\ Interchange \common\data\

When Interchange consumes this file from a back-end file directory, it recognizes that it is an AS4 MMD (from the ebXML v3 protocol attribute) and uses the file content information to build an outbound AS4 user message to the receiving participant.

Example 2: Generate a queued message for pulling

The following is an example of an MMD that generates a message to a client pulling queue.

In this MMD:

  • Pull sender is: AS4BUYER
  • Pull consumer is: AS4SUPPLIER
  • Note: A message in the pull queue does not have to contain sender/receiver information. A message can be queued for consumption by any client that is authorized for the MPC. By entering consumer (receiver) information, you restrict pulling to a specific client partner.
  • Payload files are: BusinessDocument_1.xml located in the SOAP Body and BusinessDocument2.xml attached to the SOAP message.
  • Location of the payload files on the pull sender network is: C:\Axway\ Interchange \common\data\
  • The AS4 MPC attribute is commented out. Since it is not explicitly specified, the default channel will be used.

When Interchange consumes this file from a back-end file directory, it recognizes that it is a message intended for a client pulling partner (from the "message.WaitForPull " metadata attribute). Interchange then builds a message which it puts in a "wait for pull" message holding queue, to be polled by a partner.

Example 3: Initiate a pull request

This is an example of an MMD that could be used to manually initiate a pull request (for example, in place of a scheduled polling event).

In this MMD:

  • Pull server/sender is: AS4SUPPLIER
  • Pull requester/consumer is: AS4BUYER
  • Message is signal type: PullRequest
  • MPC is the default, specified by the default value:  http://docs.oasis-open.org/ebxmlmsg/ebms/v3.0/ns/core/200704/defaultMPC.
  • Note: Alternatively, you could remove this line, and Interchange would automatically select the default implicit (empty) MPC.

Example 4: Initiate a receipt send

This is an example of an MMD that could be used to manually initiate a the sending of a receipt to a partner (for example, in place of an automatically-generated receipt setting in the configuration).

In this MMD:

  • Receipt sender is: AS4SUPPLIER
  • Receipt requester is: AS4BUYER
  • Message is signal type: Receipt

Example 5: Initiate an error message send

This is an example of an MMD that could be used to manually initiate a the sending of a processing error message to a partner.

In this MMD:

  • Error message sender is: AS4SUPPLIER
  • Error message receiver: AS4BUYER
  • Message is signal type: Error

Related topics

Related Links