When to use SAP PI/PO vs SAP CPI

/0 Comments/in , , /by

Over the last week I have see multiply cases where I have recommeded the SAP CPI tool over SAP PI/PO. I was asked why when to select what and why.

There is no right or wrong in the selection of the platforms. For some, the opposite can be a good solution. It all depends on the situation, your future roadmap, investments, and regulations. I have just tried to select the scenarios and cases where it makes sense.

TL;DR

I’m most new integrations should be created in SAP CPI. SAP PI/PO may be better if it is simple integration where you can process a message and deliver it to one or more receivers without having to do other than map it. And the mapping can be achieved in standard SAP PI way, without creating modules.

If this is updated in 1 year, then I would believe that all integrations should be created in SAP CPI.

SAP PI/PO strong side

SAP PI/PO has been around for 15+ year and is a really solid platform for creating integration. There is about 10.000 installations of the platform.

  • It is really good for point to point(s) connection, where it is asynchronous or synchronous.
  • It gives good monitoring and error handling tools, where you can reprocess messages really simple.
  • It has a really good governance model to encourage the reuse of objects and create generic interfaces.
  • It has a large developer community that is quite creative with adding new functionality.
  • Strong B2B solutions
  • It is supported to 2027 and extended support to 2030.

SAP CPI strong side

SAP CPI is a platform that started out as a native cloud solution about 6 years ago. It is inevitable that you need to use SAP CPI if you are using or planing to use, any of SAPs line of business cloud applications.

  • It comes with a lot of pre-delivered content, making it a lot easier to start on your integration. They can be used as templates.
  • Cheap to get started with and does not require a basis team. It starts at 1200 EUR/month of a two-tier landscape.
  • It is a really flexible platform where you can make integration much simpler. It makes it much easier to integrate with the cloud platforms out there.
  • It has the longest feature roadmap, it is where SAP is putting most development.
  • Integration Content Adviser (ICA) should make it easier to create B2B Integration by automation much of the mapping process.
  • It can run what most cloud providers and it will be possible to run it on your own hardware (2021).
  • If you need a “special” adapter, with OAuth, JWT, or check after calling, you can create it in a CPI iflow and use it for all scenarios.

Different scenarios

A lot of on-premise communication

If you have a large amount of integration traffic internally in your landscape. Then it does not make sense to transfer it to the cloud and back again. Then you should probably go with the PI/PO at the moment.

There will be a SAP CPI version that can be run in your own network in 2021. For now you can also run your CPI iflows on a local installed SAP PO system.

Starting developing new Integration

If you don’t have any SAP PI/PO legacy it is a simple choose. The SAP CPI the newest platform to create your integration in.

If you have a lot of integration locally on your network you may consider using SAP PI or SAP CPI on your PO system.

Migration from older SAP PI

If you have to perform a migration from 7.1 – 7.4 to keep the support you have the option to

  • Migrate to 7.5
  • Migrate to SAP CPI

If you have less than 50 interfaces, I would go with a migration to SAP CPI. An SAP CPI migration will likely cost more than a PI, but you will save in not having to install a new landscape and perform the migration. In the long run you would not need to upgrade multiply times.

If you have more than 50 interfaces you may want to migrate/upgrade to SAP PI/PO 7.5. Then later perform a migration to SAP CPI, once a migration tool is there you can upgrade.

If you have BPMN/ccBPM consider if you can migrate them to CPI on PI or in Cloud.

If you are planning migrations check out our resources on SAP PI/PO migrations.

Already on PI/PO 7.5

If you already have SAP PI/PO 7.5 and a similar integration that look like the new, go ahead and create in PI.

If the PI framework is best suited for the pattern then use SAP PI.

If you need to implement some cloud integration or integration that is more than just a point to point connection. It could be needing to create a lookup or create a token. Then CPI is the way to go. It will simplify your integration much because the tool is easier to use.

If there is some predelived SAP CPI content, it is probably the best route to take, instead of spending many hours understanding how to integrate with it.

If you think this sis something that i need to be created in a BPMN for technician reasons, you must consider SAP CPI or CPI on PO first. Then you save a migration later and have a more modern tool.

Want to make it easier to run SAP CPI

With standard SAP CPI there is some challenges in how you can run and manage your Integration content. At Figaf we have developed a tool that makes it easier to run both SAP PI and also SAP CPI. We want to help you automate most of your integration processes, making it even faster for you to develop SAP CPI.

See how you can run SAP CPI better.

We do have the same capabilities for SAP PI.

SAP PI/PO B2B Add-on alternative

/0 Comments/in , /by

We will in the next period of time see a large number of users that will be performing migrations of their SAP PI/PO platfrom to 7.5. I have created a number of resources on SAP PI/PO Migration. One of the big thing in this migration is the migration from Seeburger to B2B Add-on. We do have a tool that allow you to automate the migration from Seeburger to B2B Add-on message mappings.

B2B Add-on from SAP does work and can give you a way to manage your EDI messages. There are still some gaps in the B2B Add-on solution that could be greatly improved and where i see that an alterntaive solution could be better. It is in the area of:

  • Logging and archiving of messages sent.
  • Partner management and settings usability
  • Configuration of partner connections via AS2, VANS or SFTP.

I had a webinar with Paw Pedersen from BizBrains that created a product called Link. Link is a tool build to manage your EDI solution. It is currently being used to manage B2B for Biztalk, but the same system can be used also for SAP PI/PO. They have been running it for a number of customers from small companies wanting to run EDI to big banks. You will learn about what the solution can help with. You can see the replay here.

They have a number of different configuration options and security settings that are required for banks. They also have large customers with many partners, so they know how to make the application scale.

One of the reasons I think it could be useful for you is that you can switch to their platform and then there is no need to upgrade to the PO license and can stay on the PI License. It can save you a great deal of money and speed up your migration process.

There is a number of different ways the Link solution can tie into your SAP PI/PO solution from

  • Just as an Archive of messages
  • Partner configuration
  • Partner configuration that updates your mappings
  • Using it also for SAP CPI.

If you find the product interesting write to psp@bizbrains.com, and get a trial of what the solution can do.

I will be a part of designing a good solution that will make your migration as simple as possible.

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

/1 Comment/in , , /by

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


Casestory: Using Figaf IRT before testing SAP PI/PO upgrade

/0 Comments/in , , , , /by

Almost a year ago I had the great pleasure of having Mark Oshifeso on the sixth episode of the Integration Podcast. Mark was one of the first users of the  Integration Regression Tool for SAP PI/PO. Mark works for a mid-size oil and gas producer based in Texas, and he and his team found out, that using Figaf IRT made it a lot easier to do upgrades of the SAP PI/PO system. I haven´t had the resources to go deeper into the interview before now, but I do think it is interesting because Mark Oshifeso has some great insights from a customer point of view.

The episode was called How to automate SAP PI/PO testing with Mark Oshifeso from Anadarko Petroleum.

Stock image

You don´t need to be a scientist

By using Figafs IRT-tool Mark Oshifeso was able to test much faster.

“The tool is crazy easy to use. It is another generation from the usually SAP-tools, you list your Iflows, you mark those ones, you press record, and it is basically listening to messages in for example production. Once you have done that, you can run your test cases” Mark says and continue:

“The IRT tool helped us run a test circle with almost no human interaction, and we are now in the situation that we upgraded our production based on the automated testing, and we are hoping now to move from a 2-3 years cycle to a 6-month circle.”

Our ambition at Figaf is to create and keep on developing on the tool, so it is easy to use even in companies with many interfaces. Mark Oshifeso agrees that the tool gives a great overview in the process of the testing:

“It is easy to use, you don´t need to be a scientist, and this is really why we were able to introduce the tooling into our landscape of 300 interfaces. Some companies have more than 20.000 interfaces,
and if you have a large number of interfaces you need to have an easy tool. The tool helped us automate the test. The tool is really intuitive.”

“With IRT tool there is a very fast learning curve, and if another person takes over, you have people quickly getting familiar with this tool. There is no science, which is also why we choose it.”

There is no waiting anymore

What we want at Figaf is to give people a chance to optimize their workflow by using automated testing. And fortunately Mark Oshifeso thinks, that we have achieved this:

“The tool it selves is very speedy to use. There is no waiting anymore. The tool is really great to help facilitate, save money and especially save so many hours. The figaf tool is the most holistic approach, and easy to get everything set up, I don´t see anyone else so far on the market”, he says and finishes:

“I can really recommend this tool, if you want to go to automated testing, this is one of the tools
I would really look into.”

Here you can find the podcast: How to automate SAP PI/PO testing with Mark Oshifeso from Anadarko Petroleum.

As you can see Mark Oshifeso had great success using the tool. Since the interview we have made many improvements to the Integration Regression Tool, so I should be even more easy to use today.

Download IRT for now

 

 

SAP PI Migration webinar

/0 Comments/in , , , /by

So, on January 15. 2018 I held a webinar I webinar about SAP PI Migration. In the webinar, I talked about my 7 step plan for migration of SAP PI to a single stack. The 7 steps look as following:

  • Goals
  • Current integrations
  • Pattern mappings
  • Resource consumption
  • Migration phases
  • Development
  • Testing

The plan covers an initial assessment on your landscape and an idea of where you want to move your landscape.

Here you can watch the replay on the webinar:

If you want to know more you can also take a look at the blog post 7 steps PI PO migration, which was published on September 25., 2017.

You can also take a look at the slideshow: SAP PI/PO migrations – How to save time and lower risk on your projects:


Lastly, when you are interested in migration, you might want to take a look at this:

  • Seeburger Migration Tool The Figaf Seeburger Migration Tool (SMT) allows you to migrate your existing Seeburger BIC solution to a native B2B Add-on solution.
    It helps update your message mappings to use the new schemas created with the B2B Add-on. It makes your migration process a lot
    faster and have a reduced risk