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....
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.
For the application integration and orchestration use case, the following installation options are supported:
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.
SAP Process Orchestration (PO) is a solution bundle running purely on a Java application server which consist of the following products:
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.
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.
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.
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.
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.
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.
The SAP Process Orchestration (PO) license includes the usage of the following components:
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.
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.
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.
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.
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.
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.
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.
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.
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 you hold any of the PI licenses on the legacy price list, you are entitled to run any of the following installation options:
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.
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.
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.
In the following, I assume that you run AEX holding a legacy license.
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.
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....
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
So, it turned out that I end up at 13 options. I hope you do not believe in superstition, and hopefully this blog helps you in making your decision when planning your upgrade / migration to 7.5.
- SAP Managed Tags:
26 Comments
| User | Count |
|---|---|
| 19 | |
| 14 | |
| 11 | |
| 10 | |
| 9 | |
| 8 | |
| 7 | |
| 7 | |
| 7 | |
| 5 |
