What is the Difference Between SAP PI, PO, CPI and Integration Suite?

Do you feel like there is a complete overhaul of the SAP middleware every 3 days? Ever wondered what the differences are between XI, PI,PO, CPI and Integration Suite? Well, you are not alone! There have been major changes to SAP middleware XI/PI/PO in its lifetime. Since the first introduction of SAP XI in 2002, SAP has completely changed its architecture with its major version upgrades.

Over the years, SAP has continuously adapted its integration offerings to meet system integration needs, starting with on-premises solutions like SAP Process Integration (PI) and SAP Process Orchestration (PO). These middleware platforms were designed to connect SAP and non-SAP systems, enabling seamless business processes in traditional enterprise environments.

However, the rise of cloud computing, Software-as-a-Service (SaaS) applications, and the demand for agile, scalable, and real-time integrations brought about a significant paradigm shift. This led SAP to evolve its integration technology from the infrastructure-heavy on-premise PI/PO solutions to cloud-based Integration Platform-as-a-Service (iPaaS) models, starting with SAP HANA Cloud Integration (HCI) to SAP Cloud Platform Integration (CPI) and culminating in the SAP Integration Suite on BTP (Business Technology Platform)

This transition marks a fundamental shift in how businesses approach integration, emphasizing flexibility, scalability, and lower total cost of ownership (TCO), all while supporting hybrid and cloud-native architectures. This article explores the historical development of SAP’s middleware solutions, the key differences between on-premises PI/PO and modern cloud-based iPaaS tools, and the benefits of embracing this next generation of integration technologies.

Moreover, we will discuss the features of the SAP Integration Suite and SAP Cloud Platform Integration.

For us to understand the differences between XI, PI, PO, CPI and Integration Suite on BTP (Business Technology Platform) first, we need to look at the main functionaries of middleware and the difference between a traditional On-Premise Middleware and iPaaS Solution.

Key aspects of On-Premise Middleware (e.g., SAP PI/PO) versus iPaaS Solutions (e.g., SAP Integration Suite):

The evolution of integration technology within SAP has witnessed a significant shift over the last decade, as enterprises grapple with rapidly changing IT landscapes. Traditionally, SAP Process Integration (SAP PI) and SAP Process Orchestration (SAP PO) were the go-to middleware solutions for on-premises, application-to-application (A2A) and business-to-business (B2B) integration. These platforms, built on SAP’s NetWeaver architecture, served businesses well for years by enabling the seamless flow of data across SAP and non-SAP systems.

What is a Traditional Middleware:

A traditional middleware tries to cover system integration from requirements in the following key aspects,

  • Connectivity: Which protocol to use – SOAP, FTP?

  • Routing: Who are the receivers of the message – Multiple receivers? Condition-based routing?

  • Transformation: What kind of conversion or mapping is required? XML to text?

  • Runtime:  messages monitoring and security

  • Workflow (BPM): How to execute a series of steps? Integration scenario with a Purchase Order approval process?

SAP has been able to cover all these areas successfully with SAP PI/PO middleware solution.

However, with the advent of cloud computing, the proliferation of SaaS applications, and the need for agile, scalable, and cost-effective integration, a paradigm shift occurred. Businesses now require faster, more flexible, and hybrid integration approaches that support modern cloud-native applications while still maintaining connections to legacy systems. This shift led to the rise of cloud-based Integration Platform-as-a-Service (iPaaS) solutions like SAP Cloud Platform Integration (CPI) and SAP Integration Suite.

These cloud-based middleware solutions represent a fundamental change in how organizations approach integration. Rather than the rigid, infrastructure-heavy setups of SAP PI/PO, iPaaS offers:

  • Scalability: Elastic cloud infrastructure that grows with business needs.
  • Agility: Rapid deployment of integration flows and easy adaptation to new business demands.
  • Flexibility: Support for hybrid landscapes, including multi-cloud and on-premises systems.
  • Cost Efficiency: Reduced capital expenditure (CapEx) and infrastructure management costs.

This transition reflects a broader trend towards cloud-first architectures, enabling businesses to embrace digital transformation, streamline operations, and enhance their competitive edge. In this new era of cloud-based integration, SAP’s iPaaS solutions are designed to meet the complex, dynamic integration needs of enterprises, paving the way for the future of digital connectivity.

SAP Integration Product History Overview and Key Milestones:

  1. 2002: SAP XI – SAP’s first middleware solution focused on message-based integration.
  2. 2007: SAP PI – Rebranded from XI, expanding integration capabilities within SAP and non-SAP environments.
  3. 2011: SAP PO – Merging PI with BPM and BRM for full process orchestration and business rules management.
  4. 2013: SAP HCI – SAP’s first cloud integration platform, focused on integrating cloud applications with on-premises systems.
  5. 2017: SAP CPI – Rebranded HCI, expanding integration beyond SAP’s cloud products to include third-party applications.
  6. 2020: SAP Integration Suite – A comprehensive iPaaS solution offering hybrid, multi-cloud, API-driven, and event-driven integration capabilities.

 

 

The Key Paradigm Shift from On-Premise to Cloud Integration

When SAP introduced SAP HCI and CPI, it marked a key paradigm shift in moving from traditional on-premise middleware solutions, like SAP PI/PO, to modern cloud-based iPaaS platforms.

This shift reflects the changing demands of businesses as they transition to hybrid and multi-cloud environments. On-premise solutions were infrastructure-heavy, rigid, and often required extensive manual management, while cloud-based integration platforms offer flexibility, scalability, and agility.

With features like API management, event-driven architectures, and pre-built connectors, cloud iPaaS solutions enable faster, more seamless integrations across diverse landscapes, aligning with the growing need for real-time data exchange and digital transformation.

Overview of SAP On-Premise Middleware Versions:

The first SAP eXchange Infrastructure (XI) was introduced in 2002 with version XI 2.0. This was a dual-stack option with ABAP and Java stacks. After a few versions of XI, SAP introduced SAP Process Integration (PI) 7.0. PI single stack only installation option was introduced with PI 7.3 in 2010. Finally, in 2011 SAP introduced PO (Process Orchestration) with version 7.31.

evolution-xi-pi-po-history-versions
Evolution and history of SAP XI, PI, and PO, and their versions

To understand the differences between these versions, let’s look at the major architectural changes of each.

 

SAP eXchange Infrastructure (XI) Architecture Overview:

  • Launch: SAP introduces SAP XI as part of the SAP NetWeaver stack.
  • Purpose: SAP’s first centralized integration platform for on-premise systems, designed to enable communication between SAP and non-SAP systems using a message-basedarchitecture.
  • Key Features:• Message transformation and routing using adapters.
    • Integration of applications through a common integration engine.
overview-exchange-infastructre-xi
Overview of the eXchange Infrastructure

SAP eXchange Infrastructure (XI) contains Adapter Engine (AE), Integration Engine (IE), and Business Process Engine (BPE). It was installed on a dual stack Netweaver installation with ABAP and Java stacks.

  • AE – Adapter Engine

As the name suggests, the main purpose of this component was to provide connectivity functionality. Adapter engine provided capabilities of talking to different communication protocols using different adapters.

  • IE – Integration Engine

SAP XI component which was responsible for transformation and routing of the messages. Integration Engine also provided a runtime to the message communication. In XI heavy message processing was done through IE as each message was routed, transformed and executed by this component.

  • BPE – Business Process Engine

The engine which executess ccBPM (Cross Component Business Process Management) workflows. ccBPM is based on Business Process Execution Language (BPEL) and required a dual-stack installation as its runtime environment was on Web AS ABAP.

Drawbacks and Challenges with eXchange Infrastructure (XI):

One major drawback of XI is inefficient performance due to back and forth communication between components. Also due to the dual-stack architecture and multipole components, message persistence impacted the performance.

SAP Process Integration (PI) Architecture Overview:

  • Launched: Early 2000s.
  • Primary Use Case: Facilitates the exchange of information between SAP and non-SAP systems, typically in on-premises environments.
  • Architecture: A middleware solution built on SAP NetWeaver, using an integration server and adapters to connect applications.
  • Key Features:
    • Focuses on application-to-application (A2A) and business-to-business (B2B) communication.
    • Supports synchronous and asynchronous messaging.
    • Provides adapters for various protocols (e.g., HTTP, FTP, SOAP, and IDoc).

With SAP introducing Advanced Adapter Engine (AAE), PI was able to process messages end to end without Integration Engine (IE) runtime. This reduced the cross-communication between components and improved performance massively.

  • AAE – Advanced Adapter Engine

process-integration-pi-architecture-overview-aae
Process Integration (PI) Architecture Overview with AAE

AAE has capabilities to handle routing, transformation, and connectivity which were segregated into different components in SAP XI. Integration Configuration Object (ICO) was introduced for design time instead of traditional XI objects such as sender agreement, receiver determination, and receiver agreement. ICO made it possible to connect, transform and route messages in AAE without Integration Engine (IE) runtime. Also, dual-stack message persistence was eliminated since ICO scenarios were executed independently by AS Java.

Drawbacks and Challenges of PI with AAE

Although PI installation with AAE  enhanced performance in comparison with XI, still improvements were needed to extend connectivity and performance. AAE could only handle a limited set of connections and still required IE runtime for development and administrative purposes. Plus, the RNIF adapter and the CIDX were not available in AAE. Also, earlier versions of AAE did not include iDoc and HTTP adapters since they belonged to the ABAP stack. Moreover, BPE still required ABAP stack for runtime as it was ccBPM. As you notice, although performance was improved compared to XI, SAP couldn’t completely decouple the need for Integration Engine (IE).

  • B2B Add-on

B2B add-on was also introduced to PI with versions PI 7.1. B2B comes with a set of B2B protocol adapters, converter modules, and B2B infrastructure services for serving the EDI integration needs of most industries.

  • AEX -Advanced Adapter Engine Extended

process-integration-architecture-overview-aex
Process Integration (PI) Overview with Advanced Adapter Engine Extended (AEX)

Finally, with SAP PI 7.30 version SAP eliminated the need for Integration Engine (IE) and introduced the Advanced Adapter Extended (AEX). AEX is a single-engine which includes Enterprise Service Bus (ESB), Integration Directory (ID), and AAE capabilities. With AEX, PI became a Java AS-only installation and SAP completely decoupled the ABAP stack. Also with PI 7.3 SAP introduced the iDoc_AAE adapter and http_AAE which run on Java. The complete removal of the ABAP stack is a major change in the SAP PI architecture.

Drawbacks and Challenges of PI with AEX

Although PI with AEX improved performances by completely decoupling the ABAP stack and the need for Integration Engine (IE), it did not include Business Process Management (BPM) capabilities.

SAP Process Orchestration (PO) Overview:

  • Launched: Around 2011, evolving from SAP PI.
  • Primary Use Case: Enhances SAP PI with additional process orchestration capabilities, combining SAP PI with Business Process Management (BPM) and Business Rules Management (BRM).
  • Architecture:
    • SAP PO is a bundled solution that includes SAP PI for integration, BPM for process automation, and BRM for managing business rules.
    • This enhances the ability to design, execute, and monitor processes across the enterprise.
  • Key Features:
    • Complete end-to-end integration and orchestration platform.
    • Enables greater process automation and complex workflows.
    • Advanced monitoring capabilities and error handling.
    • Still primarily used for on-premises scenarios but supports hybrid approaches.
process-orchestration-po-overview
Overview of the Architecture of Process Orchestration

To overcome all these challenges with PI, SAP released Process Orchestration which was a Java-only installation. Yes! No ABAP stack installation was available from PO 7.31. Plus, with the new PO version SAP has added fully functional Netweaver Business Process Management (NW BPM) and Business Rule Management (BRM) which were fully executable on Java. Therefore, Process Orchestration (PO) is a combination of Process Integration (PI) with AEX, Business Process Management (BPM), and Business Rule Management (BRM) which only runs on Java.

  • NW BPM – Netweaver Business Process Management

Unlike ccPBM, NW BPM runs on a Java-based environment called CE (Composite Environment). Also, NW BPM uses Business Process Model Notation (BPMN) language while ccBPM uses Business Process Execution Language (BPEL). Although ccBPM design time was on ABAP stack, you require Eclipse-based tool NWDS (Netweaver Development Studio) for NW BPM. Even if you have extensive experience in ccBPM, you need to start learning NW BPM from scratch.

  • BRM – Business Rule Management

Business Rule Management (BRM) contains modeling capabilities targeting business analysts. Rules are owned by LoB, not by IT.

SAP HANA Cloud Integration (HCI)

  • Introduction: Launched in 2013, SAP’s first cloud-based integration platform.
  • Purpose: Designed to integrate SAP’s cloud applications (like SuccessFactors and Ariba) with on-premise SAP systems.
  • Key Features:
    • Lightweight, cloud-native integration.
    • Pre-built integration content for SAP SaaS solutions.
    • Faster deployment for cloud-to-cloud and cloud-to-on-premise scenarios.

What is SAP Integration Suite and Cloud Platform Integration (CPI) Overview:

  • Introduction: Rebranded from HCI in 2017 as part of SAP Cloud Platform (now SAP Business Technology Platform).
  • Purpose: A cloud-based iPaaS solution offering expanded integration capabilities beyond SAP’s ecosystem, supporting third-party applications and hybrid landscapes.
  • Key Features:
    • Pre-built integration flows (iFlows) for various use cases.
    • Integration of SAP cloud and non-SAP cloud applications.
    • Support for hybrid integration, connecting cloud and on-premise systems

SAP Integration Suite on BTP

  • Introduction: Launched in 2020 as the evolution of CPI, part of SAP Business Technology Platform.
  • Purpose: A comprehensive Integration Platform-as-a-Service (iPaaS) offering a full range of tools for hybrid, multi-cloud, and API-based integrations.
  • Key Features:
    • API Management: Full lifecycle management of APIs.
    • Event Mesh: Support for event-driven architectures.
    • Open Connectors: Pre-built connectors for integrating third-party applications like Salesforce, ServiceNow, and more.
    • Low-code/No-code tools: Simplified integration for business users.
    • Hybrid Integration: Integration across on-premise, cloud, and multi-cloud environments.

SAP Integration Suite was formally known as SAP Cloud Platform Integration Suite (CPI). SAP Integration Suite is the Integration-Platform-as-a-Service offering from SAP. Organizations can acquire SAP Integration Suite features on a subscription basis. Since the integration platform services can be accessed via the internet, it greatly reduces the initial implementation costs for hardware and IT resources.

The following are the main features of the SAP Integration Suite;

  • Cloud Integration
  • Open Connectors
  • API Management
  • Event Mesh
  • Integration Advisor

SAP Integration suite (CPI) is not a newer version of SAP PO. It is a new integration platform provided by SAP to address cloud-based integration requirements.

Cloud Integration

Cloud Integration feature provides a platform to build, deploy, and manage end-to-end integration scenarios in cloud-to-cloud, cloud-to-on-premise, and on-premise-to-on-premise domains.

Additionally, SAP has provided more than 2000+ prebuilt integration flows on A2A, B2B, and B2G processors that can be deployed with the minimum development effort.

Open Connectors

The open connector capability of the SAP Integration Suite standardizes the connectivity to third-party cloud applications. SAP has provided more than 160+ pre-built connectors to none-SAP cloud applications such as Shopify, ADP, SalesCloud, Workday, etc. Developers can easily reuse these prebuilt connectors to establish connections to third-party cloud applications. You can find a full list of open connectors here.

API Management

API Management is the feature that provides a platform to build, analyze, publish and monetize APIs.

Event Mesh

The event mesh makes use of event-driven architecture for integration. This greatly reduces having to have peer-to-peer connections. Organizations have the option to publish their business events in a data lake or data queue for multiple data receivers to consume.

You can read more details of SAP Integration Suite in the linked article. Moreover, we are written an article that discusses what to consider when migrating from SAP PI/PO to CPI.

Summary of the Evolution of SAP Integration Offering:

The transition from SAP XI to SAP Integration Suite reflects a major evolution in SAP’s middleware strategy, driven by changing business needs and the shift toward cloud-first architectures. SAP’s traditional on-premises solutions (PI/PO) have given way to flexible, scalable, and comprehensive iPaaS offerings like SAP Integration Suite, which cater to modern enterprises dealing with hybrid landscapes, API management, and event-driven architectures. This shift not only supports digital transformation but also positions SAP as a leader in integrating complex, multi-cloud, and dynamic business environments.

I hope you were able to visualize the evolution of SAP middleware. By looking at the history of changes to SAP middleware architecture from XI to PI to PO, you can see the reasoning behind these changes.

Additionally, we discussed the features of SAP Integration Suite and CPI.

If you have any more questions comment below!

 

Encode Message Payload to Base64 on CPI!

How to use Base64 message encoder in SAP Integration Suite.

Subscribe for more

My First Interface on CPI!

Learn how to develop your first iFlow on SAP Integration Suite within 7 minutes!

Subscribe for more

46 thoughts on “What is the Difference Between SAP PI, PO, CPI and Integration Suite?

  1. ssamatha says:

    Hi Fernando,

    In 7.31 we can see sxmb_moni in ECC. Though is is just sap transaction code, it is showing the PI messages. So was sxmb_moni is part of JAVA or ABAP? Can you please share your knowledge on sxmb_moni.

    • Isuru Fernando says:

      Hi Samantha,
      SXMB_MONI is used to monitor and reprocess XML messages in the local Integration Engine. How you monitor messages processed in the Integration Engine in ECC or ABAP stack is through SXMB_MONI. You configure it using transaction SXMB_ADM.

  2. ssamatha says:

    Hi Fernando,

    Thanks for your reply.Can you please answer below one.
    1.In 7.31 which is single stack, how can we have abap stack (sxmb_moni)..do you mean sxmb_moni is only for ecc and not belongs to PI at all?if so can you please say what is local integrtion engine and its uses.

    • Lakshman says:

      In dual stack Sxmb_moni t code uses for the ecc or abap stack.To find messages are processing or not in integration engine level. In 7.31po single stack runs java stack only so there is no need to use sxmb_Moni t.code.

      • Isuru Fernando says:

        SXMB_MONI is available in all SAP ABAP stacks like ECC, AFS, S4 HANA etc , not just in PI ABAP stack of dual stack PI. Even if PI is a single java stack version, if you have a ABAP backend system, SXMB_MONI can be used to monitor messages in backend system.

  3. Ed says:

    We are migrating to SAP PO. We have a middleware EDI translator and need to convert the flat file IDOC to and XML IDOC for PO. Is it now possible for PO to di this? Both inbound to SAP PO and out of SAP PO to the middleware?

    • Isuru Fernando says:

      Hi Ed,

      There are several options to handle EDI messages in SAP PO. You can either use B2B Integration Cockpit which comes as an add-on. With B2B cockpit you might be able to scrap the use of EDI translator and use the cockpit as the translator. It handles multiple EDI formats such as X12, EDIFACT etc.

      Or you can keep the EDI translator and use SAP PO for pass through or receiver determination (rule based routing).

      Check my blog post on how to install B2B Cockpit.

      Cheers!
      Isuru

  4. Pavan says:

    Hi Isuru,

    Very simple and nice content with so much of information.
    Excepting few more blogs.
    Please share SAP CPI knowledge as well.

    Regards,
    Pavan

  5. Densil Green says:

    I have many years of ABAP experience, but I have never had to use SAP PO until now.
    On my current assignment I need to change an existing interface.
    What transaction do I use to view an interface; and which transaction do I use to change an interface?
    Is it SXMB_MONI to view an interface and SXMB_ADM to change an interface?
    The main change I need to make is add a field.

    • Isuru Fernando says:

      Hello Densil Green,

      In order to view existing interfaces you need access to SAP PI/PO. Which version of PI/PO do you use? Usually, you access existing interfaces using Java Swing Clients or NWDS. This totally depend on the version you are using and your interface development procedures of your organization. So first get access to PI/PO clients. Then you can change the interface message format from Enterprise Service Repository. SXMB_MONI is a transaction where we can monitor Proxy interfaces. SXMB_ADM is a admin cockpit for interface configuration. They are ECC transactions and you cannot use them to change interface (add/remove fields). Interface message structure and mapping can be changed only from SAP PI/PO clients. if your scenario is a proxy interface, when you change the interface in PI/PO proxy should be regenerated in ECC side using SPROXY. When the proxy is regenerated, proxy class will include the new fields you added to the interface. After this step, you can implement the ABAP logic for the new field in the proxy class. Hopefully this helps!

      Cheers!

  6. Mathias Mulumba says:

    Hi Fernando,
    Great article!,
    i wanted to know what changes can a user with SAP_ALL profile make to the data that is routing through SAP PI and is the data closed from amendments .If the data cannot be amended during the routing process?, how is it protected from modification?
    Can a user with SAP_ALL access change the interface routes resulting in the messages going in different directions

    • Isuru Fernando says:

      Hello Mathias,
      Thank you!
      In PI users cannot edit message payload and reprocess them. But user can use “copy’ function in the message monitor to duplicate messages. That is another message can be created from a message. Also, Using PI test tool users can process messages manually. Using this test tool, users can directly copy the payload and process them. You need to make sure only super users or authorized users have access to these options in production environment.
      Hope this explanation will be helpful!
      Cheers!
      Isuru

  7. Zia says:

    Hi Mr. Isuru Fernando,

    I am new in ABAP and i have got the task to coordinate and suggest PI upgrade strategy to BASIS team of my organization. The senior resource has developed all scenarios way back since 2013, and some in 2015. There are some scenarios running in SAP PI, I got the understanding that SAP NW running is 7.4 and SAP PI is running 7.0 whose End of Maintenance was 2017. My organization wants to upgrade it to the version (But No SAP PO) so that End of Maintenance could be extended to a maximum date. Now I want to understand
    1. What i need to do to check whether all scenarios are built on single stack or in different stacks. How to identify them.
    2. Can I do something like export all objects/ scenarios and simply import into new fresh installed SAP PI version?

  8. Dharmaraj says:

    Hi Isuru,
    Really a good blog. Basically I am SAP Portal consultant and i want to convert to PI/PO consultant. your blogs are explained very well and easy to understand the difference of PI/PO advanced features.
    I would like to hear from you about the difference of HCI & CPI..both are same? or any functional difference are there?

    Regards,
    Dharmaraj
    [email protected]

    • Isuru Fernando says:

      Hello Dharmaraj,

      Thank you! 🙂

      Products HCI and CPI essentially provide the same functionality. SAP has rebranded HCI (HANA Cloud Integration) as CPI (Cloud Platform Integration). SAP HANA Cloud Integration is now called SAP Cloud Integration.

      Cheers!
      Isuru

  9. Rashmi says:

    Hi Isuru,

    I am still confused between PI and PO. Please help to clarify my down…
    I have worked on PI (AEX) where I downloaded NWDS and connected it to my AEX server then developed some NWBPM scenarios, deployed it and they were running successfully…

    What exactly difference between PI (AEX) and PO….. Please help to understand it.

    – Rashmi

  10. syed shamomhammad says:

    Hi Fernando ,
    Unbelievable Information and easy explanation. Its making me feel like “that’s it!”.
    Thank you.

  11. Sangam Ludhani says:

    Hi Isuru,
    Great explanation, complex things explained in simple way.
    Its time to enhance this blog and include CPI capabilities as well. It would be great for audience to understand the SAP Integration in cloud with On premise comparison.
    – Sangam

  12. Kishore says:

    Very nice article Isuru.
    I have attended a few training sessions for PI/PO on the Basis side and I can co-relate the stuff you have mentioned here.

  13. Nish says:

    Hello Isuru,

    Really good read, thanks.

    Is there a more details technical discussion of the same?

    For example, in Dual stack we’ve Receiver Determination , Interface Determination, Sender Agreement & Receiver Agreement which is converted to ICO in Single stack. What happens if I am migrating my system from dual stack to single stack ?

    I am sure ESR would still remain the same which means there should be a way to directly export and import ESR objects from Dual to single stack ?

    Happy to connect directly in case if this is too much outside discussion.

    Thanks,
    Nishanth

  14. Amith says:

    Easy and classy Explanation. Went through many blogs about differences in PI version, this is the best one. Thanks for sharing

  15. jagadeesh says:

    Hello Isuru

    The articles which you are published are really helpful for the beginners like me. They are simple and anyone can easily understandable. I would like you thank you for sharing your knowledge which leads to help so many professionals like me.

    Once again thanks a lot

    Regards
    Jai

  16. Midhun says:

    Hello Isuru,

    Really good read, thanks.

    Is there a more details technical discussion of the same?

    For example, in Dual stack we’ve Receiver Determination , Interface Determination, Sender Agreement & Receiver Agreement which is converted to ICO in Single stack. What happens if I am migrating my system from dual stack to single stack ?

    I am sure ESR would still remain the same which means there should be a way to directly export and import ESR objects from Dual to single stack ?

  17. anil says:

    Hello Isuru,

    I have gone throught it all the blog,still, I have doubt regarding in my scenario we are at sap pi 7.4 NetWeaver versoin and we want to update NetWeaver 7.5 for we need to update license pi to po ?

  18. Pablo says:

    Hello, today we have implemented a PI dual stack 7.5, should it be taken to PO? to CPI? Or what would be the next step?
    Thanks a lot

  19. Srikanth Chinni says:

    you made it sooo simple and cooool… great explanation… thanks for all your content… keep going…

Leave a Reply

Your email address will not be published. Required fields are marked *