Clovertech

Outbound message reply on Inbound instead of Inbound Replies

› Clovertech Forums › Read Only Archives › Cloverleaf › Cloverleaf › Outbound message reply on Inbound instead of Inbound Replies

  • Creator
    Topic
  • January 16, 2015 at 3:27 am #54528
    Elisha Gould
    Participant

      Hi,

      I am developing an CAA WS 2.0 interface in cloverleaf 6.0.2.

      Currently there is a translation that performs a KILL on the original message and CONTINUE on a newly generated message using grmencode.

      This translation is in ws-client thread in “TPS Outbound Data”, and Await replies is checked.

      In this particular case, the reply does not come through “TPS Inbound Reply”, but instead is received in “TPS Inbound Data”

      I would expect the reply to come back through  “TPS Inbound Reply”.

      I’m just checking why this would occur?

      If I KILL the new message, copy the content to the original message, and CONTINUE the original message, the reply comes back through “TPS Inbound Reply”.

    • Creator
      Topic
    Viewing 5 reply threads
    • Author
      Replies
      • January 16, 2015 at 7:24 am #81849
        Elisha Gould
        Participant

          I just checked, this occurs in 5.8 as well and for other protocols.

          See attachment for sample of this occuring.

          To reproduce send a file to the input thread. ie something like the following will work:

          hcicmd -p test -c “input resend ib data 5120 wpid nl”

        • January 20, 2015 at 7:18 pm #81850
          Michael Hertel
          Participant

            It is my understanding that you need to check “outbound only” on the thread that you want the message to come back as “TPS Inbound Reply”.

          • January 20, 2015 at 8:05 pm #81851
            James Cobane
            Participant

              What distinguishes Inbound Data from Inbound Reply on an incoming message is simply the state that the thread is in when that data comes in.  If the thread is waiting on a reply, then any message that comes while the ‘awaiting reply’ flag is set will be considered an inbound reply.  Inversely, if a message comes in when the thread is not waiting for a reply, the message will be considered inbound data.  Setting the ‘Outbound Only’ flag on the thread tells the engine to ignore any message that comes in when it is not awaiting a reply; so the message is simply ignored.

              When you are working with the inbound message, the metadata of that message will be valued with the respective property (data or reply), so if the message is a reply and you are modifying it then CONTINUE’ing it, it will still be a REPLY message.  If you are KILL’ing the original message, and creating a new message to CONTINUE, if you didn’t create the new message as a type ‘REPLY’, then it will be a ‘data’ message and treated as such.

              I believe if you perform a msgcopy of the original message, it will retain the relevant metadata of the original and possess the same attributes.

              So, in short if you are creating a new message that you want handled as a reply, you need to create it as a reply type.

              Jim Cobane

              Henry Ford Health

            • January 20, 2015 at 11:41 pm #81852
              Levy Lazarre
              Participant

                Hello, Elisha

                Just two quick thoughts.

                1. As Jim mentioned, you need to create your new message as a reply type:

                Code:


                set replymh [msgcreate -recover -type reply $mydata]

                2. If you want the returned data to be passed back to the engine as a reply message, you need to OVER (not continue) the new message. OVER will move the message to the opposite side, i.e. to TPS Inbound Reply:

                Code:


                lappend dispList “OVER $replymh”

                I hope this helps.

              • January 21, 2015 at 12:03 am #81853
                Elisha Gould
                Participant

                  Hi,

                  The Outbound Only flag does not affect this case. The result of checking this flag will cause the reply to be discarded by the engine.

                  This particular case is deleting the message in client sms_ob_data and creating a new message. Setting to REPLY does not fix the issue as a REPLY is only applicable for replying to a message received. Changing code to create the outbound message as a reply does not change the result.

                  msgcopy appears to set up the message to allow it to be acked, however grmencode doesn’t have an option to copy the required attributes.

                  grmencode acts similar to msgcreate which is why I used it for the sample.

                  The steps for this case are:

                  * Send a message to the input thread.

                  * Message is routed to the client thread.

                  * In the sms_ob_data handle of ‘client’, original message is KILL and new Message is CONTINUE. (This is the cause of the issue)

                  * New message is sent to the server thread.

                  * in the sms_ib_data handle of ‘server’, a reply message is generated.

                  * Reply Ack message is sent back to the client thread.

                  * The Reply is being handled in sms_ib_data instead of sms_ib_reply

                  The below steps will work correctly:

                  * Send a message to the input thread.

                  * Message is routed to the client thread.

                  * In the sms_ob_data handle of ‘client’, new message is KILL and original Message is CONTINUE.

                  * Original message is sent to the server thread.

                  * in the sms_ib_data handle of ‘server’, a reply message is generated.

                  * Reply Ack message is sent back to the client thread.

                  * The Reply is being handled in sms_ib_reply

                  The workaround that I have found for this case is to put the code in an intermediate thread or the input thread.

                  I was just checking if this was a “feature” of cloverleaf or another bug that has been overlooked.

                • January 23, 2015 at 10:01 pm #81854
                  Max Drown (Infor)
                  Keymaster

                    Here are a couple of Inbound Replies procs I have used in the past thay may help you understand how the pieces work with CAA-WS 2.0.

                    In this case, I have the following procs stacked in TPS Inbound Reply:

                    1. tps_ws_ib_response

                    2. cl_check_ack_iris.

                    # processes replies from CAIR web server
                    # examines http return code, if its a 200, parses out
                    # the hl7 ack and CONTINUEs it
                    # if the http code indicates an error, dump to error db

                    proc tps_ws_ib_response { args } {
                    [code]# processes replies from CAIR web server
                    # examines http return code, if its a 200, parses out
                    # the hl7 ack and CONTINUEs it
                    # if the http code indicates an error, dump to error db

                    proc tps_ws_ib_response { args } {

                    -- Max Drown (Infor)

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