Test SAP CPI Mappings using Postman

[Muniyappan]

Overview

In this blog, we will see how you can use postman, to test the SAP CPI mappings. You can use this approach for testing your groovy/xslt mapping as well if you find it useful.

SAP CPI mapping simulation lacks more functionality where as SAP PO has better one. In SAP CPI there is no way you can save your xml files as instance, generate xml, copy paste, etc. Even in SAP PO, you have to manually to go output and check the result. For verifying output, you have to manually check it, no way to automate it.

Use Case

 

For illustration purpose let us consider this simple Invoice xml with one field.

xsd:

<?xml version="1.0" encoding="UTF-8"?>

<schema xmlns="http://www.w3.org/2001/XMLSchema" xmlns:tns="http://www.example.org/Shipping/" targetNamespace="http://www.example.org/Shipping/">

    <element name="Invoice" type="tns:Invoice"></element>

    

    <complexType name="Invoice">

    	<sequence maxOccurs="1" minOccurs="1">

    		<element name="ProductType" type="string"></element>

    	</sequence>

    </complexType>

</schema>

 

xml:

<?xml version="1.0" encoding="utf-8"?>

<!-- Created with Liquid Technologies Online Tools 1.0 (https://www.liquid-technologies.com) -->

<ns1:Invoice xmlns:ns1="http://www.example.org/Shipping/">

  <ProductType>Power</ProductType>

</ns1:Invoice>

 

 

Mapping Artifact: We have simple transformation which is using fix values to transport input.

 

Simulate Mapping test

 

output xml

<?xml version="1.0" encoding="UTF-8"?>

<ns1:Invoice xmlns:ns1="http://www.example.org/Shipping/">

    <ProductType>P</ProductType>

</ns1:Invoice>

Problem

We have to run the mapping manually four times to validate all four values. And we have to manually check the values every time we run the mapping. This might sound easy, but any incremental changes, we have to run these tests again manually and check the output by looking at the output xml.

For each simulation test, you have to wait for few secs to get the output.

What if you have more than 1 field is using transform logic and more than 10 fix values to test. Not easy to do it manually.

For the documentation purpose, you have to capture the inputs and outputs and keep it as record. It is cumbersome to do it manually.

 

Solution

What I need

1. Automate the mapping simulation test


2. Automate cross checking output. No need to go to output xml and  check it manually.


3. Automate capturing input and output

Let us create a separate Iflow to test the mapping. Here is the simple Iflow with https sender adapter.

Create request in postman for each test case.

 

Write a test case for checking product type for all types. I have used chatGPT for writing test script as I am new to java script.

 

// Parse the XML response

const responseXml = pm.response.text();



// Extract the ProductType value

const productType = responseXml.match(/<ProductType>(.*?)<\/ProductType>/)[1];



// Check the ProductType value

pm.test("Check ProductType Power", () => {

    pm.expect(productType).to.eql("P");

});

 

Run the collection

 

Here you go.

 

So now we are able to automate mapping test via postman and able to very the output. Creating test scripts should be one time activity, once done, you can run it multiple time.

 

If you create postman workspace with visibility as team, you should be able to share it with your team.

 

Documentation

 

For documenting your tests, you can make use of Newman htmlextra for postman. With this you can document it.

 

[MortenWittrock]

Hi Muni

Nice blog post! There is a testing capability on the roadmap, that goes way beyond manually running your mappings and scripts, but unfortunately it won't be out for a while. Until then, something like your approach here is needed for automated unit testing.

I would suggest creating your Message Mapping in a separate Message Mapping artifact, that you can then include in both your iflow and a separate iflow wired up for testing. You could do both in one iflow, but then you'd eventually be transporting your testing endpoint into production, which you probably don't want to do.

Regards,

Morten

[Muniyappan]

Thanks Morten,

That is correct. We should always create message mapping as Message Mapping artifact. We would be able to create a separate iflow which is dedicated only for testing by adding the mapping as references. Just like maven projects, if we create separate packages one for testing and one for main integration, then it would be easier to differentiate the test flows and main flows. So that only main flow will be transported to production as a package and testing ilfows stay in Dev.

[sabarinath00]

Great One Muni