Cloverleaf xlate message size limitations?

[Jim Lohe]

Hello. I have an interface that occasionally receives an encoded document sent via and HL7 ORU message with the document broken up into multiple OBX segments.      The example I have has 50,000+ OBX segments.     I have seen others that have had 80,000.    They were choking in state 1 until I changed the ACK to  hl7Raw_ack.tcl.     Now these messages get to state 5 and then choke.      Usually it

Topic

[Russ Ross]

I would be curious to know if you take the xlate out of the equation and do a raw route on message type does the panic still occur.

In my opinion for a real-tme message I get concerned whenever exceeding 64K, mostly because I’ve seen this limitation on a number of vendor interfaces, so 10MB might be a challenging size.

I’m curious to hear if others have experience moving messages of this size because I don’t since I’ve warned against doing it and found alternative methods.

I’ve resorted to alternative methods such as passing pointers to the data in the real-time messages when dealing with large data blocks like a huge document or a scanned image.

Also, from past eperience when dealing with potentially unlimited repitions there will always be someone who runs a muck and there should be checks in place to make sure an excessively large message can’t flow across the interface as is, else you will get something too large to handle eventually.

The max message size will be limited to the capability of the weakest link in the integration chain which will be one of these:

– source system

– cloverleaf

– down stream system(s)

Russ Ross
RussRoss318@gmail.com

[Bob Richardson]

Greetings,

Other thoughts here:  perhaps the maxuprocs settings need to be upped

to allocate more memory to the engine processes.  You did not state what version of the integrator you are running or on what platform; but in our case, we followed the Cloverleaf support recommendations to up these parameters for our engine user accounts = hci and hcitest.  

Being on AIX we run the following to see what the current values are:

> ulimit -a

By upping the data, stack, and memory values by a factor of 3 we have been able to process large messages via an xlate without issues.

I know I failed to define “large” but we get some really big files with embedded pdf format codes, etc. from applications like OnBase.

Also: you may wish to consider isolating your xlate to a dedicated process

that is, the one inbound – xlate – outbound as its own process to isolate it from any other demands on the xlate cmd thread.

Again, just some thoughts to ponder in figuring out how to get around this problem.

And then again, if there is NOT that much the xlate needs to do then consider a TCL solution.

Hope this helps you out.

[Jim Lohe]

Thanks to both for your input.    I have considered a tcl solution – but given that it doesnt happen that much, it hasn’t made it to the top of my pile yet.    

BTW – we are on Cloverleaf version 5.7 Sun Solaris

[Author]

Replies