1) It can handle large messages, meaning it has no size limitations on messages.
2) SAX parser has a better runtime performance than a DOM parser.
Message mapping works internally using Queues. These queues can be used as debugging functionality when it comes to handling messages. They can be used as step by step check of mappings and are applicable to any step in the mapping program.
Lets take a simple example and see how message processing is done using Queue.
The above example illustrates on how the queue stacks up the elements from the source xml.
If no further elements are present at a particular hierarchy level, a context change is inserted in the queue.
The following scenario demonstrates the working of queues.
This Scenario is from a one level source hierarchy structure (MT_SOURCE) to a flat target structure (MT_TARGET).
Execute the mapping program in the test mode with appropriate data.
Now you can apply Display Queue function to each element and standard functions that are used within the mapping program.
Right click on the elements displayed in the Mapping editor and select Display Queue function to display the content of the Queue.
The mapping program fills in DESCP element based on specific KEYNAME value. In this case it is MATNAME.
After using the Display Queue function you can see that the KEYNAME element is filled up with 3 different values MATCODE, MATNAME and MATPRICE. Now that the condition is true for only MATNAME (as specified), the Equals Function is only true for the second test condition (i.e. MATNAME) and false for the rest of values. This way we can validate the mapping program for an input value. Now the resulting DESCP element has only one value in the queue i.e. TEST2.
Above Fig clearly depicts the process flow explained above.
Note that the queue is displayed for all the elements be it user-defined elements or standard functions.
Lets have a closer look at the queue entries in the DESCP element and find what the different entries represent.
Firstly the gray and the black rectangle at the beginning and at the end of the queue represent the initial and the terminal context change. These are not passed to the queue for message processing, so these are not used in user-defined functions.
The inner context changes are represented by light gray color. They are represented in user-defined functions by the constant ResultList.CC.
The actual Data is represented in the white rectangle.
Suppressed values are represented by blue rectangles, in our case the suppressed values are TEST1 and TEST3, they are highlighted when the target elements are created as shown in the fig above.
They are represented in he user-defined functions by the constant ResultList.SUPPRESS.
So, if you are using a user-defined function to enhance your mapping, the queue that is displayed above for DESCP element will result in a string array that is built up of:
The above diagram clearly gives you an overall view of how messages are processed at any given point of time.