Complimentary Access to Figaf to run your SAP PI/PO, CPI or API Mgt

/0 Comments/in /by

Companies are closing down. You will be affected by your work habits.

Today Denmark is closing down, and I expect a lot of other countries follow. 

You probably will not get less Integration work. Probably you will need to implement some new integrations fast. 
We want to help you make your work easier for the coming period, so you can focus on creating integration and not having to use time on manual work. 

We have made tools to simplify your SAP PI/PO, CPI, and API management processes, and it will help you with your projects.
We can help with:

  • Monitoring
  • Transports
  • Documentation
  • Tests
  • Migrations from PI to PO (To migrate from <7.5 to 7.5
  • Git integration for CPI and API mgt

Until 30 May 2020 you can use our DevOps package to test and transport up to 100 ICOs, Iflows or API proxies. 100 Tickets to register changes and 50 Migrations from PI to PO. And use the other functionality to document, and monitor your integration. 

The tools can be set up really fast. In just one hour you can get started. For the on-prem, you can use your laptop. In most cases, you will be able to use your normal PI or S-user for the tool. There are video instructions on how to get started, and we have also improved our manual. The biggest challenge will be to get the optional agent installed on your SAP PI environment to improve the testing.

You can use Figaf on-prem or the Figaf Cloud for the duration. 

Signup here

Figaf IRT onprem
Figaf IRT Cloud

We do hope you will find the tools so useful you will continue to use them after the complementary period. 

Please use responsible and not overload our systems, otherwise, we may need to change something. Please use your company email. We will be providing support via email or remote sessions.

I expect to conduct some free training sessions (Online of course) next week for the people that have signed up for the trial. 

There will also be a webinar on Thursday 19, with the topic of how Figaf can help you manage SAP CPI.

SAP CPI Testing, now with Mock and secured data

/0 Comments/in , /by

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

/0 Comments/in /by

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.

Sign up now

The new Roadmap for SAP PI/PO and SAP CPI Suite

/0 Comments/in , /by

At DSAG (German-speaking user Group) there was a roadmap session that we could see some points from. This is what happens after SAP updated their support for ECC/Business Suite to 2027 it and implications for other tools. 

I would assume that this is the current working model and we will see more updates on this later. There will come an official roadmap later, once everything has been cleared. 

I created a video with some more information.

Biggest takeaways were:

  • PI 7.5 will be the last release but support extended some years until 2027.   
  • So now a new version that we got the impression the last years. 
  • There will be an on-prem version of SAP CPI and API management you can run on your own hardware. With a monitor and development tool. 

I really love this. It will have a lot of benefits to SAP customers. 

SAP PI

Java 8 has been extended support for longer by oracle. So there is no reason to upgrade to Java 11 and create a new version of NetWeaver Java. It would be costly for SAP to upgrade and also for customers so it makes a lot of sense. It is both PI but also all the other applications on the suite.

It would also be a stretch to get customers to move to the next NetWeaver release within 2 years, now have customers that have not upgraded for 10 years. 

I don’t know what the investments will be into PI/PO with this extended support. I would assume they free some capital for not having to perform the upgrade. 

SAP CPI

SAP CPI is the path forward and where customers should move. 

Removing PI from the Netweaver stack makes a lot of sense. It was probably 6 months behind cloud deployment and was costly to implement. I would assume there is quite a bit of work to port the framework to use the Netweaver stack compared to the cloud. 

That was the main reason we dropped running our Figaf tool on Netweaver stack. 

My assumptions of this: 

  • I would assume that you need to upgrade every 1-3 months to get support or even be able to use the tool. I expect that SAP does not want customers running 5-year-old versions of CPI. So you need to be able to test and upgrade much more often.
  • If SAP did not have the dependency for Netweaver then CPI can be upgraded to Java 11 and Camel 3.0. 
  • If SAP will allow users to have an on-prem version of the CPI then it means that there will not be a change to WebIDE to develop CPI.

Learn more

If you want to learn more about SAP CPI we have created a course that helps you understand how you can develop SAP CPI, so you can get started faster. On the side you can also find our free version of the course.

If you want to develop and manage SAP CPI better try the Figaf IRT. It enables you to manage, govern, test and document SAP CPI and API management much simpler.

Plan an SAP PI/PO patch or upgrade

/0 Comments/in /by

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.