Low code integration platforms like WSO2 and Boomi have captured attention as some of the best low code platforms for connecting applications and systems, even without deep technical knowledge. The promise of low-code integration, especially through platforms known as LCDPs (Low Code Development Platforms) and NCDPs (No Code Development Platforms), suggests a world where business users can achieve integration without IT’s involvement. But how realistic is this vision? In this blog, we explore the technology behind low-code platforms such as WSO2 and Boomi, and we analyse what these integration platforms truly offer. Are they genuinely low-code, or is the reality more nuanced?
What does Low Code Integration mean?
But what does it mean if a platform could be considered Low Code or No Code? It is always good to look at the definitions that you find online. When I conducted my search, I was bit concerned that I would find as many definitions as there are vendors that sell a product that is said to be Low Code or No Code.
Each of them of course highlighting the things that their product is good at and not so much mentioning the stuff that it is not so good. However, I was wrong, which is always good to acknowledge.
When I look for what is Low Code the answer that I liked best, is the one found on Wikipedia (slightly modified):
A low-code development platform (LCDP) offers an environment to create application software, typically through a graphical user interface
What this means is, that to develop an integration (because we talk about integration mostly) is that you have a graphical user interface with drag and drop and you use that method to create a high-level process flow and fill in the details by configuration. There might be multiple processes and artifacts deployed to the platform running side by side. The deployment happens on the runtime component of the platform.
For example, you can retrieve information from a database and process all retrieved records.
Funny enough, when you look for the definition of No Code, Wikipedia offers you this nugget of wisdom:
No-code development platforms (NCDPs) allow creating application software through graphical user interfaces …
No-code platforms are closely related to low-code platforms, but unlike low-code, they require no code writing at all and generally offer prebuilt templates for businesses to build apps.
The distinction between Low Code and No Code might be that No code platforms do not offer any way that you (through scripting or custom libraries) extend the functionality or do additional things not offered by the platform. That does not mean the vendor cannot extend the functionality, it means you cannot go beyond what you can configure.
WSO2 and Boomi: defining Low Code Integration
Are we any wiser at this point? To some extent yes. The fact that there is a graphical interface is a key element on these platforms. If you were to compare the creation of an integration with Lego blocks, the graphical overview lines them up in the order that you would like to process. In LEGO of course joining together two bricks is quite simple: you just snap them together and you are done.
However, building and integration does require some form of configuration.
Because you need to define what endpoint you want to call, and possibly filtering out the information that you need for the next service. What happens when you have an error, how do you handle that?
So Low Code and No Code both have properties or configurations / templates that you need to fill in. I would say: the what, the why and the how.
Without possibility to configure these parameters the platform would be extremely limited in this operation and worthless. And configuration is not trivial, especially when you have a more complex integration with several systems involved and message mediation and transformation taking place.
In this WSO2 example, we make a call to a Spotify API. The call mediator (building block) has an HTTP address with security configured in the properties of the address. This step is needed because we need to provide the address but also configure the security.
In Boomi it looks pretty much the same, an HTTP client shape that needs configuration.
So, the difference is quite small, which is logical since both WSO2, and Boomi are integration Platforms. Configuration is the way to fill in the details of the high-level building blocks. These are very simple examples, and do not handle any error situations, from an endpoint not being available to empty responses.
We can actually show more examples of integration and in general the way the flow and configuration takes place is more or less the same. Some differences: Boomi calls messages flowing through the systems ‘documents’, WSO2 refers to it as a payload.
Boomi is a bit more focused on graphical configuration, for instance selecting fields from a profile, whereas WSO2 allows developers to directly input XPATH or JSONPath code. WSO2 also lets you view and manipulate the associated XML representation of the integration model allowing quick changes. Boomi does allow viewing of the source XML, but it can only be changed using the Boomi GUI. In general, WSO2 is more open, with free choice of IDE or XML editor, and the WSO2 Integration Studio GUI as a powerful option.
Low Code vs. No Code Integration
But why is it not No Code? We have not coded anything until now, just configured things. Well, both Boomi and WSO2 can be extended with scripting, custom connectors, and custom jar files. However, this should always be done with caution and only if necessary. By this I mean that you should consider if the functionality you would like to add is something that is in line with the functionality of the platform. In most cases scripting is done to manipulate some values or payloads. A custom piece of Java code is really an exception and so it should be.
You should consider these platforms as engines of orchestration. The comparison can be made with a conductor of an orchestra. The role of the conductor is to indicate and guide musicians to play their part, not so much playing themselves.
A No Code platform cannot be extended beyond the functionality by the developer. It can be configured but additional functionality cannot be added.
If we look at differences between Boomi and WSO2, we can also see them. I am not talking about the use of different graphics, but more on the way that we do configuration and run.
Configuration in Low Code Integration Platforms
As you can see both have a graphical interface. However, WSO2 uses Integration Studio, an add-on to the well-known Eclipse IDE that can run locally whereas Boomi uses a browser-based interface to the Boomi platform where the configuration is done.
Experienced WSO2 developers might just use an XML editor in order to write an integration. Boomi does allow in and export of, for instance, a Process into the environment, but this is not common to use.
Installation and deployment
WSO2 can run locally on your PC (Windows or Linux) or on a Mac, on a server, in the cloud or in a container. It can be run as a platform as a service or completely managed by your organization.
Prerequisites are the right version of Java and minimal configuration as far as some environment settings are concerned. Boomi runtimes also runs locally on Linux ,Windows or a container, of course, as a service in the Boomi cloud. The Boomi GUI runs always on Boomi AtomSphere.
When you look at the way artifacts are deployed, automation is key in the case of WSO2. A CI/CD pipeline tying in a repository allows more control over the deployment and reduces the chance of human error.
Boomi’s way of deployment is via the platform and a CI/CD setup is possible however not common.
In a nutshell, this is the overview of Boomi and WSO2.
| Topic | WSO2 Micro Integrator | Boomi Integration |
| Developing Integrations | Integration Studio based on Eclipse running locally | Boomi hosted Atomsphere platform, browser based |
| Code repository | Many options (GitHub, BitBucket, Visual SourceSafe, Subversion) | Built in, possible use of repository |
| Deployment of runtimes | On premise, in the cloud | On premise, in the cloud |
| Testing & Debugging | Integration Studio (step by step), external tooling | Boomi Atomsphere (step by step), external tooling |
| Able to extend | Scripting, custom java code, connectors | Scripting, custom java code, connectors |
| Logging | Log monitoring like ELK, Splunk | Logging on the platform and ELK / Splunk |
| Automated deployment | Use tooling to create CI / CD Pipeline | Deployment is done from the platform, CI / CD not very common |
| Open Source | Yes, product support advised | No |
| Customization of settings and parameters | Yes, through deployment.toml (e.g., url for exposed services) | Limited |
| Platform Updates | Choice and schedule of the client | Automated (cannot postpone) |
| Dependencies on external sources | None | Boomi Platform / Hosted Atoms |
| Additional products | IAM, API-Management, Stream Processor, MI Dashboard, MI Controller, ELK-based Analytics | API Management, Master Data Hub Management, Flow, Event Streams |
Conclusion: Low Code Integration Platforms today
Both Boomi and WSO2 are excellent choices for enterprise integration platforms. Both are Low Code platforms that allow you to develop integrations quickly and easily. WSO2 is more of a developer’s environment where some configuration can be done outside of config screens and deployment is automated using CI/CD. Boomi’s way of configuration with the structure and screens is liked by less technical people.
The open-source nature of WSO2 makes less difference than you think. Yes, there is an Open-Source version of WSO2 and not of Boomi, but client organizations typically have a product support contract for the production implementation in order to minimize risk and disturbances by providing patches for bugs and vulnerabilities. You simply want the platform to be as up to date as possible!
Until now we have not discussed the licensing and the cost.
Boomi and WSO2 have different models. Boomi typically per connector / number of connectors and WSO2 per core. Does that make a difference, yes it does but it is part of the bigger picture that we address in the final paragraph.
What is the best low code platform for our organization?
With this blog we have given insight into two top integration platforms that will allow you to integrate systems and services. Can we answer what the best platform for your organization is?
Not without hearing from you! There are many variables: size, budget, number and type of integrations, staff & capabilities, your IT vision, and IT roadmap to name a few, that we need to consider in order to advise you when you have questions or would like to discuss your unique situation, reach out to us!
