OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-msg message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Action item on: how errors generated by an Intermediary can be pulled


Action item on: how errors generated by an Intermediary can be pulled:
 
Error MPCs for pulling intermediary errors:
------------------------------------------------------------
 
An Intermediary MAY configure an MPC for pulling, called an "error MPC", that is intended only for reporting errors. In such a case, the error MPC MUST NOT be used for posting User messages. This intermediary may then post error messages (signal messages with an eb:Error element) that it has itself generated, to the error MPC. As for errors generated by end-points, several eb:Error elements may be grouped in the same Signal message. Such an error Signal message - called here an "intermediary error message" - intended for the pull error MPC MUST contain the EmptyMessagePartitionChannel eb:Error (EBMS:0006)  element in addition to other eb:Error element(s), indicating to a PullRequest sender that no User message is available on this MPC. The eb:Error generated by the intermediary SHOULD contain enough information in its eb:Error/ErrorDetail element to identify the intermediary.

The intermediary MUST then respond to a PullRequest authorized for the error MPC, with an intermediary error message. If no error message is posted on the error MPC, a single EmptyMessagePartitionChannel eb:Error will be returned as response to a pull request.

 A chain of intermediaries MAY be configured to route intermediary error messages over a multi-hop path, as described in Section 2.5.2.2, Multihop One-Way , case 3b. In such a configuration, the PullRequest signal may be sent by another intermediary, that will in turn post the received intermediary error message on its local error MPC (with same identifier) waiting for it to be pulled again, acting as a Sender for this error message, as described in the "Pull-on-Pull" forwarding pattern (section 2.6.3). Such a multi-hop path for pulling errors, may also reach an end-point MSH and be used to carry errors generated by this end-point. In such a case, the end-point MUST comply with above rules and only use this MPC for posting error messages.

 

-jacques



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]