Posts

The testing solution from SAP to test PI/PO called PIT

Friday the 8 of March was the day that SAP finally released SP 14 of SAP PI/PO 7.5. The big promise was the new testing solution that allowed users to test SAP PI message process. It is called PIT.

“TL;DR the testing solution from SAP has some good features for testing. If you are serious with your testing and want full coverage then try out the Figaf IRT tool. “

As a vendor with a similar product, I have been interested in knowing what was going on with it and how it was working. I had seen some initial working of it but did not know where it would end. If it was going to be a killer product then it would remove part of my market. No customers can see the solution and judge if it will be useful for their use cases.

The key takes away is that testing is an important part of your it process where it is upgrading/patching, development or change of your interfaces. It is something that customer have expected and would like to see improved.

It is also good to know that SAP is taking the same approach as we have for fetching and running test cases.

Let’s start with the good part.

The Good part of PIT

  • It is a part of your license so you do not have to pay separately for it.
  • It removes the excuse that you cannot run any tests because you can always set it up
  • It supports fetching test data from dual-stack systems so you can test when you are performing upgrades for the systems. You will need to apply some ABAP notes to allow the recording.
  • You don’t need to install extra systems to run it the testing application.
  • It has a shared repository of data that all developers with the right role can access.
  • You can configure comparison of attachments
  • There are batch jobs running message processing and validation.
  • It is standard software following SAP delivery and support method.
  • Messages can be stopped before reaching the adapter and thereby not send it to the receiver.
  • That no changes need to be made to your landscape except you need to switch logging on for a period of time for the interfaces you want to collect data from.
  • It gives a good overview over how many messages that are affected by a change in one element
One overview i like. In just one screen you can see where the differences are structure across the testing result

I have not seen any roadmaps of the tool and how much resources and new features will be delivered but it looks like there will be more effort in it. So this is all based on the initial release.

Check out the video that I recorded that show my first look at what the tool can do.

My first experience with the tool and what is possible.

I believe that PIT will probably run more tests that my tool because the availability of the tool and customers it is simple to install the system.

What are the requirements

The test system must be installed on a 7.5 sp 14 or above. It can only run a test on the system with that SP level.

PIT  is able to collect test data from AEX system 7.31+ that have been updated within the last 2 years (It requires this note 2650265, which seems to have been backported to all service packs on 7.31+).

PIT can also collect messages from ABAP based systems here you need to apply some more support packages to allow the system to read data.

Read more on

I still see some areas where we have advantages over the SAP tool. (Okay, I may be a little biased, but if you try it out you will hopefully too.)

Why you still need to buy my tool

  • It enables you to test your modules that way you are ensuring that it is also covered as a part of the test.
  • We have a number of options for testing including using the SAP logging, but unlike SAP we du support all 7.31+ releases because we have web scraping to get messages. It is not an ideal solution but allows you to create test data on your old system without having to patch them. Because then you will have to do testing.
  • The speed of recording multiple test cases is a lot faster with the IRT tool because it can handle a lot of configuration needed. You can select multiple iflows and record them at the same time.
  • We do have a graphical overview to view differences and add ignoring of certain elements like time stamps that you do not want to cover.
  • Figaf support patterns not covered by PIT like Async-sync, Sync-async, EDISeperator and pattern is determinated automatically
  • Comparison not only in XML but also JSON, X12, EDIFACT, Text, and Binary
  • Simple data anonymization. You can select your input payload and then with a few clicks analyze everything and insert random names or number on different locations. This allows you to test with sensitive data and comply with GDPR.
  • Allow you to run multiple jobs and test cases when you want or scheduled
  • Excel report of all results so you can show how it worked
  • Connection with our DevOps solution so you can ensure that you are testing all interfaces that are affected by your change. It also allows you to document what was changed.
  • For customers the ability to get new features or functions delivered in days.
  • And so on… I could probably find a few more areas that we cover better.

Will we integrate the Figaf IRT tool with PIT

Since SAP will have a lot of test cases running in the tool we may be able to add some additional benefits of running tests with it. There may be something that can be implemented. We can leverage the way SAP is processing messages if you don’t want to get the test messages into the adapter. We could also use the ability to send a message directly to the message processing without creating an XI30 message.

We cloud probably also leverage the SAP part about downloading messages from dual-stack systems, and use them in our landscape.

IT will probably depend on when customers are adopting 7.5 sp14.

Your take away

If you have a plan to apply 7.5 sp 14 in the near future to your landscape do evaluate it. And see how it fits your plan and idea for working with the tools.

If you want to tool that can help you set up test cases faster, give you full tracking of what is being developed then try out the Figaf IRT tool? And we do support CPI also in the same approach.

You can check out the tool and see if it will suit your testing capabilities better. Check it out at Figaf.com/IRT


A different way to restart SAP CPI content

It is pretty difficult to restart SAP CPI messages from any external applications. There is just two ways that include either the Enterprise Messaging/JMS or the Datastore. Some times this can create some complex scenarios for the user to develop.

We wanted to make some of the development a little easier. It requires just one groovy script and two script steps in your iflow. We will show a different way that allows you to restart messages in an external application and setup rules for how often it can be reprocessed. We leverage that the Figaf IRT application is able to download messages that have a specific filter like Receiver is LOG. Then the message will be downloaded and you can apply some rules to it like it should be reprocessed 3 times. There is also the option to send notifications to emails or systems like Jira.

Check out the video where you can see how simple it is to restart a SAP CPI message.

We currently do not know how this will affect count of connections on your SAP CPI system, so use with caution.

You can try out Figaf IRT on your own system. We have both a cloud and an on-prem version to deploy the application.

You can see the code below, it will be updated so you can find a more uptodate version in the IRT application.

package com.figaf.irt
import com.sap.gateway.ip.core.customdev.util.Message
import org.apache.camel.converter.stream.InputStreamCache
import groovy.json.JsonOutput
import groovy.json.JsonSlurper
def Message initalSave(Message message) {
    try {
        //Body
        def body = message.getBody(java.lang.String)
        def base64 = body.bytes.encodeBase64().toString()
        Map map = message.getHeaders()
        map.put("body", base64)
        message.getHeaders()
        def json = JsonOutput.toJson(map)
        def cache = new InputStreamCache(json.bytes)
        // we save the json as a property, so we can restore it in the pipeline
        message.setProperty("IRTSAVE", cache)
    } catch (Exception ex) {
        try {
            def messageLog = messageLogFactory.getMessageLog(message)
            messageLog.setStringProperty("CustomLog", ex.getClass().getName() + ":" + ex.getMessage())
        } catch (Exception ignored) {}
    }
    return message
}
/**
 * An error have occurred then save the payload as an attachement
 * @param message
 * @return
 */
def Message savePayload(Message message) {
    try {
        def messageProperties = message.getProperties()
        def ex = messageProperties.get("CamelExceptionCaught")
        if (ex == null) {
            return message
        }
        def irtpayload = message.getProperty("IRTSAVE")
        JsonSlurper jsonSlurper = new JsonSlurper()
        def map = jsonSlurper.parseText(irtpayload.getText())
        map.put("Cause", ex.getClass().getName() + ":" + ex.getMessage())
        irtpayload = new InputStreamCache(JsonOutput.toJson(map).bytes)
        ByteArrayOutputStream bytesOut = new ByteArrayOutputStream()
        irtpayload.writeTo(bytesOut)
        def messageLog = messageLogFactory.getMessageLog(message)
        messageLog.addAttachmentAsString("IRTSAVE", new String(bytesOut.toByteArray()), "application/json")
        message.setHeader("SAP_Receiver", "LOG")
    } catch (Exception ex) {
        try {
            def messageLog = messageLogFactory.getMessageLog(message)
            messageLog.setStringProperty("CustomLog", ex.getClass().getName() + ":" + ex.getMessage())
        } catch (Exception ignored) {}
    }
    return message
}

IRT Transporting – Improve your SAP CPI life

In this blog, I will cower how IRT Cloud will improve the way you work with transporting.

Before we get started, we need to find a clear definition of what “DevOps” are. According to wikipedia it goes like this:

DevOps is a set of software development practices that aim to shorten the systems development life cycle while delivering features, fixes and updates frequently in close alignment with business objectives

Understand what is changed

Track what object is being changed
– Is it a part of the BPMN model
– Is it scripts or mappings
– Is it configuration which is changed

Register changes with business reason

Make a service request in the IRT tool, that allow you to link the changes to the reason.

User can assign changes in iFlows to it:

Test the changes

With the build in testing tool you are able to test the modification you make does not not affect anything unexpected.

You can document what test you have run and the result of them.

iFlow configuration in the landscape

Configure an iflow once and then let IRT handle configuration in the landscape once importing the change:

Transport individual

Be able to import changes into target system. Figaf will import the object into the target system. Then configuration will be applied:

Check out the demo

So, I if want to check out how this work, please take a look at the demo video below:

So, I you ready to try Figaf IRT/Cloud to see, what IRT/Cloud can do for you? I offer a 30 days free trial at https://figaf.com/IRTCloud.

Doing SAP CPI Transports with IRT

Once I started to make my first SAP CPI transports I did not like that you needed to transport the full package. I wanted just to transport a single Iflow and log what was changed with it, then I knew what was being changed. But it was a rather difficult process to make sure you did correctly. So I thought we could optimize the process to make it easier to apply transports for single iflows.

So we have created a flow for developers where they will make the normal changes.

  1. Save it as a version in the development CPI system after normal development
  2. Syncronize the IRT with the CPI system (by clicking the button or wait for the scheduled synchronization job)
  3. Create a ticket and assign the object version to the ticket. A ticket can correspond to a Service Request or Incident. It is possible to update the version if you have multiple attempts to fix the problems
  4. From the ticket, you then create transport with one of the Iflow on the systems
  5. IRT can then import that QA/production system. It will delete the existing iflow and upload the new version.

I have recorded a demonstration video you can see how it works

The following are we working on before it will be released.

  • Fix some of the few bugs we have seen in our test environment
  • Have a way to get the configuration in a global table, so once you import an iflow on QA it will apply the configured configuration from IRT
  • Investigate if we can upload the new iflow without removing the old version.

There may also be other ways we can integrate this both with our testing application part and make a flow that better fits with a DevOps focus of development.

We expect this functionality to be released within the next few weeks both in our cloud application as well as the on-prem deployment of IRT.

Want to try it on your own system

Try out IRT

Try IRT Cloud

News for Figaf IRT – January 2019 Improving SAP CPI and PI development and monitoring

Enhanced SAP CPI Monitor, Web integration and PI create test form error

So, lately I have been working with development of Figafs Integration Regression Tool, and I think the new stuff is pretty cool. Hopefully, it will be something that is useful for you to improve the ability to develop and run SAP CPI/PI content even faster and give you less support. If you have ideas for improvements I’ll like to hear.

Improved SAP CPI monitoring

We have improved the logging of errors. So it will download the attachments for the failed flows. Then it will be a lot easier for you to monitor and process the alerts. We have also improved the OData filter, so you can specify filters for messages that do not fail. So if you are using sender and receiver information you can setup a filter like Sender = ‘Salesforce’ and Receiver = ‘LOG’ that way you can get the payloads even if there are no errors on the CPI flow.

Support tool with webhooks

The IRT Support desktop is not the only one in your organization. This way you can setup integration with Jira, Paparduty or Solution manager. We configure to receive Jira notifications in about 1 hour with the information we got from the rules using zapier.com but you can use SAP PI/CPI for it.

 

Used Mappings report

Understand what is used on your SAP PI system of mappings, we have now added an option to show also Java Mappings, XSLT and also Message Mappings. Just use the Excel export of your configuration scenario.

In December 2018 I published a blog about this topic: SAP PI/PO Used message mapping.

Create a test case from a failed message

If your message fails because of a message mapping, you can set up a new test case to cover that case. This way it becomes a lot faster to validate that you have fixed the mapping once you have fixed the problem.

 

Want to ease your work?

I do believe that these improvements will make your work a lot easier. If you want to learn more please watch this video:

 

The last details

I also cover my newest insight about IRT in this slideshow:

 

You can try the features now on your own SAP PI/CPI system.