Technology Blogs by Members
Explore a vibrant mix of technical expertise, industry insights, and tech buzz in member blogs covering SAP products, technology, and events. Get in the mix!
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 

Problematic Cases with Graphical Mapping Context

fatihpense
Active Contributor
‎11-06-2021 3:12 AM
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-...

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&...

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.


In one sentence: Using IDoc to generate a Mixed-Pallet VDA EDI file.
<IDOC>

	...

	<E1EDL24 SEGMENT="1">

		<POSNR>000010</POSNR>

		<MATNR>000000000152261111</MATNR>

		<ARKTX>Product 1</ARKTX>

		<LFIMG>150.000</LFIMG>

		<VOLEH>PCE</VOLEH>

		...

	</E1EDL24>



	<E1EDL37 SEGMENT="1">

		<EXIDV>00000000000011239048</EXIDV>

		...

		<E1EDL44 SEGMENT="1">

			<VELIN>1</VELIN>

			<VBELN>0110109712</VBELN>

			<POSNR>000010</POSNR>

			<VEMNG>150.000</VEMNG>

			<VEMEH>PCE</VEMEH>

			<MATNR>000000000152261111</MATNR>

		</E1EDL44>

		...

	</E1EDL37>



	<E1EDL37 SEGMENT="1">

		<EXIDV>00000000000011239049</EXIDV>

		...

		<E1EDL44 SEGMENT="1">

			<VELIN>3</VELIN>

			<EXIDV>00000000000011239050</EXIDV>

		</E1EDL44>

		<E1EDL44 SEGMENT="1">

			<VELIN>3</VELIN>

			<EXIDV>00000000000011239051</EXIDV>

		</E1EDL44>

		...

	</E1EDL37>

	...

</IDOC>

In IDocs hierarchical packaging is represented using reference values. Each package segment contains the children's package numbers. You need to analyze the whole IDoc programmatically or copy/group values with multiple steps of XSLT to generate a tree. There is no other way.

Create the hierarchy of parent-children using E1EDL44-EXIDV for each package.

Link packages with related line items(E1EDL24) using E1EDL44. Then, walk the package tree. If one package contains packages with different line items, it is a mixed package. It should have a different qualifier in target VDA.

Then, you need to group packages to reduce packaging lines in VDA.
Group by "packaging type" and "quantity per package" and if EXIDV values are consecutive (2,3,4) "from 2 .. to 4"

Case 3: Ordering or grouping items


<Items>

    <Item>

        <name>Product 1</name>

        <group>A</group>

        <date>2021-11-06</date>

    </Item>

    <Item>

        <name>Product 2</name>

        <group>B</group>

        <date>2021-11-05</date>

    </Item>

    <Item>

        <name>Product 3</name>

        <group>A</group>

        <date>2021-11-07</date>

    </Item>

    <Item>

        <name>Product 4</name>

        <group>B</group>

        <date>2021-11-04</date>

    </Item>

</Items>

If you want to group items by the "group" field or order by the "date" field, I don't know any clean solution with graphical mapping.

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!

 

 
7 Comments
Labels in this area
Popular Blog Posts