Load balancing multiple Ensemble operations to handle bulk load of data

Question

Question

Jeffrey Semmens · Mar 3, 2016

What is the recommended approach to handle the following scenario: Large number of HL7 messages are serviced via Ensemble. Those messages are then transformed and routed to an Operation which calls a web service which does a number of different activities. If will do address normalization, location geo coding, MPI lookup and resolution, and insert into a SQL Server database to stage for an analytics product. Unfortunately all of this work takes time and the first thing that happens in the web service is a lock taken out on the Patien in SQL Server. Each call can take seconds where the message input is taking milliseconds. This starts to impact the operation queue as the soap calls can be blocked by the locks. The Ensemble operation is waiting on the web service to return.

One work around was to create more operations to split the load so that when multiple HL7 messages are coming in for one patient, other operations can handle messages that are not being blocked. Is there a recommended approach to routing messages to separate operations based either randomly or keyed off of a hash of the patient identifier involved?

Discussion (2)1

Log in or sign up to continue

David Loveluck · Mar 3, 2016

Without a FIFO requirement, you could simpley increase the pool size on the BO; but if you want to maintain FIFO for messages referring to the same patient, i don't see a simple alternative to your suggestion.

I have seen solutions that put messages for a patient on a hold-queue until they can be processed, but this seems overkill for your situation. It is complicated to get right.

1 0

score 0 · Answer 1 · 2016-03-04T05:08:12-05:00

If you're controling the webservice 'on the other side', the best way to handle this is to make it asynchronous, just returning a sort of Ack that the message is received.

Depending if you need information back or not the service can return a status back.

Also since the service seems to provide rather unrelated functionality, it might be a good idea to split the service up in different services.