First let’s look at all the areas where Siebel EAI Queues stand strong.

1) No customisation needed
This is an OOB fucntionality. So, no custom coding is necessary. The vanilla BS can directly be called from the WF to help operate the EAI Queues. Custom code comes with its own sets of problems – dedicated human resources, architecting, implementing, testing, debugging, performance, scalability, expandability, robustness.

2) Reduced Implementation time
Implementation time is zero for Logging module. The only effort is to call the vanilla BS at all the places where we want to log messages.

3) Almost no debugging needed.
It is a Siebel OOB functionality. So, I can be sure there are no code glitches and resulting mishaps. If something doesn’t work as it says in the Bookshelf, either my usage is faulty, or it is a Siebel Product Defect

4) Lesser Team size as no concentrated effort on this module of the project.
Why have dedicated human resources working on the Logging and Error Handling mechanism?

5) Robustness
Extremely robust. It works with the file system. So, I don’t think there is a limit on as to how big a file can be stored here. The BS should ideally not fail unless some Siebel Server component itself is down.

6) Performance
Best performance you can ever get I guess. Mother knows best! If Siebel has designed and developed this, I guess, this is as good as it gets.

Do drop in some comments in case you feel I have not done justice to the positives part, and that there are points that I have missed out on. I will update the post accordingly.

But then, as with everything else on Earth, nothing is perfect. I am looking at a very simple requirement – I need to point out as to which message is an Inbound message, and which one, and Outbound. How do I implement it with the EAI Queue architecture?

Think, think, think…

The best I can think of is to extend the corresponding table for the EAI Queue, and the corresponding Business Components. I can also expose them on the UI for better handling. Question – After extending the Siebel objects, how do I use them. How do I populate this new flag called “Inbound Message” for eg, to TRUE or FALSE? The Logging of messages is being done through the vanilla BS. There is no code exposed. Now, if I have to populate this new column, I may be able to do it by scripting the vanilla BS – “EAI XML Queuing Service” after some work with the BS analysing Inputs and Outputs. Maybe, better still, just use a Siebel Operation step after the vanilla BS to update all the custom columns. But then, double query on the same record of the same BC, it’s a performance issue.

This is only one example when I could need to extend the objects with many different custom columns.

Let’s start playing! I want to link the Inbound and the Outbound messages. In a sense, there was an Outbound response to an Inbound request to Siebel. We should map which Inbound maps to which Outbound. Else, we may just be drowned in a deluge of messages. More custom columns, Siebel Links, MVLs, etc. as a solution to this. Maybe with some effort, it’s feasible.

I want to store many different types of files and many different types of messages – as in Erroneous Messages, Error Messages, Log Messages. More extensions.

Generally, all projects have a retry mechanism for all the erronous messages. I have seen SAP Business Services being integrated directly with Siebel EAI Queues. But, for custom queues, customization is the answer I guess.

With time, lots of useful and non useful data gets cluttered up in the Queue. A custom cleaning-up and archiving mechanism is thus inevitable.

Single most important issue I personally see with the vanilla EAI Queue approach is the fact that it interacts with the Siebel Filesystem and not the Siebel Database! The messages are stored in form of files in the Siebel Filesystem, eventually with the large number of Siebel messages coming in, the valuable hard disk space will be cluttered quickly. The Siebel FS size will increase. If there is a Siebel project I am working on, I would not mind having a slightly bigger database. But, unnecassary increase in the Siebel Filesystem is the last thing in the world that I would recommend. Don’t even get me started on the many of the file handling issues with many different flavours of UNIX in the market. I once ran into an implementation wherein I had to change the complete architecture from File based to DB based because the OS as a limitation could only accept at max 256 open file handles! Ridiculous as it may seem, it entailed many sleepless nights on my part to get everything up and woring within a week without any glitches – just can’t forget those!

All in all, my point of view is that, though you may use this implementation as an immediate quick fix, or a nice to have feature, Siebel EAI Queues feature fares horrendously on the Scalability and Expandability front.

If you are willing to play around with Siebel vanilla objects and extend them to suit you requirement no end, this may just be the solution for you. However, please do a deep insight and analysis of your requirements and other available options (basically custom, I guess) to get over this. It is more of an Analysts’ point of view to go with either of the two approaches.

Let me see if I can rope in somebody to explain in detail a nice custom Logging, Error Handling, Retry and clean-up / archiving mechanism.

Related posts:

1. Siebel – EAI Queue Okay, what are you thinking about? Is it Middlewares in...
2. Siebel – EAI Queue – Usage I had introduced the concept of Siebel EAI Queues in...
3. Siebel – EnableServiceArgTracing – Logging Messages Hi, We have already discussed at quite a length the...
4. Query on the Long Column or Field A typical problem in any EAI project. Others too!! One...
5. Siebel – EAI JMS Transport Hi All, After being a mere spectator and a regular...