Technical Articles
SAP CPI – Deploy and Runtime Iflows on PI/PO on-premise
Hello you,
Good?
So once again I’m here now to talk about a very interesting feature of SAP PO on-premise – deploy the integration scenarios from SAP CPI on SAP PI/PO – Single Stack java, this blog it’s just to show you the Hybrid Architecture perspective using SAP products for cloud and on-premises.
Before we start to discuss it, please take some time on the blog of Alexander Bundschuh that he wrote a fantastic blog with best practices and others of Hybrid Integration
Blog:
Best practices Cloud Integration Content in SAP Process Orchestration
Wait.. really?
Are you saying to me that I can develop the integration scenario on CPI and deploy the package (engine of SAP CPI) on SAP PI or PO 7.5 – Single stack java – and works perfectly even without SAP PO don’t support without some standard functions of CPI as General Splitter and others that you will see below ?
Yes, you can manage this with Enable Cloud Integration Content in SAP Process Integration on SAP PI or PO – On-premises.
Perspective:
Architecture – Cloud / On-Premises and Hybrid:
Hybrid Integration :
SAP Hybrid Integration – Cloud Connector or SAP PI/PO Runtime:
- SAP Cloud:
- CPI – Neo
- EM – Foundry
- SAP On-Premises:
- PI – Process Integration
- Components: SLD,ID,ESR,Monitoring
- PO – Process Orchestration
- Components: SLD,ID,ESR,BPM,Monitoring
- PI – Process Integration
- Road map Webinar: SAP Cloud Platform Integration
- Road map Webinar: SAP Process Orchestration
SAP Diagram Perspective:
Are you ready?
Ok, I think so, you need make some setups on SAP PI or PO, I already provide the link of SAP HELP also the blog of Alexander Bundschuh – that he provides all setup and notes and details, after you deploy this Cloud Integration Content you will be able to see a button on your main screen login of PI/PO.
1) Cockpit
As you see in the cockpit I already deploy one PACKAGE from SAP CPI.
When you click on the button DEPLOY, you will have three options to deploy:
- Cloud Tenant via Destination
- Cloud Tenent via URL
- File System
Click on next and SAP PI/PO will load all Packages on SAP CPI available.
Open the integration Package and you will have the view of the Artifacts from SAP CPI, choose and click each Artifact you want to deploy on SAP PI/PO.
After deploy you will be able to see the ENDPOINT’s available on SAP PO.
The integration Scenario SAP CPI:
You choose an on-premises solution and decide to deploy it on CPI, will works?
No, don’t mix up.
Choose the correct version of the on-premise solution that you have with the correct SP level.
Wow, this is a simple scenario but nice I see the integration patterns from CPI as:
- Content Modifier
- General Splitter
- Loop another process
- Request-Replay
- Gather XML
- XSLT – CPI Native Compile Engine
- Content Modifier
- Grovvy Script for Logging – CPI Native Compile Engine
Comparisons of SAP CPI vs SAP PI/PO:
Sorry but some of this functions it’s not native on SAP PI/PO when you deploy the package of the Artifact from SAP CPI it will work without any extra development of java mapping (Groovy script on the cloud) and BPM to loop another process.
The answer is: YES
Wait, even groovy script will be deployed on SAP PI/PO will works? Yes, it will keep as groovy, not java mapping or UDF, check the code and image below of the logging:
The groovy script it’s setting up the attachment:
import com.sap.gateway.ip.core.customdev.util.Message;
import java.util.HashMap;
def Message processData(Message message) {
def body = message.getBody(java.lang.String) as String;
def messageLog = messageLogFactory.getMessageLog(message);
if(messageLog != null){
messageLog.setStringProperty("Logging after Mapping", "Persist Message as Attachment to Log")
messageLog.addAttachmentAsString("01_PersistPayload", body, "text/xml");
}
return message;
}
In this blog, I will also not cross in detail each function of SAP CPI but I will explain to you the integration itself.
CPI Scenario:
1 ) Basically, I will make SOAP call with many material numbers on the SOAP BODY
2 ) The function of the general splitter will split the calls based on the //MATERIAL.
3 ) In this case, I will have 6 materials so the LOOP Process Call will invoke the S4HANA 4 times in sequence and until the last response, he will collect all results.
4 ) Gather will receive from the loop 6 XML’s and will generate only one with a merge of 4 XML.
5 ) XSLT for remove the start tags from JAVA Mapping from Gather Function.
6 ) Content Modifier.
7 ) Grovvy script
OK, I understand until now but how you define the ENDPOINT on CPI and deploy on SAP PI/PO how I will know the real ENDPOINT of On-premises?
Easy, no worries: https://{hostname:door}/igwcxf/services/{endpoint of CPI}
CPI SOAP Adapter:
Cloud Cockpit:
So let’s make all together sample:
SAP PI/PO – hostname
Port:50001
Endpoint from deployment: /igwcxf/services
Endpoint configured on CPI – Soap Adapter: /CPIRuntime
Correct endpoint: https://hostname:50001/igwcxf/services/CPIRuntime
Now it’s real, let’s start to play?
Open your SOAP call tool, in my case SOAPUI.
Request Message:
Response:
Cloud Integration Content:
For now, in deployment perspective we have this:
You can deploy the Message Mapping – Operation Mapping from SAP PI/PO on CPI, but i could not find a pure migration toom from ICO’s to CPI Flows:
Blog of MM and OM from PI/PO to CPI
Bonus information: When you deploy the integration scenario on SAP PI/PO any new changes in objects, functions or communication channel detail, you must deploy again, you can’t change or see the integration scenario on SAP PI/PO.
Cloud Integration Content Management Cockpit – SAP PI/PO for JMS:
The Deploy of JMS Integration Scenario from CPI to PI/PO – perspective:
I really hope again that you like the aspects and the blog, waiting for your feedback.
Thank you.
Kind Regards,
“Viana”
Very good Ricardo Viana !
Hi Ricardo,
happy to hear that you like the feature, I also think that the cloud integration runtime on PI/PO has huge potential, with this you can extend the feature scope of PI/PO, it allows you to setup scenarios which wouldn't be supported otherwise or which at least would require much more effort and eventually coding, now you have the possibility to leverage the flexible modeling environment of SAP Cloud Platform Integration.
You may also check out my blog series at https://blogs.sap.com/2017/08/11/best-practices-cloud-integration-content-in-sap-process-orchestration-overview/
Regards
Alex
Hi Alex,
I agree with what you told me, I will just update the blog with your content also and this is fantastic because as I mentioned on the comparison of development on CPI and PI/PO when the engine of CPI pack all objects from the Integration Scenario, my first time I said it's not going to work, there is no loop of sync call on SAP PI/PO native without BPM or ccBPM Component, and then when I deploy works... I was impressed, simple, clean and others benefits.
Thanks for your opinion and share with me your blog.
Kind Regards,
Viana.
Hello Ricardo,
Thanks for this wonderful write up in addition to Alexander Bundschuh article. I have seen this being used in one of my clients and it’s really great. However I have one question and trying to figure it out . The use case is , for the employee replicator (success factor) betweeen S4 and CPI they are using PO 7.5 as an gateway, just as a proxy . So the messages go from S4 to PO to CPI. I can see the endpoint in S4 SOAMANAGER defined as PO, but what missing link is, I don’t know where the endpoint has been defined in PO to say it has to go E- tenant ( test) vs L- tenant(prod) . Obviously I’m overlooking something , but if you can point it out that would be helpful!!
Thanks,
Justin
Justin,
In general, you must build the endpoint as I explain, only if you are sending the data to CPI as HTTPS, CPI will generate automatically this to you, but if you will deploy this on SAP PO you must change the endpoint, hostname, and port to SAP PO.
So let’s make all together sample:
SAP PI/PO – hostname
Port:50001
Endpoint from deployment: /igwcxf/services
Endpoint configured on CPI – Soap Adapter: /CPIRuntime
Correct endpoint: https://hostname:50001/igwcxf/services/CPIRuntime
Regards,
Viana.
Hi Ricardo,
Nicely written.However I am unable to figure out the value proposition with this type of deployment model,Until unless SAP CPI-IS and SAP PRO shares the same license,that means either SAP PRO should be complementary for SAP CPI.
If this is not the case,If I own CPI-IS license then why would I prefer to deploy on on-premise SAP PRO gateway runtime?Also, If I wanted to change IFLOWs in future, again I should access CPI design time to edit.
One of my client is having SAP PO 750 and CPI, however CPI is mainly used to Integrate SFSF and other cloud applications (not sure on on-premise integrations,but it can be done through Cloud Connector etc.) but never deployed CPI-Cloud Integration Content to on-premise SAP PRO.
Please help me to understand on this or kindly point me to the best use cases,In case If i am missing anything.
Cheers
Pavan Nukala
Hi Pavan,
Let’s make it simple, image the you still with SAP PI/PO on your landscape but you start to migrate to Cloud – CPI – for other cloud platforms as SAP Hybris, Concur or external Cloud Products SFSF but others interfaces still on-premise but in duty of difficult to make integration or it’s complex or too much time consuming on SAP PI/PO pure.
You can use this approach, develop on SAP CPI because there is a big range of integration patterns that SAP PI/PO does not have as:
You can use this advantage of CPI on PI/PO instead of using heavy java mapping/XSLT together with BPM (PO) for this – just using the integration patterns – Gather and Loop Another Process for example.
SAP even provide this option, check the image below:
2b – Cloud Connector: Load Balance Service and Reverse Proxy (Protection) for SAP CPI – to connect with on-premise.
1 – SAP PI/PO together with WebDispatcher – to connect with on-premise back and or external system on-premise.
Once you develop on SAP CPI and deploy the package on PI/PO, you can not make any changes, you just have simple monitoring of the objects and messaging, new changes, always on CPI and deploy again the integration scenario.
So in short explanation, if you have SAP PI/PO – stop the development in on-premise and start develop all your integration scenarios on SAP CPI – Easer, Light, Centralized development (Old School - Repository and Directory plus SLD), Faster, User-Friendly and much more integration patterns available, take this advantage to support you with on-premise integration.
For Architecture point of view, it depends on how you want to use – CC or PI/PO Runtime for on-premise integration.
I really hope that I clarify your points, this is the ideas that I have in mind about this Hybrid Integration Perspective.
KR,
Viana.
I would just like to confirm what is being said here. If we have Process Integration (PI) 7.5 (not PO, Process Integration) we can have a CPI runtime on that system?
Yes, we can!
You can deploy, execute, and operate cloud integration content from the SAP Integration Content Catalog in the Advanced Adapter Engine with all the deployment options:
– PI-AEX (aka Java Only or Single Stack);
– decentral Adapter Engine;
– SAP Process Orchestration;
– SAP PI dual usage type (in 7.5 there is no Dual Stack, it’s called Dual Usage, but it is ABAP+JAVA).
Have a glance at the documentation:
Cloud Integration Content
Best Regards.
Pedro Baroni
Hi Ricardo,
Thanks for the wonderful blog! In our landscape, we are planning to have the similar hybrid model. CPI cloud runtime for cloud based integration and CPI on-premises runtime for on-premises integration (satisfying audit compliance)
I have referred fantastic blog series of Alexander Bundschuh on the CIC in SAP PO and in addition I have some queries before we configure CPI runtime in SAP PO. Can you please assist/guide me on this Query post
Thanks for your kind support.
Regards,
Baskar
Muito bom Viana!
Obrigado pela explicação e exemplo.
Very helpful blog!
Thanks Viana.
Hi Viana,
Thanks for sharing such a informative document.
However, I am bit curious to understand background configurations.
Since we are developing IFLOW on CPI, do we still need to perform background configuration on CPI or that will be required in SAP PI/PO.
For e.g.
on-prem (ECC) --> CPI (Dev) --> PO (Runtime) --> on-prem(Legacy)
In case of CPI, we perform exchange of certificates/SSL settings in ECC and CPI, Cloud Connectors etc
In case of PI/PO, we create RFC destinations, partner profile, ports etc in ECC and PI.
I am trying understand apart from designing my IFLOW on CPI and deploying it on my PO server what else settings I need to do.
Thanks in advance,
Rashmi
Hi Ricardo,
A lot of links in this blog are broken. Is it possible to update those so as to understand the things?
Regards,
Ankur
hi Ricardo Viana & Alexander Bundschuh ,
Thanks for sharing the useful information on CPI runtime. I have question on the SAP Recent annoucement on the SAP PI/PO going end of support by 2027. In this case how the SAP CPI + SAP PI/PO Runtime environment architecture sustain in future.
Can you share more on this ?
BR,
Shobhit taggar
Hi Ricardo Viana & Alexander Bundschuh,
I am also very interested in an answer to the question put by Shobhit Taggar.
Repeatedly we get similar requirements where on-premise third party tools need data from our on-premise SAP ERP R/3 system. This results sometimes in a synchronous PO integration flow with HTTP/REST sender & XI (ABAP proxy) receiver adapter.
Our PO system has the release version 7.50 with SP19 and therefore includes also a local cloud platform integration runtime. We are interested to implement all new interfaces with the above pattern on a forward-looking way and prefer to keep down the future migration efforts from PO to the new planned PO aka "integration cell".
We would like to know if currently the https sender adapter (version 1.4) of local CPI runtime of PO system is mature enough regarding provided authentication methods to replace the REST sender adapter of the "old" PO system. We need an enterprise-ready capability to secure IFlows on local CPI runtime.
As you can see from attachment "Local-CPI-IFlow-HTTPS-sender-adapter-authorization-methods.png" the https sender adapter supports "client certificate" and "user role" authorization methods. In In this context we have this questions:
1. "user role" method: Is it possible to use this method in order to create a technical system user on PO system and create a scenario-specific user role on PO system and assign this user to the role? We need the runtime behaviour that a client is only able to consume an IFlow on the local CPI runtime if it has the right basic credentials. We didnt' found an official documentation how to configure this.
2. "client certificate" method: Does this feature work for local CPI runtime and how are the configure steps?
3. Will the future "integration cell" also support the current PO REST adapter (software component: SAP BASIS 7.50) or is it planned to refine the HTTP sender adapter of CPI that it covers the capabilities of the PO REST adapter? Which technology is more future-oriented?
From our opinion only when the needed features of 1 + 2 are available it makes sense to implement IFlows with the above pattern on the local CPI runtime of PO system.
Best Regards,
Tobias Miller
Local-CPI-IFlow-HTTPS-sender-adapter-authentication-methods
The user used in the JMS configuration. What roles do you have to have?