Translation Thottling

[Mark Brown]

Quick question about this feature on CL 5.7 running on Windows.  I tried setting this up on a process to hopefully avoid the flooding of A08 messages from our hospital system (McKesson Series) that seems to happen every couple of weeks.  But it didn’t help so I obviously have no idea what I’m doing.

A couple of questions…

Does this setting (Process Configuration – Translation Throttling) even do anything if you aren’t using any XLATES?

What is the best setting to use to stop a thread from dumping hundreds of messages in the span of a few  minutes from flooding the engine (and preventing important messages like orders and results from going through in a timely manner)?  I really don’t understand the relevance of the Min, Max and %.

Thanks,

Topic

[Eric Fortenberry]

Under the “Configuration > Network Configurator > Process Configuration” topic in the Cloverleaf help files, there is a pretty good description of translation throttling.  It should apply the throttling logic to any routes, not just those using Xlates.

Here’s an excerpt from the documentation:

Quote:

Translation Throttling

Select the checkbox and specify the Minimum,  Maximum, or Percent values. These control how many messages the translation thread processes each time it runs. Under normal circumstances, the translation thread processes all of the messages on its queue. By specifying translation throttling, the number of messages processed is limited. This allows other threads in the engine process to run.

   Minimum  specifies that, if the number of messages on the queue is less than this value, then all of the messages are processed. If the queue has more than this many messages, then the percentage is applied.

   Maximum specifies the absolute maximum number of messages to process. If the Minimum is exceeded, then the percentage is applied. If the resulting number of messages is greater than this maximum, then only the maximum number of messages is processed.

   Percent  specifies the percentage of messages to process if the queue has more than the minimum number of messages.

   Clear the checkbox for the translation thread to process all of the messages in the queue.

Thanks,

Eric

[Russ Ross]

Whenever a real-time interface is used as a batch interface it creates a noticeable delay and backlog problem because that is not what it is designed for.

Unfortuately, vendors sometimes have such a mismatch and they gerenerate a batch of messages in a non-real-time fashion to burst across a real-time interface that isn’t designed for that intense load all at once.

I have not used the throttling settings successfully that you are playing with because I too was challenged to understand or see much impact of tinkering with them.

So here are methods I have utilized to help.

Move the burst of batched messages to a time slot that has the least impact, since these are usually scheduled events.

Create multiple sites so that one site just receives the messages from the source system and only raw routes (no xlates) to another distribution site or outbound site (the outbound sites contains the xlates).

This is the fastest way I found to get them off the source system and onto cloverleaf, with our fastest I’ve wittnessed hitting 150 messages per second but the vendors capacity usually will be the throttling factor and not cloverleaf with this design.

On one of our source vendor (SMS/CARE) feeds that has combined message types (ADT & Orders) we had enough control to send any Orders out of their sending que before any ADTs go out.

In other words establish with the vendor or configure their interface if you have control to prioritize from the source if possible.

Also, if possible have a seperate integration from source to destination each using their own port like one for orders & one integration for results and another integration for ADT.

I try to avoid combining 2 or more source feed into one outbound interface using a single port, which lends itself to maintenance headaches and the problem you are describing.

There is a message priority setting within cloverleaf that can be set but the times I tried to use on older versions of cloverleaf (like CL 3.5.5 and earlier) via the resend feature it seemed to have no effect.

I’m not sure if that is the case using a TPS/TCL proc to set the priority in the message metadata since I was discouraged with what I saw from using the GUI resend and setting the priority their.

Others might have useful suggestions to offer if you can describe in more detail your integration of concern from the sources system -> cloverleaf -> outbound system.

For Example:


IB-ADT —->|
[code]
IB-ADT —->|

Russ Ross
RussRoss318@gmail.com

[Keith McLeod]

Do these messages have to come in to the engine on you main ADT feed?  If not, you may be able to establish a delay in your ACK message going back to the source.  You would want to put the inbound thread in its own process at the very least and then delay the OVER disposition in your ACK message.

It woul be better if cloverleaf had aa way to throttle the inbound messages as a feature possibly like ftp/fileset protocol or a way to throttle the ACK message.

I have something set up where I route Specific Order message to a different destination thread which jumps to an inbound thread in a separate process which feeds back to the original destation.  The ACK I use delays the messages by argument so I can easily change the delay.  In my case, I regulate the delay by inserting the inbound time into a high MSH field so that burst of messages can go through but all have been delayed 45 seconds.  The delay becomes a calculated value up to 45 seconds.  Not perfect, but works for the most part.

[Richard Hart]

Hi Mark.

Just to add our experience.

We have not used throttling in production as we prefer manual throttling if connected applications have ‘gone ferral’. I believe normal Cloverleaf configuration will attempt to ’empty’ a thread before moving on. This can result in an inbound thread processing all messages before routing.

If throttling is turned on, in theory, processing is passed to other threads once the maximum number of messasge has been reached which can result in smoother flow.

We do have Cloverleaf sites where the inbound threads have different priorites and this works well. I believe a resend of messages uses the priority of the resend, rather than the thread.

When we have performed a data load, Cloveleaf will process as fast as possible which is not always what’s required.  We have slowed processing by creating a job to stop (phold_obd) messages for a period of  time. The ACK message is delayed and message processing is throttled

[Victor Ligenza]

Not sure if I can add a specific solution, but I had experienced a similar experience a nuber of years ago, but my issue occurred every day……

The flood of A08 messages were triggered from Series billing runs.  We had modified the update portion of the billing run job stream to send an A08 message when a patient representative code was assigned to an account.  These patient representative codes were used by McKesson’s  Horizon Business Folder to place accounts in Billing Work Queues.  Since the A08’s went out of the same Series pipe that all ADT and Order messages were sent this caused significan delays.  We had two work arounds.  1.) change the billing run schedules to run at a time that presented the least impact.  2.) The cloverleaf server was upgraded as part of normal life cycle so the additional horse power helped messages flow faster.

If your Series analyst can identify the job that is generating the A08 messages, there may be the option to turn off the trigger producing them if they are not needed or have it run during an off hours time slot.

[Author]

Replies