Technology Blogs by Members
Explore a vibrant mix of technical expertise, industry insights, and tech buzz in member blogs covering SAP products, technology, and events. Get in the mix!
Showing results for 
Search instead for 
Did you mean: 
Active Contributor


Recently, I had the opportunity to evaluate the trial version of HANA Cloud Integration (HCI). With SAP focusing its business on cloud-based services, HCI is an area that is receiving increasing interests as well as investments. It is great that SAP provides a 30-days trial access for potential customers to evaluate whether HCI will be suitable for their integration needs.

After receiving the welcome pack for the trial program, I started off following the guide included in the pack, subsequently the blogs by sujit.hemachandran and i063124. Finally, I just tried to explore as much as possible the various functionalities in HCI.

There are already plenty of blogs on SCN related to HCI, covering the features, architecture, etc, so I won't be going into that area. Instead in this blog, I will share some of my experience with it during the one month trial period, in particular what I liked and disliked. As my work experience is mostly on PI (SAP's on-premise integration solution), the perspective of this blog will mostly be in comparison with features in PI.


HCI can be accessed via the Web UI or Eclipse (via HCI plugins). While the Web UI is constantly being updated with new features, I prefer to use Eclipse for development as it caters for more functionality compared to the Web UI.

I found that installation is pretty easy and I could start working with it relatively fast. There are other blogs that cover the installation process, as well as the guide that comes with the welcome pack, so this is just a summary of the steps involved.

After the installation has been completed. Below are the versions of the plugins as well as the tenant that I worked on.

HCI Tenant Version: 2.8.5

Eclipse Plugin Versions: Adapter 2.11.1, Designer 2.11.1, Operations 2.10.0


  • Message processing is based on Apache Camel's message model. Compared to PI's Adapter Framework, HCI has a more flexible messaging pipeline. While PI only allows single occurrence of receiver/interface determination steps in the pipeline, HCI's modular approach allows for this to be included anywhere (that makes sense) within the iFlow design. This flexibility allows for the possibility to design relatively complex iFlows (an example shown below). Furthermore, integration that requires multiple calls (i.e. retrieve session ID or token first) can be incorporated into an iFlow as compared to PI where such calls have to be coded in UDFs, Java mapping or custom modules. Following is a sample of such a multi-call iFlow design in HCI (HCI: Developing custom OAuth 2.0 authentication in iFlows).

  • Utilizes deploy-able artifacts to store Credentials (as described in following blogs Building your first iFlow - Part 4: Configuring your credentials, Authenticating from HANA Cloud Integration). With this approach, it is possible to configure and deploy a user credentials once, and then use it in multiple locations (different channels, different iFlows, Groovy script logic). If the password changes, only the user credential artifact needs to be updated and re-deployed compared to PI where every single communication channel needs to be changed.

  • Supports custom logic (transformation or user-defined functions) via Groovy scripts. Parsing XML with Groovy scripts is simpler compared to Java, for example implementing a DOM parser or the usage of GPath to traverse an XML document instead of XPath.

  • Comes with public pre-packaged integration content for many cloud-based integration scenarios. These content can be easily used just by copying them via the Web UI and configuring as necessary.

  • Rolling Software Updates on a monthly basis allows for latest features and bug-fixes to be automatically available in the tenant. In comparison, PI follows the quarterly NetWeaver SP release but each release needs to be installed manually and sometimes a system can be different from the latest SP version by a lot, thereby lacking the latest features and bug-fixes.


  • As mentioned in this blog post, the most frustrating aspect of working with HCI is the buggy development environment of the Integration Designer that causes corruption to the iFlow.

  • Due to the disparity between the features available on the Web UI and Eclipse's Integration Designer plugin, it is not possible to test message mapping locally in Eclipse. As a workaround we need to go through the elaborate process mentioned in HCI: Transferring Integration Package Content from WebUI to Eclipse and back if we want to use the test functionality in Web UI for message mappings developed in Eclipse.

  • The default editor for Groovy scripts does not have any syntax checking or highlighting. Even if the Groovy-Eclipse plugin is installed, the Groovy Editor only provides syntax highlighting for the scripts within an Integration Project. As such, compared to Java coding, we do not benefit from automatic syntax checking of the script during development time. This can lead to error during deployment or runtime. As an alternative, we can first test out the logic by creating the script under a Groovy Project in Eclipse. However, Groovy scripts require the following import statement "import;" but unlike PI, the JAR file for this is not available for download to be included in the class path.

  • Rudimentary functionality for XML to CSV (and vice versa) conversions as mentioned in HCI: XML to CSV conversion in HCI. I couldn't even get the CSV to XML converter to work successfully :sad: .

  • No proper deployment log that shows the status of iFlow deployment. Instead, we have to utilize the Tail Log and "hunt" for messages there to indicate whether there were any errors during deployment. In contrast, NWDS has a Deployment Log view that shows status for each deployed iFlow whether successful or not, with the option of viewing the related deployment trace.

  • Does not support as wide selection of adapters as compared to PI.

  • There seems to be no reprocessing functionality for asynchronous messages in error. As such, sender application needs to resend the messages but this is not always possible with certain applications.

  • There seems to be no alerting mechanism when a message fails processing. As such, this will require periodic proactive monitoring to check the logs in HCI.


Overall, I enjoyed the time evaluating HCI and IMHO it has a very good foundation conceptually and architecturally, and it shows a lot of promise.

However, I would also honestly say that it is still not a mature integration solution yet, both from a feature perspective as well as developer toolset. For those who are more familiar with PI development, expect some level of frustration dealing with some of the cryptic, non-descriptive errors found in HCI. Additionally, to overcome some of the limitations of the toolset or features, expect to figure out some workaround (for processes) or custom logic (for developments).

Saying that, I believe this is an area where SAP will continue to invest in, and I will definitely continue to keep an eye on it.

Labels in this area