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.

Installation

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.

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.

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 do 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 com.sap.gateway.ip.core.customdev.util.Message;” 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.

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

Conclusion

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, no-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.

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

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

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.

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.

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.

Thanks for your reply and pointed out the blog. I heard this service from Mr. Daniel Graversen’s post on LinkedIn. In this situation I would say on-premise integration will still be the main stream for a while from my point-of-view.