A Better XML Logger

This article is Part 3 of Siebel Error Handling Approach

Introduction

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

1. XSLT
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
2. XSLT
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
Comments
Queued Timestamp
Reference Id
Reference Val2
Reference Val3
Sequence Number
Status
Queue Name
AttachmentIsTextData
Extension
MsgFileAutoUpdFlg
MsgFileDate
MsgFileDeferFlg
MsgFileDockReqFlg
MsgFileDockStatFlg
MsgFileExt
MsgFileSrcType
MsgFileName

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

s_eai_queue_itm_1-62O6DB.txt

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"?>
<PartyUpdate>
   <PartyIdList>
       <PartyIdDetails>
           <Id>1-XXXX</Id>
           <Type>Siebel</Type>
       </PartyIdDetails>
   </PartyIdList>
   <PartyType>PERSON</PartyType>
   <EventSource>ESB</EventSource>
   <SourceSystem>Imagr</SourceSystem>
   <NewImageFlag>true</NewImageFlag>
</PartyUpdate>
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!

Conclusion

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?



Reactions:

0 comments:

Post a Comment

Comments are open to all, please make it constructive.