The longer I write object oriented stuff, the more I learn and realize: as a matter of fact, the approach I am suggesting here won’t sound any newer for object oriented gurus, but does for me, who too often has a very empiric approach (mercy on me!), and hopefully will be useful to other people on SDN.
When I write a Java mapping for SAP XI, I usually use DOM, which is my favourite technique, no doubts. Please be aware that what I’m going to show you here is no way the formula that will resolve any situation, but rather a suggested approach. An approach that, truly, can be applied in a number of scenarios: the same stuff can be done if you prefer Java mapping using SAX, JDOM, or whatever. And more, as ABAP mapping is also based on an object oriented paradigm, this can be easily applied to the ABAP world as well! (I don’t have time to show this now, too, but I can guarantee it’ll work.)
The Helper Class
The driver question is: what are the main tasks of a Java mapping (using DOM in this case)?
1. parse input document
2. getting a new document for output result
3. working on root element
4. serializing output document to stream
Starting from these basic tasks, we can build an abstract class that implements them as methods. Why abstract? Well, an interface would be useless enough, as we’re aging to write some real code inside it. Let’s say that the abstract class in this case is a good middle course between an interface and a real class. First fo all, it would make no sense to instantiate and use this class directly. Second, we’ll be leveraging on nice features in NWDS (NetWeaver Developer Studio) based on this.
Take a look at the code of my DOMTranformation class, and get an idea. The class name comes from the basic idea that this class is a derivation of the too generic StreamTransformation SAP standard interface which we must always implement to get a workin’ Java mapping.
What do we have, then?
Of course we have the promised methods to perform our afore-said basic tasks, plus the always-needed
method. Following this very easy way of thinking, you can embed in this java mapping superclass any other frequently used methods.
Well, now you probably want to build the “real” mapping. So proceed as follows:
– create a new Java project
– extend your build path adding the usual aii_map_api.jar
– extend your build path again, adding the project in which you put our DOMTransformation class. At the time of “installing” the whole thing on XI, you’ll have to create two Imported Archives: one .jar for the DOMTransformation class, in a base SWCV/namespace, and onw .jar for the real java mapping(s).
– create your java mapping class: as in the picture below, you don’t need anymore to declare the StreamTranformation interface, but rather to extend our DOMTranformation.
You can search the superclass (DOMTransformation) by using the Browse button (highlighted with lime green) which will popup a class search window (highlighted with lime green as well). Be sure to flag “Inherited abstract methods”: this is no great help actually, but at least we’ll have the core
execute(InputStream input, OutputStream output)
method ready to implement in the new java class (and that’s one of the reason why we used abstract class!).
Now the real java mapping code follows, in which you’ll have to perform only the real xml message transformation, as basic tasks will be accomplished by the superclass DOMTransformation. Also, please find in the code below relevant comments!
As already said, this will be no news for object oriented minded people, but at least I hope it will make some people life easier. And more, that it could serve as a basis for many other weblogs/implementations (ABAP, JDOM, SAX, etc).