Connecting SAP HANA on-premises to SAP Cloud Platform Integration (CPI) is a crucial step in establishing a seamless data flow between on-premise and cloud-based systems. This integration allows organizations to leverage the power of cloud-based integration capabilities while maintaining access to their existing on-premise HANA databases.

This document will provide a comprehensive guide on how to achieve this connection, covering essential steps, configurations, and potential challenges. By following the outlined procedures, you can effectively establish a bridge between your on-premise HANA environment and CPI, enabling efficient data exchange and process automation.

In order to Fetch Data from the SAP Hana Database from CPI iFlow – you need to complete the following configurations. (Step A and B as mentioned in the following diagram)

A. Cloud Connector

Cloud Connector is a software application that acts as a bridge between cloud-based services and on-premises systems. It establishes a secure connection, allowing these systems to communicate and exchange data seamlessly.

Login into the Cloud Connector Application and establish the connection for Cloud to On-Premises system

• Map the Hana Server into the Cloud Connector using TCP Protocol
  
• Provide Internal IP and Port , Provide Virtual IP and Port
  
• Note down the Virtual IP and Port ( this will be used in the JDBC Connection inside the CPI subaccount)

To Add new System – you need to provide details as below:

• Backend Type : SAP – Hana
  
• Protocol : TCP
  
• Internal IP & Port
  
• Virtual IP & Port

Once saved, you can verify the connectivity test by checking the Check Availability icon – that will shows Reachable or Not-reachable. (Please note down : The Virtual IP and Port )

B. Cloud Platform (CPI Account)

SAP Cloud Platform Integration (CPI) is a cloud-based integration platform as a service. CPI provides a flexible and scalable solution for integrating cloud and on-premise applications, facilitating seamless data exchange and process automation.

Login into the CPI Subaccount and Create the new JDBC Material / Connection.

• Create the JDBC connection
  
• Provide the JDBC URL : format jdbc:sap://virtualIP:virtualPort/?databaseName=myhanadb
  
• where virtual IP is the virtual IP you mentioned in cloud connector in step A, virtual port is the virtual port you mentioned in cloud connector in step A

While adding JDBC, you need to provide the following details

Name: name as per your wish
Description: as per your wish
Database type: SAP Hana Platform (on premise)
User ID and Password: your database userid and password
JDBC Url: jdbc:sap://virtual ip:virtualport/?databaseName=your database name

Finally, in the iflow, you use JDBC adapter and in the properties tab, you mention the JDBC connection name you created in the step B.

C. Iflow

In the iFlow, the Hana Server is connected via the Request Reply pallet. The connecting adapter properties should mention the JDBC connection you created in the step B.

In the iflow, In the JDBC Adapter properties – you mention the JDBC connection name you defined in step B.

D. Execute the iflow in Postman

In the Postman, you pass the SQL statement in the body.

select * from sapabap1.sflight;

The output you will receive in xml format.

This is how, we can establish the connectivity from CPI-iFlow to SAP Hana On premises and execute the SQL Queries to fetch data.

POSTMAN

The SQL output will be displayed in the xml format.

Conclusion

In conclusion, this document has outlined the steps and considerations involved in establishing a seamless connection between an on-premises HANA database and SAP Cloud Platform Integration (CPI). By leveraging the capabilities of CPI, organizations can effectively bridge the gap between their on-premises systems and cloud-based services. By following the outlined procedures and best practices, we can ensure a successful and reliable connection between their HANA database and CPI, unlocking the full potential of both platforms.

The post Connecting SAP HANA on-premises to SAP Cloud Platform Integration (CPI) appeared first on ERP Q&A.

Business Continuity is of utmost importance for any organization. A well defined High Availability (HA) & Disaster Recovery (DR) strategy ensures business critical SAP Applications accessibility during any planned or unplanned outage. SAP HANA database being a central component of a SAP Application is configured with relevant HA/DR setup to make the business data available at secondary node/site to ensure business continuity.

HA for HANA database is being used as fault tolerance mostly for any infra related failures where HANA database fails over to secondary hot standby node deployed in cluster mode within a single region. RPO and RTO are almost zero in this case as most of the steps are seamless and automated with cluster management. Synchronous HANA replication across zones of the same region ensures the secondary HANA node is in sync with the primary node all the time.

In case of complete primary site loss, where Primary Node along with HA hot standby is not available, DR solution on a separate geographical location termed as Secondary or DR Region in public cloud acts as a safety net to ensure business continuity. Asynchronous HANA replication to the standby node in the secondary region keeps pushing the data from the Primary node. Manual failover is required to make the DR node as Primary.

Let’s discuss some SAP HANA DR options along with their pros & cons respectively.

Performance optimized DR setup (cost challenge)

For mission critical applications with requirement of minimum RTO (few minutes to hours) to have the system up & running in the secondary region with all the business data, performance optimized DR using SAP HANA HSR is deployed. In this DR setup, computing capacity of DR HANA node is kept the same as Primary HANA Node and full data is loaded in memory of DR HANA node at the time of replication setup. Then all the delta data committed in primary, post initial load, is replicated regularly in secondary through archive logs.

As depicted in the diagram below, secondary node cpu and memory configuration is kept the same as primary node so the major chunk of data is already loaded in secondary HANA node memory. In a disaster scenario, such configuration enables the Secondary node as Primary in minimum possible time and almost no data loss. However maintaining the PRD equal hardware at secondary site for DR node adds to a significant cost.

Cost optimized DR setup (higher RTO)

To overcome the cost challenge with performance optimized DR setup, we can consider following cost optimized SAP HANA DR options. Trade off with such setups will be higher RTO but with low DR cost.

(i) Shared HANA DR node

In a DR setup where secondary node sizing is kept identical to PRD primary, generally resources on secondary node can not be used for anything else until the takeover takes place. In this shared DR setup, PRD data is not loaded in memory but in disk at secondary site and thus resources can be shared by another non-PRD SAP HANA instance e.g. QAS or TEST on the same node. In order to achieve it, memory allocation to the PRD secondary node is restricted and the rest of the memory is allocated to non-PRD (QAS/TEST) instance.

In case of a PRD Primary disaster scenario, non-PRD system QAS/TEST to be stopped, full memory/resources to be allocated to the PRD standby node, load data from disk to memory and bring it up as Primary. Apparently these steps will increase the recovery time but it has the advantage of low cost DR setup because we are using the same DR node for our QAS/TEST instance.

(ii) Lean HANA DR node

As compared to Shared DR setup, here we opt for bare minimum memory configuration for PRD secondary instance so as the replication of PRD data keeps loading in the disk. Thus we don’t need a DR node to match the same sizing/memory configuration as PRD primary. As in shared DR setup, preload of column tables to memory of Standby HANA node is disabled by setting the database parameter “preload_column_tables” as false.

In case of a PRD Primary disaster scenario, DR node to be stopped & upgraded to configuration matching the PRD primary (Google VM type approved by SAP for PRD use) and full memory/resources to be allocated to PRD standby node. The value of database parameter “preload_column_tables” must be changed back to default value as true so as to load the complete data including the column tables to memory. As compared to Shared mode, this setup will have significant reduction in the DR cost as we are keeping the Standby node computing/memory to bare minimum to support the data replication from the Primary node.

Minimum memory configuration/Google VM type needed for Cost optimized lean DR secondary node to be calculated as per SAP guidelines and supporting documentation (SAP Note 1999880 FAQ SAP HANA System Replication). It is advisable to run a Pilot/PoC to come up with exact memory & sizing configuration requirements for lean DR node and arrest any other unforeseen issues upfront.

(iii) Backup-Restore HANA DR

In this most cost effective HANA DR solution, no dedicated secondary HANA Node is deployed and no real time data replication from Primary HANA node happens. However, we need to ensure that backups (HANA Database – data & logs and Application/file systems) are being stored (dual region/multi region mode) on another region identified as a DR site. RTO to bring up the Primary instance at identified DR site will be quite high as , in case of disaster scenario of Primary region not being available, one needs to set up the Servers in DR region from scratch, Install the Application along with Database and then restore the Database from the backup.

We also must reserve needed computing capacity in the DR region so that required VMs can be deployed quickly with needed capacity at DR site in a disaster scenario. We also must ensure to have a network connectivity (VPN) to DR side to access the Applications.

Conclusion

Performance based HANA DR setup is the preferred one with minimum RTO & RPO as the business would like to have the critical SAP Application up & running on a secondary site in the shortest possible time. But having hardware configuration same as Production will be a cost overhead.

All cost optimized HANA DR options discussed here will definitely save cost as compared to performance optimized HANA DR setup. However, one must sacrifice on the time needed to stand up the functional DR in the secondary region. Depending upon the acceptable RTO and criticality of the HANA based SAP application in a DR scenario, appropriate cost optimized HANA DR setup can be deployed.

The post Cost optimized SAP HANA DR options on Google Cloud appeared first on ERP Q&A.