- This topic has 6 replies, 2 voices, and was last updated 10 years, 3 months ago by
.
-
Topic
-
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?
-
Replies
-
-
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 $dispListAnother 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 -
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.
-
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 -
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 contextswitch -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.
-
-
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.
-
- The forum ‘Cloverleaf’ is closed to new topics and replies.
