Why have a full SAP PI/PO regression test case is needed

Do you have a full set of regression test cases of your SAP PI/PO system and can run them when needed to ensure that nothing is broken.

This week I was talking with a potential customer about our testing tool and the newest feature where they did not need to install anything on the PI system. They did, unfortunately, have a too old version of one of the components to allow us to read the log messages. It was added with OSS 2437778.

It is the standard way out to add new features to patches or service packs to give customers there the features which are required. Most of all the time you want to be able to leverage the new functions in some scenarios to solve a business need.

With the way SAP is delivering the Java code is it cumulative patches. This mean that patch 3 contains updates from patch 2 plus some more changes. So you cannot just get the fix you want as you can with ABAP.

They are also linked with dependencies so if you upgrade one, some part will stop function because it is missing a dependent library. So most of the time you have to update quite a bit of component and you have no idea about how this will affect everything else. You can read the release notes, but it is difficult or close to impossible to predict how this will impact your system.

And to make matters even worse, you probably need to upgrade all components to the latest to ensure all dependencies are met.  

In a normal company it will take a long time to validate these things, so if you’re just adding a simple feature it is really a no go to do this. The business case is difficult to explain, we want this feature to do X, but it will cost a lot of testing. So you have to wait for the business to ask for a new feature and then that project would have to pay for the upgrade/patch.

That’s the reason why I want to have a full set of regression test cases that you can just run whenever there is any patch or an upgrade that you have to ensure that everything works as expected without involving people in the testing of the new features.

The price for an upgrade is a partial basis to get them to upgrade the system and then a part to test the component. The biggest cost is the tests that you need to perform to ensure that everything works as expected. It makes, therefore, sense that to be able to automate that part if it is possible.

With most test tools that take a long time to set up these the test cases and that’s why we’ve created a tool to enable you to set up these test cases fast.  We had a customer Anadarko Petroleum Corporation that could set up 300 test cases in just 3 weeks.

Since then we have optimized the process a lot making it a lot faster to set up test cases. So I would assume you will be able to set up test cases a lot faster than now.

The cost of running the test for the full system is close to zero, so you can run them daily to get information about how the system performs or if anything is broken.

So you can apply the latest support packs if you want to have an updated system with the latest features and fixes.

You can download Figaf IRT tool and use the tool for free upto 10 ICO’s to test on your own SAP PI/PO system. You can request a trial license to get more tests done. If you already have the patch mentioned then you don’t need to install anything on your system and in many cases use your own use for the testing.

 

Migrating Seeburger to SAP B2B Add-on the fast way

We have lately seen a large interest in the Seeburger to B2B Migration because SAP PI/PO customers are seeing as a way to bring down cost and optimize. There is a number of factors that allow users to achieve this

  • The new solution from SAP has a lot of advantages making it a lot more flexible and supports the newest schemas. It includes all EDIFACT, X12, Tradacom and EANCOM messages that you want to be using, so you don’t need to pay for each message.
  • It is also simpler to transport since they don’t require the use of the BIC to make the one to one mappings
  • It contains all the same adapters with some new features
  • The price of the solution is also included in your standard SAP PI price so you don’t need extra licenses to make sure you can communicate with EDI for your partners. So you can save money on the maintenance of the Seeburger solution.
  • You have the option to use the Trading Partner Management solution making it a lot easier to maintain many partners and the information from them.

When facing the migration there are some challenges that you must figure out how to solve.

  1. Schemas are different so everything needs to be remapped
  2. Test nothing happens with the output messages.
  3. Budget and planing

1) Schema changes update from Seeburger

One of the issues is the schema structure between the Seeburger and the SAP PI B2B Add-on is different on some different levels. The root element is different but there is also some different naming of groups and fields. In the Swing tool you have the option to remap some fields, but then you need to take manually account of all the fields in all mappings. And if it is not done consistently then you can end up with problems.

I always want to optimize as much manual labor as possible as that is what we are doing with our Seebuger Migration Tool. Simply select the message mapping and the new target XSD and it will convert it for you.

We currently have the free introduction package that contains 10 mappings for free. It is normally 100 USD pr mapping. So it is a really good way of getting started with the migration. That way you can prepare your self for the migration project and understand the complexity and what you otherwise need to move.

In the video below you can see how to get started, requesting licenses that you get to select 10 off for free. Then run the migration. Running the migration for a message mapping takes a few seconds.

 

2) Testing the migration

For any migration, it makes sense to test that nothing vital has changed. It is really crucial for EDI because the importance for the business, you cannot afford to be down for a period of time.

Even if the mappings are validated there is still a lot of components that you need to ensure is not messing up the flow. We recommend using the Figaf IRT SAP PI/PO test tool. You can use it for free for up to 10 Interfaces, so you can use it to validate the migration tool work. The Figaf Testing tool is build to make it really easy to fetch test messages from your production system, and then be able to use them on your development system for testing with. If there is any difference you know there could be something wrong. IRT has support comparing XML, EDIFACT, X12 and other formats.

If you purchase the migration tool for your full conversion we can find a good offer on the test tool.

 

3) Budget and planning

It is pretty difficult to get any budget for a migration project. In most cases, you will halt development for a period of time to perform the migration. It is more fun to spend the money o new development that helps the business. The biggest reasons for a Seeburger to B2B add-on from a financial perspective is that you can avoid the maintenance of the Seeburger application and use the license you already have. The support and maintenance of the new system may also be faster but it will not likely be something that will make it selling criteria.

I have created some blog post that covers more details on how to perform migrations in and make it easiest. They are focused on general migration but it will be the same concepts that are required for the other migration.

 

Testing SAP PI/PO without installing anything on the PI server

With Figaf IRT we have been able to test your SAP PI/PO system for two years.

One of the big concerns of customers was that they needed to install our component on their SAP PI/PO system. We have tried to ensure that it cannot break anything and they can receive the code for it. I do understand the challenge in organizations.

That is the reason that new now have added a new feature that allows users to test only their SAP PI/PO interfaces without installing any code on the server. They just download our Jar application and start it on the local laptop for testing. Then add connection information on the PI server, and in most cases, you can use your existing SAP PI user for it.

You can try it out now at https://figaf.com/irt

It is free up to 10 ICOs/100 inbound messages used for testing. You can run it as many times as you like. There is also a host of other features for testing and improving the development of interfaces.

Requirements for testing

You must have JAVA 8 on your laptop to run the IRT application. And it must be able to start up the web application that is build in to it.

You need a patched system after October where the feature to read payloads from the log messages was released. See SAP note 2437778 

You user must have access to read in the message logs and possible setup the XI30 channel for running the test with.

You will need to have the interface to save both the inbound and outbound message (BI and AM) . You can configure this global or just for the specific ICO/Iflow See this blog on the logging. It is just the logging required not the staging.

Future development on this

We still have a few improvement that will be delivered over the next weeks.

  • The ability to look in the history instead of just from you start the recording. This will make it a lot faster to setup test cases because the system could see everything you have processed.
  • Option to add the standard SAP Logging modules on the channels to allow recording of messages after module. It will cost a little on the performance and storage requirements but for some scenarios it will make it easier to run
  • Support for other patterns than just Async.

I’m looking forward to hear you feedback on how this works in the real world.

IRT feature: Monitor SAP Cloud Platform Integration Content (CPI)

A few weeks ago we added an option to monitor your SAP PI/PO repository content, so you could see what was changed in any objects. And based on the changes you registered you could test the scenarios.

We have also enabled users to test SAP Cloud Integration so it made a lot of sense also to monitor the content so we could support full cycle development. So we can now monitor all changes to the content. So you can see what was changed in a script and what areas were changed in an iflow. The output may be a little technical but it will allow you to see that something was changed.

We also have the ticket content that allows you to register the changes that you are doing and ensuring that you are testing all of the changes that you are making. It is a way to ensure that enables you to document the changes in a better way than using Word documents for the information. You can then link your existing ticket/helpdesk system to the IRT tickets as an extra data source.

You can see a short demo here.

 

There is some features that we will improve in the comparison, so you can see the message mappings content and see the part that was changed. And also improve the comparison of scripts. It will come in a future release.

If you have other wishes to future development do let us know.

First I recommed you to try to install IRT and try it out. You can get started within 30 minutes. Watch the Cloud Platform Integration installation and configuration guide video .

 

Add IRT to your existing SAP test scripts in HPE UFT

We have been getting request on using Figaf IRT as a way to improve the testing of existing customers existing testing application. This will allow you to test both SAP PI/PO and SAP Cloud Platform Integration (CPI)  in the flows.

A few releases ago we released the new testing principle for Baseline testing. Baseline testing requires that you are sending the same messages into the system again, as the perfect companion to when you have existing test scripts in Solman or in this case HPE UFT. If you want to integrate with any tool then this guide provides a good way to start the integration.

In your existing HPE UFT, ALM or Worksoft solution can create a comparison and do validation of which messages are sent. There is an API to read the messages from the PI system, it would tough require a lot of coding to ensure that you got all the validations correct. We are really good a making test of the messages in an Integration system, so you can just focus on creating the validations of existing programs. It would be really beneficial for you to know what messages are changed and why.

The steps in the procedure are outlined in the video below. It will probably take you 10-15 minutes to add the IRT component to each script that you are running.  You need to run the script a few times to ensure that it works and you have configured IRT correct. The video covers how to set this up.