Simple Unsolicited ORU message – being continuously sent

Homepage Clovertech Forums Read Only Archives Cloverleaf Cloverleaf Simple Unsolicited ORU message – being continuously sent

  • Creator
  • #51352
    Nicholas Steblay

    I am new to Cloverleaf.

Viewing 20 reply threads
  • Author
    • #69836
      Jerry Tilsley

      Did you put in the check_ack proc in the await replies section?

    • #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)

    • #69838
      Nicholas Steblay

      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.

    • #69839
      Jim Kosloskey

      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.


    • #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)

    • #69841
      Nicholas Steblay

      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?

    • #69842

      You may have the thread configuration wrong in another tab. Can you please post screenshots of your tabs?

      -- Max Drown (Infor)

    • #69843
      Jim Kosloskey

      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’?


    • #69844
      Nicholas Steblay

      Here are some screen shots.

    • #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)

    • #69846
      Nicholas Steblay

      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.

    • #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)

    • #69848
      Nicholas Steblay

      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.

    • #69849
      Keith McLeod

      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.

    • #69850
      Jim Kosloskey

      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.


    • #69851
      Nicholas Steblay

      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:

    • #69852
      Keith McLeod

      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….

    • #69853
      Nicholas Steblay

      Yes, I am using the MLLP v2 protocol (mlp2_tcp.pdl).

    • #69854
      Keith McLeod

      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.

    • #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)

    • #69856
      Bob Richardson


      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.

Viewing 20 reply threads
  • The forum ‘Cloverleaf’ is closed to new topics and replies.

Forum Statistics

Registered Users
Topic Tags