Hi Unai,

What you’re trying to do—triggering a process based on a database insert—is a common pattern. However, using a SQL trigger to directly start a production or business process isn’t recommended in IRIS.

SQL triggers execute within the database transaction, and invoking interoperability logic from there can lead to locking issues, transaction rollbacks, and performance concerns.

The typical and safest approach is to use an EnsLib.SQL.InboundAdapter to poll the table for new records. For example, you can:

Add a flag column (e.g., Processed = 0)

Configure the adapter with a query like:

SELECT * FROM YourTable WHERE Processed = 0
After processing, update the record to mark it as processed

This keeps your database operations and interoperability processing cleanly separated, and it aligns with standard IRIS patterns.

If you need near real-time behavior, you can tune the polling interval to be very short.

Hope that helps point you in the right direction.

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 $$$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:

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.

Hi

If I had to guess I would say that in iis you have an app defined /test that is tied to the web gateway.

In your example that doesn’t work you are redirecting to a path /mobile/…

I would guess you might not have an app defined under your /mobile path that is tied to the web gateway