Interchange 5.12 Administrator Guide Save PDF Selected topic Selected topic and subtopics All content 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 Required metadata Message Metadata Documents (MMD) MMD examples Example 1: Initiate a push Example 2: Generate a queued message for pulling Example 3: Initiate a pull request Example 4: Initiate a receipt send Example 5: Initiate an error message send 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. <?xml version="1.0" encoding="UTF-8"?> <MessageMetadataDocument protocol="ebXML" protocolversion="3.0"> <Metadata name="From" type="String">AS4BUYER</Metadata> <Metadata name="To" type="String">AS4SUPPLIER</Metadata> <Metadata name="PModeID>TradePO</Metadata> <Metadata name="FromRole" type="string">http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/ns/core/200704/initiator</Metadata> <Metadata name="ToRole" type="string">http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/ns/core/200704/responder</Metadata> <Metadata name="Service" type="string">POService</Metadata> <Metadata name="Action" type="string">ProcessPO</Metadata> <Metadata name="ConversationId" type="string">trade-po-001</Metadata> <Metadata name="AgreementRef" type="string">Trading-PO</Metadata> <MessagePayloads> <Payload id="12345" packagingLocation="SOAPBody"> <Location type="filePath">C:\Axway\Interchange\common\data\PurchaseOrder.xml</Location> </Payload> </MessagePayloads> </MessageMetadataDocument> 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. <?xml version="1.0" encoding="UTF-8"?> <MessageMetadataDocument protocol="ebXML" protocolversion="3.0"> <Metadata name="From" type="String">AS4BUYER</Metadata> <Metadata name="To" type="String">AS4SUPPLIER</Metadata> <Metadata name="PModeID>TradePO</Metadata> <Metadata name="FromRole" type="string">http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/ns/core/200704/initiator</Metadata> <Metadata name="ToRole" type="string">http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/ns/core/200704/responder</Metadata> <Metadata name="Service" type="string">POService</Metadata> <Metadata name="Action" type="string">ProcessPO</Metadata> <Metadata name="ConversationId" type="string">trade-po-001</Metadata> <Metadata name="AgreementRef" type="string">Trading-PO</Metadata> <Metadata name="message.WaitForPull" type="string">true</Metadata> <!-- <Metadata type="string" name="MessagePartitionChannel">Buyer</Metadata> --> <MessagePayloads> <Payload id="12345" packagingLocation="SOAPBody"> <Location type="filePath">C:\Axway\Interchange\common\data\BusinessDocument_1.xml</Location> </Payload> <Payload id="123456" packagingLocation="Attachment"> <MimeContentId>POAttch1</MimeContentId> <MimeContentType>application/gzip</MimeContentType> <Location type="filePath">C:\Axway\Interchange\common\data\BusinessDocument21.xml</Location> <Schema location=test1 namespace="t1" version="1.1"/> <Schema location=test2 namespace="t2" version="1.2"/> </Payload> </MessagePayloads> </MessageMetadataDocument> 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). <?xml version="1.0" encoding="UTF-8"?> <MessageMetadataDocument protocol="ebXML" protocolversion="3.0"> <Metadata name="From" type="String">AS4BUYER</Metadata> <Metadata name="To" type="String">AS4SUPPLIER</Metadata> <Metadata name="SignalType" type="string">PullRequest</Metadata> <Metadata name="MessagePartitionChannel" type="string">http://docs.oasis-open.org/ebxmlmsg/ebms/v3.0/ns/core/200704/defaultMPC</Metadata> </MessageMetadataDocument> 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). <?xml version="1.0" encoding="UTF-8"?> <MessageMetadataDocument protocol="ebXML" protocolversion="3.0"> <Metadata name="From" type="String">AS4BUYER</Metadata> <Metadata name="To" type="String">AS4SUPPLIER</Metadata> <Metadata name="SignalType" type="string">Receipt</Metadata> <Metadata name="RefToMessageId" type="string">eec1aad9-74b8-4608-961f-213066ab0e70@AS4SUPPLIER</Metadata> </MessageMetadataDocument> 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. <?xml version="1.0" encoding="UTF-8"?> <MessageMetadataDocument protocolVersion="3.0" protocol="ebXML"> <Metadata type="String" name="From">AS4SUPPLIER</Metadata> <Metadata type="String" name="To">AS4BUYER</Metadata> <Metadata type="string" name="SignalType">Error</Metadata> <Metadata type="string" name="ErrorCode">EBMS:0010</Metadata> <Metadata type="string" name="Category">Processing</Metadata> <Metadata type="string" name="ErrorDescription">Error reason</Metadata> <Metadata type="string" name="ErrorDetail">Error Location</Metadata> <Metadata type="string" name="ConnectionId">dbf86a9f-bf2d-4353-bfe5-4df56ed5e9fd</Metadata> <Metadata type="string" name="RefToMessageId">urn:uuid:E1E424CA5832EB21A61361174114991@SUNSUPER</Metadata> <Metadata type="string" name="FromRole">Buyer</Metadata> <Metadata type="string" name="ToRole">Seller</Metadata> <Metadata type="string" name="Action">ProcessAck</Metadata> </MessageMetadataDocument> In this MMD: Error message sender is: AS4SUPPLIER Error message receiver: AS4BUYER Message is signal type: Error Related topics AS4 AS4 messages Message Partition Channels (MPC) AS4 user authentication Large message splitting and joining Enable handling of empty SOAP Body messages Configure a one-way client pull AS4 use case: One-way push (MMD initiated) AS4 use case: One-way pull (MMD initiated) AS4 tasks Related Links
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 Required metadata Message Metadata Documents (MMD) MMD examples Example 1: Initiate a push Example 2: Generate a queued message for pulling Example 3: Initiate a pull request Example 4: Initiate a receipt send Example 5: Initiate an error message send 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. <?xml version="1.0" encoding="UTF-8"?> <MessageMetadataDocument protocol="ebXML" protocolversion="3.0"> <Metadata name="From" type="String">AS4BUYER</Metadata> <Metadata name="To" type="String">AS4SUPPLIER</Metadata> <Metadata name="PModeID>TradePO</Metadata> <Metadata name="FromRole" type="string">http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/ns/core/200704/initiator</Metadata> <Metadata name="ToRole" type="string">http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/ns/core/200704/responder</Metadata> <Metadata name="Service" type="string">POService</Metadata> <Metadata name="Action" type="string">ProcessPO</Metadata> <Metadata name="ConversationId" type="string">trade-po-001</Metadata> <Metadata name="AgreementRef" type="string">Trading-PO</Metadata> <MessagePayloads> <Payload id="12345" packagingLocation="SOAPBody"> <Location type="filePath">C:\Axway\Interchange\common\data\PurchaseOrder.xml</Location> </Payload> </MessagePayloads> </MessageMetadataDocument> 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. <?xml version="1.0" encoding="UTF-8"?> <MessageMetadataDocument protocol="ebXML" protocolversion="3.0"> <Metadata name="From" type="String">AS4BUYER</Metadata> <Metadata name="To" type="String">AS4SUPPLIER</Metadata> <Metadata name="PModeID>TradePO</Metadata> <Metadata name="FromRole" type="string">http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/ns/core/200704/initiator</Metadata> <Metadata name="ToRole" type="string">http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/ns/core/200704/responder</Metadata> <Metadata name="Service" type="string">POService</Metadata> <Metadata name="Action" type="string">ProcessPO</Metadata> <Metadata name="ConversationId" type="string">trade-po-001</Metadata> <Metadata name="AgreementRef" type="string">Trading-PO</Metadata> <Metadata name="message.WaitForPull" type="string">true</Metadata> <!-- <Metadata type="string" name="MessagePartitionChannel">Buyer</Metadata> --> <MessagePayloads> <Payload id="12345" packagingLocation="SOAPBody"> <Location type="filePath">C:\Axway\Interchange\common\data\BusinessDocument_1.xml</Location> </Payload> <Payload id="123456" packagingLocation="Attachment"> <MimeContentId>POAttch1</MimeContentId> <MimeContentType>application/gzip</MimeContentType> <Location type="filePath">C:\Axway\Interchange\common\data\BusinessDocument21.xml</Location> <Schema location=test1 namespace="t1" version="1.1"/> <Schema location=test2 namespace="t2" version="1.2"/> </Payload> </MessagePayloads> </MessageMetadataDocument> 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). <?xml version="1.0" encoding="UTF-8"?> <MessageMetadataDocument protocol="ebXML" protocolversion="3.0"> <Metadata name="From" type="String">AS4BUYER</Metadata> <Metadata name="To" type="String">AS4SUPPLIER</Metadata> <Metadata name="SignalType" type="string">PullRequest</Metadata> <Metadata name="MessagePartitionChannel" type="string">http://docs.oasis-open.org/ebxmlmsg/ebms/v3.0/ns/core/200704/defaultMPC</Metadata> </MessageMetadataDocument> 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). <?xml version="1.0" encoding="UTF-8"?> <MessageMetadataDocument protocol="ebXML" protocolversion="3.0"> <Metadata name="From" type="String">AS4BUYER</Metadata> <Metadata name="To" type="String">AS4SUPPLIER</Metadata> <Metadata name="SignalType" type="string">Receipt</Metadata> <Metadata name="RefToMessageId" type="string">eec1aad9-74b8-4608-961f-213066ab0e70@AS4SUPPLIER</Metadata> </MessageMetadataDocument> 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. <?xml version="1.0" encoding="UTF-8"?> <MessageMetadataDocument protocolVersion="3.0" protocol="ebXML"> <Metadata type="String" name="From">AS4SUPPLIER</Metadata> <Metadata type="String" name="To">AS4BUYER</Metadata> <Metadata type="string" name="SignalType">Error</Metadata> <Metadata type="string" name="ErrorCode">EBMS:0010</Metadata> <Metadata type="string" name="Category">Processing</Metadata> <Metadata type="string" name="ErrorDescription">Error reason</Metadata> <Metadata type="string" name="ErrorDetail">Error Location</Metadata> <Metadata type="string" name="ConnectionId">dbf86a9f-bf2d-4353-bfe5-4df56ed5e9fd</Metadata> <Metadata type="string" name="RefToMessageId">urn:uuid:E1E424CA5832EB21A61361174114991@SUNSUPER</Metadata> <Metadata type="string" name="FromRole">Buyer</Metadata> <Metadata type="string" name="ToRole">Seller</Metadata> <Metadata type="string" name="Action">ProcessAck</Metadata> </MessageMetadataDocument> In this MMD: Error message sender is: AS4SUPPLIER Error message receiver: AS4BUYER Message is signal type: Error Related topics AS4 AS4 messages Message Partition Channels (MPC) AS4 user authentication Large message splitting and joining Enable handling of empty SOAP Body messages Configure a one-way client pull AS4 use case: One-way push (MMD initiated) AS4 use case: One-way pull (MMD initiated) AS4 tasks