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!
Showing results for 
Search instead for 
Did you mean: 
Active Contributor
I want to share how I improved my mapping development workflow for CPI. It can be useful for everyone working on a complex mapping.

Working on a mapping can take minutes, hours, or days. It can make sense to make an upfront investment of 5 minutes to gain more efficiency. In my case, I thought I will be doing mappings for years and spent a few weeks on developing this tool.


There is too much information. While you are holding mapping rules and XML in your own human memory, every small distraction removes some information&motivation from you.

I want to focus only on the mapping development, see the results in a fast feedback loop.

Finding test cases, triggering them, finding results in the logs… all distract me from my main task.


You can use the excellent CPI Helper extension by 6c74addc374841d587eccd4a68075de8 to alleviate "monitoring while developing" problem. You don't need to switch between development and monitoring views. Or you can use the simulation feature to some extend & keep simulation data persisted with SuperEasy simulation filler. These solutions don't require you to use "Mapping Flows"

Or you can add MPL attachment logging before & after mapping. Trigger the flow and see payloads in CPI Monitoring. Using MPL attachment logging everywhere can cause problems for the production. You need to check which of them should be transported to production and remove others. To solve this, you can use this Groovy function shared by malteschluenz and set the flow to "Debug" only in your development tenant.

If you can separate your mapping to a single mapping flow(I recommend that if your mapping is complex) and if you want:

  • to keep the input/output files on your computer or in a Git repository for reference. (They are sometimes unspoken specifications.)

  • to test multiple cases at once &ensure you don't break old cases, multiple times with minimal effort in between tests.

  • to automatically get a list of wrong fields among many test cases.

  • to keep test cases for future mapping regression tests.

You can consider using Pizug Mapping Test Tool(Open-Source)

Using the Tool

Once you download the Jar file and configure your test suite directory.
Prepare what you want out of this mapping once: Expected result. You can find setup instructions and an example test suite in the GitHub repository.

Here is the workflow, Until your mapping works perfectly fine:

  1. Change the mapping, use anything CPI offers in a flow, connect the boxes on the monitor to appear like a child to your non-integration colleagues while thinking deep technical consequences, use random node functions to get the context working for some PI/PO nostalgia 😉 add some Groovy spice... Deploy!

  2. In the Terminal window: Up, Enter

    • Only first time you need to write java -jar pizug-test.jar --directory="C:\dir\test-suite"

  3. Wait to see the result in the console & in your favorite editor. If there is an error, go to 1;

Example screenshot for the repeated test until everything is fine:

Getting feedback is very fast and more importantly, you don't have to think about it. Instead of finding my way through logs. I can see all results at once in any editor that can show directories. It will be refreshed automatically.

What is new in v0.2?

  • Documentation is getting better

  • You can now send input headers for a case

  • Mapping result body is saved to the case folder, so you can just wait and the result will come to you

It is open-source and open to new ideas!

GitHub Repository:

Compiled Jar download:

Thanks for reading!
Labels in this area