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 Dominic Beckbauer 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 Malte Schluenz 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:
- 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!
- In the Terminal window: Up, Enter
- Only first time you need to write java -jar pizug-test.jar –directory=”C:\dir\test-suite”
- 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: https://github.com/pizug/cpi-mapping-test
Compiled Jar download: https://github.com/pizug/cpi-mapping-test/releases/latest
Thanks for reading!