Skip to Content
Technical Articles

From PI to HCI: My one month adventure with HANA Cloud Integration


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 Paul Todd. 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


Likes ➕

  • 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.

Dislikes ➖

  • 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 🙁 .
  • 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.

You must be Logged on to comment or reply to a post.
  • Hello Eng Swee,


    Nicely documented the pain points and plus points.!


    For Error Handling/Alert Mechanism you can use "Exception Sub process" and customization of the same requires more effort.


    I agree on point that Alert Mechanism is not at comparable with SAP PI.



    Sriprasad Shivaram Bhat

    • Hi Eng,


      i had query in Hana Cloud Integration . we are having two options for to integrate the data as follows

      1. Hana Cloud Integration for Pi

      2. Hana Cloud Integration for Data Services


      Here My query is when we have to Go for Pi and when we have to For Data Services?


      As of my Understanding if it is a migrating project from pi to HCI then we can go for this.Please correct me if i am wrong.


      Apart from this is there any Other reason to choose Hci or Data Services?


      Could you please explain.





  • Hi Eng,


    You already mention that some functionality is missing in the WebUI.

    I think this is especially true for the mapping part.

    In the WebUI we noticed that there (so far) are no options for things like:

    - changing contexts

    - duplicating subtrees

    - displaying queues




  • Hi Eng,


    Excellent summary. Totally reflects most of the points i experienced from the trial too.

    Anyway i have to say Sujit & co were very responsive on any error we reported and i saw a few things fixed pretty quick (with next release, which happens every month and is a total plus in the subscription model).


    Some points i would mention also:

    • Building adapters with the HCI sdk in my opinion is more simple then with the PI adapter framework as it's (with some restrictions on metadata) mainly Camel components.
    • Some errors are more clear if you're familiar with the Camel framework and how it works, i also wish SAP could improve some parts of the documentation about error handling and what properties/headers etc actually are plus their lifecycles through an Iflow. It's familiar to me as i used Camel before but not to most people coming from PI. Also it's only just a feature subset of Camel thow.
    • Asynchronous message handling in Camel works different. Camel therefore normally relies on a message queue (e.g. like ActiveMQ or RabbitMQ) to guarantee the reliability. In case of an error the message is not taken from that queue and could be reprocessed by the flow automatically or manually. The Camel flow (and thereby the Iflow itself) in most cases is stateless. This is a huge difference to a PI Iflow that has an own message queue. Will be interesting if SAP will complement this with the long rumored Solace partnership for the Hana cloud . So far as you rightly stated reliability /retry is mostly on the sender side, which is ok e.g. for some simple IDOC-SOAP->HCI Cloud transfers where the IDOC runtime can retry in case of an error in the Iflow but not much further.


    About the alerting i saw SAP had some alerting functionality documented for Solution manager for HCI, but didn't see it at work and it sounds not as feature rich like PO's message based alerting.

    Summed up i agree with you that at the time of now it's not a full fledged plattform and some features PI/PO users are used to are working conceptional different in HCI/Camel.

    Looking forward how HCI is evolving especially as it's now included into PO 7.5




    • Hi Sebastian


      Thanks for your comment as well as the additional points. Good to hear some viewpoints from someone who is familiar with Camel.


      Yeah, I'm not familiar with Camel (as well as most who are from PI background) so it takes a bit of getting used to.

      Looking forward how HCI is evolving especially as it's now included into PO 7.5

      What do you mean it's now included in PO 7.5?



      Eng Swee

      • Hi Eng,

        SAP included the HCI runtime on the new release of PO 7.5.

        E.g. take a look here:


        Afaik you could run now most of the bundled Content Scenarios (e.g. SAP ERP <-> Successfactors) also directly on your PO box by that.


        Strangely it seems to be only present in the HCI docs not in the PO docs? At least i couldn't directly find anything on that there.


        With best regards


        • In PO 750 there is an additional option available Cloud Integration in the home page however if i am not wrong i think that is only to access the SAP HCI content.




        • Hi Sebastian


          Thanks for bringing this up. I read up more on this and found that it was mentioned in the following blog too.

          What’s new in SAP Process Orchestration 7.5 SP00


          However, I don't think it's a case of HCI's runtime being included in PO 7.5.


          From what I read, it looks like it just allows you to design integration content for PO 7.5 with HCI's Web UI. When designing with the Web UI, a particular product profile needs to be selected which determines whether the target runtime is HCI or PO. Once the profile is selected, the Web UI imposes restrictions on the design based on the target runtime.


          Sounds like it's just a cloud alternative to the current Swing or NWDS design environment. The drawbacks of this would be:-

          i) You would need an HCP platform that hosts the HCI Web UI

          ii) I personally feel the Web UI environment is not fully mature yet (but of course that would change) plus I really enjoyed working in the Eclipse-environment



          Eng Swee

          • Hi Eng,


            Yes it's a subset of the complete HCI and i see the same limitations you mentioned.

            So far to me it looks also just as "first step" as you mentioned only the Web UI is usable and that in a restricted way.

            However execution of the iflows (only SAP contents by now) will then happen on your on premise PO as far as i understood by that. That's what i meant by "runtime included" on PO.


            With best regards


          • Hi Sebastian


            Do you still have access to the HCI tenant? If you do, would you be able to try out the WebUI and see what the restrictions are when you choose PO 7.5 as the product profile (i.e. target runtime)?


            Would be interesting to know when PO 7.5 is selected as the product profile:-

            i) Is it possible to design the iFlow with steps that differ from the order of fixed PI pipeline (i.e. receiver determination, interface determination, mapping)

            ii) Is it possible to include Groovy scripts in the iFlow?



            Eng Swee

          • Hi Eng,


            I still have Access, however till now i couldn't activate the settings to choose PO 7.5. It might be not enabled for the tenant. will update you if i manage to get it.


            About your questions above, not sure at what time you had access, but the WebUI had some improvements, you could edit/use Groovy/Javascripts scripts in the WebUI now & arrange the iFlow like in the Eclipse Editor for HCI.

            However anyway about usability of that feature in the WebUI i would say it's one thing to "type" into a script there and another thing to test it really like we could do in Eclipse

            Honestly i didn't use the WebUI much, in most cases Eclipse is still more convenient.




          • Hi Sebastian


            Yes, when I tried WebUI, I could edit Groovy Scripts and arrange the iFlows, but it was always for HCI as the product profile.


            I'm curious to know if PO 7.5 is chosen as the product profile, will it allow that as well?



            Eng Swee

          • Hi Sebastian


            I happened to stumble upon the following and it looks like indeed a lot of the functionality/component in HCI is supported for deployment into PO.

            Supported Components, Adapters, and Events - Advanced Adapter Engine - SAP Library


            If you read further the related materials there, it does seem like my previous assumption is incorrect. It does look like there is an "HCI runtime" (with Data Store, Message Processing logs, etc) included in the PO 7.5 system and it can be monitored via NWA instead of PIMON.


            Pretty interesting stuff



            Eng Swee

          • Hi Eng,


            Yes right, so far that's what i understood from it too


            Well we are spoiled for choice then what iflow runtime to use 


            P.s.: Didn't have time yet to look into Deplyoment mode on PO, but i guess that answers the question




  • Did anyone find a way to resolve the issue with Groovy scripts needing the import and it not being available for download?

    The lack of syntax checking and code completion assistance is quite a drawback. Does anyone have ideas how to get around this?

  • Hi Eng Swee,

    Thanks for sharing this blog even it's already one and half years ago.

    From development perspective, it's very clear for us. But how about maintenance, do you know or read any information about how SAP is updating/maintain adapters or functions for HCI?

    I read your most recent blog (Chronicles of a PI TLS 1.2 upgrade) talking about how frustrate you went through regarding upgrade TLS stuff. Imagine now SAP can patch HCI at anytime to whether fix bugs or add new functions, but in many situations our clients just want integration server to be as stable as possible. Let's assume If one day SAP updated TLS stuff in HCI, would it be by any chance to break some clients' integration flows on HCI? Because HCI is connecting with many other systems that SAP may not be aware or know.

    Looking forward to seeing your feedback. Thanks.


    Kind regards,



  • Hi Eng Swee,

    Excellent article!  Wondering if you can do a follow up BLOG - to show if any of the points that you have in your dislikes section has since been addressed by SAP with the newer HCI deployments.

    It would be nice if there was a way to test the Groovy scripts developed in the flow from the Eclipse Groovy plug in if SAP could provide the necessary jars.