Simple Unsolicited ORU message – being continuously sent
› Clovertech Forums › Read Only Archives › Cloverleaf › Cloverleaf › Simple Unsolicited ORU message – being continuously sent
- This topic has 21 replies, 6 voices, and was last updated 15 years, 1 month ago by
Bob Richardson.
-
CreatorTopic
-
November 18, 2009 at 8:55 pm #51352
I am new to Cloverleaf. -
CreatorTopic
-
AuthorReplies
-
-
November 18, 2009 at 10:08 pm #69836
Did you put in the check_ack proc in the await replies section?
-
November 19, 2009 at 3:47 pm #69837
Nicholas, what version of Cloverleaf are you on? If on 5.6 or later, this is how the Outbound tab should be setup.
Also, you should be using mlp_tcp.pdl I believe. That’s what we use anyways.
-- Max Drown (Infor)
-
November 19, 2009 at 7:05 pm #69838
Thanks for the help! I was able to resolve the issue. I had to call hcitpsmsgkill in the Send OK Procs of Outbound Data. When the ACK was received by MWB then the message was deleted.
-
November 19, 2009 at 7:22 pm #69839
Uh – actually – I think by placing hcitpsmsgkill there you are unilaterally killing the outbound message whether or not you ever receive an acknowledgment.
I don’t think that is what you want to do even though it may appear to have solved the issue.
email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.
-
November 19, 2009 at 7:27 pm #69840
Yeah, you don’t want to use anything in Send OK in versions 5.6+ unless you specifically need something for an odd interface. Try to lay it out exactly as I have it in the screen shot and see what happens.
-- Max Drown (Infor)
-
November 19, 2009 at 8:09 pm #69841
I tried laying it out in your example but it didn’t work. I am using version 5.7P.
We attempted to put hcitpsmsgkill in TPS Inbound Reply but it did nothing. We attempted to use a recover_33 proc presented the Cloverleaf Level 2 class but that didn’t work. It doesn’t appear that the ACK (which I see is being sent and received) fires off the proc specified in TPS Inbound Reply. What am I missing here? How can I tell if the thread is receiving the ACK?
-
November 19, 2009 at 8:15 pm #69842
You may have the thread configuration wrong in another tab. Can you please post screenshots of your tabs?
-- Max Drown (Infor)
-
November 19, 2009 at 8:18 pm #69843
You can turn up the EO and you should see the ack coming into the engine in a hex dump (assuming pdl).
If you have SMAT turned on for the inbound messages, the acknowledgments will also show up there.
We use the recover procs here and not the newer functionality because we do some additional work that is precluded when the new functionality is turned on.
Do you have ‘Outbound Only’ turned on (the thread tab) and also ‘Wait replies’?
email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.
-
November 19, 2009 at 8:57 pm #69844
Here are some screen shots.
-
November 19, 2009 at 9:00 pm #69845
What do you have under Timeout Handling?
Try setting Timeout to 45 instead of 5.
Assuming you have Timeout Handing correct, everything looks good to me which implies the problem is mostly likely with the receiving application.
-- Max Drown (Infor)
-
November 19, 2009 at 9:22 pm #69846
We’ve tried 45 seconds and longer. The problem is the thread continues to send the message, multiple times. I see the ACK being sent back by 7Edit or the HL7 Messaging Workbench (the testing apps we use). For some reason Cloverleaf doesn’t recognize or see the ACK, thinks the message hasn’t been sent correctly, and resends the message. The TPS Inbound Reply is where I assume I specify a script to run when an ACK is received. I don’t understand why it isn’t being executed.
-
November 19, 2009 at 9:26 pm #69847
The ACK is handled by hcitpsmsgkill in TPS Inbound Reply. It simply kills the ACK.
Do you see the ACKs in the smat files? Have you turned up EO and watched the logs?
-- Max Drown (Infor)
-
November 19, 2009 at 9:37 pm #69848
Like I said I am a newby. I am in process of figuring out how to turn up the EO. By the way, I appreciate the help. Thanks.
-
November 19, 2009 at 9:37 pm #69849
Check to see if you have messages failing on the status of that thread. On the inbound tab you may want to check the Outbound Only check box. Your acks may be appearing as msgtype data instead of reply…. Just a thought since most everything else looks good.
-
November 19, 2009 at 10:06 pm #69850
Humor me and try checking ‘Outbound only’ on the prinmary thread tab of the outbound thread. Stop and Start the thread, then resend a message.
Turn your EO up so you can track the flow.
email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.
-
November 19, 2009 at 11:30 pm #69851
OK It looks like I receive the ACK. Here is the log file with EO turned on. I clipped off the dates and times. Is there something I need to do so that Cloverleaf recognizes the type of ACK?
input buffer accepted 90 bytes, now 90
0b 4d 53 48 7c 5e 7e 5c |.MSH|^~|
26 7c 7c 7c 4c 41 54 49 |&|||APP|
54 55 44 45 7c 42 4f 53 |NAME|COM|
54 4f 4e 20 53 43 49 45 |PANYNAME|
4e 54 49 46 49 43 7c 32 |AAAAA|2|
30 30 39 31 31 31 39 31 |00911191|
37 31 34 32 36 7c 7c 41 |71426||A|
43 4b 7c 32 35 30 30 30 |CK|25000|
30 31 7c 50 7c 32 2e 35 |01|P|2.5|
0d 4d 53 41 7c 41 41 7c |.MSA|AA||
32 35 30 30 30 30 31 0d |2500001.|
1c 0d |..|
multi: phrase #0 rejected; trying next
trying to match phrase: nak-msg
multi: phrase #1 rejected; trying next
no-match: no more phrases to try
Calling Tcl procedure: write.gotNak
with args: {{status error} {type no-match}}
pdiIgnoreInput: chop to 4294967295, bolen 0
pdiIgnoreInput: after clear: 0 + 0
Tcl procedure write.gotNak returns ‘TRANSMIT’
writing out 10985 bytes:
-
November 20, 2009 at 12:03 am #69852
What protocol driver are you using? The Wrapper on the ACK is . It appears as thought the pdl driver does not recognize this. mlp_tcp.pdl is what matches this message wrapper. So the protocol is PROTOCOL:pdl-tcpip with mlp_tcp.pdl selected. If you are not this, go ahead and try this….
-
November 20, 2009 at 3:38 am #69853
Yes, I am using the MLLP v2 protocol (mlp2_tcp.pdl).
-
November 20, 2009 at 1:49 pm #69854
Are you receiving errors in the status? You may have matched the ACK of this form ‘0b 06 1c 0d |….| ‘; however I would expect a trxid 101 error since you are using HL7 to determine the message type. The Application ACK from above would have satisfied the standard use of mlp_tcp.pdl.
-
November 20, 2009 at 4:16 pm #69855
You have that tab of the NetConfig configured correctly from what I can tell. We have that exact layout in hundreds of threads in version 5.6 and 5.7.
How do you have the “Timeout Handling …” box configured?
What is the difference between mlp_tcp.pdl and mlp2_tcp.pdl? I’ve never used mlp2_tcp.pdl before.
-- Max Drown (Infor)
-
November 20, 2009 at 7:19 pm #69856
Folks,
Starting with CIS5.6, the hcitpsmsgkill proc has a problem in that it doesn’t handle the new key OBMSGID to kill replies. I had received a modified version from Charlie Bursell that fixed that problem. It should be in the TCL procs library in this Forum but I have attached our version
(which should be the same).
Place this proc in your “master site” (common directory) so that the engine will find it over the one at the root level.
Don’t know if you are running this version or not – if not then just blow by this response.
-
-
AuthorReplies
- The forum ‘Cloverleaf’ is closed to new topics and replies.
