GeeKs Blogging @ dotCOM

Siebel – EnableServiceArgTracing – Logging Messages

by Nitin Jain

---

Hi,

We have already discussed at quite a length the logging methods, the most prominent of these being the usage of vanilla Siebel EAI Queues. You can read about the entire series through the following links:
A meeting with Siebel EAI
Siebel – EAI Queue
Siebel – EAI Queue – Usage
Siebel – EAI Queue – a Critique’

I recently came across another vanilla method (EnableServiceArgTracing) to log the messages. Using this, the various Siebel logs can be created, and the Input and the Output messages to some of the Business Services can be written in XML format to a file. These XML files would appear as Siebel Dump files with a “.dmp” extension. These can be read off any standard text reading tool like Notepad, Editplus, Notepad++, etc. This process works with EAI Siebel Adapter and EAI Dispatcher business services.

Usage
Read about the detailed Local logging in Siebel here.
Set the Siebel SIEBEL_LOG_EVENTS environment variable value to:
3 – Input property set as Output in case of Error will be received
4 – Both Input and Output property set would be received

Be ready to receive huge Log files in your Siebel Log directory, and exceptionally slow Siebel performance after enabling this. Logs are now being created for every step, so this is all the more logical.

Set the Server parameter, “EnableServiceArgTracing” to “TRUE”.
In case of dedicated, local, or sample based testing, edit the following sections in the .cfg and set the following:

[EAISubsys]
EnableServiceArgTracing = TRUE

Restart Siebel and you are ready to go.

Now, whenever a process is run, it would create logs. Also, in the same directory you would see .dmp, or the Siebel Dump files being created. These are XML files which would have the Input and Output property sets contained. You can open and view these in any text editor.

The names of the files created are in the format:
_input_args_.dmp OR,
_output_args_.dmp

The main advantage of this method is that it does not require any changes, or switches in the main process to get the debugigng information. So, it is as clean as can be. Also, we can do this easily on any environment, TEST or any other.

The main disadvantage I see with this approach is that it logs Inputs and Outputs of only the EAI Siebel Adapter and the EAI Dispatcher Business Services. More usually, the integration is done using many other services, wherein a proper logging and error handling architecture becomes mandatory. So, I cannot do away with the other fancy stuff I generally incorporate into my architecture for that reason I guess!

I wish Siebel provided an easy way except studying Logs, to know which all Business Services or Workflows were invoked, and what all inputs and outputs were provided, whenever a complex process was invoked. It would make my life so much easier..

Related posts:

1. Siebel – Enable Detailed Logging – Local Very often we come across scenarios wherein the process is...
2. Siebel- Close Browser window when logging off In case of standard interactivity applications like eSales , eService,...
3. Siebel – EAI Queue Okay, what are you thinking about? Is it Middlewares in...
4. Siebel – EAI Siebel Adapter – Looping Multiple Records This is a follow-up post on the post, Siebel –...
5. Siebel – EAI Queue – Usage I had introduced the concept of Siebel EAI Queues in...
6. Siebel – FINS Industry XML Query Service “Extracting values from a tag deep down in the Hierarchy.”...
7. Siebel – SIA BC Utility Service – Loop multiple records This is a vanilla business service which provides an extensive...