EAI XSLT Service namespace limitation

If you've ever tried to use EAI XSLT Service to transform a XML message with more than 30 namespaces, you will get the following dreaded error.

"(xsltransform.cpp (564)) SBL-EAI-04267: XSLT Processing Exception: SAXParseException: An exception occurred! Type:RuntimeException, Message:The buffer manager cannot provide any more buffers"

Googlers will find this information useful, because this error is not documented on Support web, and unless XML is prolific in your Enterprise, you are not likely to run into this problem.

[Root Cause]

Since Siebel is a packaged software, it is not well known that it uses the Xalan 1.5 engine to transform our XML, but this fact can be verified by the existence of xalan-c_1_5_0.dll in the Siebel Tools/BIN folder.

A quick search of the web seem to yield no problems with namespaces with this XSLT engine, so its up to us to dig further into this problem.

If we start by isolating the Xalan component, and see if we perform the XSLT transformation directly using the Xalan DLL, we can test for this namespace limitation and determine if this is a Siebel or Xalan problem.

You can still find the Xalan 1.5 engine on the web; if you want to try it out, go over to the Apache website and download it from the archives.

http://archive.apache.org/dist/xml/xalan-c/binaries/

Finding a Xerces parser compatabile with this engine was more of a challenge, since Xalan 1.5 is obsolete, no archive is kept of the parser.

After 15 minutes of fruitless searching, it occurred to me, that i can use the Xerces DLL from the Siebel directory.

[XSLT transformation with Xalan]

1. Download the Xalan 1.5 binary from Apache.Org
2. Extract the ZIP into any directory
3. Goto your Siebel Tools/BIN folder and copy the xerces-c_2_2_0.dll to the Xalan release folder
4. Supply a XML file with more than 30 namespaces
5. Supply a XSLT file
6. Run the transformation

If you've followed the above steps, you should get the following error.



Bingo!, its the exact same error that we recieved in Siebel.

This is very interesting, so does the problem still occur with the latest version of Xalan?

I used Oxygen 8.2 which comes with the latest Xalan 2.7, and it passed the 30 namespace test.

So we can confirm that this defect is caused by the Xalan 1.5 engine (Oracle engineers take note).

But since this engine is a core part of the product, dont bet on it being upgraded any time soon. Defects in the core Siebel product cannot be easily fixed, so what options does the hapless customer have?

1. [Reduce namespaces in XML]

You can try requesting for your Enterprise to reduce the number of namespaces that is sent to your Application, although this is out of your control, it is worth trying.

2. [Strip out the unused namespaces before transformation]

The idea is that you pass your incomming XML message to a BS utility to strip out the un-needed namespaces, and pass it to the EAI XLST Service for transformation, ensuring that it has less than 30 namespaces.

The above two methods have the following advantages
1. Can be implemented quickly
2. Has very little impact to testing

but it has the following disadvantages.
1. Not scalable
2. Namespaces can change adding to maintenance
3. All namespaces may be needed
4. Different namespaces may be needed for different messages

3. [Use external transformation engine]

An alternative is to replace the default Siebel Xalan engine and use an external transformation engine.

This allows us to bypass the limitations of the standard EAI XSLT Service, and it also provides us access to a more modern XSLT parser.

To achieve this, Siebel provides us with a few mechanisms to extend vanilla functionality by calling on external code.

1. SElib.dynamicLink
2. EAI DLL Transport
3. Java Business Service (JBS)

Although we can use any of the above, methods to call external code. I'll look specifically at using a the JBS option to workaround this product defect, because all the tools and software needed are free and open source.

Using a JBS to call a more modern XSLT parser, will allow our transactions to be more efficient, as well as offering the latest methods available in the XSLT standard.

This is exciting stuff so put that holiday on hold, until this comes out.

SHARE