Hana Cloud Integration in comparison to Dell’s Boomi.

As we all know HCI is not the only middleware solution that is out there and if you are working in the integration scene, names as JitterBit, MuleSoft, BizTalk and Boomi are probably not unfamiliar to you. That last one, Boomi, is specifically for all the SuccessFactors Employee Central users and integration partners. Until a month ago, when purchasing an SAP SFSF enterprise package, the middleware software that came with that package was Boomi. Now it is also possible to go for a SAP SFSF enterprise package with…..HANA CLOUD INTEGRATION.

Because this option is relatively new, there are still a lot of SFSF customers who are working with Dell Boomi. Therefore I want to compare some options in Dell Boomi to Hana Cloud Integration. I’m going to make a simple integration flow in HCI and Boomi and show you my results. The iFlow will contain an inbound connector (SuccessFactors), a simple mapping, an XML to CSV converter and an outbound connection (email).
Because the HCI web UI is not fully developed yet (e.g. there is no possibility to start a new iFlow from scratch) I’ll be using Eclipse for the HCI part. For Boomi I will be using the web environment (https://platform.boomi.com)

Inbound connector

In HCI, you create an inbound connector and a connection to the start shape. On the connector itself you can adjust the authentication details. On the connection you see two sections; ‘Connection details’ and ‘Processing details’. These are quite self-explanatory: one section is to determine where the inbound connector has to go, and the other section tells it what to do over there.
You also have the opportunity to schedule you’re flow here.

As you can see in the pictures, in Boomi there’s one place where you enter the authentication, the connection details, and the operation details (called process details in HCI).
A big difference between HCI and Boomi is the way these connectors are saved. In HCI, you create a project, in which your iFlow is stored. In the iFlow you’ll find the different connectors that have been used. In Boomi, there’s one big project where all your iFlows and connectors are saved. That means, for example, that you create one SuccessFactors connection which you can use in all your iFlows, even those that have not yet been created. That also applies to the operation details. So it’s possible to use the same SuccessFactors connector in two iFlows, but create different operations.

Mapping

The mapping in Boomi and HCI are quite similar. It’s possible to drag a value from your import directly to your desired output, or you can change the data by using different kind of functions. For example, if the date format from your input does not match with the desired output it’s possible to use a TransformDate function.

In Boomi the mapping looks like this:

Combine and/or convert

Now we come to the part where Boomi and HCI show some difference. When looking at HCI, we see that the requested data rows from SuccessFactors are treated as one document. Within HCI all records (data rows) will automatically be combined into one document. This is not the case with Boomi. Every single row (record) is treated as one document, which can be sent out individually. Normally, you’d want to have one file (.csv) containing all the rows (records) so it’s necessary to combine the documents (each containing one data row) to one document.
On the other hand, in HCI the data is processed as xml. We need to convert this data to .csv if that is the output we want. In Boomi, we just need to indicate that the output should be a .csv file and don’t need to adjust or transform any data. Let’s see how that looks like in HCI:

And in Boomi, we do not convert but we must combine:

Another difference is naming the resulting document. In HCI the document is named in the connector which is being used (e.g. the mail adapter, which we will discuss in the next chapter). In Boomi, the name of the document must be set as a property before setting the outbound connector.

Outbound connector

The outbound connector is set up in the same way as the inbound connector. In HCI you need to create a connector and a connection, and in Boomi you need to create a connector and an operation.

Wrap-up

When you deploy and run these simple iFlows in both systems you get the following result:

As shown, Boomi takes up to more than a minute to run this flow. It has read 668 documents (read: rows of data) out of SuccessFactors, and has sent one .csv file out.
HCI doesn’t display the amount of documents in or out, and only takes 16 seconds to complete. Off course this is just one simple test, but I think the speed difference is remarkable.
There are two things that I would love to see in HCI in the near future. In Boomi you have the possibility to “test” the iFlow before actually deploying it to your atom. If your iFlow request to much data it will only take the first 10 documents and run the iFlow as if it is was deployed. In HCI you have to deploy the whole iFlow to your tenant and run it to see if the changes you have made were successful.
The second thing is the way Boomi handles multiple accounts. I now have one email address to login and from there I can service all my customers. This saves me a lot of time and I’m very curious in wat way HCI is going to develop in this matter.
The thing I like a lot in HCI is the trace functionality. Your iFlow becomes decorated with envelopes where you can see the data that is going through. In Boomi the trace function is much more standard and you cannot see directly what data is going through the different steps.

As explained there are some differences between Boomi and HCI, but definitely also a lot of similarities between these programs. For now, the community behind Boomi is a lot bigger, but I’m sure HCI will continue to develop more and more standard packaged integrations and become more standard within the SuccessFactors EC community.