Sending message to error database in pdupoc_write context.

Clovertech Forums Read Only Archives Cloverleaf Cloverleaf Sending message to error database in pdupoc_write context.

  • Creator
    Topic
  • #54301
    Carter Harrison
    Participant

      I am writing a protocol UPOC that uploads transactions via HTTPS.  The context of such a UPOC is ‘pdupoc_write’.  Everything works great when the upload succeeds and I return a disposition of ‘CONTINUE’.  However in the event of a failure I am updating the ‘USERDATA’ metadata field in the message and then I am returning a disposition of ‘ERROR’ using the following two lines of code.

      Code:

      msgmetaset $messageHandle USERDATA “Error message goes here”
      return “{ERROR $messageHandle}

      The issue I am having is that in the Send Fail TPS, the error message that I previously set in the USERDATA metadata is gone.  Furthermore when I view the message in the error database my metadata is also not present.

      What is the proper way to error out a message in the pdupoc_write context such that USERDATA is preserved?

    Viewing 5 reply threads
    • Author
      Replies
      • #80933
        Russ Ross
        Participant

          I would like to hope the context is not the underlying problem.

          This part of your code

          Code:

          return “{ERROR $messageHandle}

          has an unbalanced double quote.

          Here is an example of working code snippet, from a different context than yours, for doing what you described (looks mostly the same but uses list command to retrun disposition.

          Code:

                 # If we get here, the Bed field does not exist or is
                 # not all digits

                 # Tell them about it.  Use extra line feeds to make it stand
                 # out in the log.  It may help to put a copy of the
                 # message in the log.

                 echo “n$myname: Incorrect or missing PV1 field 3, subfield 3!”
                 echo “To the Error Database.  Msg is:nn$msgn”

                 # *ANYTIME* you send a mesasge to the Error Database on purpose,
                 # *ALWAYS* put the reason why in the USER meta data field.
                 # The ERROR return forces a Tcl error and thereby forces the
                 # message to the error database.  So, a user must be able to
                 # distiquish between real and forced errors.

                 # Note continuation of the command. The “” will insert a space

                 msgmetaset $mh USERDATA “Incorrect or missing PV1.3.3
                                 (Bed Location)”

                 # Return the ERROR disposition and force to Error Database

                 set dispList [list “ERROR $mh”]
                 return $dispList

          Another thought that came to mind is that only the inbound side (ex: inbound thread TPS, pre-route, xlate) of an integration typically can write things in the recovery DB, so if your proc is on an outbound thread then that could also come into play.

          In fact, we don’t even turn on recovery DB for our outbound threads since they never write to the recover DB anyway.

          Russ Ross
          RussRoss318@gmail.com

        • #80934
          Carter Harrison
          Participant

            Hey Russ,

            Thanks for the response.  The unbalanced double quote was simply a typo on my side.  Obviously that unbalanced quote would cause a TCL exception.

            Anyway I am thinking it is an engine bug – my code is doing more or less what yours is doing in terms of setting the metadata and returning the disposition list.

          • #80935
            Russ Ross
            Participant

              I’m still concerned that an outbound only thread doesn’t write to either the recovery DB or error DB from my past observations.

              Now if you wanted to route the desired replies or do something to generate routeable data from your outbound thread then you might have a better shot of getting it into the error DB along with your metadata.

              Russ Ross
              RussRoss318@gmail.com

            • #80936
              Carter Harrison
              Participant

                Russ,

                An outbound thread can definitely send messages to the error database.  That I’m am confident of because I am successfully doing it.  By returning a disposition of ‘ERROR’, the thread will re-attempt the transmission of the message up to the number of retries specified on the Outbound tab of the thread properties.  When the retries are exhausted the SEND FAIL TPS is invoked and then finally the message is sent to the error database.  The problem is that the pdupoc_write context does not seem to allow me to set the USERDATA and have it preserved up to the point where the message is finally written into the error database.  You can try this yourself by writing a very simple UPOC that does nothing but set the metadata on the message and then return a disposition of Error.

                Code:

                proc outboundProtocolUPOC { args } {

                global HciConnName HciRoot HciSite HciSiteDir
                   
                #Get current mode and engine context.
                keylget args MODE mode
                keylget args ARGS arguments
                keylget args CONTEXT context

                switch -exact — $mode {
                run {
                keylget args MSGID messageHandle
                msgmetaset $messageHandle USERDATA “My Error Message”
                return [list “ERROR $messageHandle”]
                }
                }
                }

                When the message finally hits the error database it looks like the following.  Notice that the USERDATA field is not set.

                Quote:

                > hcidbdump -e -L -c

                msg: 0x3000003c

                   msgType           : DATA

                   msgClass          : PROTOCOL

                   msgState          : Message undeliverable within retries (405)

                   msgPriority       : 5120

                   msgRecoveryDbState: Log:update (3)

                   msgFlags          : 0x8a02

                   msgMid            : [0.0.2]

                   msgSrcMid         : [0.0.0]

                   msgSrcMidGroup    : midNULL

                   msgHostId         : 3736122838

                   msgOrigSrcThread  : conn_1

                   msgOrigDestThread :

                   msgSrcThread      : conn_1

                   msgDestThread     :

                   msgXlateThread    :

                   msgSkipXlate      : 0

                   msgSepChars       :

                   msgNumRetries     : 2

                   msgGroupId        : 0

                   msgDriverControl  :

                   msgRecordFormat   :

                   msgRoutes         :

                   msgUserData       :

                   msgStaticIsDirty  : 0

                   msgVariableIsDirty: 0

                   msgTimeStartIb    : 1405090156.918(Fri Jul 11 10:49:16 2014)

                   msgTimeStartOb    : 1405090156.918(Fri Jul 11 10:49:16 2014)

                   msgTimeCurQueStart: 0.000(Wed Dec 31 19:00:00 1969)

                   msgTimeTotalQue   : 10.070

                   msgTimeRecovery   : 1405091900.885(Fri Jul 11 11:18:20 2014)

                   msgEoConfig       : 0x0

                   msgData (BO)      : 0x30000124

                   message           : ‘         8  999999999          1x0a’

                Previous recovery db state is 15.

              • #80937
                Russ Ross
                Participant

                  In that case, double check that the recovery DB box is checked in the NetConfig for this outbound interface.

                  Russ Ross
                  RussRoss318@gmail.com

                • #80938
                  Carter Harrison
                  Participant

                    Hey Russ,

                    The ‘Use Recovery database’ option is checked on all threads in the site, but I’m not sure I see the relevance to my problem.  As you know the recovery database is used to cache messages and their current state to disk in case the engine process dies and the contents of memory are lost.  Regardless as to whether or not the recovery database is in use or not, the messages and their metadata should remain in memory so long as the process is still running and the message has not been successfully delivered.

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