If you are a SAP Process Integration (PI) user every time you use a feature supported by the ABAP stack you a digging a bigger and bigger migration technical debt. The reason of this is that the successor to SAP PI called SAP Process Orchestration (PO) only uses the Java stack. This architectural change has lots of benefits, some of which are highlighted in this blog, after reading this you may decide to migration SAP PO, but even if you don't you can stop creating technical debt now - please read on.
Note : PI 7.4 is the last dual stack PI version - support ends on 31/12/2020, in 7.5 you have to split the stacks onto there own SIDs, I also think 7.5 might be the last version to support the now double stack - support currently ends on 31/12/2022
The good news is that in many many integration scenarios you can STOP USING ABAP now in the dual stack version of PI. This means that most new integrations can be done using only Java components modelled using iFlows / Integrated Configuration Objects (ICO) which will automatically migrate to SAP PO when you are ready to make the move.
Owen recommends : Stop Using ABAP in SAP PI systems for new integrations – note your existing partner may not support this as it means they will have to invest in new skills – make sure you push back on this.
You could go one step further and start to look at your existing integrations to see which of these could be converted to iFlows / ICO so you can reduce the work you need to do when you do migrate. Often when you re-look at the integrations that you have, you will find that there are better / more efficient ways to implement them – this can sometimes be down to poor / rushed implementations and sometimes down to features not being available in older releases. Once you come to migrate you can use the SAP PI to PO migration tools to help with the conversion process. You can read more about the tool here.
Owen recommends : Look at all your existing integrations and move any “problem/poor” ones to use iFlows / ICO in the Java stack only.
Owen recommends : Use the PI to PO migration tool to understand how much work you will have to do to move to PO
One area that you may not be able to move away from ABAP is any of your integrations which use the ccBPM components. This is a Business Process Execution Language (BPEL) engine that is used for orchestration logic. These will either have to be implemented using logic in the new Java adaptors (e.g large file splitting) or implemented into the SAP BPM component which is a Business Process Management Notation (BPMN) engine which only works in the Java only SAP PO system.
Owen recommends : Look at the integrations that use ccBPM to see if you can re-implement using adaptors. If not understand how they could be re-implemented using the SAP PO Enterprise Integration Patterns and make these the first integrations to be created in you new SAP PO system.
Another area to consider is how you currently do EDI/B2B communications using SAP PI. Many organisations either use a specialist EDI broker or have 3rd party EDI/B2B adaptors for PI. With SAP PO you can use the out of the box B2B add-in that provides EDI/B2B functionality. This will simplify your landscape and mean that you can save on 3rd party maintenance costs. You can read more about the features in this Blog by Agni.
Owen recommends : Investigate if the B2B Add-in can be used to replace 3rd party solutions - perhaps these savings can fund your move to SAP PO
Finally you can have a think about any business logic / rules that you have currently implemented in the sender / receiver systems. With SAP PO we have a much more powerful business logic engine available in the middleware with both Business Process Management (BPM) and the Business Rules Manager (BRM). These can be used to encapsulate business logic and simplify your end points. You can also use BPM to involve business users in business processes. For example this could mean starting data integrations (upload file with validation), approve items that fail rules (e.g discount levels), fixing errors (e.g failed mapping) – in fact you can automate pretty much any process you want.
Owen recommends : Investigate how BPM/BRM can be used to automate business processes in your organization.
The diagram below shows the possible options :-
As the diagram above shows, it is possible to do the migration in one step, but my experience is that many customers see this as high risk and prefer to do the migration over time. The problem with this approach is that it means that you need to run both a PI and PO system at the same time. This obviously costs more in terms of infrastructure but also has the disadvantage of having to license both the PI and PO systems for productive usage.
Owen Recommends : Check with SAP about how long they might let you parallel run PI and PO without additional license costs and what the licence costs for SAP PO would be.
Owen Recommends : If you have a limited window to do the conversion, convert as much as you can up front so the migration window is as small as possible.
- SAP Managed Tags:
1 Comment
