Now accepting guest editorial from SAP, Oracle, Workday and ServiceNow practitioners.Pitch a guide
The Sign-Off Table

Lesson 6 of 6

When graphical mapping is not enough

8 min

Listen to this lesson

0:00 / 4:57

Graphical mapping is readable, testable in the editor, and familiar to every PI/PO developer who will support Contoso's interfaces after Theo's team moves on. That's a strong reason to keep it. But some logic doesn't fit the queue model well, and forcing it in produces mappings nobody can maintain. The skill is knowing where the line is and writing it down as a team rule before the 57 remaining interfaces move.

Your options in Cloud Integration

OptionWhat it isGood for
Standard and node functionsThe graphical mapping itselfStructure changes, field moves, conditions, formats, simple totals
Custom function (Groovy)A script function added in the Mapping Expression area and used like a standard functionOne small rule, e.g. strip leading zeros from an ID, reading a header
XSLT Mapping stepA separate flow step that runs an XSLT stylesheetGrouping and sorting by keys, deep restructuring, teams fluent in XSLT
Script step (Groovy)Code that works on the whole message (sap-pim-202)Logic around the mapping: computed headers, parsing, custom error handling
Other standard stepsContent Modifier, Splitter, Aggregator, ConvertersHeader values via XPath, splitting, JSON/XML conversion

Ways to transform a message in Cloud Integration, from most to least declarative.

Signals that graphical mapping is the wrong tool

  • Grouping by a key, such as summing invoice lines per tax code or per plant, needs sortByKey, counters and several context tricks. An XSLT for-each-group or a short script is clearer.
  • Lookups. Mapping lookups such as RFC or JDBC aren't available. Fetch the data with an adapter in a Request Reply step, put it in a header or property, then read it in the mapping (sap-pim-202 shows how).
  • String parsing of semi-structured text, such as splitting a free-text field by several delimiters.
  • Very large messages where memory matters; consider splitting the message first.
  • The same custom function copied into many mappings, which is a sign the logic belongs somewhere shared.
Contoso's decision path: stay graphical by default and escalate only as far as the logic requires.
The Sign-Off Table · thesignofftable.com/academy/sap-pim-201

What happens to PO-specific mapping content

ESR content doesn't all move the same way. Cloud Integration supports importing, viewing and editing Java user-defined functions that come with an imported message mapping. Message mappings that use imported archives fail to import. Import parameters of simple and adapter types are supported (in the Cloud Foundry environment) and become message properties. In Contoso's architecture decisions, the interfaces marked rebuild are the ones whose PO logic depends on such content. They get a fresh design, not a line-by-line copy.

Graphical mapping in a flow stepSimple logic used once: keep it local and readable
Graphical mapping artifactSimple logic used by many flows: deploy once, reference everywhere
Custom function or XSLT step in one flowComplex logic used once: isolate it and test it hard
Script collection or shared XSLTComplex logic used everywhere: own it centrally and version it
Where to put mapping logic depends on how complex it is and how often it is reused.
The Sign-Off Table · thesignofftable.com/academy/sap-pim-201

Contoso's team rules

  • Graphical mapping first. A custom function needs a one-line reason in the mapping description.
  • No business rules hidden in custom functions: code translations go to value mappings (sap-pim-204), partner differences to the Partner Directory (sap-pim-205).
  • One owner per shared artifact, named in the package documentation.
  • Every mapping, whatever its technology, ships with its sample set and downloaded outputs.

What would you do?

A developer proposes rewriting Contoso's ORDERS05-to-850 mapping for Lakeside as one 400-line Groovy script, because "scripts are faster to write than graphical mappings". Theo has to decide.

Key points
  • Default to graphical mapping; it is readable and testable in the editor.
  • Use a custom function for one small rule, XSLT for grouping or deep restructuring, and a Script step for logic around the mapping.
  • Lookups become adapter calls whose results are passed in headers or properties.
  • Write team rules down before migrating, and test every technology with the same sample sets.

Check your understanding · not graded

Lesson check

  1. 1. Which need points most clearly to an XSLT Mapping step instead of graphical mapping?

  2. 2. An imported PO mapping relies on an imported archive. What does SAP's documentation say?

  3. 3. Where should a code translation such as ISO unit PCE to partner unit EA live, per Contoso's rules?

  4. 4. What must every mapping ship with, whatever technology it uses?