Product Information
SAP Process Orchestration – What options do I have when upgrading or migrating to release 7.5?
End of mainstream maintenance for SAP NetWeaver releases 7.1x, 7.3x, and 7.4 is coming closer. It’s actually end of 2020 (check out SAP note 1648480). I hope if you read this it doesn’t come to you as a surprise. If you haven’t started already at least planning for an upgrade/migration project to move to release 7.5, it’s time to do so now.
By the way, mainstream maintenance of SAP NetWeaver release 7.5 has been recently prolonged to 2027 with an option for extended maintenance until 2030. This also applies to release 7.5 of SAP Process Integration and SAP Process Orchestration. See Maintenance strategy for SAP NetWeaver 7.5 fully aligned with SAP Business Suite 7. Product strategy of SAP BW/4HANA fully in line with SAP S/4HANA.
Note: There is no dedicated end of support schedule for a specific installation type such as SAP Process Integration dual usage type or SAP Process Orchestration. The maintenance support for any of the installation types described below depends on the maintenance support of the respective SAP NetWeaver release.
The question is, what options do you have? In fact, there are a couple of options which I would like to address here. In this blog, I won’t talk about how to technically run an upgrade or migration, the intention is rather to explain you the different installation options that are supported in 7.5, which upgrade paths exist, and what the implication would be in terms of feature coverage and licensing.
Installation options
Which installation options are supported in 7.5?
For the application integration and orchestration use case, the following installation options are supported:
- SAP Process Orchestration (PO)
- Advanced Adapter Engine Extended (AEX)
- Advanced Adapter Engine (AAE)
- SAP Process Integration (PI) dual usage type
- SAP Business Process Management (BPM) / SAP Business Rules Management (BRM)
What is the Advanced Adapter Engine Extended?
The Advanced Adapter Engine Extended (AEX) provides Process Integration capabilities on a Java application server. It has been evolved from the Advanced Adapter Engine (AAE) and hence supports the very same PI runtime and connectivity capabilities as the AAE. However, unlike the AAE (see below) it can run as standalone engine, i.e., in addition to the AAE it also comes with an Enterprise Services Repository (ESR), Directory, System Landscape Directory (SLD), etc.
What is SAP Process Orchestration?
SAP Process Orchestration (PO) is a solution bundle running purely on a Java application server which consist of the following products:
- SAP Process Integration (PI) on Java, so actually an AEX
- SAP Business Process Management (BPM)
- SAP Business Rules Management (BRM)
PO is actually our strategic integration offering for an on-premise deployment which covers the full functional range of an integration platform including message processing, connectivity, and business process and rules management. TCO in terms of hardware costs as well as operation and monitoring costs is lower compared to a dual stack / dual usage type architecture, see below.
What is the Advanced Adapter Engine?
The Advanced Adapter Engine (AAE) has been evolved from the Adapter Engine supported in past releases so that you can run now integration scenarios within the Java stack only, i.e., when connecting to a PI dual-stack bypassing the ABAP stack. The AAE consists of the adapter framework, the mapping engine, and the message server, all running on a Java application server. Other than the other options mentioned above, the AAE can not run on its own, it always needs to be connected to any of the standalone options.
An AAE can be added to your integration landscape for many reasons: scalability, separation, security, localization, etc. You may check out the following video.
Why is PI dual-stack now called PI dual usage type?
The PI dual-stack is based on both an application server ABAP and an application server Java. The core of a middleware, the messaging system, resides on the ABAP stack. Same with the Business Process Engine for running integration-centric processes (ccBPM), and the user management. The adapter engine holding most of the connectors as well as the mapping engine runs on the Java stack.
As of release 7.5, we do not support the dual-stack architecture anymore. So, when upgrading your PI dual-stack system to 7.5, you need to split the stacks afterwards. Hence, this is called PI dual usage type. See also SAP note 2190371.
What use cases can I run on SAP Business Process Management?
SAP Business Process Management (BPM) / SAP Business Rules Management (BRM) can be installed as standalone if no or limited integration capabilities are needed. Main usage scenarios would be business process composition, business process extensions, UI and service composition. The type of business processes would be rather human-centric, i.e., workflows that run across applications. In case of integration-centric processes, i.e., when running Enterprise Integration Patterns such as aggregator, composed message processing, scatter-gather, etc., you would rather go for an SAP Process Orchestration installation.
Where can I find the Product Availability Matrix for any of the above mentioned installation options?
There is no dedicated Product Availability Matrix (PAM) for SAP Process Integration nor for SAP Process Orchestration. Since both are part of SAP NetWeaver, the SAP NetWeaver PAM applies, see direct link to the SAP NetWeaver 7.5 PAM here.
Licensing
How is SAP Process Orchestration priced?
As of April 2013, the price metric for PI, BPM, BRM, and PO has been changed to a linear core-based pricing model. The new price list item for PO with material number 7015920 has replaced all PI, BPM, and BRM price list entries. All previously sold licenses for PI (either volume-based or CPU-based), and BPM/BRM (CPU-based) have been moved to the so called legacy price list. Regarding licenses for B2B add-on, see below.
Note, that for indirect sales, there are two so called edge edition price list items. In the following, especially when talking about feature scope, I will only refer to material number above for direct sales.
What is included in the SAP Process Orchestration license?
The SAP Process Orchestration (PO) license includes the usage of the following components:
- SAP Process Integration (PI)
- SAP Business Process Management (BPM)
- SAP Business Rules Management (BRM)
- SAP Process Integration, Business-to-Business Add-on (B2B Add-on)
- SAP Process Integration, Secure Connectivity Add-on
- SAP Process Integration, Connectivity Add-on
- Cloud integration runtime (SAP Cloud Platform Integration runtime co-deployed)
- Process Integration test tool (PIT)
How many cores do I need to purchase for SAP Process Orchestration?
The number of cores required is based on the sizing of PO whereas the minimal number of CPU cores a customer has to purchase is 2. The sizing is determined by properly sizing the usage of the different components, especially BPM and PI components, and adding the same. See sizing guide.
In a license audit, how can I count the number of cores relevant for licensing?
When counting physical cores, each core of a physical CPU that runs at least parts of the licensed software, including those that are temporarily assigned or scheduled to cover peak processing, is considered and counted.
In a virtualized environment, each virtual core that runs at least parts of the licensed software, including those that are temporarily assigned or scheduled to cover peak processing, is counted.
The product measurement document explains how to count cores in either physical or virtual systems and how to determine the components which are relevant for the licensing.
What license is required for the B2B Add-on?
As of April 2014, the B2B Add-on is part of the PO license material number and is not available separately on the price list. New customers who will buy PO will automatically get usage rights for the B2B Add-On (limited to the hardware limitations and thus the core usage of PO).
The previously sold license for the b2b add-on which was based on EDI relations has been moved to the legacy price list.
See also SAP note 1690557.
Can I only run the B2B Add-on on an SAP Process Orchestration system?
As mentioned above, the B2B Add-on is not available separately. It’s now included in the PO license. This doesn’t necessarily mean that you need to run the B2B Add-on a PO system. When you hold a PO license, you are entitled to run either PI, AEX or PO, and you can run the B2B Add-on in any of those installations options.
What license is required for the Secure Connectivity Add-on?
The Secure Connectivity Add-on provides SFTP adapter and PGP (Pretty Good Privacy encryption, signing and compression) capabilities. The usage of the Secure Connectivity Add-On is included in any PI or PO license.
What license is required for the Connectivity Add-on?
The Connectivity Add-on provides SAP SuccessFactors adapter and OData adapter capabilities. The usage of the Connectivity Add-On is included in any PI or PO license.
What if I already hold a license which is on the legacy price list?
If you are a net new customer, as mentioned above, the core-based PO license is the only license that you can purchase. If you however have already bought any of the legacy price list items before and intend to buy more, you are actually entitled to buy more from what you have previously bought.
Optionally, you can transition your legacy license to the PO license. Especially, if you hold individual licenses for the different components, consolidating your licenses into one PO license may be the better option. With the PO license you only pay once and you are flexible in deploying any combination of the components across the licensed cores. Furthermore, with the PO license you can benefit from a comprehensive solution bundle covering the full functional range of an integration platform in one solution including message processing, connectivity, business processes and rules. SAP’s license conversion policy is a flexible way to receive credit for your existing license investment toward your move to PO.
What license is required for the cloud integration runtime component?
As of SAP NetWeaver release 7.5, the Apache Camel based SAP Cloud Platform Integration runtime has been co-deployed on the adapter engine of PI/PO. The intention is to provide a hybrid integration platform approach that allows customers to flexibly deploy their integration scenarios either on-prem or in the cloud. Customer who are on release 7.5, can use the cloud integration content component with any PI or PO license. However, in order to model and configure the scenarios, i.e., the integration flows, customers require a SAP Cloud Platform Integration (CPI) tenant, and hence have to hold any CPI license for productive usage of CPI. See also FAQ note 2428801 and best practices blog series.
Which installation options can I run with the SAP Process Orchestration license?
The allocation of SAP Process Orchestration components PI, BPM/BRM, and B2B add-on on the licensed cores is very flexible. Customers may deploy the required components they need dependent on their use case. This means, if you hold a PO license you are actually entitled to run any installation option as mentioned above.
Note, we distinguish between a PO license and a PO installation option. If you hold a PO license, this doesn’t mean that you can only run a PO system, you actually have the full flexibility in running any of the above mentioned installation options.
If I have SAP Process Integration licensed on either a volume-based or CPU-based contract, which installation options can I run?
If you hold any of the PI licenses on the legacy price list, you are entitled to run any of the following installation options:
- Advanced Adapter Engine Extended (AEX)
- Advanced Adapter Engine (AAE)
- SAP Process Integration (PI) dual usage type
This means, you are not entitled to run PO nor the B2B add-on. For a PO installation option as well as the B2B add-on you need to hold a PO license. Differently phrased, if you do not need BPM/BRM nor B2B, you can stick to your legacy license.
What if I only want PI or BPM?
If you have use cases that only require BPM or PI, you still need to purchase PO licenses. PI and BPM do not exist as individual material numbers any more. You can then select which components to allocate the license to. The advantage is that you have additional flexibility for future consideration.
Upgrade/Migration options
In the following, I assume that you run any of the installation options mentioned above on a release lower than 7.5, and you would like to move to release 7.5.
For the B2B use cases, I assume that you run PI and either you don’t have B2B licensed so far or you have licensed B2B on an EDI relation-based contract which is not on the price list anymore.
In the scenarios discussed below, whenever a license transition from your legacy license to the core-based PO license is required, usually you can get credit on your existing license. In this case, please reach out to your account representative.
If I run PO on a lower release, what are my options?
Option 1: Either upgrade or migrate to PO 7.5
- Whether you go for an upgrade or a migration depends on different criteria: risk reduction, downtime, project timelines, etc. An in-place upgrade can be usually run much faster compared to a migration. By running the migration step-by-step, you have a better control of the scenarios that you plan to set live, and always the possibility to rollback once you face major issues on the new environment. This way, you run a lower risk compared to the big-bang approach with an upgrade.
- Since you already run PO, you already hold a PO license. Licenses are not bound to any release assuming that the release is still in maintenance. So, you can move to 7.5 without any license transition.
If I run AEX on a lower release, what are my options?
In the following, I assume that you run AEX holding a legacy license.
Option 2: Either upgrade or migrate to AEX 7.5
- You go for this option if you do not need BPM/BRM nor B2B
- Regarding upgrade vs migration, see above
- No license transition is required
Option 3: Migrate AEX to PO 7.5
- Technically, you can either use the Software Update Manager (SUM) to add the missing usage type BPM to AEX (see SAP note 1793486) or you migrate AEX to PO, either way the target system becomes a PO system
- A license transition to core-based PO license is required
- With the core-based PO license, you are entitled to use the B2B add-on
- With the core-based PO license, you are entitled to use BPM/BRM
If I have PI licensed on a volume-based or CPU-based contract, what are my options?
Option 4: Either upgrade or migrate to PI dual usage type 7.5
- Regarding upgrade vs migration, see above
- In case of upgrade, run the in-place upgrade, and then split the stacks
- In case of migration, new system needs to be installed as split stacks
- Go for this option if you have a large footprint in ABAP, i.e., many ccBPM processes, ABAP mappings, eventually custom ABAP tables or programs on an additional client
- No license transition is required
- Note: because the stacks need to be split, TCO is higher compared to a dual-stack system or a Java only system
Option 5: Migrate PI to AEX 7.5
- You can leverage the lower TCO of the Java only server with no need to transition your license
- Go for this option if needing only the messaging capabilities of AEX, i.e., in case that BPM/BRM is not required
- However, B2B is not included either
- Note: ABAP artifacts like ccBPM and ABAP mappings are not supported on an AEX
Option 6: Migrate PI to PO 7.5
- Note, that PO is SAP’s strategic integration platform on-premise
- With this option, you can address a larger set of use cases: process integration both A2A and B2B, business processes both human- and integration-centric
- Furthermore, you can leverage the lower TCO of the Java only server
- A license transition to core based PO license is required
If I haven’t licensed B2B add-on so far, and I need B2B/EDI capabilities, what are my options?
If you hold any PI license and haven’t bought the b2b add-on at the time when it was provided separately, and you need b2b functionality now, you need to transition your legacy license to the core-based PO license. Usually, you can get credit on your existing license. In this case, please reach out to your account representative.
Option 7: Run B2B Add-on on PI dual usage type
- A license transition to core-based PO license is required
- You can continue to use your existing PI footprint, e.g., ccBPM which runs on ABAP, ABAP mappings, etc.
- You are entitled to run BPM, however since we do not support BPM running on a PI dual usage type, you need to run BPM on a separate server. Note, in this case the cores of the BPM server need to be covered by the existing license. Furthermore, other than in a PO system PI and BPM are not tightly integrated
Option 8: Migrate PI to PO 7.5 and run B2B Add-on on PO
- Because a license transition to the core-based PO license is anyway required, you may migrate to PO and leverage from additional capabilities provided by PO and its lower TCO
- See also option 6
If I have B2B add-on on an EDI relations-based contract, what are my options?
Option 9: Stick to B2B on PI dual usage type
- No license transition is required
- If needed, you can just license more EDI relations as per existing contractual metric
Option 10: Stick to B2B on PI dual usage type with transition to a PO license
- License transition to core-based PO license required
- You can get credit on both legacy licenses, i.e., for PI and B2B. Moving to a PO license simplifies the licensing model. Depending on the number of EDI relations required, the PO license may cost less. Reach out to your account representative, and do the math
Option 11: Migrate to PO
- See also option 6.
If I have BPM licensed on a CPU-based contract, what are my options?
Option 12: Stick to BPM standalone
- Go for this option if no PI capabilities are needed
- No license transition is required
- If needed, just license more CPU using the existing contractual metric
Option 13: Migrate BPM to PO
- Either use SUM (see above) to add the missing usage type AEX to BPM or migrate from BPM to PO, either way the target system becomes a PO system
- In this scenario, you need to convert your CPU-based BPM license to the core-based PO license
- With this option, you can extend your BPM processes with PI capabilities for running integration-centric processes across applications and systems
- See also option 6
Great info Alex!
I believe in all upgrade/migrations blogs we can highlight two more things:
a) that as of SP 14 for PI 7.5 – PIT (a free SAP Test tool for PI upgrades) is available. Info on how to set it up:https://www.int4.com/sap-test-tool-pit-sap-po-7-5-sp14/
b) that PI has a long roadmap – which can be found – https://www.sap.com/products/roadmaps.html
so it’s good to think about the future of SAP PO too as it will be there with us for many more years to come,
Thank you for the blog, I’m sure it will clarify the paths for many customers,
Best Regards,
Michal Krawczyk
I was seeking this certain info for a long time. Thank you and good luck.
I find it very annoying that SAP does not give an official statement about the future of SAP PO. So far it is stated that there is support until 2024, but then everything is unlcear.
So I am not happy at all with the actual situation.
This is a really helpful blog, thanks for putting it together.
I understand that it's possbile to install only PI or BPM but they're both under a PO license. For a new installation of only PI (AEX) would there be any costs savings or the price is the same whatever you install only PI, only BPM or both?
Thanks in advance.
Hi Leal,
it depends whether you have purchased a volume based license for instance in the past or if you are a net new customer, net new customers can only purchase the core based PO license, the rest of the license material codes are not on the price list any more, for the PO license it doesn't matter what kind of deployment option you run, the price per core is the same
Alex
Hi Alex,
We have a potential client that is considering the migration from PI 7.4 dual stack to PI 7.5 dual usage, since they have a very complex landscape (dozens of ccBPMs, etc).
After the migration, they would like to re-implement the ccBPMs as BPMN in Netweaver little by little, so that a future migration to PO single stack would be easier.
Is this possible? I understand that SAP BPM is not included in the SAP PI 7.5 Dual Usage license, but can the component be installed separately and be compatible with PI 7.5?
Thanks and kind regards,
Judit
Hi Judit,
BPM is not supported on a PI dual usage type, you may install and run it on a separate server but I wouldn't recommend this, when running BPM as a solution bundle together with PI within PO we do support reliable messaging when exchanging messages between BPM and PI, this is not always guaranteed when PI and BPM run on different servers, also the tight monitoring integration won't work.
So, if you plan to migrate to PO anyway, I would wait with migrating the ccBPM until you have the PO system in place.
An alternative would be that you use the cloud integration runtime inside a 7.5 adapter engine, this is actually supported for both PI dual usage type and PO. In the cloud integration runtime you can deploy and run iflows which you have modeled on Cloud Platform Integration. Those iflows do support stateful message processing as well, so you may migrate your integration-centric ccBPM processes to CPI iflows. Prerequisite is that you have a Cloud Platform Integration tenant to be able to model the integration flows. This works with any CPI license.
See https://blogs.sap.com/2017/08/11/best-practices-cloud-integration-content-in-sap-process-orchestration-overview/
And here I have compared most commonly used patterns on PO vs CPI as best practice for migrating from PO to CPI iflows: https://blogs.sap.com/2020/01/31/enterprise-integration-patterns-at-sap-cloud-platform-integration-scatter-gather/
Regards
Alex
Hi Alex,
Thanks a lot for this blog.
In option 4 above, if we are in PI 7.31 dual-stack, do you mean that we can have 2 options to move to PI dual usage type 7.5, i.e. we can either upgrade the 7.31 in-place or migrate to a newly setup PI 7.5 dual usage type systems (ABAP and Java instances)?
Francis
Hi Francis,
yes, this is correct
Alex
Hi Alex,
this question here got me thinking:
Cheers
Jens
PS: Great blog for getting an overview btw.
Hi Jens,
I take it that my colleague Elke answered your question in the above mentioned thread already
Alex
Hi Alex,
We are on PI/XI 7.10 and need to upgrade/migrate to PO 7.5. We did a greenfield install of 7.5 and were exporting/importing our components etc. We found that ccBPM will not work on PO java stack. Do you know of a good method or some good documentation to help migrate from the dual 7.10 version to PO 7.5?
Great Blog; thanks,
Rick
Hi Rick,
check out this blog https://blogs.sap.com/2020/03/02/upgrade-migration-checklist-for-sap-pi-po/
For ccBPM, there is not migration tool available because BPEL differs too much from BPMN, instead we have published a blog series where we describe how to implement the enterprise integration patterns in BPMN, see https://blogs.sap.com/2012/09/15/sap-process-orchestration-integration-patterns/
Furthermore, our new test tools helps automating integration test during the migration, see https://blogs.sap.com/2019/03/08/process-integration-test-tool-shipped-with-sap-process-orchestration/
Alex
Hi Alex,
My integration team is telling me that it is possible to run ccBPM in an ABAP NW stack and then the other integrations in PO. Would that be recommended by SAP? Any performance issues or other considerations for that path?
Thanks much for your advice!
Best Regards,
Rick
Hi Rick,
this is not correct, SAP Process Orchestration runs on SAP NetWeaver Java, there is no ABAP stack, instead of ccBPM we do support BPM.
Maybe, your integration team refers to a PI dual usage type, here ccBPM is supported, and scenarios that do not need ccBPM may be configured as so called Integrated Configuration Objects and hence bypassing the ABAP stack during runtime
Alex
Hi Alex,
At Grundfos we are in a process of upgrading SAP PI from version 7.31 to version 7.5.
In our version 7.3 we already moved to advanced adapter engine using ICOs and closed down ccBPM processes. So we are not using ABAP Integration Engine anymore. I am still uncertain if we can do an upgrade (not migrate) from SAP PI version 7.31 to version 7.5 strict java, that is without dual usage type? Or must we when we do an upgrade from SAP PI version 7.31 do an upgrade to SAP PI dual usage type?
I am looking forward to read your advice. Thank you in advance.
Sincerely,
Brian Emmertsen
Hi Brian,
an in-place upgrade from PI dual stack / PI dual usage type to a Java only installation option such as AEX or SAP Process Orchestration is not supported.
If you upgrade to a PI dual usage type, you won't be able to remove the ABAP stack even if you don't use the Integration Engine any more, the reason is that the user management is within the ABAP stack and a switch to the Java UME is not supported.
Alex
Thank you so much for your reply. Now we can confidently move on preparing the correct upgrade.
Hello Mr. Bundschuh,
We are planning to upgrade our existing PI under Netweaver 7.0 dual stack to Netweaver 7.5. We only have PI license (volume based) and the company has no intention to buy license for PO. In this case, we can only install AEX, AAE, and PI dual usage type. If we install these and plan to reconfigure our existing interface scenarios from PI 7.0 to PI 7.5, how different of the user interface to reconfigure these objects under PI 7.5 than PI 7.0? Would you mind share some resources related this to us?
Thank you.
Brian Hui
Hi Brian,
in the PI dual usage type, integration flows are not supported, so you rather stick to the Java Webstart tools to configure your scenarios, you can stick to your "classical" configuration objects i.e. interface determination, receiver determination, agreements, or you can migrate your scenarios to Integrated Configuration Objects (ICO), when using latter you can bypass the ABAP stack during runtime hence leveraging the better performance of running through one stack only.
In an AEX system, you have both options ICOs using Java Webstart or integration flows using the Process Integration Designer perspective of the NetWeaver Developer Studio
Alex
Hi Alexander Bundschuh,
will there be an update on the options and recommendations which also considers the hybrid setup?
Regards
Holger
Hi Holger,
I won't update this blog, this blog was intended to provide guidance for upgrading/migrating to 7.5, for moving to Cloud Integration or the hybrid integration platform once we have shipped the on-prem runtime, check out the featured content section on our community at https://community.sap.com/topics/process-orchestration, hope this is the information you were looking for
Alex
Thank you Alex for the immediate reply. I will check out the link you provided.
Cheers,
Holger