match phrase basic-msg rejected

[Jeff Dinsmore]

I have a standalone web service that receives HL7 messages and forwards them to Cloveleaf via MLLP.

The messages contain Base64 encoded PDF documents.

Most of the messages flow through this process smoothly.

There are a few, however, that are generating these errors:

[pdl :PDL :WARN/0:imageTrend_ib:05/01/2024 13:52:53] match phrase basic-msg rejected
[pdl :PDL :ERR /0:imageTrend_ib:05/01/2024 13:52:53] no-match: no more phrases to try

I grabbed one of the messages that’s causing the problem and processed it through the web service manually.

The MLLP send of the full message throws the above error every time – whether processed manually or through normal operation.

If I cut out most of the Base64 encoded data, that same message processes fine.

I do a hex dump of the message when it’s sent via MLLP and it is properly enveloped.

I’ve decoded the payload and it extracted a good PDF.

So, I believe the message is a properly formatted HL7 message and is delivered in a proper MLLP envelope with all data in the message intact.

That leads me to believe there may be something in the Base64-encoded payload that’s confusing Cloverleaf when it’s attempting to receive the problem message.

Have any of you experienced something like this?

Am I meowing up the wrong tree?

Jeff Dinsmore
Chesapeake Regional Healthcare

Topic

[Jim Kosloskey]

Jeff,

Is this message uncommonly large? I am assuming you are using PDL. Have you tried Tcp/IP with MLLP encapsulation for the thread protocol? Base64 encoding should not produce any of the MLLP encapsulation characters. But, if I recall correctly, PDL is old and maybe is sensitive to message size.

I too am just speculating.

Jim

email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.

[Jeff Dinsmore]

Yes, it’s using PDL, so that’s useful info.

Those that have failed recently have been the largest payloads – a couple MB or more. – so I considered that size might be an issue.  But I wasn’t thinking they’re huge.

I switched my test inbound to use TCPIP with MLLP encapsulation, and now get a different error, but looks like the same problem.

[tcp :read:ERR /0:imageTrend_ib_tcp4:05/01/2024 15:54:26] Tcp encapsulated read timed out after start block, reseting to look for start block.
[tcp :read:WARN/0:imageTrend_ib_tcp4:05/01/2024 15:54:40] Nonmessage data received. Enable tcp/read/info/0 to see detail

But… it looks like CL actually eventually receives the whole message.  It’s written to SMAT, but I don’t see an ACK back to the sender.  The client sent the message five times total after timing out four times waiting for an ACK.

And, again, the TCPIP with MLLP encapsulation works fine if I remove most of the Base64-encoded payload.

Very strange…

Here’s the start/end of a hex dump of the message that’s being sent.  It looks like it has proper MLLP start/stop characters.

HEX DUMP – 2582103 characters

0b 4d 53 48 7c 5e 7e 5c *MSH|^~\*
26 7c 49 6d 61 67 65 54 *&|ImageT*
72 65 6e 64 7c 34 34 39 *rend|449*
7c 45 4d 52 5f 56 65 6e *|EMR_Ven*
64 6f 72 7c 30 38 7c 32 *dor|08|2*
30 32 34 30 35 30 31 30 *02405010*
39 33 38 35 39 32 30 32 *93859202*
34 30 35 30 31 31 34 33 *40501143*
38 35 39 2d 30 35 30 30 *859-0500*
7c 7c 4f 52 55 5e 52 30 *||ORU^R0*
31 7c 34 37 31 36 31 35 *1|471615*
37 36 31 31 36 37 32 36 *76116726*
32 33 39 39 30 7c 50 7c *23990|P|*
32 2e 35 7c 7c 7c 41 4c *2.5|||AL*
7c 4e 45 7c 7c 7c 7c 7c *|NE|||||*
0d 50 49 44 7c 30 31 7c * PID|01|*

…

7c 7c 7c 7c 7c 7c 46 7c *||||||F|*
7c 7c 32 30 32 34 30 34 *||202404*
31 36 30 35 31 31 31 36 *16051116*
7c 7c 7c 7c 0d 1c 0d *|||| *

 

Jeff Dinsmore
Chesapeake Regional Healthcare

[Jim Kosloskey]

Jeff,

In the darkest regions of my (getting poorer) memory, trying to get out, is something related to buffer size settings related to IP. Perhaps it is worth checking with support?

I still think it is related to size and how the message is getting broken up within Tcp/IP.

Perhaps there are shops out there that have large messages via Tcp/IP that can chime in but I think support would be a good next stop.

Just curious – what release of Cloverleaf and what O/S?

email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.

[Jeff Dinsmore]

Host Server Build Information:
Version: 19.1.0.1P

Like the Bartles & James guys said – “Thank you for your continued support”

Jeff Dinsmore
Chesapeake Regional Healthcare

[Jeff Dawson]

Hi Jeff,

We came across a similar issue regarding read timeout errors on a few of our inbound threads due to message size of base64 encoded pdf’s, we ended up having to adjust the timeout setting to higher value besides the default of 30.   This might be something to adjust on your side and see if it helps, for some of our systems we upped this to 300.  We also came across another issue where the HL7 message was just to large in general to receive but Infor support confirmed this is an AIX problem only apparently.

• This reply was modified 7 months, 3 weeks ago by Jeff Dawson.

Attachments:

You must be logged in to view attached files.

[jianasingh]

[pdl :PDL :WARN/0:imageTrend_ib:05/01/2024 13:52:53] match phrase basic-msg rejected
[pdl :PDL :ERR /0:imageTrend_ib:05/01/2024 13:52:53] no-match: no more phrases to trysalesforce developer online training

You grabbed one of the messages that’s causing the problem and processed it through the web service manually.

• This reply was modified 5 months, 4 weeks ago by jianasingh.

[Author]

Replies