This document is additional information to be used when an implementation has the integration scenario of SAP Hybris Cloud for Customer(C4C) with SAP Cloud Process Integration service(CPI) and S/4Hana(S4H) or SOH on SAP Hana Enterprise Cloud (HEC). It should be used along with the other relevant integration and security guides. Here the emphasis is on understanding the difference S4H or SOH on HEC makes for the integration with C4C via CPI with certificate based authentication.
S4H and SOH are available for installation in customer’s landscape OR as a hosted solution on HEC. The former is the standard configuration that we know of. The latter is something new and what we will concentrate on here.
The hosted solution is on HEC which is a private cloud edition. Here SAP or a partner manages the infrastructure. Customer accesses the system via VPN or MPLS lines. Hence, the integration guides for the on-premise systems S/4Hana and ERP would be applicable for S/4Hana and SOH on HEC respectively. In effect, it is an extension of the customer’s own network. When the server names are created then the customer’s domain names are used.
The solutioning process for setting up SOH or S4H on HEC happens early on and if integration is already mentioned by the customer or any integration service from the SAP Cloud Platform has been bought then SAP Platform Cloud Connector(SPCC or HCC as previously called) will be installed in the HEC landscape. There can be one or more than one web dispatcher(WD) and load balancers in the landscape. There will be a forward proxy made available in the landscape as well.
The integration with C4C via Cloud Process Integration (earlier known as HCI) can work with WD or SPCC for sending messages to S/4Hana or SOH and will use forward proxy for receiving messages from S/4Hana or SOH.
Information about the HEC setup and which components are available in it, can be procured from the single point of contact for HEC(SPOC HEC) from SAP for that customer. All system level configurations/setup steps will be performed by the HEC team handling the infrastructure. For such steps, incidents should be raised. All application level steps will need to be performed by the implementation project team (includes partner and customer). The project team should have a close alignment with the SPOC HEC during the project.
The stakeholders in the integration between C4C and S4H/SOH on HEC would therefore be: C4C functional consultant, CPI consultant, customer admin team and HEC hosting team.
Such flows are seen for the master data replication to C4C from the S4H or SOH. The setup for this flow is identical to the setup customer must do for an integration scenario for a ECC on-premise system in customer’s landscape with C4C via CPI:
S4H/SOH needs to trust the Cloud Process Integration(CPI) hence, upload the CPI server certificate chain the S4H/SOH trust store and map the CPI client certificate to the integration user in S4H/SOH.
Check the relevant integration guide for the technical setup at this help link.
Such flows are for triggering transactions in the backend system and pricing calls. In this scenario, for an on-premise system set up in the customer’s landscape, generally a reverse proxy would be needed. In HEC setup, we have option of using SAP Platform Cloud Connector(SPCC) or Web Dispatcher(WD).
Check the details of how SPCC is setup and to be configured in help link here. The SPCC would be already installed in the HEC environment if integration service is bought by the customer and this is known during the solutioning time. Else it will need to be requested later – raise request with the SPOC for HEC on getting this installed in the HEC landscape and made ready for connection with Cloud Platform. SPCC is free to install and configure.
The configuration of SPCC via the admin console would need to be done by you. The link to access the SPCC admin console can be provided to you by the HEC team on request.
One of the main advantages for the connector is one does not need to configure the on-premise firewall to allow external access from the cloud to internal systems. You can read about advantages of SPCC here.
It comes with its own default certificate which is recommended to be changed. This can be changed with a self-signed certificate or a certificate signed by a CA. The latter option is an extra cost. However, it is expected to be more secure. Principal propagation allows log on of Cloud Platform logged on user to backend system. The trust will need to be setup between the SPCC and the backend system( S4H & SOH). S4H/SOH should be certified by a CA which is supported by Cloud Platform. More information on principal propagation is available in help link here.
There are several blogs on how you can configure CPI to work with SPCC in the community and with principal propagation.
Load balancers and web dispatcher (one or more) will be available in the HEC environment. Setup and configuration of Web Dispatcher mostly will be system level task and hence, this will not be accessible to you to setup and configure. The load balancer or the WD(whichever terminates SSL connection) will need to have a public IP. This may have a cost.Please confirm with your HEC SPOC.
The steps in the integration guide which deal with setting up trust with the reverse proxy are to be done here by the hosting team. You would need to raise request and provide them the signed certificate to them upload to Web dispatcher. Getting the certificate signed by a public CA will be an additional cost. You will find more information about the certificate etc in the integration guide relevant for your scenario here. The settings to be done in STRUST for setting up the trust in S4H/SOH will need to be done by the customer basis team.
Certificate-based authentication for integration between C4C and S4H/SOH via CPI will require the S4H/SOH to have a certificate signed by a public CA supported by CPI. S4H/SOH being on HEC does not change this. Using SPCC instead of WD also does not change this.