Graphical mapping looks nice, and it is easy to see which fields are mapped from where. It also naturally validates your mapping by XSD structure. It looks like the default mapping option (more so in PI/PO)

Starting a new implementation, sometimes it is very clear that Graphical Mapping will not work well. Other times, it is more nuanced. It is hard to clearly explain why it can be a maintenance problem to someone without years of Graphical Mapping experience.

How can you explain what context problems can cause to a technical person who is new to the topic?

I need a clear explanation of such cases that I can refer to when using graphical mapping is not optimal and this blog post is my attempt.

In our team, we pushed hard to use only graphical mappings for years. Frankly, you can find solutions to most of the context problems. The question is “at what cost?”

The Context in Graphical Mapping context

Most of the problems arise from the context implementation.

Here is a great explanation of context logic:
https://blogs.sap.com/2012/06/22/queues-contexts-concept-of-graphical-mapping-understand-it-to-turn-it-into-your-advantage/

Look at the number of questions:
https://community.sap.com/search/?ct=qa&mt=01200615320800000719&q=mapping%20context&qt=all

Also in Cloud Integration(CPI):
https://community.sap.com/search/?ct=qa&mt=af99d3f6-ee20-415a-897d-ac391f643ddc&q=mapping%20context&qt=all

Problems related to the context

My main problem is, this is incidental complexity. I want to focus on the inherent complexity of the mapping. I want to think about how fields relate to each other. Satisfying context takes my brainpower away from the real problem.

Context logic is so low level & so complex (when it becomes a problem), It feels magical and doesn’t add anything to your greater knowledge. Yes, it is an exercise for your brain. But, you can finish your mapping then solve some sudoku puzzles.

The context can be brittle, in some mappings one small change in the input can break the whole mapping. By “break”, I mean the correct structure having data from different rows. As a consultant, I’m embarrassed by this. It has no logical explanation to an outsider! The rows slipped?

No good way to edit the mapping as a text file!

Another annoying situation: If you commit to graphical mapping for an interface, you will be invested and think “let me do this one fix and it will be done”. Repeat this x5 times on different days. And rewriting it in Java/XSLT was cheaper and less stressful… but not today, today you just have to solve the context problem. Hey frog, how long have you been here? (No response)

Some Solutions

• Right-clicking on the source node, changing the context of a field, and trying again
• Randomly placing Node Functions
• Writing UDF to deal with context changes
• Using “useOneAsMany” or some other UDFs from the B2B package
• Another mapping before the current mapping that has “mapWithDefault” for each field
• Another mapping before the real mapping for filtering some items.
• Using variables

Case 0: Good Case!

When input and output have similar header/detail structures you can use Graphical Mapping with peace of mind. In this example, field names are different but the mapping logic doesn’t require combining or filtering multiple levels of elements.

Source/Input Structure:

<Root>
	<Header1>...
	<Header2>...
	<Header3>...
	<Lines>
		<Line>
			<A>...
			<B>...
			...
		<Line>...
	...

Target Structure:

<Message>
	<Header>
		<Field1>...
		<Field2>...
		...
	<Item>
		<ItemField1>...
		<ItemField2>...
		...
	...

Case 1: Layers of context with filtering requirements

Source Structure:

<DEBMAS>
	<IDOC BEGIN="1">
		<E1KNVVM SEGMENT="1">
			<VKORG>A</VKORG>
			...
		<E1KNVVM SEGMENT="1">
			...
		...
	<IDOC BEGIN="1">
		<E1KNVVM SEGMENT="1">
			<VKORG>A</VKORG>
			...
		<E1KNVVM SEGMENT="1">
			...
		...

Target Structure:

<Message>
	<Item>
		<Field1>...
		<Field2>...
		...
	<Item>
		...
	...

Requirement: We are creating an Item element for each IDoc. Some target fields require values from E1KNVVM element (filtered with VKORG=A condition is preferred, otherwise it should use VKORG=B and no other E1KNVVM segment is allowed)

Note: Please don’t touch your eyes with your hands while you are crying.

Imagine there are 100 IDocs, and one of them has a missing element (not empty/self-closing element) under E1KNVVM used in context. Result: You can see values from Items under the wrong Items. (This case can come up in 2 months after go-live).

Imagine there are 20 fields on the target that has “if” logic. Then the requirement changes slightly or you notice a context error while testing. You have to change each field manually and it takes more effort than it should be. (This is where I miss using text.)

Case 2: Clearly complex cases when it requires complex analysis on the input.

One sentence: Using IDoc to generate a Mixed-Pallet VDA EDI file.

In IDocs hierarchical packaging is represented using reference values. Each package segment contains the parent package number. You need to analyze the whole IDoc programmatically to generate a tree. There is no other way.

Case n:

I want to update this post with more examples in the future. If you have a good war story using Graphical Mapping, write a comment or send it to me directly!

Thanks for reading!