Stream: implementers
Topic: Messaging response
Adam (Nov 01 2018 at 06:06):
Hi all, I'm now working on the Messaging, another data exchanging paradigm. But I'm confused about the response of the Messaging. It's said that 'The response content type returned is always a Bundle with type "message" containing a Message Header resource as the first resource, or an HTTP error', If I got some issue while processing, is it supposed to return a 'Bundle' which contains an Operation Outcome resource? Or I should just return an Operation Outcome resource without enveloped in a 'Bundle'?
René Spronk (Nov 01 2018 at 08:41):
Any response message should be a Bundle of type message, with an OperationOutcome resource and MessageHeader resource in the bundle (as well as other resources in case of successfull processing of the original message that this response message is responding to).
Lloyd McKenzie (Nov 01 2018 at 15:36):
Rene, that's not totally accurate. If you post to the "$processMessage" endpoint, and send something totally invalid, it's legitimate for that endpoint to respond with a bare OperationOutcome (or even just an HTTP error code) and not pass back a Bundle. It depends what "layer" the error occurs in. If the message reaches the point where the content is being processed as a FHIR message, then the expected response would be a FHIR message (which may or may not allow for an OperationOutcome as part of the content). But if it's a situation of authorization privileges or something like that, you won't necessarily get back a message.
Lloyd McKenzie (Nov 01 2018 at 15:37):
It's handled the same as any other operation invocation. If the operation gets to the point where the operation can execute, you'll get back the "output" for the operation (in this case a message Bundle). But if not, you'll get back an unwrapped OperationOutcome. or nothing.
René Spronk (Nov 02 2018 at 16:08):
Agree - if there's an error at the transport/authorization level you'd get an error at that level. I interpreted the question to be solely about messaging (and not about the underlying transport, which could be REST or lots of other things). In that wider context you're correct.
Last updated: Apr 12 2022 at 19:14 UTC
