Testing SAP PI interfaces in ABAP.

Introduction

Recently, I got a task to look after several interfaces that have already been implemented. All these interfaces are similar.

I will discuss my problem based on one of them (Supplier master data).

It is an interface for sending supplier’s master data from the SAP system to an external system.

The biggest challenge was that the same interface was implemented on many different systems. Three PI systems and four ECC systems.
Below is what the data flow for the interface looks like.

Everything would be fine if the interface never changed, but the reality is completely different. There are always a lot of changes or repairs in existing interfaces. The most changes for this specific interface were in SAP PI mapping.

Over time, it was difficult to track which changes were transferred to which system and which changes still need to be transferred. And generally, a change in mapping in one place can cause an unexpected result in another place.

I thought it would be good to have some tool that would allow me to test the result of mapping.

I created a simple tool in ABAP that sends a message to PI, the PI system performs mapping and then the tool reads the message that arises after mapping. This message is compared to the reference message and it is checked if the reference message and the actual message are the same.

Interface Testing Tool

The general appearance of the transaction is shown below. On the left side you can see a tree with projects. On the right you can see test cases in a specific project.

The most important columns are:

• Test case ID
• Description of the test case
• Test case status (Success / Failure)
• Test type (PM – PI Mapping)
• System name
• Interface name
• Message Guid – Message guid in the PI system
• Message (payload) Guid before mapping – this column represents the message (payload) before mapping. This message is stored in database and can be modified. Its first version is downloaded from the PI system.
• Message (payload) Guid after mapping expected – this column represents the expected message (payload) afterer mapping. This message is stored in database and can be modified. Its first version is downloaded from the PI system.
• Message (payload) Guid after mapping actual – this columen represents the message (payload) after PI mapping after action “Execute test”

The message flow in PI system is shown below

Now I will show how the tool works on a specific example.

Task: Changing mapping in the PI system – adding additional quotation marks when the supplier name already has quotation marks.

Example:

Input: Supplier “name” => Supplier “”name””

1. The first step is to add a new test case and search for the reference message guid in the PI system

2. From the list of found messages it is possible to select a specific message

3. If we have a GUID, we can download reference messages (payloads) before mapping  and after mapping

4. Below is the message (payload) before mapping (Idoc content). In the field NAME1 there is value – tho test “quotation mark”. After PI mapping there should be value – tho test “”quotation mark””
5. It is possible to edit the Message (payload) after mapping – expected.
   The value has been edited as it should be after making changes to the PI mapping.

6. After the execution of the test, an error occurred (as expected)
   

7. It is possible to compare messages (payloads) after mapping – expected and actual. You can see that the actual message (payload) is missing quotation marks.
8. Now it’s time for changes on the PI system side.

   Changes in PI system:

   Before update:

   

9. After update:

10. It is possible to restart the test case. The result is success.
11. The file comparison shows no changes.

Now we can run the remaining tests and check if our change has made changes in an unexpected place.

In my opinion the tool, although it is very simple, gives great possibilities.

Benefits that come to my mind:

• we are not afraid to make changes because we have a set of tests that must pass after making the change
• it’s easy to see if our change affects another part of the interface, after making changes, the remaining tests should pass
• we can easily check if the change has been transferred to other systems – just create a new test with the same content for another system

There are also several disadvantages:

• The tool only makes sense for interfaces where mapping is not 1:1. I see no sense in testing mappings in which there is no logic
• before use, the tool requires a lot of manual configuration, among others you need to configure the connection to PI systems, create logical ports, configure interfaces and systems.
• This tool is more proof of concept than the final version.
• There is plenty of room to improve e.g logging messages for which errors have occurred in the PI system, better errors handling

I plan to make this tool available as an open-source project in the future. I need to refactor some code first and make it more customizable.

I talked to several people about this tool, the votes are divided. That’s why I wanted to ask you for your opinion. What do you think about this approach to interface maintenance? When does it make sense to create mapping tests? Does it make sense to create test cases? Or does it rather require too much work? What else should be implemented in the tool to make it more useful?