Returning a Response from a Business Process that is not the same Message Type Request
I thought I knew how to return a Response from a Business Process back to the Source Config Name, but I guess not.
I am working on a Proof of Concept, that the Request Message Class would determine a "Route" within a Business Process to make a FHIR call (search, read) to our External FHIR repository, and return back the HS.FHIR.DTL.vR4.Model.Resource.xxxxxxx as a Response to the Source Config Name.
I have the FHIR part working, however now that I have the data in the form of HS.FHIR.DTL.vR4.Model.Resource.xxxxxxx, I am struggling to understand how I could send it back to the Original Source Config. In theory this sounds ok but when I get to the Management Portal build, I am struggling...
Do I send the FHIR Response to a EnsLib.Msg.RuleEngine? If so, how do I make sure the Request Source Config Name gets forwarded on so the Rules Engine knows where to send the message?
Any Ideas on how I can make this happen?
Comments
Hi Scott,
What you’re running into is less about FHIR or DTL and more about how IRIS handles response routing via message headers and session context.
A couple key points that should help:
1. Don’t route the response through the Rule Engine
The Rule Engine is intended for request routing, not for sending responses back. If you send your FHIR response there, it won’t automatically know how to get back to the original caller.
2. Use the built-in request/response pattern
If your Business Process is calling out to another operation (your external FHIR repo), the easiest and most reliable approach is:
Set pResponse = tResponse
Quit $$$OK
This preserves the session and ensures IRIS automatically routes the response back to the original Source Config Name.
3. You don’t need matching message types
It’s perfectly fine that your response is an HS.FHIR.DTL.vR4.Model.Resource.* type that differs from the request. IRIS does not require the message classes to match—only that the response is returned within the same session context.
4. If you go off-pattern, you must manage headers
If you’re not using SendRequestSync (e.g., async or custom flows), then you’ll need to explicitly preserve things like:
SessionIdSourceConfigNameTargetConfigName
Otherwise IRIS won’t know where to send the response.
Bottom line
You shouldn’t need to explicitly “send it back” to the Source Config. Just return the response from your Business Process (pResponse), and IRIS will take care of the routing.
Hope that helps—this is a common stumbling point when first working with BP response flows.
Hi Scott,
What you’re running into is less about FHIR or DTL and more about how IRIS handles response routing via message headers and session context.
A couple key points that should help:
1. Don’t route the response through the Rule Engine
The Rule Engine is intended for request routing, not for sending responses back. If you send your FHIR response there, it won’t automatically know how to get back to the original caller.
2. Use the built-in request/response pattern
If your Business Process is calling out to another operation (your external FHIR repo), the easiest and most reliable approach is:
Set pResponse = tResponse
Quit $$$OK
This preserves the session and ensures IRIS automatically routes the response back to the original Source Config Name.
3. You don’t need matching message types
It’s perfectly fine that your response is an HS.FHIR.DTL.vR4.Model.Resource.* type that differs from the request. IRIS does not require the message classes to match—only that the response is returned within the same session context.
4. If you go off-pattern, you must manage headers
If you’re not using SendRequestSync (e.g., async or custom flows), then you’ll need to explicitly preserve things like:
SessionIdSourceConfigNameTargetConfigName
Otherwise IRIS won’t know where to send the response.
Bottom line
You shouldn’t need to explicitly “send it back” to the Source Config. Just return the response from your Business Process (pResponse), and IRIS will take care of the routing.
Hope that helps—this is a common stumbling point when first working with BP response flows
Hi Scott,
What you’re running into is less about FHIR or DTL and more about how IRIS handles response routing via message headers and session context.
A couple key points that should help:
1. Don’t route the response through the Rule Engine
The Rule Engine is intended for request routing, not for sending responses back. If you send your FHIR response there, it won’t automatically know how to get back to the original caller.
2. Use the built-in request/response pattern
If your Business Process is calling out to another operation (your external FHIR repo), the easiest and most reliable approach is:
Set pResponse = tResponse
Quit $$$OK
This preserves the session and ensures IRIS automatically routes the response back to the original Source Config Name.
3. You don’t need matching message types
It’s perfectly fine that your response is an HS.FHIR.DTL.vR4.Model.Resource.* type that differs from the request. IRIS does not require the message classes to match—only that the response is returned within the same session context.
4. If you go off-pattern, you must manage headers
If you’re not using SendRequestSync (e.g., async or custom flows), then you’ll need to explicitly preserve things like:
SessionIdSourceConfigNameTargetConfigName
Otherwise IRIS won’t know where to send the response.
Bottom line
You shouldn’t need to explicitly “send it back” to the Source Config. Just return the response from your Business Process (pResponse), and IRIS will take care of the routing.
Hope that helps—this is a common stumbling point when first working with BP response flows.
What you’re running into is less about FHIR or DTL and more about how IRIS handles response routing via message headers and session context.
A couple key points that should help:
1. Don’t route the response through the Rule Engine
The Rule Engine is intended for request routing, not for sending responses back. If you send your FHIR response there, it won’t automatically know how to get back to the original caller.
2. Use the built-in request/response pattern
If your Business Process is calling out to another operation (your external FHIR repo), the easiest and most reliable approach is:
Set tSC = ..SendRequestSync("Your.FHIR.Operation", pRequest, .tResponse)
Set pResponse = tResponse
Quit $$$OKThis preserves the session and ensures IRIS automatically routes the response back to the original Source Config Name.
3. You don’t need matching message types
It’s perfectly fine that your response is an HS.FHIR.DTL.vR4.Model.Resource.* type that differs from the request. IRIS does not require the message classes to match—only that the response is returned within the same session context.
4. If you go off-pattern, you must manage headers
If you’re not using SendRequestSync (e.g., async or custom flows), then you’ll need to explicitly preserve things like:
SessionId
SourceConfigName
TargetConfigName
Otherwise IRIS won’t know where to send the response.
Bottom line
You shouldn’t need to explicitly “send it back” to the Source Config. Just return the response from your Business Process (pResponse), and IRIS will take care of the routing.
Hope that helps—this is a common stumbling point when first working with BP response flows.
What's your Business Process class?
If you're using a message router (derived from EnsLib.MsgRouter.RoutingEngine), check Response From, Response Target Config Names, and Forward Generated Response To Target(s) settings. Although if called in a sync way, it should return a response to the caller anyway.
If you're extending an Ens.BusinessProcess, you can populate a response in any On* method (OnRequest, OnResponse, OnComplete, etc.)
If you're writing a BPL process, you should be able to access a response object everywhere.