A comparative study on SAP CI and Boomi
The cloud is the most revered destination for most integrations at present. Today there is a rising demand for developers to support multiple projects as new languages, procedures and applications are introduced. Platforms now need to support many different use cases, like automation, customer service, web experience, e-commerce, data analysis as well as enterprise software development. One of the most interesting scenarios lies in data integration on the cloud. This blog will explore the features of SAP Cloud Integration (also known as SAP CPI/CI) and Boomi to help you ascertain which of them is more suitable for your business requirements. If we specifically consider ERP integrations, the task that looms big is connecting ERP software to other applications and data sources and synchronizing them. Usually, the expected end product is a single solution for the entire ERP spectrum, irrespective of where the data originates from.
Data is omnipresent and available in huge chunks like in a departmental store. To process this data, interpret and translate it into information is what drives business intelligence. So data visualization programming with low code has become a handy tool, for who would prefer tapping through spreadsheets, charts and maps instead? In Boomi as well as SAP Cloud Integration (referred to as SAP CI henceforth), ‘the single solution’ that we previously talked about, in integrations are packaged as a unit. These units are called Processes in Boomi and Iflows in SAP CI. These units access APIs or services in a hybrid landscape – public cloud & on-premise systems alike with the help of integration components that are represented on a visual canvas.
Extract in ETL – Connectors and Adaptors
These packaged units have to begin somewhere right? Since these solutions are aimed at performing ETL, let’s begin with the Extract layer. The first step to creating these processes and iFlows would be fetching data. This is done using connectors in Boomi terms and adaptors in SAP CI terms. Without any assistance from ETL tools naïve developer may attempt to seek different solutions to get the job done, but what about agility, scalability, maintainability? Boomi has a number of pre-built standard connectors to basically any application. For on-premise connectivity, SAP CI uses SAP Cloud Connector which is limited to only SAP CP products. Boomi on the other hand, has three types of connectors: Application connectors*(e.g., NetSuite, QuickBooks, etc.), Technology connectors (e.g., FTP, SFTP, mail, etc.) and Event-driven connectors(e.g. Amazon SQS, Google Pub Sub, etc.)*. Boomi also treats connectors as a component comprising of two parts: connection(the “what”) and operation(the “how”). So considering the landscape compatibility side of things, unlike Boomi, SAP CI is more limited to the SAP ecosystem which include S/4HANA, C/4HANA, SuccessFactors, Hybris, etc. However, considering the vast market share that these services occupy we would probably be lead to a debate for another day on whether this is a ‘limitation’ or not.
Transform in ETL – Shapes for data manipulation
In the Transform layer, a number of options are available on both platforms to perform data manipulation. Some shapes that are offered by SAP CI include content modifiers, splitters, content enrichers and so on. Boomi on the other hand has three types of shapes – Execute, Logic, Connect – which are used to again, perform some operation or task on the data that flows through the process. Each shape has multiple suitable shapes available to perform these operations. The data storage infrastructure has an inherent processing capability, so ETL in effect saves the time which data spends in transit. The use of Hadoop and cloud-native data lakes has in turn popularized use of the ETL process. By separating the loading and transformation tasks, the interdependency is minimized. The ETL process is adaptable and scalable across hosted services like iPaaS and SaaS, allowing capacity expansion at the touch of a button.
ERP integrations also mandate some complex mappings to be performed, so let’s explore that some more. SAP CI can only map XML data but Boomi can easily handle Non XML data as well, this saves a lot of development time when it comes to mapping to file based formats. In fact, Boomi supports 5 different types of these formats or in Boomi terms, profiles. These include flatfiles, XML profiles, JSON profiles, Database profiles and EDI profiles. To allow conversion logic to be applied to individual values, we make use of mapping functions. On Boomi mapping functions can be standard or user defined. SAP CI has a similar offering with comparatively lesser standard options available. SAP CI offers three types of mappings: (i) message mapping which is a graphical mapping tool to perform XML to XML transformations, (ii) XSLT mapping which uses templates to convert the source structure into the specific target structure, (iii) operation mapping which encapsulates the used mapping program (either defined graphically by a message mapping or contained in an imported archive). However, for both middlewares, the sky is the limit when there exists a need to customize the mapping functions since both allow incorporating scripts! Additionally, Boomi also offers Boomi Suggest community driven suggestion wizard for integration that can offers auto-generated mappings.
Branches and decision pathways
Having multiple paths and decision shapes are an important requirement of data flow diagrams. What a router would do in SAP CI is the same as what a decision shape would do on Boomi which is to take different pathways on satisfying a condition. For passing down a document down multiple branches, a sequential multicast on SAP CI executes all branches simultaneously and a branch on Boomi offers the same functionality.
SAP CI also offers some amount of encryption and decryption (using PKG or PKCS7) to be performed when we look at the security offerings. For encryption in Boomi, you can make use of the program command shape and make use of disk shapes and .bat files for command line based encryption. By default, Boomi uses CAST5 encryption with the help of a data process shape.
Load in ETL
For loading data, the newly transformed data is supposed to be sent to a new destination. The connectors and adaptors that are responsible for bringing in inbound data can similarly also be used for outbound data. The destination(s) can be an application or a data source such as disk, mail, HTTP, FTP, SFTP, or database. Both Boomi and SAP CI support these outbound connections.
Deploying, Monitoring and Managing
Coming to the Load layer, we deal with deploying our packaged units and managing them. If we specifically look at the runtime management by these platforms, SAP CI’s architecture is divided into two integration nodes – Tenant Management Node and Runtime Node. The former manages the Runtime Nodes and also reads the monitoring Data written by latter. It has the Java Virtual Machine(JVM) which is where our iflows run. Boomi has three different runtime engines – Atom, Molecule and Atom Cloud – each suitable for different integration scenarios be it on-premise, cloud or hybrid. For on-prem to on-prem integrations, Atom or Molecule could be used. For on-premise/cloud hybrid integrations as well Atom or Molecule could be used. In addition to these two runtime engines, Atom Cloud could also be used for pure cloud-based integrations. If we look at the monitoring side of things, Boomi has a distributed architecture with centralized monitoring and managing that also includes a section for process reporting. SAP CI has a monitor tab as well where you can monitor message processing across iFlows and also manage stores, security and integration content.
Looking at reusability and accessibility, Boomi has the upper hand as the concept of reusability is practiced throughout the platform. Be it reusing components, process, subprocess, or anything else. Boomi best practices in maintaining the file and folder structure in Boomi attests to this concept as well. SAP CI does provide some amount of referencing and using infrastructure as a code but this is limited to only some shapes such as scripts that could be referenced multiple times. When accessing data and performing cross reference lookups, Boomi offers cross reference tables that could be used as a component. Although SAP CI has no such existing components, there is nothing that is impossible when using a the right data structures in a script that could be incorporated in our iFlow to offer the same functionality of a cross reference lookup. Both Boomi and SAP CI offer some modularity in breaking down concepts into independent reusable components known as subprocesses in Boomi and process and calls in SAP CI.
Looking at licensing for both the platforms, when purchasing a license for specific services with defined server capacity on SAP CI you get access to a sub account. Different sub accounts for DEV, QA and PROD are required to be created. Remember how we discussed Boomi providing special emphasis on reusability? Boomi goes an extra mile just to ensure this using their licensing policy where all connections are actually licensed, thereby incentivizing efficient usage of components.
In SAP CI, each version of the iFlow needs to be explicitly saved as a version as per the developer’s needs. Boomi on the other hand has a different version stored every time a change is made to a process. This creates a number of different versions of which not all may be useful.
The UI on Boomi is smooth, the components are well illustrated and self explanatory and developer experience is pleasant. When making use of a canvas, the drag and drop functionality is like the holy grail of building integrations. SAP CI has some glitches and lags in this sphere and it may not offer multiple people to collaborate at the same time giving Boomi the upper hand in building processes real-time. However, with SAP CI frequently rolling out its updates, it has been noticed that some session caching is offered where unsaved data can be recovered in SAP CI when working on iFlows.
SAP CI is the hot destination when you want to integrate different systems through the cloud. Whether it is systems, services, data, developer, AI or IoT, the SAP Cloud Platform Integration seamlessly merges all processes end-to-end, irrespective of whether the application is cloud-based or on-premise. It provides a set of tools and applications that help you do anything: development and deployment, packaging and publishing, accessing and editing the integration content, both from SAP and third-party providers. This is possible through Open Connectors available in the SAP Cloud Platform Integration Suite, which are very good for integrating third-party systems, with different applications and technologies, with SAP systems via open standards. This means that data exchange among different products or services are freely possible or ‘interoperable’ so that they can be adopted widely across the enterprise spectrum. As SAP components (ABAP or ABAP Objects) become interoperable with other components (Java, C++, Visual Basic, .NET), it is inviting anybody and everybody to use them. In addition there are the Special connectors, which have appropriately automated the authentication process and also added consumption of some resuscitative API services, in its repertoire. Some of the big time connections include SalesForce Cloud, MS Dynamics CRM, Twitter and Facebook.
So finally how can SAP CI transform you? Well you can say that you have the best business content, in the shortest possible time, connected real time without any physical storage onsite and your LOBs perfectly safe on the cloud! Can it get any better?
Some more similarities
When viewing published copies and versions of integration flows SAP CI has the Design tab and Boomi has the Process Library. If you want to test your packaged unit without deploying, both platforms offer modes that gives you a mini testing opportunity on your canvas too. This is called test mode is Boomi and simulation in SAP CI. Storing data temporarily can be done in both platforms as well. Boomi has shapes such as Add to Cache, Retrieve from cache, etc. to perform document cache lookups. SAP CI has also provides the same functionality using its temporary storage location known as datastore.
Summarizing key features..
|Application connectors/adaptors||Technical protocols used for connecting the tenant are made using sender and receiver adaptors.||Pre-built standard connectors accessible using the Connect shape.|
|Data formats||Can use XML as well as Non-XML data varying across available shapes.||Supports 5 different forms of data profiles.|
|Data transformation and mapping||Mapping can done using scripts or using the mapping function that help with filtering, providing 1:1 mapping as well as custom mapping.||Uses mapping function that supports cross lookup tables, different profiles, mapping functions.|
|Routing and orchestration||Multiple routing shapes available that provide for different types of joins and branches.||Decision shape and branch shape offer a number of conditional routes to be followed when processing data.|
|Licensing||SAP CI has licenses based on the number of iFlows deployed and resources that are being used.||Boomi licensing is based on the number of connections being used.|
|Deployment||iFlows can be deployed on the tenant using a single button.||The deployment environment needs to be selected before deploying a process.|
|Monitoring||Different logs and artifacts can be monitored and managed at all points of an integration iFlow.||Process reporting is one way of checking at logs of a deployed process. Atom availability and general health can also be monitored.|
The whole SAP ecosystem is a like a fair; so many business processes are happening simultaneously. And they have readymade functionality for each one of them. This means that the tailoring required for each customer is so minimalistic and virtual on the cloud, that it is almost a made-from-scratch business process closely catering to his specific needs. The domain we are looking at is quickly addressed, and the content here is so vast, that solutions to specific issues come at the drop of a hat. With businesses functioning on the SAP environment, SAP CI helps with keeping all-things-SAP.
There are multiple integration helpers and functionalities available on both SAP CI and Boomi. Boomi has been a leader in the field for a very long time. Boomi may be a mite better in its UI for integration design-time environment but SAP has also improved significantly in its present version compared to the older (pre-2018) SAP CI. Boomi’s drag and drop method of working with components into a process is easier and beginner friendly than SAP CI’s click-to-point-click method. However, SAP CI can also be more developer friendly for those coming from a coding background. Either way, both platforms are very powerful and can do wonders to your integration lifecycle scenarios.
Let me know your thoughts and feedback in the comments below. To view the full version of the article, see here : https://integrtr.com/a-comparative-study-on-sap-ci-and-dell-boomi/
Indeed blog on both the platforms - SAP CI and Dell Boomi. It's informative. Thanks for sharing.
Great article. Full disclosure: I work for Boomi. BTW, it would be great if you could modify the article to remove 'Dell' since Boomi is now an independent company as of October of 2021.
It seems like you have to code in SAP CI for a number of functions. 95% of the time, I don't have to write any code to complete even a non-trivia process in Boomi. Therefore, would you agree that Boomi is low code and SAP CI isn't so much? To quote you from above:
"However, SAP CI can also be more developer friendly for those coming from a coding background."
Lastly, WRT integrating with SAP, Boomi has a very innovative solution that enables SAP Business Analysts to get and send any data in and out of SAP in a codeless, configuration based graphical environment. Check it out:
Access and Unlock Data With Boomi aXis for SAP
If you would like to contact me, email me at email@example.com