Error trap TPS
When an error message is transitioned to the error database, you can control the event processing through the error trap TPS. You can specify procs to be called before messages are sent to the error database.
For example, you can show, save, stop, resend, or NAK, the message before it goes into the error database.
Configuration locations include:
- Network Configurator:
The error TPS can be configured in the protocol thread and process levels. The NetConfig is:
- Process level:
process helloworld { { ERRDBTPS { { ERRTPSPROCS {{ARGS {{}}} {PROCS cl_show_err_msg} {PROCSCONTROL ENABLED}}} { RETRIES 2 } } } }
- Protocol
thread:
protocol in { { ERRDBTPS { { ERRTPSPROCS {{ARGS {{}}} {PROCS cl_show_err_msg} {PROCSCONTROL ENABLED}}} { RETRIES 2 } } } }
- Process level:
- Engine Output Configurator:
EO module
dbi:etps
- Database Administrator:
501: Error database TPS error
- TPS disposition:
A RETRY disposition is in the
DispositionList
of Tcl and Java UPoC. - Error database TPS:
The error database TPS gives you a control point before a message is written to the error database. This means you have the opportunity to change the error message content and to route the message to another context.
For example, you can:
- Change the message content to add information before the message goes to the error database.
- Stop the message so it does not go to the error database.
- Send a NAK to the source to notify there is an error when processing the message.
- Save the message to a file or another external source, and resend the message that is based on it.
Samples and templates include:
- errdbtps.tcl
-
errdbtps_template
- %HCIROOT/tclprocs
TPS mode message flow
These TPS processing modes indicate the timing and scenarios when the engine calls the corresponding Tcl code fragment:
TPS_MODE_START
When the thread has started, but is not yet scheduled to run and process events, the engine calls the thread initialization function. This is the function in which it calls the DBI initialization function for error and recovery database setup. During DBI initialization, it sets up DBI thread specific data (DTD data). In this stage, it gets error database TPS specific data from the NetConfig file. It then sets the TPS context in the xlate thread data and protocol thread data. Then, it runs the TPS start mode.
TPS_MODE_RUN
When the thread is processing an event and it goes to an error, it calls a function to transition a message to the error database. In this stage, it gets the TPS context from the DTD data. Then it sets the mode in TPS context to
TPS_MODE_RUN
, and runs TPS run mode code. After this completes, the message is written to the error database or goes somewhere else depending on the disposition state returned from TPS.TPS_MODE_SHUTDOWN
When the thread is shut down, it calls the DBI shutdown function to release resources that are related to the error and recovery database. In this stage, it runs the TPS shutdown mode code. Then, it frees the TPS context and destroys the Xlate thread data and protocol thread data to free the resource.
TPS_MODE_TIME
is not supported. Error database TPS message flow
When the process transitions a message to the error database, it goes through these steps:
- Updates the monitorD statistic information that is based on the EDB state of the message, then goes to the next step.
- Updates the recovery database state of the error message. If this fails, then it returns with an error; otherwise, it goes to the next step.
- If message tracing is enabled, then it writes the tracing information for the error message. If this fails, then it returns with an error; otherwise, it goes to the next step.
- If an error database TPS is configured, then it calls the TPS procedure stack and passes the error message and error context for processing. After TPS processing, it does the callback function for disposition. When the disposition is continue, it goes to next step. Or, it goes to Step 1 when the disposition is error, or ends/drops the message when another disposition is found.
- Writes the error message to the error database. If this fails, then it returns with an error; otherwise, it goes to the next step.
- Writes the error message context to the error database. If this fails, then it returns with an error; otherwise, it goes to the next step.
- Removes the message from the recovery database.
Example: Finding and resending a message in ErrorDB
User 1 needs to search the Error Database for a specific message, edit it, and resend it.
To do this, User 1 launches the Error DB IDE tool and performs a regular expression search for “12345.”
One or more transactions are returned from the search. User 1 selects a transaction and edits it to change the user ID from “12345” to “54321.” The edits are temporary and not made to the stored data.
User 1 then resends the transaction.