Every time I hear this song, I get chills down my spine. And not in the good way ;-). But let’s not talk about this song. Let’s talk about what I think are useful functionalities for Boomi to become even better. I want to split this post in three parts: development, administration and the engine. I begin with administration.
I work more than one and a half decade as a administrator/developer and used several integration solutions. Some enterprise solutions, some industrial solutions and even custom build ones. And most of these solutions are build with administration in mind.
I could reroute messages to a different location or endpoint without redeployments. This way I could send messages to other locations without altering the process at runtime.
I was able to resume processes from certain persistence points in the process when a subsystem was down or something else was wrong without rerunning every step.
All messages were easily visible and searchable in a dashboard. One of the main benefit of this dashboard was if a message did not run correctly, you can reprocess it, and if it ran successfully afterwards it would disappear from your dashboard. This way a system administrator would only see the messages that needed reprocessing like a "to do" list. I created a wishlist from most wanted to least wanted.
In the current dashboards, the processes that have an error stay in this dashboard, which can be handy. Add a new dashboard (Or filter) that only shows current processes in error. Successfully reprocessed processes should disappear from this dashboard.
Ability to reroute documents to different location/endpoint at runtime and without making the processes more complex with if/else and try/catch constructions. It could be achieved with adding an option in the connector/operation and let the process use it at runtime.
Make certain process steps persistent from where you can restart the process. Save the document to disk and let Boomi restart from that step using the persisted document.
Coming from a fullblown IDE, it can be a step backwards with the current way we develop in Boomi. And there are many idea’s on this forum about making the current IDE better. On of the main issues I ran into is that we are not able to import and export maps, profiles, processes etc. The ability to do this would make things much easier.
The next big thing is unit testing. I think it would be very useful to create real unit testing options which run everytime you save the process, just like the buildingprocess in a offline IDE. Maybe create extra shapes where we can define the unit test rules and add them to the canvas or something like that.
One other thing is that we can not work offline. Even in the always-online society we live in today, there are occasions or situation where you can not be online. It can become very costly if the internet connection is down and you have multiple developers waiting to be able to do something. More painfully is when you are giving a demo to a customer and the internet feed goes down. Then the customer would immediately see one of the most critical problems with cloud based development. No internet feed means no development. So here is my wishlist.
Make profiles, maps ,processes etc exportable.
We need real unittest abilities. To be able to see issues when you save(build) processes without deploying them and testing them, can make development easier and even quicker.
Make the IDE available offline.
The boomi Engine itself is very robust and quick, but I think it could be even better. One of the main issues I ran into is that the endpoint could not process the number of request I send to it. So we had to add parallel processing and tune the number of threads and batchsize. While this works great, it is not very flexible. In some of the enterprise integration platform I worked with, we had the ability to let the system throttle itself based on the responses of the endpoints. We defined these throttle rules in runtime and the system used these rules to alter the number of messages send to the subsystems so it would not bring the subsystems down. If the endpoint responded quickly it would send messages faster and in more threads. And if the endpoint slowed down, the number of messages send were reduced. On other thing what can be very useful is a way to alter business rules in runtime. Companies alter their business rules very often and at this point you have to alter the process and redeploy them. Or you have to create a custom solution where you get the current parameters from. But with the addition of a business rule administration tool, functional administrators can alter these parameters at runtime without redeployments or expensive custom solutions. My Wishlist.
Make parallel processing more intelligent and use throttling to dynamically alter the number of documents send to endpoints.
Build in a Business rule tool so we can alter business rules at runtime.
So here you have my Boomi Christmas Wishlist. I think all of my wishes can be useful additions to Boomi. Some of these are very situational like the business rules or throttling, but others are mandatory addons for me like the ability to see a “to do” list or an offline IDE capability. I created this list based on working with Boomi, wishes from customers and experience with other tools.
While Christmas is over, I hope some of these wishes are picked up in 2018 and make developing and administering a bit easier.
I hope that people would add more items to this wishlist