We need to be careful, I think many existing implementations do use
0010 for all situations where they cannot map a message, whether it
is messages with a PMode attribute value that is unknown, or based
on its UserMessage values to a configuration. I would prefer to
generalize the definition of the error to a more general "pmode
lookup error".
On 11/19/2014 09:02 PM, Jacques Durand
wrote:
>
Based on the short descriptions it seems logical that
EBMS:0010 – ProcessingModeMismatch …
That is a bit of a stretch: that error
above was supposed to occur when (a) the Pmode is actually
well identified and known, (b) the message does not comply
with tthat Pmode.
So sure we could say that a missing Pmode
(unidentified) is a corner case, for lack of a specific error.
But it seems we need a new error as that
solution does not help the users to understand what happened.
Something like:
EBMS:0012 MissingPmode “The MSH could not
identify the Pmode for this message.”
-jacques
From:
[mailto:] On Behalf Of
Sander Fieten
Sent: Tuesday, November 18, 2014 1:10 PM
To:
Subject: [ebxml-msg] Error to use when P-Mode not
found
All,
I have some questions I would like to
discuss with you about the Error that should be returned if
an MSH can not determine which P-Mode should handle a
received message.
Do we want to specify a specific Error for
this situation?
If so, which Error should be used?
Section 6.7.1 of the Core Spec lists the standard ebMS
processing errors. Based on the short descriptions it
seems logical that EBMS:0010 - ProcessingModeMismatch is
the correct Error to return. However the description of
the semantics - "the header expected by the MSH is not
compatible with the expected content, based on the
associated P-Mode." - is a bit unclear because of the
incompatibility between expectations and that it talks
about an associated P-Mode. Especially the latter seems to
suggest that a P-Mode is found for the message. Another
option could be Error EBMS:0001 - ValueNotRecognized as
the MSH is unable to find the P-Mode based on the received
information.
Regards
Sander
