Siebel has multiple debugging tools, but sadly not much is said or written about them. Here is one tool that is used by a section of developers, but ignored by others.
The problem statement: Debug Interfaces using Siebel EAI
Siebel EAI was (and still is) considered to be something exciting to work in. It beats me why people think that, but that is another story.
The premise of Siebel EAI is simple – it provides a set of interface layer objects and helper objects that enables you to create interfaces with other enterprise systems. You recognize the trigger points, process flows, data structure, and let it rip.
The problem with any interfaces – data seems to develop a mind of its own once freed from clutches of the system. So you have developers on the both sides of the interface complaining:
- I sent the data, and I don’t know where it went
- I did not receive the data (of course, follows point 1)
- I swear I did not send this value
- I am not sure why you are trying to update the state as Karnataka, when I sent you Kansas
And, so on..
Get Siebel Interface Input and Output – The Old Way
If you have spent any time in Siebel you would have known that people have developed different ways of debugging this issue.
- Have a debugging step in the workflow/business service that can write inbound/outbound XML to file
I have seen/enabled this in production as well to debug interface issues. The writing of XML can be triggered by a simple LOV flag that can be switched off later to save processing time.
- Get the middleware to do the hard work
A lot of middleware systems would have their own framework to write both sides of the transactions at the flip of a switch. This solves about 80% of the issues, but you still see developers getting unhappy about it.
- Debug through Siebel logs
This solves 100% of the issues, but I personally believe developers have an aversion for logs.
You just bump up the log events to 4 for the Object Managers. refer to the logs of the interactive Object Manager (e.g. Siebel ePharma), or the listening Object Manager (e.g. Siebel EAI OM).
- Refer to Webserver logs
Yes. Been there, done that.
Debug Siebel Interface with EnableServiceArgTracing
EnableServiceArgTracing is actually easier to use, but often ignored.
Enabling the parameter is simple.
- Identify and locate the CFG for the application that you use
- Locate [EAISubsys] section in the CFG, and introduce an additional line1EnableServiceArgTracing = TRUE
- Identify the OM in Enterprise > Server Configuration
- Locate the EnableServiceArgTracing parameter and set it to TRUE
Then, you would have to increase the client logging levels to 4.
Once enabled the parameter ensures that all the input/output XMLs are written as *.dmp (dump) files in the same directory that Siebel runs. These files have the actual XML being passed around, and can be trusted more than your code :).