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

[Peter Heggie]

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

Topic

[Jim Kosloskey]

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.

[Peter Heggie]

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

[Jim Kosloskey]

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.

[Jim Kosloskey]

Peter – how did you end up resolving this?

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

[Author]

Replies