Using DOM4J in XI – A More Sophisticated Option for XML Processing than SAP XML Toolkit

CONTENT

1. What is SAP XML Toolkit? 2. Limitations of SAP XML Toolkit. 3. What is DOM4J & How is it More Sophisticated than SAP XML Toolkit? 4. How to Use DOM4J in XI? 5. Conclusion

DETAILS

1. What is SAP XML Toolkit?

SAP XML Toolkit is based on Java 2 Platform, Enterprise Edition (EE) v1.3 API Specifications. Therefore, it inherits the limitations of J2EE v1.3 for processing an XML message in XI. For example, SAP XML Toolkit doesn’t provide support for XPath which is a more efficient approach of navigating XML than traversing it with SAP XML Toolkit. DOM4J is an Open Source XML framework which provides a more sophisticated option (including the support for XPath) for XML processing than SAP XML Toolkit in XI. The objective of this weblog is three fold: (1) to highlight few limitations of SAP XML Toolkit in processing an XML message in XI, (2) show how to use DOM4J in XI as a relatively more sophisticated option for XML processing than SAP XML Toolkit; and (3) to provide some sample code for DOM4J.

2. Limitations of SAP XML Toolkit.

SAP XML Toolkit is based on Java 2 Platform, Enterprise Edition (EE) v1.3 API Specifications which in turn uses Java API for XML Processing (JAXP) v1.1. Therefore, SAP XML Toolkit is limited by the XML processing power offered by JAXP v1.1. This version of JAXP doesn’t offer the ability to use XPath. XPath can be very useful in mapping source XML to target XML in XI. It provides us the ability to get the value of an XML tag WITHOUT traversing the whole XML message. This gives us a significant performance advantage during runtime in XI if Java mapping is used for mapping the source to the target XML. Along the same lines, JAXP v1.1 doesn’t give us an easy way get the value of a given XML tag (see Figure 1). FIGURE 1: getNodeValue() method of Node Class Returns NULL when Invoked on an Element in JAXP v1.1 (reference)

3. What is DOM4J & How is it More Sophisticated than SAP XML Toolkit?

DOM4J is an Open Source XML framework for Java. dom4j allows us to read, write, navigate, create and modify XML documents. DOM4J integrates with DOM and SAX and offers full XPath support (reference). DOM4J has been in the industry for over five years now and I have personally used it with other EAI products and have deployed and supported it in production. It provides full XPath support along with utility methods to get the value of a given XML tag (notice how the getText() method of DOM4J’s Node class is used in the next section) which is currently not available in SAP XML Toolkit. Though DOM4J comes with an embedded parser, but it also provides us the option of using our choice of XML / SAX parser (crimson.jar or xerces.jar) if required. For additional details on DOM4J, please refer to the Quick Start Guide, API documentation and FAQs.

4. How to Use DOM4J in XI?

The following steps show how to deploy and use DOM4J in XI. Sample code is also included to show how to use XPath with DOM4J in XI to accomplish mappings and to manipulate an XML message: NOTES: I have also covered these steps in my previous weblog, SLAW, a New Logging & Tracing Framework for XI. in section, ‘How to Use SLAW for Error Handling & Logging/Tracing in XI?’. Secondly, please make sure to see the SAP note number 753294: Syntax error while compiling message mapping before applying the steps described below. Step 1 – Download the DOM4J java archive (dom4j.jar). Step 2 – Download Jaxen java archive (jaxen.jar). This is required to use XPath expressions with DOM4J. Step 3 – Import both dom4j.jar and jaxen.jar into XI such that the functionality is globally available as compared to being available only at the message or the data element level. This can be done by saving both the jar files (dom4j & jaxen) in the following three sub-directories (shown in figure 2) under the j2ee directory on the XI server and restarting XI’s Java Stack for the JAR to be loaded into JVM: – j2eedeployinglib – j2eeclusterdispatcher insystem – j2eeclusterserver0 insystem FIGURE 2: Directories where DOM4J JAR files are Saved(Path shown up till bin for dispatcher & server0. Actual dir is system in bin) Step 4 – Using DOM4J in Java Mappings in XI. The purpose of this section is to showcase basic XML processing using DOM4J. Following is the sample code that shows how to import DOM4J classes while developing Java Mappings in XI (see figure 3), to use DOM4J to populate an outgoing XML (e.g. target application XML) with data from incoming XML (e.g. source application XML) (see figure 4) and to remove and add XML tags (see figure 5 & 6). Please note that there is a reference of ‘SLAW’ in the sample code which stands for the SAP Logging API Wrapper. I have discussed SLAW in detail in my previous weblog, SLAW, a New Logging & Tracing Framework for XI.. FIGURE 3: Importing DOM4J Classes in Java Mappings in XIFIGURE 4: Using DOM4J to Move Data Between XML MessagesFIGURE 5: Using DOM4J to Remove CDATAFIGURE 6: Using DOM4J to Add CDATA

5. Conclusion

This weblog has highlighted certain limitations with the existing version of SAP XML Toolkit (based on J2EE v1.3) and introduced DOM4J, an Open Source XML framework, which provides a more sophisticated option for XML processing in XI than SAP XML Toolkit. It has also covered details of how to use DOM4J in XI along with sample code. It is important to note that DOM4J is only for XML processing and SAP XML Toolkit offers other APIs such as javax.mail.*, javax.ejb.* and javax.security.* which can be necessary to implement other functionality in XI. In addition, it is also possible that the next version of SAP XML Toolkit may offer better functionality for XML processing than the current toolkit.

Hi Xin,That is a good questions. If a new version of SAP XML Tool Kit comes out with the same functionality (or better), then that means at least two things: either we keep the current code as is and use this new version of SAP XML Tool Kit in all development going forward OR retrofit the current code with the new version AND use it in all development going forward.

I think the best case scenario will be if SAP decides to use DOM4J (open source framework) to enhance the current SAP XML Tool Kit instead of reinventing it… 🙂

Please let me know if you have any further questions. Thanks for asking a great question.