← Figaf Friday

Figaf Friday: testing is important to your integration

Why you should test SAP integrations, who is responsible, why manual tests miss real data and how to automate tests from production messages.

January 14, 2022 · 4 min read

Why do you want to perform testing of your SAP Integration?

There are two reasons for testing your integration.

  • To ensure the quality of the integration
  • Not introducing bugs

I had a case where I was asked to fix an EDI message mapping to handle one new case of messages. The problem was I had not considered what if this new value was not there. Next, we ran a quick test to see if it worked as expected and it did, so we moved the mapping to production.

We had not made a regression test so all other messages failed. We got information from the monitoring team that a lot of messages were failing. Then I realized my mistake!

I could quickly fix the problem and test it with some more messages. Luckily, we could reprocess the messages because they failed.

I cannot recall if it was a big problem that cost money or it was just some inconvenience.

It would have been much worse if the message had not failed but processed with the wrong data. Then it would have taken way longer to find and resolve the problem.

If we had a way to run tests we would not have been in this situation.

Whose responsibility is the testing?

We all know the quote “if it is everybody’s responsibility then it is nobody’s responsibility”. That is true for testing integration. There are a lot of people involved in the process of delivering integrations. If nobody is testing then it will ultimately be the integration department that is responsible for the number of errors introduced in the integration. They are the ones that can not run the integration but must have the capabilities to run it.

Ways of testing

The most common way to test is with a business expert. And in some cases, because there are two systems, you send messages from one system to the other and see how it works.

This is a good way once you are developing your integration and want to figure out what happens. But there are also cases where it becomes much more problematic.

Let’s say you need to apply a change to an existing mapping. Being able to test with the two process experts is then no longer an option. Also, you have probably lost a lot of knowledge in the organization.

What if you want to migrate to a new platform or upgrade to a newer release. Then you need to get everybody involved to help with the testing.

Testing takes time

It takes a lot of time to test the integration. It can be a problem for transporting new integrations or development. You need to find all the people that know about the integration and coordinate with them.

Testing does not only require integration developers. You also need business people that know the outcome of the integration and need to know the testing process.

Testing scope

Testing with a business expert is different than real life data. Most of the time you will get a business expert to create an order with one line. That is not the way most orders look in the real world. They will contain 200 lines of information with 5 different types of conditions that need to be handled in the mapping. This is the part you need to pay close attention to in your mapping.

This is why you need more complicated messages so you can use them for your transport.

Can you automate it?

The traditional tools for handling test cases can also connect with SAP PI or CPI systems and fetch the data. But it is a really laborious process that you need to go through to set it up. Plus, in most cases, you end up with two simple test cases.

Real automation

The best way to test is to automate the test case creation. You take a lot of messages (both input and output messages) and send them through the integration engine. That will allow you to create test cases fast either from your productive data or they are developed while you are creating test cases.

We have built a testing tool that can easily take data from your production system and run them as test data. This will automate the testing process. This means that your developers will be able to run a lot of tests themselves, so the business people will not be involved in all the testing.

If you can test faster then you can deliver your integration faster.

If you want to learn more about our testing tool, you can go here to find out.

More from Figaf Weekly

Oct 16, 2026

Put your B2B migration on a real calendar

A new calculator plots your B2B migration go-live on a real calendar. Also: wildcard ICO migration, Cloud Integration chamber of horrors and SAP TechEd.

All issues →

See this working in your landscape

No credit card required.

Integration cost calculator →

Start your free trial

No credit card required

Try Figaf DevOps Suite free for 30 days. It takes less than an hour to get started, and we send everything you need by email.

Join our newsletter

Get the latest about Figaf, SAP and anything relevant to SAP integration, every week in Figaf Weekly.