In the first of our Cloud Integration blog series ‘Answering the Cloud Integration Challenge’; we looked at our experiences with HANA Cloud Integration (HCI). In this blog, we would like to share some important learning, when using HCI to integrate SAP Cloud applications, such as Cloud for Customer, and on premise SAP systems, such as CRM and ECC.
Know your business, and system, processes
When it comes to data flows and data integration, there are a number of options available with HCI. If integrating Cloud for Customer and ECC, the standard data iFlows are delivered:
One of our biggest issues around data flows was not the technical set-up, but understanding which data objects should flow from where, and when. Prior to any technical set-up, it is key to understand your business and system processes, and to identify a lead system for each set of data.
Data, Data, Data
The standard set-up guides contain detailed information on how to map data between SAP ECC / CRM and Cloud for Customer, using either SAP PI or HCI. Once we had mapped typical data objects, such as account groups, product hierarchies, sales areas and order types, our integration was still failing, due to a further level of data mapping that was missing.
This ‘code list mapping’ requires field values to be mapped between the systems. To minimize effort, values can be mapped automatically. However, Field values will need to be mapped manually if the value keys differ between the systems.
When integrating Opportunities to ECC Quotes, we had to map many fields of the Cloud Opportunity, such as Sales Cycle, even though the fields are not available to populate within the ECC Quote.
The creation of a customer specific mapping group would have allowed us to remove irrelevant data types, saving us time and effort on creating unnecessary mappings, and investigating integration failures.
Monitoring and Errors
When integrating C4C with our backend ECC system and vice versa, SAP’s pre-delivered interfaces were downloaded from our HCI tenant and used. However there were still a number of manual configurations that need to be made to these interfaces and invariably we faced errors along the way which required investigation. Fortunately the HCI plugin for eclipse provides us with message monitoring. The Message Monitoring editor displays all messages processed for a tenant according to the filter settings. To display messages, you can specify the following filter criteria: Time and Status, Log ID, Processed At, Status, Receiver, Processing Time, and Integration Flow.
Message monitoring is also available when you access your tenant via a web browser:
Messages processed by SAP HANA Cloud Integration can have one of the following status.
Certificate Authentication is used to authenticate messages sent from an SAP backend to HCI. An x.509 sender certificate needs to be added to the HCI iFlow for ERP2COD scenarios. The How-To Guide describes how your own certificate can be exported from your on premise ERP system via transaction STRUST. The certificate is then saved as a file and imported into your iFlow. However from our experience we have found this approach not to work. The certificate which the How-To guide tells you to export (own certificate under SSL Client SSL client Standard PSE) and include in your iFlow, is a self-signed certificate. HCI however doesn’t accept self-signed certificates, only certificates from specific Certificate Authorities. To solve this you have two options:
1. In STRUST, create a certificate request, order a certificate from SAP Trust Center and import the certificate response (involves costs).
2. If you only need the interface for test purposes a workaround is to create a separate SSL Client node in STRUST, create a PSE with your SAP Passport CA Certificate and use it in your SM59 Connection. Likewise, your iFlow would include your SAP Passport CA Certificate.
In the next blog in the series, we will cover how to create your own integration flows and the challenges faced.