Planning for a migration from your XI 3.0, PI 7.0, PI 7.1, PI 7.3 dual stack installations to SAP Process Orchestration? This blog will help you setup the base foundation for migration and provide insights into the approach for such an exercise.
I am assuming that the reader is aware about the Process Orchestration suite and the technological differences between SAP PO and its predecessors.
Also there are licence considerations one needs to keep in mind. Unlike earlier versions, SAP PO is a core based license and is not volume based license as it was in case of most of the dual stack PI versions. I mention this since license benefits can also be a core driver for the adoption or not of SAP PO.
If there has been a decision on the license models and it provides benefits in moving to a core based model, then read on.
Note: These recommendation have been formulated based on my experiences in engaging with requirements around migration across customers I have been working with. Will like to place a disclaimer as to validate this with your own landscapes and that these inputs below are not SAP official recommendations.
XI 3.0/PI 7.0 to SAP Process Orchestration
This would be the longest path and apparently the toughest to manage. At a high level, the below flow diagram will provide a summary;
The key considerations here will be number of;
2. ABAP mappings
3. Java mappings and UDFs
If the above components are significant in numbers, it will be ideal to migrate from the 3.0/7.0 version to the PI 7.3 dual stack. All the ccBPM components can be easily migrated to PI 7.3 without any changes. So would the ABAP mappings.
What needs to be considered are the java mappings/UDFs and the modules. From 7.1, SAP released a new api for the mapping and modules. You will need to consider that as you move the code to 7.3. In my personal experience, this is going to be more of an adjustment to the existing code rather than a complete rewrite. There are major enhancements also in the graphical mappings that could be considered to be implemented as part of the migration.
Do go thru this blog to understand how you can adjust your UDFs when moving from 3.0 or 7.0. Another aspect you will also need to keep in mind is the changes to the ABAP proxy implementation. The execute_asynchronous method is deprecated and hence this needs to be also considered as part of the migration that will invoke changes in the SAP backend.
Most of the ESR content could be ported directly with the adjustments. In case of ID, it would be ideal to utilize the Java IDoc and HTTP adapters replacing the traditional ABAP counterparts. So do account for the work that will go into the ID aspects of the migration.
Once the migration to 7.3 dual stack is completed, then a passive migration can be planned which will mean the redesign of ccBPM scenarios to BPMN based standards and also the ABAP mappings. This is the most significant activity which is going to be time and money consuming. Remember that all ongoing developments on the dual stack should be aimed at utilizing the AEX to its fullest extend so as to radically reduce efforts of migrating those interfaces to SAP PO.
PI 7.1 to SAP Process Orchestration
This wouldn’t be that radically different to the above that we discussed. Things will be less complicated since the adjustments to UDFs, Java mappings and Modules would already be in place. Most of the enhancements to mappings like the graphical lookups would have been utilized along with features like parametrized mappings which would be compatible with both 7.3 and SAP PO.
The decision making will ideally follow the below flow;
PI 7.3 to SAP Process Orchestration
This will be the one with the minor headache of all. If in your 7.3 implementation, you had been smart enough to base most of the developments on the AEX, 80% of your work is done. It will only then depend upon the number of ABAP mappings and ccBPM scenarios that need to be remodelled.
In this case also, a passive migration is recommended with the assumptions that the ccBPM and ABAP mapping scenarios are quite significant in the landscape. Hence, it will be ideal to have both PI 7.3 and SAP PO run in parallel until the migration is completed so as to provide a less riskier and disruption free migration.
Hope this quick overview helps all of you who are looking to get engaged in migration projects in the near future.
Additionally, I will also like to point out an excellent tool (thanks to SAP) which shall try and radically reduce a lot of effort that one might have to put in for the creation or modification of ID object. Ref: Directory Content Migration Tool
Do feel free to provide your thoughts and ideas that can better help the community when it comes to migration requirements. I will be more than happy to accommodate your inputs into the blog. Please do leave a comment. Thanks!