This post will focus on introducing the application named Postman as a tool to help SAP Functional Consultants in their SAP testing. This is not going to be a full blown technical how-to guide for developers (I might touch base on that in the future with a separate post).
Instead, the goal of this post is to simply help functional consultants get acquainted with Postman and provide some high-level use cases.
Tip: If you are not yet familiar with API’s, you can read my post on “SAP INTERFACES IN A NUTSHELL | RFC, BAPI, IDOC, EDI, ALE, UDDI, SOAP, WSDL, REST, API, FTP, SFTP”. It should help you get started.
Overview
- Purpose
- How To
- Additional Info
- Summary
Purpose
If you were to search on “Postman” and “API testing in SAP”, you will be presented with a multitude of results – most of them might even come from a technical perspective.
In this post, I will try and explain some concepts in the simplest way I can. Think of this as an introductory post and let’s try to leave most of the technical jargon for the meantime.
First, let us get acquainted with some words.
Postman
Postman is an application used for overall API development. The application can be used to create, share, test, and document APIs.
You can read more about Postman in their official website.
API
API stands for Application Programming Interface.
From my previous blog post on SAP Interfaces, I mentioned that you can think of APIs as an agreement (or contract) between applications.
The API doesn’t care about the application. It just needs to fulfill the contract (its end of the deal).
SAP Environment
Simply put, this is the SAP application or the SAP environment you are currently working with.
Second, I will share some example use-cases for using Postman.
As a functional consultant, you may deal with SAP standard configurations and even custom SAP developments. In an overall architectural perspective, it is highly likely that you will encounter integrations involved with the SAP landscape of the organization.
As integrations are involved, it is possible that other non-SAP systems will be using API’s to retrieve and/or send data [to and from] SAP.
The usual scenario is that each non-SAP system will have its own set of consultants / experts / IT professionals.
You (being the SAP consultant) would be focused on SAP.
You would most likely know the ins and outs of SAP but not necessarily the rest of the non-SAP applications.
Now…What if you need to do the following tasks:
- Test the connection between the non-SAP system and the SAP system.
- Test the API data flow between the non-SAP system and the SAP system.
- Perform regression testing in SAP to ensure API integrations are working fine.
- Simulate the data flow between the non-SAP system and the SAP system.
- The list goes on…
Those tasks may seem like they will require a lot of effort in terms of coordination with several groups of people. If you were to handle multiple test cases with different groups of people, it may take a lot of time.
For example: for you test on scenario 1, you need to contact System A IT Support to trigger some “command” for SAP to provide a certain detail. The next scenario would require you to contact System B to trigger another “command” to SAP.
We can add onto the scenario and say that the first time you have asked System A IT Support to trigger a command to SAP, it was not successful because of a missing configuration on SAP side.
This means that after you work on that missing configuration, you have to ask System A IT Support to retrigger the command. Overall, it takes up a lot of time.
That is a completely valid scenario. There could be instances wherein the first testing doesn’t go as planned.
This time let us take into consideration the test cases you have. Let us say that the interfaces have been running smoothly for a year or two and there are plans to update a certain feature in SAP.
Those test cases are now regression test scenarios. You need to work on this regression testing in a short amount of time and you need to ensure that the interfaces are still working after the system update.
Note: The goal of regression testing is to ensure that the application still behaves as expected after a change that was done.
How do I speed things up?
You can use Postman to assist you with the testing and communication checks as a first level check. Postman (in this case) can serve as your tool to “mimic” those non-SAP systems.
Before going through the extensive communication route, you can perform some first level checks to ensure the connection is okay and is behaving as expected.
If you need to replicate some scenarios in your SAP test environment, you can also use Postman as your tool to mimic the non-SAP system involved.
For example, a non-SAP system is sending data to your SAP system and stores the data in a custom SAP table. If that data does not exist, you can use Postman to send the data to SAP.
Consider: Keep in mind the security policies and system architecture policies of your organization. In most cases, a direct linkage (or connection) between a non-SAP system and SAP is not allowed. As such, you will most likely expect an instance of SAP PO or SAP PI in between the 2 systems.
Refer to the blue box below showing SAP PO in between the 2 systems (non-SAP systems and SAP).
IMPORTANT: It is important for you to be aware of your organizations security policies. Keep that in mind as you go through this post and choose to apply it.
How To
The following How To’s are in the context of a functional consultant.
It is advised that a developer (in charge of the API development / integration in SAP) work on the Postman environment and collection setup from scratch. The developer would know the settings needed to establish a connection to the SAP environments involved.
The idea here is that the postman environment and collection can be exported so that the functional consultant can import them into his / her postman application and focus on the functional testing / checks.
Setup
To quickly setup your Postman application with the SAP “connection” you need as a functional consultant, follow the steps below.
- Download Postman and create an account (free)
- Open Postman and log in using the free account
- Import your SAP Environment
Note: this is assuming that the developer has provided you with the exported environment/s needed. It can be in .postman_environment.json format.
Go to your workspace and import the SAP environments you need. You can also select the environments tab and click on the import button.
Click on Import and select the postman environment files provided by the developer.
Once done, you should see the import notification below.
You should also see the list of environments that are now available to you in your Postman workspace.
The details (or values) will most likely include the following (these are just some examples): SAP Client, SAP Host, Service, User, Protocol, etc.
Take note of the highlighted blue box on the upper right-hand side. This tells you which environment you have currently selected. Before running your methods, please make sure you properly select the intended environment first.
- Import your “Collection/s”.
Note: this is assuming that the developer has provided you with the exported environment/s needed. It can be in .postman_collection.json format.
Go to your workspace and import the SAP collections you need. Be sure to select the “Collections” tab.
Click on Import and select the postman collection file/s provided by the developer.
You see the “Import As” column showing “Collection” if it registers the file as a collection.
You should now see the imported collection in the Collection tab.
If you were to explore further, you will see that each method will have the following tabs: Params, Authorization, Headers, Body, Pre-request Script, Tests, and Settings.
Below is an example of me selecting the GetSingle method for dataCollection. Notice the blue highlighted box again on the upper right-hand side. This is where you can see the environment you have currently selected.
IMPORTANT: Be mindful of the environment and methods you select!!
Test the connection (GET METHOD)
We can try to mimic the non-SAP system by attempting to request data from SAP.
Now that you have the environments and collection/s in place, you can test the connection by using the GET Method. It should not update anything in SAP and simply retrieve the data requested.
Simply double click on that method, select the environment you are concerned with, update the text with the data you want to retrieve, and click Send.
In the example below I have:
- Replaced the “sampledata” with “1123231” because that is the data (for example the order # that exists in SAP)
- The “variables” below will retrieve the data from the variables that were maintained based on the environment you selected (see highlighted blue box)
- I have selected “SAP QAS” environment.
Clicking the SEND button will show the screen “sending” below.
If the requested data exists in SAP, you should receive the example result below.
You can cross check by viewing the custom SAP table data concerned:
If the requested data does not exist in SAP, you should receive the example result below.
You can cross check by viewing the custom SAP table data concerned:
Note: it is assumed that you know the behavior of the API / method based on the documentations provided to you. The above is just an example.
Test the connection (POST METHOD)
We can try to mimic the non-SAP system by attempting to post data to SAP.
Now that you have the environments and collection/s in place, you can further test the connection by using the POST Method. It should store the data in the custom SAP table (based on our scenario).
Simply double click on that method, select the environment you are concerned with, update the text with the data you want to post in the “BODY” tab, and click Send. Note the proper format expected.
In the example below I have:
- Entered the details (following the expected format) in the Body tab.
- The “variables” below will retrieve the data from the variables that were maintained based on the environment you selected (see highlighted blue box)
- I have selected “SAP QAS” environment.
If the requested data is successfully posted in SAP, you should receive the example result below.
You can cross check by viewing the custom SAP table data concerned:
Note: it is assumed that you know the behavior of the API / method based on the documentations provided to you. The above is just an example.
Additional Info
If you are starting a project (meaning to say you are in the scenario of starting a new API integration), the developer will need some connectivity details for the environment setup.
The scenarios provided above takes into consideration that the connection has already been established and all pre-requisites are complete. All that is left is to work on the additional testing for post go-live scenarios etc.
Of course, there are more diverse scenarios and use cases for Postman and SAP API testing. Hopefully this simple overview helps give you an insight to this testing option.
Summary
- Purpose – Quickly test the connection and / or simulate the API data flow between non-SAP and SAP systems. You can use Postman to mimic the non-SAP system.
- How to Setup – Download Postman, create your free account, then import the Postman Environment/s and Collection/s.
- How to Test the connection – Utilize the GET Method and POST Method. Update the data request following the expected format and Click on the Send button. Make sure to select the Environment you are working on (double check as needed).
I hope this helps. Good luck! 😊
Techlorean. 