A Better XML Logger

This article is Part 3 of Siebel Error Handling Approach


Last time we looked at an XML logger implementation using the vanilla "EAI XML Queuing Service", and ran through its shortfalls. This time we go through the design of a better XML logger, and introduce a new XML tagging feature.

The keys to building a better XML Logger comes back to understanding how the EAI XML Queueing Service works. The Queueing service takes a SiebelMessage, converts it from a PropertySet to an XML document, and saves it to a file attachment BC, all of which are standard Siebel operations. So we can use this design as the basis of our own EAI XML Queueing service implementation.

High Level Design

1. Create an IO around the EAI Queue/Item BC
2. EAI Queue Item will store References to our Error table, and XML Tagging information
3. Implement an XML query capability to extract information from the message
4. Dynamically Generate a Siebel Message around the EAI Queue structure, with our XML message as an attachment
5. Use EAI Siebel Adaptor to insert the XML message
6. Put a view on top of the above components to allow association to the error table, and to support querying through the UI

Build Steps

1. Create a new WF: "A Better XML Queuing Process"

This workflow has to support logging of either a SiebelMessage, XML document, or any other type of interface message Eg. If a SiebelMessage is provided, this has to be converted to XML Doc.

2. Generating the EAI Queue SiebelMessage

This WF step generates a SiebelMessage that contains the above interface message as an attachment.

There are 3 mains method for creating an instance of this IO

2. PRM ANI Utility Service
3. Scripting

PRM ANI Utility will easily generate a SiebelMessage structure which is 90% of your work, but it will not generate the File Attachment IC, so it has to be complemented with some scripting, or go for the declarative option using XSLT, which will allow us to generate a message complete with the Attachment IC without resorting to scripting.

3. Populating the SiebelMessage

This WF step populates the SiebelMEssage with actual data and will require some sort of transformation, so you have the following options

1. Data Mapper
3. Scripting

Once you have your SiebelMessage, using Data Mapper with inputs should be straight forward, however, using the XSLT method requires a little more work, because you will need a source document that contains all your source values, plus the XML payload. This can be achieved by using an empty SiebelMessage, and using dot notation to inject all your variables, including the XML payload, into the SiebelMessage header as attributes. These attributes would then be available in your source document to complete the transformation.

The following, is a list of the attributes required to produce an IO with attachment

XML Payload
Queued Timestamp
Reference Id
Reference Val2
Reference Val3
Sequence Number
Queue Name

The vanilla EAI XML Queueing Service produces attachments with a rigid format similar to this


The file type is hard coded to txt, and the filename cannot be controlled

The "MsgFileName" is of particular interest to us, as it allows us to produce a more meaningful filename.

4. Insert SiebelMessage

At this point, the populated SiebelMessage is ready to be Inserted via EAI Siebel Adaptor.

5. Build a nice UI to retrieve these XML logs, in association to its Error log.

Our XML files are saved to the Siebel file system, allowing users to retrieve the XMLs without going through file system permissions.

Message Tagging

Message Tagging provides the ability for a project to peek inside the XML message while in transport, and log certain elements/attributes for searching. This was one of the downfalls of EAI Queueing Service, as key details of the message were hidden, until you opened each message individually. This capability is important because Siebel zips the files stored in its attachment folder, and the contents become unsearchable, unless we tag it.

The following XML is a sample of an image notification message. The key pieces of information to be tagged from this message are the Id, PartyType, SourceSystem, and NewImageFlag.
<?xml version="1.0" encoding="UTF-8"?>
The schema would obviously allow for other types of notifications, and the Message Tagging capability would need to be flexible enough to cater for these other schema options. Message Tagging can be implemented with different kinds of tools, but at the heart of it, we need to query data from the XML.

A few Siebel favourites which can be used for deep hierarchy extraction are

1. FINS Industry XML Query Service
- Allows XPathish notation to be used

2. PRM ANI Utility Service.GetProperty
- Supply the IC name, and property to be extracted

3. WF Alias
- Similiar to Dot notation, but without the 75 character limitation

To be honest, none of the above options are particularly flexible, especially for dealing with namespaces, repeating groups, filtering, getting the nth child, dynamic querying etc. There isn't any vanilla querying capability, that meets this particular requirement.

So for your more ambitious Error handling needs, I would go for a Java based solution, that implements the full XPath standard, allowing all of the previous problems to be addressed. This would be implemented in a JBS, which accepts two arguments the XML, the XPath expression, and returns the XPath result.

To follow our theme of flexibility, the system shouldn't be hard coded to look for certain elements, the design should allow the customer to configure XPath statements, and associate them with an Interface, and maybe more specifically an Interface direction. Going down this path, takes us down a level of abstraction that is not available out of the box, which is a good thing, except for the poor designer who has to materialise this concept!


In this series on Error Handling in Siebel, we've taken a look into the key features of an Error Handling framework. We also delved into the complex error handling requirements of an EAI professional, dissected EAI Queueing Service, and provided the map for framework designers to build a better XML Logger. For an alternative approach, fellow Siebel expert Mik, also provides a different design that readers should also consider.

The capability to capture an XML message, along with its associated error detail, should be a core part of every projects toolset and there should be no doubt, on the importance of this feature. Error Handling Frameworks are not new to Siebel, but they are only available behind closed doors, so the comments are open to readers.

Do you have classy Error Handling ideas that you would like to share with the rest of the world?

The Future of Siebel CRM: Community Poll

This year marks the 20th anniversary of the founding of Siebel Systems. After being acquired by Oracle in 2005, Siebel CRM and the successor of Siebel Analytics, Oracle Business Intelligence, are still flagship products. Thousands of IT professionals worldwide make a living from these two systems.

Siebel CRM itself has been on the market for 17 years, and in the Siebel community there is much excitement about Oracle's commitment to strengthen the product's position, for example by delivering the Open UI framework. At the same time, many people wonder how many years Siebel has left.

Always with our fingers on the pulse of the Siebel community, we - a group of dedicated Siebel bloggers* - are working together to conduct a poll to find out public opinion on that question.

If you want to cast your vote on the poll, you can do it right here. Alternatively you can use this link to access the poll in a separate window or on a mobile device.

Thanks for your vote

Have an impossible day!

*The following blogs are hosting this poll:
(in alphabetical order)

CRM Conundrum
On Demand Education
Only Siebel
Siebel Essentials
Siebel Observer
Siebel Tech Blog
Siebel Unleashed

Did we miss your blog from this list? Do you want to participate? Then please contact Alex via twitter or Google+.