Skip to Content

Think objects when creating Java mappings

Most of the XI consultants come from SAP (ABAP) background and face many problems when they need to implement Java mapping for the source to target transformation. This weblog attempts to give a guideline on approach to be taken when developing mapping programs.

Assuming we have a IDoc to flat file scenario, let us first have a look at the source IDoc structure.

Source IDoc XML structure

Graphical reprensentation for quick understanding


Starting from the lowermost level of T08 as a composite structure i.e. made up of other simple properties, think of T08 as a class having all string properties with names same as that of the tag names of IDoc XML. So a typical T08 class structure would be,

The fastest way to create this class could be going to the segment editor in SAPGUI, copy all the property names and create String variables with all these names. Next, assuming that you are using NWDS as your development tool, create the getter / setter methods for all these properties. Matter of a right click only!!! Right click anywhere inside the class body, select Source –> Generate getter / setter –> Select All.Click Ok.

Now that we are done with T08 class, lets move on to its parent i.e. A00. Create the A00 class on the similar lines of T08, key point to note is, A00 should have a class member of type T08 .

Generate the getter / setter methods for this class too.

We are now ready with the basic data structure in which the data would be stored at runtime and following steps with more or less modification could be taken as the basis for the actual program logic

1.Based on the occurrence of a particular sub-structure the data type of the class member should be decided. E.g. in our case, T08 was having only one occurrence so we declared A00 with a class member T08. If T08 had multiple occurrences, then declare a Vector / Arraylist of T08 as a class member for A00.
e.g. private T08 t08; //reference to the T08 structure i.e. for single T08 occurrence.
private Vector t08List ; //reference to a dynamically growing Vector of T08 structures.

2.If multiple source structures appear in the input to the mapping program , simply have a class level member ArrayList or Vector which would contain various A00 structures.
private Vector idocList; // list of idocs

3.Build the child object completely before adding / setting it to the parent object. So , in our case, we have to make sure that we set all the possible properties of T08 before adding it to A00 structure.

4.The sequence of building all the hierarchical objects should be from the lowermost composite structure to the top level composite structure. So a typical code based on this approach would look like ,

5.So once you are done with populating the complete data structure , imagine how handy it is to refer any value within the data structure using the getXXX methods.

Advantages of this approach:

1.You can write more readable, modular, and maintainable code.

2.Use of objects along with Java’s predefined data structures, collections helps you reduce programming effort, increases program speed and quality as these predefined structures are very well designed and well tested. Performance & efficiency overheads as well as chances of runtime errors associated with usage of Arrays can be safely avoided.

3.toString method of the composite structure classes can be overridden to provide any specific output requirements. E.g. if FILE_TYPE attribute of A00 should appear with double quotes in the final output, the logic could be written in toString of A00 class. toString is the method which if overridden, gets called automatically say if we use a statement like

You must be Logged on to comment or reply to a post.
  • Creating objects for xml structures? Take a simple edi xml. Are you going to create 30 classes (minimum) and 200 getter & setters for implementing the same or just 50 lines of xml parsing code in a single class. Think twice!
    • Hello Felix,

      I agree. And especially in the EDI case, you have the "problem" of qualifiers, which need to be observed for OO. So for example in EDIFACT you have a Segment NAD (Name and Address Details) and the first element is the qualifier, which could be "by" for a buyer. You normally would want to have a "Address" Object which is extended by "BuyerAddress".

      You can then pass the supertype around. This is the big advantage where you could reuse OO code. If you only use it to hold strings using hashtables or dom could be much more dynamic.

      BTW: creation of the Java Objects from XML Structure could be automated with JAX-B (or other XML Binding Technologies). But you still have a lot of getters and setters. At least the unmarshalling (parsing) and marshalling (serialization) is done automatically for you.


    • You can always take a call depending on the situation. For simple, 3-4 level deep structures with moderate number of attributes, this approach would help you to generate very flexible / maintainable /extendable code.