Where Does My Hybrid Integration Development & Deployment Fit In – PI | PO | CPIs
Classical integrations were mostly focused on connecting different systems running in legacy data center (ex: A2A) or otherwise it would be about connecting with its partners’ systems in a different network. (B2B). There were different use cases like process integration, data replication, etc. With the emergence of cloud, businesses started moving towards cloud, looking at different benefits whereas certain systems, applications, and mission critical business processes, could not leave the building. Moreover, cloud computing models SaaS, PaaS, and cloud deployments (hosting) became, popular. As a result, today’s enterprise landscape comprises of such a blend of on-premises systems and systems on different clouds. That has been the reason for business to re-imagine integration context and integration has become more important driver which will help business to transform to a digital entity and to become intelligent enterprise.
SAP PO is an integration platform which relay on centralized ESB and not something designed for native cloud integrations. Integration suite is the strategic hybrid EiPaaS from SAP to leverage for native cloud integrations and to connect systems across cloud and on-premises networks and systems on multi clouds.
in this blogpost I will try to speak on bit of background from cloud story, how we could better leverage CPI (cloud platform integration)and PI/PO for developments and deployments and smoothly planning for the transition.
Today’s Integrations :
Irrespective of cloud or not, physical limitations are an influential factor from the perspective of performance. Of course, we see cloud is better in terms of scalability, agility and so on, But the network distance between elements in the cloud is something no one could control. Bandwidth is not the limiting factor in majority of the cases, but the round-trip latency is.
This is the reason SAP PO being the best fit for on premise to on premise integrations. The reason for cloud providers to come up with an integration add-on or integration services, for EiPaaS vendors to leverage the idea of container technology and come up with Co-located runtimes which helps integration artifacts to be deployed closer to its dependent cloud assets, for EiPaaS solutions to become a multi-cloud offering.
Since modern integrations are decentralized it is always a concern where should integration artifacts live. Whether in cloud or on premise. if in cloud in which cloud.
SAP integration suite and SAP PO :
Indeed, strategic integration platform from SAP for businesses to plan their digital journey is integration suite. But in terms of serving on certain topics, (Ex: B2B trading partner management, connecting on premise systems, etc), still you will find PO would be the best fit. Again, from the perspective of maturity of the product and experienced consultants SAP PO might still ahead. Nevertheless, ultimate goal needs to be moving all integrations to CPI at a certain point.
As of the official announcement from SAP, extended maintenance of PI/PO until 2030 and customers those who already invested on PO is secured for the next decade. But it is the timeline set from SAP for larger companies to make the transition smooth and gradual. In reality we see companies those who are running SAP PO are already leveraging CPI. (utilizing it consumption based rather than align with full subscriptions.)
Bottom line would be at this point, SAP PO and CPI to be considered as complementary offerings which could be used to develop and deploy integrations in such a way.
Cloud to Cloud integrations :
Let’s say we have a scenario where we need to do an A2A integration and applications hosted on two different clouds and what if integration suite is running on another cloud. No one will complain on the time spent as long as it is some sort of a backend process (Ex: data replication). But when it comes to a scenario where it is a synchronous and touches a UI, time elapsed for the round trip going to be apparent and will be a bad experience for the user. Let’s try to understand how this impact could be mitigated.
Integration suite : why a Multi cloud offering:
As shown in the diagram, different cloud providers might offer the best match with different parts of the business. Moreover, multi-could strategy will help business to avoid vendor lock-in, to find the best price, to find the best-in-class SLA and so on. These are some of perceived benefits for organizations to follow a multi-cloud strategy. As already mentioned, it is important for integration platform sitting next its dependents. As a result, SAP cloud platform has become a multi cloud offering as of today and CPI is available on google cloud, AWS, Azure, etc which benefit from the reduced network latency and better integration possibilities.
Concluding cloud to cloud integrations, recommended approach for the development would be align with CPI and IFlows should be deployed in cloud as well.
Having all these facts in mind, does it make sense for you the below innovation on CPI roadmap which is to come sooner.
Note: But in reality, in cloud-to-cloud cases, as long as network elements are not located across the globe you might not see significant differences in performance with co located runtimes. you may realize it doing the same cloud to cloud scenario with using two trial accounts attached to two different data centers.
Hence the extra effort which needs to be put on maintaining that additional cell may not add a value. Then this decision needs to be made with those facts.
connecting on-premise systems :
With the conversation built up so far, it is obvious PI/PO is the best fit for connecting systems hosted in legacy data center behind the firewall. But let’s try to see where it is beneficial to leverage CPI design time and deployed in local CPI runtime on PI/PO.
why : “Local CPI runtime”
You may come across such instances where PI/PO design time couldn’t serve better than nice set of integration patterns available in cloud integration, like Loop another process, aggregator, Gather XML, Request-Reply and so on. Then it does make sense to design it on cloud and deploy it on CPI local runtime which runs on PI/PO. Some of those controls are not native on SAP PO but all works well on PO and no adaptations required.
Note: For this either classical on premises connectivity with ICO configured in PI/PO could be leveraged with no adaptations in S4 side or endpoint deployed in in PI/PO could be called with ABAP WS-runtime/local integration engine with no ESR/ID artifacts. What this does mean is you may use ABAP proxies with XI or SOAP adapter to connect S4 and PI/PO. Another benefit of this approach would be you will have a good time when migrates to CPI.
Please check this nice write up to find out how to configure endpoint, once IFlow is deployed in PI/PO.
What “Integration Cell” : Hybrid deployments
This is one of the most important features in CPI roadmap. Because it would stop joint usage of CPI and PI/PO in complementary way. Integration cell will enable, doing developments, configuration, and monitoring in the cloud where integration artifacts to be deployed on a runtime available on premise. As a result, CPI will become a complete platform.
Cloud to On premise (or vice versa) : Hybrid integrations
From SAP we have the direction to leverage CPI for hybrid scenarios. But, in life you may find some different expectations from organizations . It may be on security and architecture perspective (Ex: if cloud connector is not enough), it may be a data concern , it may be because business has already invested in PI/PO and business may not need to pay for CPI traffic, or it may be something different as well.
Having said that, let’s try to understand why it is important to create net new hybrid integrations on CPI. The percentage of the cloud assets of a company is being growing over last few years significantly and we may not that far from the day’s companies having majority of its business runs on cloud or cloud only. Yet larger global organizations may have lot of mission critical business processes not specifically designed align with cloud architecture. So, they need to put a big effort on redesigning and adapting them to the cloud. That is the reason we need a cloud-based platform which could support hybrid integrations to make the transition smooth and gradual in a day when applications running other end moving to cloud too. At this point re-factoring the developments would not be required but only the connectivity does.
Why : “Cloud Connector”
Hybrid integrations will cross firewall somewhere. Cloud connector is an agent which runs on an on premise server which will enable internet to send a traffic to on premise without compromising the firewall.
Cloud connector or CPI local runtime ?
But what if from architecture perspective, cloud connector is not what business needs and connectivity have to be managed in classical way with PI/PO, then below approach could be adopted.
Note : Instead of cloud connector, SAP PI/PO along with web dispatcher could be used to connect with on premise backend system or to securely open the network to an external on premise system/user.
What if business has already invested on PI/PO, the message size is going to be larger and not need to pay for CPI traffic, but you will find it easier to develop message flow with new CPI integration patterns, then below is something could be used.
in immediate above two use cases ICO could be used for classical connectivity (any other feature of PI/PO if needed), and it is better to use features of CPI as much as for the rest. The endpoint of IFlow should be called from ICO and as the sender adapter of IFlow either XI or SOAP could be used.
Also, this nice blend could be leveraged in many other ways as well depending on the business limitations and integration requirements.
Mapping perspective :
In integration suite too support graphical mapping which is in the similar way as SAP PO. But it is not that good when it comes to a complicated mapping, since when someone needs to change it later point, there is a higher risk of get failed the test cases which worked well before the change was introduced. So, manage such situations better, either XSLT or Groovy script may be better. But there is a steepest learning curve for XSLT and XSLT debugger tools like Oxygen comes with a cost. But when it comes to Groovy, learning curve perspective it is better than XSLT. Debugger tool, IntelliJ IDEA supports for Groovy and there is a community edition of that as well. So, Groovy has a good potential and leverage developments on cloud. Yes, this is always a subjective decision.
Transition is something should not happen overnight. if integration developments could be done on CPI and deployed as relevant it would be the ideal way for organizations to moving ahead and seamless transition. That make sense since upon the availability of Integration cell, all the IFlows could be migrated to cell and only the connectivity may need to be tested.
Note: SAP PO can also run in the Cloud (Microsoft Azure, AWS, SAP HEC),But as this not a SaaS/IPaaS approach, but rather a hosted scenario (infrastructure-as-a-service). So, it is not correct to argue to follow a strategy as, same level of performance could be achieved or in terms of anything. Because it doesn’t have any perceived benefits as CPI in terms of cost, innovation, agility, or anything. Most importantly, SAP integration suite is the strategic integration platform moving forward and every organization should move their integration in to CPI in coming days. Nevertheless, for the companies still runs on majority of their business with on-premise systems and not having a cloud focus make sense to leverage SAP PO further..