Thursday, Aug. 17, 2017

Troubleshooting Transaction Router

Written By:

|

March 10, 2012

|

Posted In:

Transaction Router, a component on the server side, calculates visibility for transactions and routes data to mobile users. It picks up the transactions from DOCKING\TXNPROC and determines which mobile users should receive them. It then sends these DX files to each Remote client’s outbox on the server in the docking directory based upon visibility and routing rules. After Transaction Router completes its task, it instructs Transaction Processor to purge the DX files in the DOCKING\TXNPROC directory based on the Transaction Processor’s parameter and clean .dx files iterations.

There are two database cache files used by transaction router : Visdata.dbf and dobjinst.dbf.

dobjinst.dbf is the visibility database and visdata.dbf is the visibility ID database.
Basically Transaction Router will check these files to get additional information on other tables affected by visibility changes and cache this information locally to eliminate the need to make multiple trips out to the database. You can use visutl utility to troubleshoot visibility database.

Transaction Router Errors:

The Transaction Router Siebel Remote server task may fail under certain conditions which will cause a backlog in the transactions to be routed to Siebel Remote mobile users and regional nodes.

There are 4 main causes for Transaction Router failures:

1. Connectivity and RDBMS behaviors.
2. Errors when reading from and writing to .dx files.
3. Errors when accessing cache files and docking directories.
4. Visibility Database (visdata.dbf) corruption.

Troubleshooting :

The first step in diagnosing a Transaction Router failure issue is to try to determine whether the failure was a one-time occurrence or a persistent failure. This is easy to achieve by simply trying to restart the Transaction Router. If the Transaction Router starts and continues processing without further error then it is likely that the cause may be poor network connectivity, database connectivity, or another intermittent system issue at the time of failure. You can then inspect the log file to see why the Transaction Router failed. If the Transaction Router fails again after restarting then it is likely that you have a persistent failure which will require some action to be taken before it can restart and continue without failing. In that case you can increase the log levels and inspect the resulting logs.



Share This Article

About Author

Rohit

Siebel Technical Consultant

  • Matt

    Thanks. Nice article…

  • Tim

    Thanks, really helpful