Cloverleaf Adding Segments and Text at End of Message

[Lonnie Davis]

Hello all!

I have a peculiar problem I am trying to troubleshoot and recreate in my test environment.  Cloverleaf received an ADT^A01 message from a sending system and sent an extra segment and text at the end of the message before sending outbound which wasn’t there when it hit Cloverleaf.

The outbound message was logged in the receiving system, however, it didn’t generate an ACK message back.  Since the Await Replies Timeout setting is set to -1, a backlog of data starting building in the recovery database.

The vendor for the receiving system stated the message outbound (inbound to the vendor) did not have the end of message character which the system caught and thus didn’t generate the ACK.  I am assuming the end of message character stated is 1c although the vendor didn’t specify.

It appears something happened in Cloverleaf as the message appears right in the inbound SMAT but wrong in the outbound SMAT.

My questions are…

1) If a message inbound to Cloverleaf did not have the appropriate beginning and ending characters, wouldn’t Cloverleaf send to the error database?  The protocol being used on inbound and outbound threads is mlp_tcp  (mlp_tcp.pdl)

2) How can I troubleshoot what happens in Cloverleaf between receiving the inbound message and the sending outbound without the involvement of the vendors?

3) What are the steps used to view the hex format of an inbound message in the process log?

Here is an example of the inbound and outbound problem message from my SMAT logs.  I removed all of the fields leaving the segments and the extra text in the outbound message.  Any suggestions on how to troubleshoot this to see what happened are greatly appreciated!

INBOUND

MSH|^~&|||||20140701005223||ADT^A01|27770772|P|2.3

EVN|A01

PID|||

PV1|||

OUTBOUND

MSH|^~&|||||20140701005223||ADT^A01|6835223|P|2.3

EVN|A01

PID|||

PV1|||

|||||||||||||||||||||||||20140701

AL1||3|130^NO KNOWN DRUG ALLERGY  

ALLERG

Topic

[Charlie Bursell]

Have you looked at your log files?  It looks to me like some extra CR or something similar.  But there should have been some errors generated somewhere.  Turn up the EO and take another look

[Jim Kosloskey]

Is there any Tcl or Xlate involved?

If so I assume you have checked those.

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

[Brandon Grudt]

The question would be, what is adding that timestamp and the AL1 segment?  My guess is that process is creating the issue.

[Lonnie Davis]

Thanks for the replies and suggestions.  

There is a lot more to this story than I originally thought and too many unknowns to complete troubleshooting.  I was, and still am in a way, trying to troubleshoot a problem that occurred about a month ago.  

The inbound example I provided has a corresponding outbound message that went out correctly on July 1st.  The malformed outbound example appears only in the outbound SMAT for July 30th where the original correct outbound message went out July 1st (which is where the time stamp in malformed example comes from).  It looks like the original outbound message sent on July 1st was resent on July 30th to the outbound thread (pre or post TPS).

There is no real conclusion to this, but all I can tell is that the engine didn’t do this between coming to the inbound thread and sending to the outbound.

[Author]

Replies