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.

Mobile/Dedicated Client

• Identify and locate the CFG for the application that you use
• Locate [EAISubsys] section in the CFG, and introduce an additional line EnableServiceArgTracing = TRUE

Web Client

• 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 :).