SAP CPI testing automation with Postman

[valivanov]

Introduction

While startling and confound at the same time, my last SAP Cloud Integration projects revealed me one important thing - that we need to focus more on integration testing. Therefore, I took it as a personal challenge to design and put in place in two months a solution that can help building but also running SAP CPI tests. Postman is a very popular platform used by more than 11 million developers so after investing some time analyzing the included API testing automation features at its true potential, cleanCPI was born. This is my opportunity to get back to the SAP Community some insides about the first result.

CleanCPI is a package tool that supports running cloud integration in an SAP environment. It is a multi-feature tool focusing around areas like testing automation, cloud EDI, CPI documentation, though we will concentrate now on presenting the testing automation feature.

The goal of the testing feature is to concentrate the testing process on SAP CPI by isolating the testing process and having the option to exclude the 3rd party systems in any regression testing performed during the project. For this we are using a demonstrated method (by SAP and other companies) similar with what Rotoscoping is for visual design: "use to trace over motion picture footage, frame by frame, to produce realistic action". In the same way our testing tool is working - we select the execution runs that were validated as an end-to-end process, extract the trace data behind those executions and generate different test cases having the same or a changed context depending on each test scenario.

Architecture

CleanCPI consists of three components:

1.  A CPI package with 3 main iflow types:
   
   
   
   •  Flows that supports the tool functionality
   
   
   •  Template flow for creating new flows with special testing functionality included
   
   
   •  Demo flows - to test various testing scenarios
   
   
   
   


2. Web app (Node.js + Express, MongoDB) with backend, frontend, API and security sub-components


3. Postman - for storing and running the test cases.

Fig.1 - CleanCPI components

Fig.2 - Components and data flows

Main Functionalities

Data Model

Data used by the tool is stored inside the MongoDB collections:

• Project has one or many tenants


• Tenant has one or many scenarios


• Scenario


• User

A project can be a new CPI implementation, a migration from PI/PO to CPI or just an internal integration project. Postman API key is one important attribute maintained at the project level as this should be available for all the tenants inside the project.

CPI tenants are represented inside the Tenant collection and consist of attributes like tenant URL, test dispatcher flow URL, connectivity details. All sensitive data including passwords are encrypted in the database collection.

Testing Scenarios are created for each CPI flows that will to be tested and include all the attributes required to read the CPI payloads and to generate the Postman requests.

User management built in

For user authentication and authorization we are using the passport and passport-local node modules and a User collection in MongoDB where the user data is stored. For now only admin and non-admin users are handled.

Create and synchronize Postman environments for each tenant

Test cases created from one tenant source can be executed on any other tenant just by switching the environment in Postman (and of course having the CPI testing package configured in advance for that tenant). For each tenant defined in cleanCPI an environment can be created and sync with Postman. This option is included in the tenant detailed view.

Extract CPI flows executions data in two main modes: Trace or Persist

Test cases in cleanCPI are created based on prior completed runs. Extracting the data from old runs can be done in two modes, depending on scenario definition:

• Trace Mode - using the standard SAP CPI trace data feature - in this case no special steps are required in the flow definition


• Persist Mode - using dedicated steps inside the flows

Fig.3 - cleanCPI test modes

Each test mode has different use cases, depending on the integration flow particularity. Trace Mode is easier to implement for already existing flow definitions - even SAP standard flows,
Persist Mode on the other hand uses some additional logic included in the flow definition to enable extended testing options.

Create Postman test cases

Creating the test cases is the ultimate goal of the web component. For one particular test scenario and based on completed execution runs, test cases are created as Postman requests and include details like request payload, headers, endpoint and of most important - test scripts.

Evaluating expected outbound is done in two modes, depending on the Inbound Adapter of the tested flow - HTTP or non-HTTP.

Fig.4 - Output evaluation options

Module to customize the generated Postman test script based on payload and headers

A set of advanced options are available in the tool to control the way that test scripts are created,

like encoding the payload, evaluating the full output payload, evaluating particular header

existence or/and values, evaluating particular payload parts/nodes.

Fig.5 - Test script advanced options

Three test script type options are available:

• Full body - in this case the test case evaluates the full and exact outbound payload


• Full body plus headers - if we want to evaluate the entire payload but also the outbound headers - either their existence or a precise value


• Body nodes plus headers - depending on the payload type, the outbound in this case is flattened and only parts of the payload can be selected to be evaluated in the generated test script

Fig.6 - Example of generated Postman requests

API to update Postman collection - called by the web app but also from SAP CPI directly in the auto mode

Test cases are generated by calling an API created on the web tool backend component. This gives the flexibility of consuming the API in a secure way from any other system. One important feature is the option of calling the create request API directly from the running flow and generating the test case automatically. For this, a specific configuration needs to be activated first in the tested flow that will call a Process Direct flow that includes the logic required to auto create the test case in Postman.

Resource page with documents and SAP CPI packages

As part of the web tool, we included a resource page synchronized online with a AWS S3 bucket where content like best practices, SAP CPI packages, documents will be posted or updated. SAP CPI packages will have the option to be downloaded directly into the tenants configured in the tool. This will allow us to send updates to our tool as soon as we will develop new versions or features.

Working in trace mode

For working with testing in trace mode, enabling the iflow trace level should be an easy task for the testers. The web component includes the option of activating the trace level directly from the scenario. Also, mostly for developers I created a local tool to automatically enable the work in trace mode for more than 10 minutes, depending on specific scenario. This is very nice option when working on test cases with different teams and not being able to fit in the standard 10 minutes window.

What is included in the package

CleanCPI is delivered as a bundle that includes:

• A CPI package with 3 different types of flows:
  
  
  
  • Flows that supports the tool functionality
  
  
  • Template flow for creating new flows with special testing functionality included
  
  
  •  Demo flows - to test various testing scenarios
  
  
  
  

• The web component source app deployed as a Node.js + MongoDB


• Postman collection that includes demo requests for the demo CPI flows package. With these demo requests the tool can be tested for different payload scenarios (json to json, xml or text, xml to xml, json or text).

Deployment options

The tool can run fully on cloud or in a hybrid landscape and is not dependent on any SAP existing backend solution. Deployment options come into picture for the web component that can run on a local server, on SAP Cloud Platform or on any other cloud provider platform. All the web tool components are Docker containerized and any deployment can be done in minutes (e.g. SAP Cloud Platform Cloud Foundry). Also, a GitHub repository is available for any other custom deployment.

Onboarding steps

• Install the web app and maintain the basic configuration data sets


• Copy the CPI package to your tenants and configure the iflows


• Create a Postman account


• Configure your Postman account - create API key, collection structure, etc


• Create your first iflow based on the template or use an existing iflow to create your first test case

What's next

As the tool is already deployed and live on some of our clients, we will concentrate now on refining and extending the testing scenarios with new integration patterns. Also, we will extend the tests results UI from Postman by using the visualizer option and preparing a custom Newman Reporter. The auto create test case mode is a feature that can potentially raise the tool adoption, so in regard to this, two updates are on my bucket:  As the current API in built in Node.js, we will add the option of running this as FaaS on SAP Cloud Platform as an event consumer, and from SAP CPI this part will be called asynchronously by integrating with the Enterprise Messaging service. Also, expectation is that the tool will play new roles when SAP will release the persistence option on the SAP CPI simulation mode. For now, let's just start testing.