All,
1. Yes – already encountered situations this where PModes are varied – no way for Client to discover them; they need to
be assigned on basis of inbound unique property. Any HTTP side element (URL; IP address etc) can be mangled by routers etc and lost. We are using the ebMS Form field to index agreed PModes and load these at runtime; but there are cases where these are not
known ahead of time and I think it better to return as specific a message as possible.
2. Can we add a new Error to specifically cover this situation? Ie PModes
Unknown – ie not set up in advance. Not actually an error - normally applies to a new or not configured connector attempts.
Not sure what the specific process is – ie mod to update Spec – how easy or hard is this?
Regards,
David Tuke
Enterprise Architect
Oban Pty Ltd | Ground Floor 19-23 Prospect St
| Box Hill 3128 | Australia
ABN 18 163 365 080
T: +61 3 9044 1702 | M: 0408 017 962 | F: +61 3 9044 1799
E:
David.Tuke@obansolutions.com.au | W:
www.obansolutions.com.au
***NOTICE***
This e-mail may contain confidential or legally privileged material and if you are not the intended recipient, you are advised that Oban Pty Ltd does not consent to you reading or copying the material and does not waive any confidentiality or legal privilege
associated with it. This e-mail may also contain material which is protected by copyright and if you are not the intended recipient, you are advised that Oban Pty Ltd has not consented to your reproduction of the material and there is no intention to provide
you with an implied licence to exercise any of the rights of the copyright owner or an authorised licensee. If you have received this e-mail in error, please advise Oban Pty Ltd immediately by return e-mail or by telephone on 61-3-9236-1900.
The recipient of this e-mail is solely responsible for conducting such tests and virus scanning as may be necessary, before using any attachment, to ensure that the attachment does not
contain any virus and that use of the attached materials will in no way corrupt the recipient's data or systems or those of any other person.
From: ebxml-msg@lists.oasis-open.org [mailto:ebxml-msg@lists.oasis-open.org]
On Behalf Of Sander Fieten
Sent: Wednesday, 19 November 2014 8:10 AM
To: ebxml-msg@lists.oasis-open.org
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