Re: Best way to approach delay on Request/Response

Hi all,

As part of our SLA, many of our operations limit a five second wait time on receiving a response from two or more scatter and gather targets.  Allow me to explain the design to offer some clarification on requirements and expectations, then share results and desirables.

We're running BizTalk in a healthcare environment and we have a process that accepts EDI claim requests (HIPAA 276) and we need to fire back a response (HIPAA 277).  When we accept the initial claim status request, we have a master orchestration that will execute an attempt at a scatter/gather approach and send a query to a SQL Server database, send a query to an HP based solution via MQSC and process the responses and send back the 277.

The master orchestration calls two nested orchestrations that are responsible for querying the external targets and capturing the results, which may be correlated back to the master orchestration (except the SQL send/response).  This seems all well and good, but within the master orchestration, we have a listen shape that includes a delay of five seconds within each branch.  If, whether it be the SQL call, or the queue processing, if the calling child orchestration does not send a response back to the parent, the parent delay shapes fire, then ultimately orphans the child orchestrations generating a slew of suspended, non-resumable instances in the MessageBox.

My goal, is to move the delay mechanisms from the parent orchestration and manage them within the children processes.  If the delay fires, then I can build a default response that will go to the parent and gracefully exit each "failed" process and keep things a bit cleaner.

Here's my challenge...

Every SQL request/response port requires a response, so I cannot drop a send shape and then drop a listen shape immediately afterward and support the delay, as this will not guarantee a response every time:

(when this pattern attempts to go through the build process, I receive the following error: "incomplete requestresponse operation; missing 'receive'")

What I had though about doing, was to dynamically set the WCF-SQL port(s) that require the delay with the 'SendTimout' to the allowed amount.  When testing this approach, however, the timeouts are not exactly consistent.  Out of ten transactions dropped, maybe three of them will timeout at the five second mark while others will execute with longer, or shorter response times.

With that...does anybody have any ideas on how to meet the goal of enforcing the five second SLA, and still provide the graceful end of life on the children orchestrations?  Is it possible to unhook the SQL calls from the request/response pattern and support a correlation between a disconnected send and response?

Thanks!

-Rich