Over the last 2 months, we have been working on making full automation of the migration tool. It is probably the longest we have worked on a release. I had expected it would be a lot faster but once we got into the different areas we could see there process we could improve.
There are still a large number of customers how are still not on 7.5 for all their integrations. They will need to be using a lot of effort in migrating. We want to be able to save them time.
The migration is handled in waves/releases that each can contain a number of interfaces/ICOs. Once you have assigned an ICO to a migration task then it will guide you through the process. There is two processes and you will get tickets to handle them both in the Figaf Tool.
Migrate the content from old Dev system to new Dev system
Development to move from new Dev system to production.
What is the goal with the tool
The Figaf tool will handle all transports, testing, and configuration from an easy to use approach. Check the video below to see how smooth it works for the process of migrating 3 interfaces at once time.
There are still some gaps that we need to solve for the process to be maximumly automated, but we are moving towards it. It is a great leap compared to what existed earlier. It also gives a much better view of what you have migrated for each process.
Signup now to get access to the first release once we are ready.
SAP PI migrations are important if you are not on 7.5, you have 16 months to complete it. For the last year, we have been building components that could help in the process. Now we are taking steps to bundle it all together so you as a user will get full support of the process.
Today I held a webinar to show what we have been working on, and get feedback if it was the correct direction. We did not get to show the full process, but it is not long before we can show it.
The goal is to be able to handle the processing of the full migration process automatically. There will be areas where you need to take and handle the processes your self.
Create test cases on your old landscape
Migrate Repository and Directory to the new landscape
Configure channels and ICOs in full landscape
Run testing in the new landscape
Manage the process
You can watch the replay of the presentation webinar
Want to try it
If you think this is interesting then your first step is to try out the Figaf IRT testing part of the application. You can try it for free on https://figaf.com/IRT. You will anyway need to create test cases on your old SAP PI system. We currently support 7.31-7.5 and have a number of different ways to create and run tests. All are pretty easy to setup. Download it for free now. Then in a few weeks, we will show the first version of the tool.
https://figaf.com/wp-content/uploads/2019/09/Automate-SAP-PI-Migration-1.png6281200dgraversenhttp://figaf.com/wp-content/uploads/2016/05/160510_FigafLogo_final_35cm_KW.pngdgraversen2019-09-06 14:11:092019-09-06 16:25:20Automatic Migration of SAP PI/PO
3 years ago I saw the challenges of migration Seebuerger Message Mappings on SAP PI to use B2B Add-on. It was a different structure that people needed to use and it would cause a lot so problems to get it working.
I got an idea for a project to make the process automated. I found a developer that could create a Proof of Concept for it and it did work. We could take a Seeburger Message Mapping on our SAP PO system and update the mapping to use B2B Add-on. It was not a really pretty operation in the beginning and it did strike as a PoC. SMT was working and customers could try it. We have been able to convince some customers to use it have they have used it convert 300+ mappings using the tool. They have just started using the tool, so they have 1000 more planned.
You can see a video of the tool here to see what it can do.
What is new
Now it was time to a version 2.0. We had learned quite a lot about the tool worked and what customers problems were with it. We have made improvements to the following areas
Licensing. Before users needed to get us to sign licenses request before they could convert the tool. It was not a really easy process that caused a lot of manual wor on our and the customer’s side. So now we just give users a license they can use when they start the application. Then it will count each license. Customers can then see the licenses they have used in a document
Test driven approach: The original application was developed as a PoC that was then extended with bug fixes. It meant that we did not have a good way of testing how a change would impact, so it was a lot of manual testing to try to figure out how it can be improved. We had taken some examples that we got bug reports from and created test cases based on it. After it, we could rewrite our code to be simpler and every time validate that we did not cause more problems. So we could rewrite the code so it was easier to add rules and functions.
VDA: 28 days ago one of our customers was trying to convert a VDA mapping. It failed because our algorithms did not know how to convert the mappings. It is now possible to convert VDA. We have also got a request for Tradacom, and it will not take that long to implement, with the current architecture
UI: We had just created a simple application that could help convert mappings. It was not optimal and difficult to use. We now went for a UI5 approach just like with our Figaf IRT tool. It is not possible to search for mappings and schemas, so the conversion process should be a lot faster.
You can see how the UI has changed to be a lot easier to use.
Old UINew UI using OpenUI5
I want to try
If you have Seeburger Mappings and want to convert them fast then try the Seebuger Migration tool. The first 10 conversion is on us.
Yesterday I had a demostration with a client of the Seeburger Migration tool, that was doing a migration of their EDIFACT/X12 from Message mappings from Seeburger to B2B Add-on on the format. I wanted to show how it was possible to make it possible to test that the mappings were correctly migrated and converted.
I do think that this also could be useful for other SAP PI/PO customers, that are either considering a migration project or just want better control of what is happening to their EDI messages.
It is crucial to test all your EDI documents because of the volume of the business going that way. Some of the customers I have worked the EDI part was 20-50% of their turnover, so it is the part that is too big to fail. It is pretty difficult to test it normally because you need to have a good understanding of what can change in your mappings. Both when it comes to upgrades and also when it comes to changes done by developers.
As you can see of the video it is pretty simple to setup a test case based on data from your productive system. Because it is where you have the most reliable amount of data and variance. It is just to complex to test everything based manual test case creation, that is why we believe it should be automated.
We will set up both EDI document in both directions so you can see validation of EDI document and also that it works with the EDISeperator. We only show EDIFACT but X12 and EANCOM works the same way.
We do not currently have an integration with dual stack systems. We did implement it in the old release of IRT, so it will be possible to update it to the current version. We currently do no have access to a dual stack system, so if this is something you want. We hope you will help working with us to make it possible.
How about change management
So Figaf IRT is a lot more than just a testing application. We started doing testing of SAP PI/PO but have since expanded the service to handle the full change management. Just link the CTS transport with the Business request and you are able to do document all changes. And also test the changes that you make. It reuses all your EDI test cases for the process.
Try IRT
You can try out Figaf IRT tool. It just takes 15 minutes to set up on your laptop to see how easy it is and what it can do for your SAP PI/PO and CPI development. The solution can scale to run for your full enterprise.
https://figaf.com/wp-content/uploads/2019/07/Test-EDIFACT-with-SAP-PI.png6281200dgraversenhttp://figaf.com/wp-content/uploads/2016/05/160510_FigafLogo_final_35cm_KW.pngdgraversen2019-07-03 15:06:502019-07-03 15:06:51Test EDIFACT/X12 on SAP PI/PO
There many companies working on migration or planning a migration of their SAP XI/PI to SAP PI/PO 7.5 systems. Over the years I have created a number of resources that make a lot of sense if you are in the process of considering a migration. Here is one place that you can find all my best resources on the topic.
Timeline
One of the drivers for migration is that the support of everything but 7.5 will end in December 2020. That is currently in 20 months time. Not a long time if you need to plan a project, get funding and running the upgrade. I would assume that the minimum time for a migration is 6 months once you got people working on the project. If you need to get the funding you know your companies budget process, so you better get started.
As I read the note 1648480 extended support will not be possible for the Java stack.
Options for upgrading
There are a number of options that you can use when upgrading your landscape. Product manager of PI/PO Alexander Bundschuh has written a list of the different options (13) that you have depending on where you are at the moment. What options for Upgrading SAP PI/PO
My recommendation is to go for a single stack system because the dual stack is not developed anymore. It will also improve your next upgrade because of a simpler architecture. You will have to covert your ABAP Mappings.
Your different options
There is also the option to migrate to SAP CPI, which is the cloud-based tool for Process Integration. It has some areas where it can replace a PI and BPM solution, but there are patterns that are not fully optimal yet. It will no doubt be the place where SAP is focusing their development, so you will see a number of improvements there.
If you are not planning to use PO functions like B2B Add-on, BPM/BRM then it is probably best to keep at current license but move to an AEX, Java only version of your system. The only reason they would be to run CPI content on your PO system. If you have a few ccBPM probably consider moving them to CPI or Cloud Workflow.
If you are using B2B Add-on or want to run CPI content locally the PO is the way to go.
There is the concept Stack split that I have heard some customers use. The idea is to upgrade your 7.31 dual stack system to 7.5 with dual stack. In 7.5 they cannot share a system ID so one of the systems will get a new System ID. You will then be able to delete the ABAP system. So you only have a single stack system. It does require that you are using ICO’s for all your integration. I’m not sure if this is a supported process and how it works. Maybe your consultants know how it works.
Outlook
SAP PI/PO 7.5 will be in maintenance until 2024. SAP has announced there will be a new version of SAP PI/PO in 2022. The goal of this version is to support a newer Java version and latest Databases. The release will depend on when drivers for databases and Java is availabe from vendors.
There is a roadmap for the SAP PI/PO you need to search for Process Orchestration and then login to see the roadmap.
From what I can see on the roadmap it does not look like BPM and BRM function will be improved. You probably need to find another solution for BPM process. It could be the SAP Cloud Platform Workflow or CPI that will allow you to run it. The place where you will see most development is on running CPI content on SAP PO.
Process
The process for migration is pretty simple. It is just something about planning what to do. It does make a lot of sense to get an understanding of how you want to migrate so you can get started and know how it will work. I think it will give you some information to start the migration from. It can be improved and need to be adapted to your model. There are two areas that you need to focus on.
Planning: In this, you try to understand what you should be doing with regards to migration. This is where you need to figure out how to upgrade certain elements. This should be considered before you scale up the team. In this phase, you will also be able to see how you automate the solution.
Execution: In this part is about making the migration as fast as possible and keep the risk low. Here is where you make a migration of a single interface, test it and then move it to production.
You can read the full post and see all slides and the replay at the link below.
We have been making a lot of tools for the SAP Platform and they do make a lot of sense to apply in any migration project. The more you can automate the easier the process will be. Here are some of the things you can consider for your project.
Understanding your current integration
To understand what part of your current integration and message mappings, we have created a free tool that allows you to see what is going on. It can give you information about which message mappings you have used and how many times they have been executed in the last month. It can also give you information about which modules you have and how they are used. It is a free part of the Figaf IRT application so it is just to try it out, so you can plan your migration.
If you have Seeburger and are considering what options you have for migration then we have a path for it. We have created an automated tool that can take your Seeburger Message mapping and convert it to a B2B Add-on mapping with a few click. You can then save many hours in the migration process. You just select which mapping you want to convert and which B2B structure you want to use. Then the application will take care of the rest. It will cost you a fixed fee per mapping.
If you are doing any upgrade or change of your landscape it is really useful to perform test to validate that it works correctly. I have in some cases seen that after an upgrade something on the mappings had changed behavior. It is, therefore, a good idea to be able to test that nothing is affected.
You have the following options to Test SAP PI.
Manual testing requires a lot of resources
SAP PIT a free tool from SAP to test from 7.5 sp14.
Figaf IRT a tool build to make it a lot easier to test SAP PI/PO. Is our tool designed to make upgrade testing faster
INT4 Iftt a ABAP tool made for testing interfaces. It is good for testing result in the ABAP tables
Comparison of the two testing tools, I would recommend the Figaf tool because it makes the testing a lot faster to create and allow you to test your first upgrade. It also contains more patterns for testing and is able to test modules which is important with B2B Add-on.
Automation of the migration process
SAP have a tool that allows you to migrate channels and ICOs. It is a part of the PI system and you just link the two systems together and can then migrate scenarios or channels.
Figaf is currently working on a tool to automate the full migration process. The goal is to make the process a lot easier and enable users to see if they have tested and performed configuration in the full landscape.
