Test your SAP PI/PO transports

SAP PI/PO development is not just about creating interfaces, map the documents and configure the interface. There is the full change management part about ensuring you know what is transported and ensuring it is tested correctly. This is something that normally requires a lot of paperwork and manual steps. It is one of the critical things about the process, to ensure that nothing else is broken.

We have been working on a tool for making sure that the testing works better and is a lot faster to set up. We have now implemented a functionality that allows you to run the same test on your QA environment with a click of a button. We have had the option earlier but it required some manual work, now you can just select which system to run the test on and it will happen.  You can also run the tests with the key of your transports.

Check out the video on the tool and how easy it is to run the same tests again on your Test system.

 

 

The solution is designed to work together with the SAP Transport (CHARM) you just need to implement a call once the transport has been imported to ensure that the test is called with the correct system.

We have a free version that allows you to start testing your system really fast and then it has the option to also support in your development process.

It is really fast to implement the solution and get it up and run. It will probably take 15 minutes to get it running on your system.

 

 

How to get paid more for your SAP PI/PO/Cloud Integration Projects

I started my IT profession in one of the big five accounting companies in 2001. One of the things I got really impressed by was how they were able to create nice looking models of how to approach all kinds of challenges.  It is a lot easier to sell something to a customer if you had a model then you had a superior product. If you have the matching powerpoint that you can show it becomes even easier. The model did have some good ways of approaching the situation from a business perspective, but it relied heavily on the experience of the consultants.

Example of a model, probably not the best. It does have nice colors

I was writing my master thises around one of the models for security testing. My focus was on how we could improve the testing with an automated tool. This way we would be able to test more with the same resources. The tool we build worked ok thought it was not the easiest to use. I did manage to get the project approved and got my masters degree.

I did learn that you need a good framework to show you are different and can command higher rates.

I wrote a blog on the importance of having a great quality and how difficult it is for customers to judge. Customer score price and quality as separate parameters, and score them in some way. If you are able to prove your score in quality you may be able to command a higher price. The way you can document your quality is with:

  • ISO, ITIL or other certifications
  • Have customer references
  • Having a model that shows what you will do
  • Have a tool that automates the processor model

How are using Models or Frameworks

SAP Activate (credit: SAP)

SAP has SAP Activate which assists companies to implement S/4 HANA faster. It is using a methodology, a set of templates for best practices and the solution manager tool. It should all be making it a lot faster to implement S/4 for customers and enable them to faster take the leap of faith and start the implementation. Earlier they also had the ASAP (Accelerated SAP) implementation method. They have updated the model to be more agile focused suitable to newer approaches. 

In some cases, you may have your own methodology for delivery. Either a project management or from a service delivery point of view. You can present in a slide deck of about 105 slides. That covers all the situations and explain how the business will get all the benefits and no risk for the implementation project.

For SAP PI/PO projects you can follow any form of a waterfall or agile methods. From what I have seen there is a lot of exploration in the process to get users to understand what is going on. There has not been that many tools allow you to increase your performance and reduce the risk.

At Figaf we are working to improve the development process making it a lot faster to do developments. This will support your projects making it a lot faster for you to do the implementation and will lower the risk for you. The same thing is true for SAP PI/PO project the better framework you have for prove that you will deliver quality the better.

And if you can show this is not just paperwork but something that has an IT system behind will improve the quality even more. Enabling you to get bigger projects. 

What tools will help SAP PI/PO or Cloud Integration

We have the following offer things that could be in your next bid, to ensure that you can prove your work and what you are doing.

  • SAP PI/PO/Cloud Integration lifecycle tool. This will allow tracking of what objects are changed, show you the difference between each version and show and test the objects in question for any project.
  • SAP PI Support tool that will allow you to handle errors faster and ensure you document how to solve the issues.
  • SAP PI Test tool that allows you to set up test cases for all scenarios fast and runs them. You can use it for
    • Migration project to ensure there is no impact on the output messages
    • Upgrade project where you just want to upgrade the SAP PI/PO system to latest support pack and do not want to test too much
    • Everyday development of interface where you want to be able to do regression testing.
  • Seebuger to B2B Add-on Migration tool that allows you to speed up the conversion of the old mappings to use the new formats for X12 and EDIFACT. In this we would also recommend the test tool, so you can ensure that everything is covered and there are no surprises. 

(The first 3 tools is grouped into just one application that you can run standalone making it easy to deploy and use on projects)

You can try out the products for free on the website or simply just register below.

Why will a tool help your projects

As a consultancy, you are often billing for a number of hours so the more hours you work the better. If you can lower the number of hours you work and get a higher rate for your works it will give you bigger revenue. Some of the reasons are: 

  • A lower number of hours worked, so you can command higher rates for the hours or have fixed price projects
  • Reduce the risk of your project
  • Improve the quality of your documentation
  • Better employee satisfaction because they are not going to spend as much time on the creation of boooring documents
  • Better business satisfaction with your services, so you will be able to work long-term with the customer

At the moment I don’t have any SAP service partners at the moment, but some are looking at it.

We can also get a price for your project that accounts for project duration and number of developers, so it can match your project scope.

The Goldilocks Zone of Change management for SAP PI

Setting the correct change management procedure can be challenging. You need to capture the right things and not too much.

For one SAP PI/PO client, I just had to do development in Dev, and then move to production to test. I was really uncomfortable doing this.
Another client requires a lot more effort to do the transportations needed. Here is multiple checks and validations to do transports. Here it takes too long time to do something.

That is the reason I believe there is a Goldilocks zone for change management you need to do not too little and not too much.

In many places, people are just trying to implement the same changes that they have to do ERP changes. Which is probably not ideal for transporting SAP PI/PO objects. I have been spending a lot of time making documentation that was not ideal.

In my example where I had to change a field in the XML formats it would be nice if I could mark the changes and then use it. The more manual work you are going to do the more difficult it will be to make the documentation and ensure it is correct. And how do you find it when it is necessary. So at the client, I worked where we had a lot of documentation we could just capture a few lines text about what we had done on the interface. Finding it again would be difficult because how did you find the message mapping information.

 

For SAP PI/PO we are working to improve our Change Tracking tool that allows you to do better change management on your landscape. We have currently been looking at just directory objects, but in the next, release we will also have documentation of repository objects. This will allo you to assign a ticket and a description of why something was changed. You can then see for a message mapping when something was changed in it and why. You can also do an easy comparing between the versions to find the differences.

Read more at http://figaf.com/ctt

 

Updating a SAP PI/PO system, what to think about.

Do you open iPhone/Android apps that have not been updated for 1 year. I have 3 apps on my phone not updated in 2018. Yet most companies do not upgrade vital systems for years. This post is around updating your SAP PI/PO system.

Your SAP Integration

In all organization is Integration really important. It must run 24/7 without interruptions or problems to ensure that your IT systems function optimally. The integration layer connects everything and is therefore critical in all processes.

As developers, we have to be at agile and develop integration today so the business can start using it and get the benefit of it today. This contradicts normal system development because the amount of paperwork and testing can take a lot of time.

I hope this post will give you some insight into how to keep your SAP PI/PO system update and what is really useful in that case.

Takeaway

To make the upgrade/update easier, ensure you have automated your testing. Have a look at Figaf IRT to improve the test

 

What is the current status

If you are on SAP PI/PO 7.5 SP 8 or above you are probably one of the few companies that keep the system updated to the latest release. In the survey from 2016, there was a large number of users still on releases prior to 7.31. The number adds up to some strange percentages but it shows that a lot of users still use the old platforms. SAP PI 7.31 is from around 2011 so it is pretty old in a world that change so much. 7.5 is from fall 2015. You would probably not start an iPhone/Android app that has not been updated for 2 years.

The two main reasons why companies are not using the latest release is the following

  1. It is too difficult to get the system upgraded. This document covers this part
  2. They are licensed differently

The difference with the license is that SAP Process Integration was licensed pr number of GB traffic sent to Non SAP systems. Process Orchestration is licensed based on the number of cores in your system so it may be a little strange converting the two and many have found it expensive.

There are some ways you can reduce the price by limiting the number of cores.

  • There may be a saving in the number of cores if you move to a newer processor architecture so it can reduce the new price.
  • You can also run the database on a separate system, so you are not paying for cores only used for database activity.
  • Setup message prioritization so you have batch messages being processed slower.

Why Update the SAP PO system

There is a number of benefits of having an updated system at your disposal.

  • SAP Bugs: It has the potential to backfire when implementing new scenarios you could run into problems bugs in the software that you need SAP to fix. So once you find bugs report them to SAP you are asked to upgrade to a new patch. And if you just patch are you then sure nothing else is broken in the process. See the section on update types and patches.
  • Security: All systems have security bugs that are fixed from time to time. There has not been that many security problems in SAP PI/PO system. It would still be an important target for hackers to get access to. So if something critical is found it should be fixed fast.
  • Latest release: You want to be on the latest release to be able to get the new functionality so it can be used to enhance your scenarios. Most features will come in the newest Support Pack that way you can start using it without having to do any workarounds. This is true if you want to run Cloud Integration Content locally, where there is a lot of work going on.
  • Continued support: SAP has a limit on how long time they will be supporting each release and if you get too close to the limit you will have to pay a higher maintenance cost.
  • SAP Support cost: What would happen if SAP only had to support tools 1 year back, then it would be much easier to maintain the code and ad new functionality.

 

The cost involved with updating the systems

Each time you must perform an upgrade or update of the systems there is a number of the cost associated with it. I have tried to list them below at a high level.  

  • Installation cost of installation of the new software on all SAP PI systems can take time. SOLMAN should help to make the installation process easier
  • Testing of the installed system can be a rather big process. It often requires the developer, business experts to do a lot of testing to ensure that it works. This is probably the most costly part of all the upgrade.
  • Downtime for the upgrade. Near Zero Downtime is a hot topic at SAP and it makes it easier to do different types of upgrade without affecting the business. It is also a costly procedure and many organization may skip it so they PI systems can be down for up to a weekend. This always causes problems.
  • Developers may not be able to develop or deliver new functionality while the upgrade is in progress
  • Then there the once that fit into your organization.

 

Different update types

So there’s a couple of different updates types that you can use whenever you are doing SAP PI development. I will cover them in this section.

 

  • Patch:  a patch fixes barks in the current release and it’s not adding new features. It is a cumulative patch so once it is applied it will include all other bug fixes found in the support pack. So you don’t really know what changes are made to the code in the period. Many upgrades also have dependencies to other components so you may have to upgrade may different components to get one updated correctly. This could then lead to other problems.
  • Support package:  a support package add new functionality to the system to follow customer requirements. It also contains some patches of the previous release to fix the bugs in it.
  • Release:  a release is adding new functionality but most important other deployment options like new java versions or support for other databases. It may add new functionality, not in previous releases and contains an updated Support Pack. There has not been any talk on any new version above 7.5.
  • Migration:  one of the upgrades that a lot of people are doing is immigration from a dual stack system to a single stack system this is not really an update but it also counts as a major change in your environment. Most customers would use a new system to do this migration and then move all the different countries that have over to it.

 

What can go wrong with an upgrade

There is a number of things that can go wrong with an update to the standard components. I have seen the following things happen in my time applying patches or support packs. This is the things that should be found in your testing.

Message mapping is changed. This is the most common change. The message mapping framework is complex and rather delicate, so once something is changed it affects other processes. It could be the way User Defined Function is evaluated for complex queues or how it is evaluated if a node is correct.

In this occasion, the problem may only be affected by the few elements where you use a specific function of the framework in the mapping. I have seen four different cases of those changes, where it sometimes only is seen in production because the testing was not complete enough. So some messages failed in production, while a solution should be created. And what happens if the messages do not fail but just give a different output.

Adapters are changed. New functionality has to be added to an adapter so it may behave differently in the scenario that you are using. Sometimes there has been changed to the adapter specific attributes. This will mean that the adapter does not function as you expect and the integration will not work.

Modules are changed. The SAP is providing a number of different modules and they may change. This is not often they are changed, but I would expect that the B2B modules could be a little fragile and when combined with custom content for flat file conversion.

Your own code could change. If your code relies on any SAP or Java libraries the functionality may change in the process.

Something else there is room for other problems to occur like routing or use of Trading Partner Management functionality.

How to test?

There are different ways that you can test your SAP PI/PO solution and they all have advantages and disadvantages. The more you are able to test fast the better because then you don’t have to worry about the changes.

End to end test

An end to end test that you test all components in the flow. You start with the sending system to create the document that you are looking to use, the document is processed in the SAP PI/PO system and delivered to the receiving system.

This is a very time-consuming process to set up and ensures it works. You can either automate it with scripts or just make it manually. In both cases, it takes a lot of effort to create, maintain or execute.

Unit test

The unit test allows you to test just the part that is changing. You are just testing the SAP PI/PO system it is only that part you want to test. Most would just test the message mapping, or just run it to see that it functions. Or you can send in the message in using the test tool in SAP PI and download the response. It is a way to test, though not optimal.

Automated Unit testing

Both of the options for testing is too time-consuming. It takes much time to perform the test each time you upgrade, or just to setup the test cases. That is why I created the Figaf IRT tool for SAP PI. It is a tool that simply allows you to collect a bunch of test data and you can use to test your interface.

So we are narrowly focused on testing just the SAP PI/PO interface, that mean you just select which ICO’s you want to do testing on. Then the system automatically fetches test data from your production system, which is then used as a baseline. To run a test it sends this set of recorded messages into the test SAP PI system and gets a result. The two output message is then compared to ensure they are identical.

A customer has reported they were able to set up test cases 300 ICOs in just 3 weeks. So it is something that is fast to setup compared to a normal End to End test.

The best tool on the market to make it easy to test the things is Figaf IRT, a tool build around optimizing the SAP PI/PO test to be done fast.

IRT 2.1 released for SAP PI/PO including Change Tracking and Manual Upload

Proud of the team to deliver the IRT 2.1 release today for SAP PI. We have now added some features to make it easier to testing SAP PI/PO.

Testing normally requires a lot of manual work it is also the case when you want to test SAP PI/PO. I wanted to make it faster and easier for users to perform testing because I hate testing but it is one thing that you must ensure is performed.

View the video below hear about the different functions and learn what they mean to you. Or read the overview under the video.

 

The main things for users are the following:

  • CTT (Change Tracking Too) is a tool that allows you to see how made which changes to directory objects/trading partner management objects and assign it to an issue/ticket number. So you get a better visibility to when something has been changed. This will be something we will expand to the repository to automatic test what has been changed.
  • Manual Test upload allows you to create a zip file with payloads that you can use to upload your test cases. This is really useful if you have migration from dual to a single stack or from another tool to PI.
  • Audit log to see how made changes to objects and see what is going on on the system.
  • Transfering from 1.4/1.5 for existing customers
  • Included a global splitter configuration if you are testing the EDISeperator file.
  • Help is now provided at https://figaf.com/help/irt/

You can learn more about IRT and download IRT for free for your SAP PI/PO system here.