DTC REPLY failing – what am I doing wrong?

Homepage Clovertech Forums Cloverleaf DTC REPLY failing – what am I doing wrong?

  • Creator
    Topic
  • #120369
    Jim Kosloskey
    Participant

    I am experimenting with DTC. I have a configuration where I am orchestrating sending a message to a thread which then replies with the intent Transitions will continue following the reply on to the next step. The transitioned message indeed gets to the intended thread and a reply comes back with what seems to be the proper Trx ID but DTC complains it is an INVALID REPLY.

    See the attached for what I think are salient screenshots.

    I am open to any and all suggestions.

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

Viewing 1 reply thread
  • Author
    Replies
    • #120370
      Jim Kosloskey
      Participant

      OK so apparently this forum does not like .rtf files. it would be nice if the limitations were provided.

      Let me try a PDF format

       

      OK that worked.

      Attachments:
      You must be logged in to view attached files.

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

    • #120378
      Don Martin
      Participant

      I’m not sure how you copied your message so I can say for sure, but it looks like the DRVCTL metadata didn’t get copied form the original reply message to the new copy of the message, so you’re missing your DTC context.  We use DTC threads a lot, and whenever we copy a message, which is a lot in DTC threads because you need to take replies and change them them to data messages, we do these two additional steps:

      set drvctl [msgmetaget $replyMessageHandle DRIVERCTL]

      # DTC needs the DRIVERCTL from the copied message
      msgmetaset $dataMessageHandleCopy DRIVERCTL $drvctl

      The entire snipped to copy a DTC reply and CONTINUE the data message looks like this:

      # Reply messages need to be copied to data messages in DTC flow; data message is sent on in the DTC flow.
      set mhData [msgcreate -type data [msgget $mh] ]
      # DTC needs the DRIVERCTL from the copied message
      msgmetaset $mhData DRIVERCTL $drvctl
      # set the code for messages with length > 6 to DONE, else QUIT the message
      set message [msgget $mhData]
      if { [some condition used to determine next state } {
      set xCode SOME_STATE
      } else {
      set xCode DONE

      }
      lappend dispList “DTCNEXT {{$mhData $xCode}}”
      # Kill the reply message prevent leaked memory/handle
      lappend dispList “KILL $mh”

      • #120379
        Jim Kosloskey
        Participant

        Don,

        Thanks for the input -very interesting.

        But in this case, the message shown is a Reply message not a copy. The thread from which the reply came is a TCP/IP connection to a foreign system that then returns the message you see in the PDF,

        The msgcopy you see in 3 of the PDF is done by Cloverleaf as part of the DTC receipt of the Reply message.

        So, if the reply is coming from a foreign system, how is the Driver Control from the DTC sent message supposed to transition?

        I would think this would be a common scenario:

        1. IB Cloverleaf thread –>
        2. DTC Thread –>
        3. OB Cloverleaf Thread –> Outside system (Driver Control exists in OB Msg)
        4. Outside System returns reply –> (Original Driver Control is lost)
        5. DTC Thread receives outside system reply requires original Driver Control? How is that possible?

        Is that the scenario you are describing? If so, how do you get the Driver Control from the OB message to get into the Reply?

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

Viewing 1 reply thread
  • You must be logged in to reply to this topic.

Forum Statistics

Registered Users
5,117
Forums
28
Topics
9,292
Replies
34,435
Topic Tags
286
Empty Topic Tags
10