Posts

SAP CPI Testing, now with Mock and secured data

Testing is not really fun. But you need to perform it.

Making a good unit test for SAP CPI and testing full iflows is one of the more complicated processes. You could create some test cases but it became pretty difficult to manage

1) Testing with mock services. This is if you have SuccessFactors systems you cannot call once you want to run regression tests. Then the Figaf tool will replace calls to SuccessFactors and replace them with an HTTP call to Figaf. In the request, it will inject the expected response. So you can get to test scripts, routing, and flows.

2) Secured testing. The best test data you have is from production. This is in many cases confidential like HR data. You, therefore, do not want all your developers to see the information. That is why we have added secured testing. This ensured the payloads are masked in the Figaf tool, so normal developers only see masked data. So they will be able to determine something is wrong but to get the name of the person.

We have written a lot more about the secured testing that also is for SAP PI/PO.

You can see how this works in the following video.

3) Groovy unit tests based on the Figaf test cases you have. This is a simple way to test all your groovy scripts in an Iflow. We have bundled this with the Git integration to make it possible to run the development process simpler. This allow you to run and debug your groovy scripts and it is a lot faster to develop in that way.

Try it out

There is free trials of the tools at https://figaf.com/irt. You can get started in less than 60 minutes to try out what the tool is able to.

If you any questions email info@figaf.com and we will answer your concerns.

SAP PIT sp 17 first look and compared with Figaf IRT

We now have gotten SAP PIT the test tool for SAP PI/PO upgraded to SP 17. 

SP 17 was released Thursday 27 February you can see the release notes here

It contains the following updates

  • PIT: Developments & bugfixes for SP17
  • PIT: new UI5 based web interface for PI Test tool
  • PIT: Scheduled Test Execution and Verification

I did not have a look at SP16, we skipped that one. You can also create test suites, which is a collection of test executions. (Probably added in SP 16). Now it becomes interesting because you can schedule them at specific times. Like each night. Then you can see if something has happened to your test/development system. 

You have the WebUI now where business users can run the test and see if everything is okay with the test executions. They can see which fields there is something wrong with.

You can see my video of the tool here

Why Figaf IRT can save you money comparing to SAP PIT.

PIT is free and you get it with all SAP PI 7.5 installations above SP 14. 
At Figaf we do have some benefits that you will enable you to save time on your testing. 

We do have the following features that makes testing much simpler.

  1. Creating of multiply cases of many ICOs at one time and no need to edit ICO to enable the correct logging
  2. Comparison on module level, so you can see the payloads after EDIComparison so you can get to test the full flow. 
  3. Managing the test cases and update changed items
  4. Generate Excel Reports of your test cases
  5. Secure testing, so normal developers will not be able to see confidential messages but can still run tests with them. 
  6. With our tracing of changes are you able to run the tests on what is changed? And an embedded transport system.
  7. A faster release cycle, so we can deliver new functionality to make your SAP Integration easier.

To view it in real life see.

Try Figaf IRT

You can get started in less than 60 minutes with the Figaf IRT tool. In most cases, you can use your current computer to run Figaf at and use your SAP PI user to connect with.

Plan an SAP PI/PO patch or upgrade

How you plan an SAP PI/PO Upgrade or patch. This is what we try to discover in the article

The simplest project is an upgrade from single stack 7.31 or 7.4 to 7.5. The process is the same if you are applying patches or support packs. 

If you have a dual-stack and only using ICOs the projects are the same. You though need to consider the stack split and subsequent delete of the ABAP system. 

If you are using Seeburger BIC for your EDIFACT/X12 then you probably want to perform a migration project in some form. It can be on your current system and then upgrade afterward. 

We have been writing about SAP PI/PO migrations, which you want to move to a new version or if you have to redesign part of your integration. It will be a bigger project but may reduce the risk. 

I have created a video version of the document if you want some other perspective on the content.

Difference between upgrades and patches

In the SAP Java world SAP is delivering a set of Java Archives or compiled classes. In each patch, there is release all to the latest version of all code. The Java applications are delivered in Software Components that contain a set of code. SAP is releasing patches for each Software Component. In each patch, you will always find the latest version of all the code in one patch.

You do not have the option to apply a delta patch as you have in ABAP. It is a full Software Component each time. There is also a dependency between the software components so you often need to upgrade the full stack to the latest release. 

It is pretty difficult to know what the difference is between two patches. You cannot see the mapping engine has been changed in this way. 

The differences in a patch are smaller than the differences in a support pack and a release. But you are anyway getting a bunch of differences that you don’t really know how it will affect your landscape. 

The process should, therefore, be the same no matter what you are applying. 

How often to upgrade

Most companies try to have one patch upgrade every year to stay current on the SAP software.

SAP PI/PO will get 3 support packs in 2020, which is the same as in 2019. It may change. 

 It does depend on how much you need to leverage the new technology. If you are using SAP CPI flow on your PI system, then you probably need to upgrade 2 times a year because that platform is getting more functionality for each release. If you are just using plain old PI message processing, there is not a need for more than every 12 – 18 months, unless you plan to use one of the new innovations.  

Testing

Testing is one of the most important things in regards to an upgrade. That is the thing that needs to be a big part of your project. 

Should you be testing

As a vendor with a tool to automate SAP PI/PO testing my answer should by, yes. You need to buy our testing solution. 

I have seen customers upgrade their PI/PO from 7.31/7.4 to 7.5 with some minimal testing and without any problems. So you can upgrade without performing a lot of tests. 

You need to talk with the business about what they accept of risks. 
After an upgrade, there can be two types of errors.

  1. The errors that result in a mapping or processing error
  2. The error that is hidden, and it will not appear as a runtime error

I have seen some of type 1. In most cases, it is possible to find a fix for the problem and resent the message. It does though depend on the speed you can solve the issues. I have seen this some times, in places where we had complex message mapping and use exotic steps. 

We were able to fix it in some time. One of the cases required us to get a patch to fix the issue. 
If you get a message of type 2, it may take a long time before you are able to identify something is wrong and then it will be costly to find a fix for it. It could happen by changing the way of handling queues and could be something we value was placed at the wrong line. 

Identify Testing approach

You need to consider how you want to be testing this project. You have two options depending on how much risk you allow.

  1. Test manually
  2. Automation of tests

Automated testing will give you an ability to run the same test cases multiple times, so you can have them also when you perform an upgrade next time. You need to find a way that is easy to perform.

For the testing SAP PI/PO you can use for Record/Replay: 

  • Figaf IRT tool that we have created that contains a lot of functionality to speed up the testing of SAP PI/PO. You can create a lot of test cases really fast, without much work or knowledge about the content. We would obviously recommend this. 
  • SAP PIT (a Testing tool for SAP PI) It is a part of SAP PI 7.5 sp14.  
  • INT4 IFTT also has a tool that can test upgrades. 

Some are trying to use traditional script-based testing, it does take quite a long time to set something like this up. It will require you to have a business understanding of both sending and receiving applications. 
You may need to perform some manual testing if the approach you have selected is not covering adapters. Then you can write some test scripts on ie the REST adapter. It can be a place where the traditional tool can be used. 
In some cases, the business can accept the risk of the upgrade and then you can ignore the testing.  

What should else be tested

In this, we are mostly just concerned with the testing SAP PI/PO integrations. There is other areas that you should consider testing like BPMN, BRM or the UI Interfaces you are using. 
There are to my knowledge not any automation tool for testing other types of processes, so you have to find the best solution for it. 

Steps for the process

Identify the target release you want to move to

Some customers have an idea about moving to current release -1. I don’t think that it adds as much value in an SAP context because it will anyway contain the same fixes as before. You can just not use the new functionality. 

If you want to see which versions are published check out this guide.

Timeline

You can of cause speed up the process depending on how much time you have and the urgency in the upgrade. In some cases, I have seen 3 months period for an upgrade if there is a lot of testing required. The bad things are once you have upgraded your development environment, you man cause problems once you are moving new interfaces into production. So that count for not having to spend 3 months on the process but rather 1-2 months. 

Preparation

Create test cases as baselines on your development system. If you run them on the old system you know they will work on the system.

If you spend the time creating your test cases in your development system, you can easily run them manually after the upgrade. The more you can automate this testing the faster you can get the update tested and go to production.

One of our customers Anadarko Petroleum were able to use the Figaf Tools to create test cases for 300 interfaces in just 3 weeks. Then they could test everything in just 1 week.  

Development

On your development landscape apply the upgrade. Remember to take the latest patches for the specific support pack you apply. You should save the packages that you are going to deploy, so you can apply the same again in the other landscapes.

Spend 1-2 weeks testing in Development. 

Testing

Apply the update to SAP QA or Test system. Remember to time the upgrade, so you have an idea about how long the time you need in production. 

Run your technical tests to see if everything stil is okay. 

Ask the business to perform some of the more critical tests. The part about getting business to test is probably the most difficult part. To get them to commit to testing in the timeframe, and if not then they approve the upgrade. 

Production Go live 

Depending on your setup you may need to plan for some downtime for the upgrade.

You can get NZD(Near Zero Downtime) on the system but if it is not required and you can afford some hours of downtime it is preferred. 

I would also recommend a full back up before the upgrade, then you can much easier rollback if something bad happens. 
Once you have applied the patch do check everything working as expected. There can be alerts, in that case, you need to be able to resolve them fast so it put the minimum impact of the company. In extreme case you may need to roll back but it will be rather costly. 

Automate more than just your Testing

Figaf IRT is able to help with more than just your test automation. It enables you to govern and manage your SAP PI/PO transports at a much more detailed speed. 

Signup now.

You can get started and create your first test in 1 hour. 

Secure your SAP PI/PO and CPI test cases

Testing is important for your interfaces. For migration and bug fixes it is important to be able to perform regression tests.

The place you can create the best test data from is from your productive systems, where customers are creating orders with 100 lines with 10 different product types. It is not only from the clinical approach from a user test. You need both.

The bad thing about the production data is, it often contains confidential data. Social security number, payroll data or customer information. It can, therefore, lead to problems if you want to test with it. You may often have externals working on your systems and don’t give them access to confidential data.

Scrambled comparison, user can see there is something wrong but not content

We had to solve this problem with the new innovation. You simply select any of your SAP PI/CPI systems you have connected to and specify that they are confidential. Then all test cases created from that system will be marked as confidential. Then it will only be possible for users with the role IRTSensitivePayloadViewer, to view the original data. Otherwise, you can only see the scrambled version as seen in the image.

It is only possible to run the test on the system marked as secured. With secured systems is meant that it is systems is configured so users cannot view the payloads being processed. We are working on ways to block confidential messages only. It will be a component to filter out the messages and using the web dispatcher.

You can see a video about the testing functionality here.

Over the next patches, we will enable some more functionality like

  • Blocking viewing messages of SAP PI, so you can view your normal test messages
  • Testing SAP CPI with the same approach, where you have a lot of SuccessFactors integration
  • Testing synchronize messages, where the Figaf Tool will work as a proxy to give the results back

This function is really useful for SAP PI/PO migrations where you just want to get a lot of messages from your productive system and let contractors handle the configuration. With this approach, they can test all interfaces.

Try it for your self

You can signup for Figaf IRT and get a free trial. You can get started in 20 minutes.

Creating unit tests for SAP CPI

Cross-Post: This blog has also been posted on blogs.sap.com

The best way to be able to fix any of your integrations is to be able to run tests really fast. If you are doing SAP CPI development in ie. Groovy it can be a little challenging to set up test cases for your SAP CPI scripts.

There are a number of different blogs on how to make it possible. I think Eng Swee Yeoh has created a number of blogs on how to test SAP CPI.

You will need some boilerplate code to set up test cases and run and do your verifications. We have now added a way to automate the process.

Last week we showed how we could expose your SAP CPI and API management as a Git repository. In the Git repository, we have added mock services for all the necessary implementations, so it is possible to run the scripts without connecting to the services.

Since it is mock some parts of the running may not be 100% if you use some exotic functions. That is why you still should be testing in real CPI.

In one of the coming releases, we will also be adding mesageFactory to test the attachments that you have created.

The only thing you need to do is to add the SAP CPI jars you can download here.

Testing with Figaf

Last week we released a version of Figaf IRT that enabled you to expose your SAP CPI content via Git. With this integration, we now have another nice option. We can create unit tests based on your scripts.

If you have created test cases for an iflow in Figaf IRT then you have the option to “Generate Groovy Scripts Test data”. This will create test cases for all the scripts that you have in that iflow.

The program will create all input and output messages in a Json format like the following. This will allow Figaf IRT to create automated assertions of all the parameters in the message.

{
  "input" : {
    "headers" : {
      "SAP_MplCorrelationId" : "AF1eZ3x-sdvOIJSgilALr8Lldude",
      "CamelHttpResponseCode" : "200",
      "apikey" : "124234523",
 //  ....
    },
    "properties" : {
      "CamelStreamCacheUnitOfWork" : "DefaultUnitOfWork",
      "CamelSplitComplete" : "false",
      "CamelSplitIndex" : "1",
      "CamelCorrelationId" : "ID-vsa6859459-36905-1565339707446-5304-2",
      "CamelMessageHistory" : "[DefaultMessageHistory[routeId=Process_1, node=CallActivity_27_1566467962530], DefaultMessageHistory[routeId=Process_17, node=CallActivity_39_1566467962450], DefaultMessageHistory[routeId=Process_17, node=MessageFlow_34_1566467962454], DefaultMessageHistory[routeId=Process_17, node=setHeader13227], DefaultMessageHistory[routeId=Process_17, node=setHeader13228], DefaultMessageHistory[routeId=Process_17, node=to14489], DefaultMessageHistory[routeId=Process_17, node=removeHeader3781], DefaultMessageHistory[routeId=Process_17, node=removeHeader3782], DefaultMessageHistory[routeId=Process_17, node=removeHeader3783], DefaultMessageHistory[routeId=Process_17, node=to14490], DefaultMessageHistory[routeId=Process_17, node=CallActivity_41_1566467962463]]",
      ".hasMoreRecords" : "false",
   // ....
    },
    "body" : "{\r\n\"d\" : {\r\n\"__metadata\": {\r\n\"uri\": \"https://services.odata.org/V2/Northwind/Northwind.svc/\"type\": \"NorthwindModel.Customer\"\r\n}, \"CustomerID\": \"TOMSP\", \"CompanyName\": \"Toms Spezialit\\u00e4ten\", \"ContactName\": \"Karin Josephs\", \"ContactTitle\": \"Marketing Manager\", \"Address\": \"Luisenstr. 48\", \"City\": \"M\\u00fcnster\", \"Region\": null, \"PostalCode\": \"44087\", \"Country\": \"Germany\", \"Phone\": \"0251-031259\", \"Fax\": \"0251-035695\", \"Orders\": {\r\n\"__deferred\": {\r\n\"uri\": \"https://services.odata.org/V2/Northwind/Northwind.svc/Customers('TOMSP')/Orders\"\r\n}\r\n}, \"CustomerDemographics\": {\r\n\"__deferred\": {\r\n\"uri\": \"https://services.odata.org/V2/Northwind/Northwind.svc/Customers('TOMSP')/CustomerDemographics\"\r\n}\r\n}\r\n}\r\n}"
  },
  "output" : {
    
    //same as input
    
     }
}

It will also create a testing method like the following that contains all the scripts in the flow and link to all the test messages that you have in the repository. You can remove all the scripts that you do not want to be testing with.

Every time you run the generate test case it will update the file and add more test data with an increased number. So you can run generate as many times as you want it would be wise only to add each test case once, otherwise, you are not adding any value to the testing.

The generated test case looks like the following. And contains testing of all your scripts.

package com.figaf

import org.junit.jupiter.params.ParameterizedTest
import org.junit.jupiter.params.provider.ValueSource

class GroovyScriptsTest extends AbstractGroovyTest {

    @ParameterizedTest
    @ValueSource(strings = [
            "src/test/resources/test-data-files/SetHeaders2/processData/test-data-1.json"
    ])
    void test_SetHeaders2Groovy(String testDataFile) {
        String groovyScriptPath = "src/main/resources/script/SetHeaders2.groovy"
        basicGroovyScriptTest(groovyScriptPath, testDataFile, "processData", getIgnoredKeysPrefixes(), getIgnoredKeys())
    }

    @ParameterizedTest
    @ValueSource(strings = [
            "src/test/resources/test-data-files/setHeaders/processData/test-data-2.json",
            "src/test/resources/test-data-files/setHeaders/processData/test-data-3.json"
    ])
    void test_setHeadersGroovy(String testDataFile) {
        String groovyScriptPath = "src/main/resources/script/setHeaders.groovy"
        basicGroovyScriptTest(groovyScriptPath, testDataFile, "processData", getIgnoredKeysPrefixes(), getIgnoredKeys())
    }


    @Override
    List<String> getIgnoredKeys() {
        List<String> keys = super.getIgnoredKeys()
        keys.addAll(Arrays.asList())
        return keys
    }

}

I think this approach will make it a lot easier to set up testing and run a set of assertions. As you don’t need to do anything and all required information is added to the environment. If there are parameters that you want to exclude from your script you can add it to the getIgnoredKeys.

Custom testing

The standard way will only allow you to test input with the expected output. It may not be what you want to do in all cases. There may be test cases you are creating that need to be evaluated differently.

You then have the option to just send a message to the processing and then insert your assertions to the processing. An example of such a testing approach is the following. So here you can do all your custom assertions and get the errors if anything does not match.

An example of such a custom validation could look like the following.

package com.figaf

import org.assertj.core.api.Assertions
import org.assertj.core.api.SoftAssertions
import org.junit.jupiter.api.Test

class SetHeadersTest extends AbstractGroovyTest {

    @Test
    void customTest() {
        String groovyScriptPath = "src/main/resources/script/setHeaders.groovy"
        String testDataFilePath = "src/test/resources/test-data-files/setHeaders/processData/test-data-1.json"
        def (MessageTestData messageDataExpected, MessageTestData messageDataActual) =
        processMessageData(groovyScriptPath, testDataFilePath, "processData")
        String actualModeValue = messageDataActual.getProperties().get("newError3")
        Assertions.assertThat(actualModeValue).isNotNull()
        Assertions.assertThat(actualModeValue)
                .endsWith("Test3")
    }

    @Test
    void customTestSoftAssertions() {
        String groovyScriptPath = "src/main/resources/script/setHeaders.groovy"
        String testDataFilePath = "src/test/resources/test-data-files/setHeaders/processData/test-data-1.json"
        def (MessageTestData messageDataExpected, MessageTestData messageDataActual) =
        processMessageData(groovyScriptPath, testDataFilePath, "processData")
        String actualPropValue = messageDataActual.getProperties().get("newError3")
        String expectedPropValue = messageDataExpected.getProperties().get("newError3")

        SoftAssertions softly = new SoftAssertions()

        softly.assertThat(actualPropValue).isNotNull()
        softly.assertThat(actualPropValue).endsWith("Test3")
        softly.assertThat(actualPropValue).isEqualTo(expectedPropValue)

        softly.assertAll()
    }
}

In the examples you can see different ways to run the assertion.

Try Figaf IRT

There is a community version of Figaf IRT that allows you to run the application in single-user and with some limitations, but all of this should be working. It is all free.

I do hope that you see the functions and can see how much it can improve your usage of SAP CPI and want to buy the full package.

We are improving the functionality over time, so it will be easier to manage your SAP CPI system.