Has anyone used the Error DB UPOC – errordbtps and looked at USERDATA?

Tagged: errordbtps

This topic has 4 replies, 2 voices, and was last updated 4 years, 12 months ago by Jim Kosloskey.

Creator

Topic
December 9, 2019 at 2:48 pm #114170
Peter Heggie
Participant
We are trying to use a portion of the sample code in ../cis19.1/integrator/tclprocs/errordbtps.tcl.

This is the proc that you can specify either in a Thread configuration (on the main properties tab, in the field Error Database Procs), or in a Process configuration (also on the properties tab, in the field Error Database Procs). This proc receives control when a message is about to be placed in the Error Database and allows you to change the disposition – for example, to retry the message.

I believe it is working – we check the context and when it is “error_db” we change the disposition to RETRY. We put echo statements in it and see them displayed in the log.

Is the error message text, which is normally seen in the process log, available somewhere in the message metadata? I am retrieving the contents of USERDATA to display, but it seems to be empty. Is there another metadata field that holds an error message?

Thanks

proc cl_retry_err_msg { args } {
keylget args MODE mode
set dispList {}

set module “cl_retry_err_msg”
set debug 2
if {$debug > 1} {echo “$module debug enabled”}

switch -exact — $mode {
start {
if {$debug > 1} {echo “$module start mode”}
}

run {
keylget args CONTEXT ctx
if {$debug > 1} {echo “$module context: $ctx”}

keylget args MSGID mh

set userdata [msgmetaget $mh USERDATA]
if {$debug > 1} {echo “$module userdata $userdata”}

if {$ctx ne “error_db”} {
lappend dispList “CONTINUE $mh”
if {$debug > 1} {echo “$module context $ctx not error_db – continuing message”}
} else {
lappend dispList “RETRY $mh”
if {$debug > 1} {echo “$module context $ctx = error_db – retrying message”}
}
}
}
return $dispList
}

Peter Heggie
Creator

Topic

Viewing 3 reply threads

Author

Replies
- December 10, 2019 at 11:22 am #114203
  Jim Kosloskey
  Participant
  Peter,
  
  I don’t have an answer for you but I am curious.
  
  By what is seen in the Process Log are you talking about the ERR notation or something else. I guess I am just wondering exactly what information you are looking for.
  
  If it something generated by the engine, then I don’t think it would b in the USERDATA.
  
  On the other hand, if it something generated b a proc before the message is ERRORed, then I think that proc would need to place a key/value set in the USERDATA.
  
  email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.
- December 12, 2019 at 8:31 am #114277
  Peter Heggie
  Participant
  Right – that makes sense. The error from a DB outbound protocol that is returned to the engine is probably not part of the message context.
  
  We will probably have to put our error handling in the DB stored procedure that is being invoked. We have occasional deadlocks, with an error text like this written to the process log:
  
  [dbp :wrte:ERR /0:to_batchRpt_db_0:12/10/2019 16:04:21] Transaction (Process ID 634) was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction.
  [java:wrte:ERR /0:to_batchRpt_db_0:12/10/2019 16:04:21] Call to “doMsg” returned error string “BADDATA caught exception trying to processMessageFromCloverleaf: Failed to write message to database: Transaction (Process ID 634) was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction.”. Returning bad send to engine.
  
  We want to RETRY these types of errors.
  
  But sometimes we get content-related errors like this:
  
  [dbp :wrte:ERR /0:to_batchFile_db_0:12/11/2019 11:36:40] Conversion failed when converting date and/or time from character string.
  [java:wrte:ERR /0:to_batchFile_db_0:12/11/2019 11:36:40] Call to “doMsg” returned error string “BADDATA caught exception trying to processMessageFromCloverleaf: Failed to write message to database: Conversion failed when converting date and/or time from character string.”. Returning bad send to engine.
  
  And we do not want to RETRY for these.
  
  I’m guessing that there is no way for this error DB tps to get the error text and make a determination of the type of error occurring. I will investigate adding a Try Catch in the stored procedure.
  
  Peter Heggie
- December 12, 2019 at 10:12 am #114278
  Jim Kosloskey
  Participant
  Is it possible inside the DB Outbound Protocol invocation of the SP to specify arguments?
  
  If so, what I like to do with DB Stored Procedures (via ODBC in my case) is to have an argument for the Stored Procedure to return 2 items (as separated sub-fields if you will). The first sub-field is the DB Error Code encountered if there is an error or zeros if there is not. The second sub-field is the text associated with that DB Error Code.
  
  That then allows me to make any decisions inside my Tcl code I would like about what happened inside the SP.
  
  Unfortunately, there I have discovered a discernible architecture to the various DB Error Codes from the myriad of DBs that would allow intelligent triage based on the code.
  
  That leaves textual evaluation which is tedious an unreliable in my opinion since the DBs can change the txt any time they want and rarely specify that in release notes, etc.
  
  That will require you to have the SP properly modified to trap the errors (appropriately placed Try), extract the text (the Try should provide the code I think) then set the argument sub-fields.
  
  email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.
- December 26, 2019 at 8:03 pm #114532
  Jim Kosloskey
  Participant
  Peter – how did you end up resolving this?
  
  email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.
Author

Replies

Viewing 3 reply threads

You must be logged in to reply to this topic.