cancel
Showing results for 
Search instead for 
Did you mean: 

Model based message mapping?

Former Member
0 Kudos

Hi guys,

We're doing a message mapping based on external XSD schemes.

The schemes are quite large and complex with a lot of extensions.

After importing the XSD into the mapping we realized that the XI mapping is data based but not model based.

Means that if two nodes inherit from the same type, the elements of that type appear in both nodes and have to be mapped twice.

Is there a way to avoid that?

Is there a way to realize model driven mapping? Maybe by NOT using message mapping??

Thanks in advance

Karsten

Accepted Solutions (1)

Accepted Solutions (1)

Former Member
0 Kudos

Karsten,

>>Means that if two nodes inherit from the same type, the elements of that type appear in both nodes and have to be mapped twice.

I am lost here. Can you please explain this with an example here.

Also, it is not advisable to go for a XSLT mapping if the data involved in the mapping is gonna be huge. In terms of performance, XSLT is the least preferred one.

Regards,

Jaishankar

Former Member
0 Kudos

Hi Jai,

Let's say we have a node called mammal with the element "age".

Then we have a male with the element "muscels" and a female with the element "measures".

They both inherit from mammal. So they both have "age" beside "muscels" and "measures" respectively.

Male and female are integrated with a choice relationship so there can be male OR female in one message. (with createIf construction in message mapping)

In the message mapping the "age" appears twice: As a child of male and female and therefor has to be mapped twice. That's data based mapping and not model based.

I thought XSLT in the ABAP stack is not that bad in performance?

Thanks

Karsten

Former Member
0 Kudos

Karsten,

A really good discussion by 2 XI veterans about mapping performance.

If I understood the concept of model based mapping correctly.

The resultant XML you expect is either

<mammal>
<male>
<age></age>
<muscles></muscles>
</male>
</mammal>

or


<mammal>
<female>
<age></age>
<measures></measures>
</female>
</mammal>

If I am correct in my understanding, then graphical mapping is target based mapping. You need to map each target element separately. This can not be avoided.

Using Java/XSLT mappings you have wide control over the mapping. While using a Java (SAX) mapping, you can choose to do what operation has to be performed when a particular element (say age in our case) is encountered.

Regards,

Jaishankar

Former Member
0 Kudos

Jai,

Your output is almost right. It's just that the mammal tag must not appear in the message.

We want a structure like that:

<male>

<age></age>

<muscles></muscles>

</male>

Still your opinion confirms my expectation that mapping twice can not be avoided.

Java SAX? I'd rather prefer Java DOM instead....

Thanks for the link!

Karsten

Former Member
0 Kudos

>>Java SAX? I'd rather prefer Java DOM instead....

Using DOM is simpler, but it loads the entire tree structure in memory. Using SAX is a bit complex but fires events on the fly. So memory usage is less compared to DOM.

What is the average size, peak size of source payload you expect for this mapping. Based on that choose the mapping type.

Regards,

Jaishankar

Former Member
0 Kudos

Thanks for your suggestion Jai.

This is a pretty good blog about mapping performance:

/people/udo.martens/blog/2006/08/23/comparing-performance-of-mapping-programs

But I don't want to focus on performance in this thread.

It's more about model driven mapping and handling XSD schemes with extensions.

I now understand that message mapping might not be the first choice for that.

I'm still waiting for suggestions concerning the best way to deal with extensions...

Thanks so far!!

Karsten

Former Member
0 Kudos

Karsten Excuse my ignorance.

What is XSD with extension?

Regards,

Jaishankar

Former Member
0 Kudos

I pardon you

It's like the mammal example.

You define the mammal once and then use it in other elements.

It could look kind of like that:

<xs:complexType name="mammalType">

<xs:sequence>

<xs:element name="age" type="xs:integer" minOccurs="1" maxOccurs="1"/>

</xs:sequence>

</xs:complexType>

<xs:complexType name="maleType">

<xs:complexContent>

<xs:extension base="mammalType">

<xs:sequence>

<xs:element name="muscles" type="xs:string" minOccurs="1" maxOccurs="1"/>

</xs:sequence>

</xs:extension>

</xs:complexContent>

</xs:complexType>

<xs:complexType name="femaleType">

<xs:complexContent>

<xs:extension base="mammalType">

<xs:sequence>

<xs:element name="measures" type="xs:string" minOccurs="1" maxOccurs="1"/>

</xs:sequence>

</xs:extension>

</xs:complexContent>

</xs:complexType>

<xs:element name="male" type="maleType" />

<xs:element name="female" type="femaleType" />

<xs:element name="mammal" type="mammalType" />

As you see the "age" is only defined ONCE in the model but when you load such a structure into the XI, the "age" will occur twice: beneath the male node and beneath the female node.

That's absolutely correct from the data point of view but not from the model point of view.

Our structure is not as simple as the mammal example and I don't want to map every element several times but I'm afraid with massage mapping there is no alternative.

Or is it??

Answers (2)

Answers (2)

Former Member
0 Kudos

Hi,

You could use the XSLT Mapping for the model based external XSD schemes.

Even you could do this with Java Mapping with DOM parser.

Thanks

swarup

Former Member
0 Kudos

Hi Swarup,

is there a special XSLT-technique to realize model based mapping or can one say that XSLT is model based in general?

Thanks

Karsten

Former Member
0 Kudos

want to try XSLT mapping?

Former Member
0 Kudos

Hi Arvind,

Well,... yes!

First of all I am much more experienced in XSLT mapping. Then it seems to be the more effective technology for complex structures with a lot of extensions and also choice declarations.

On the other hand message mapping is "best practice" and I need reasonable arguments to change to XSLT.

So come on, feed me with good reasons for XSLT!

Thanks

Karsten