Another Way to Route?
The June 2016 Release contains the next iteration of the exciting new "Tech Preview" feature called Process Route. The Process Route shape acts like a cross between a Route shape and a Process Call shape. The documents which flow into the new shape are routed dynamically based on a key (similar to the Route shape) where each route is a sub-process invocation (like the Process Call shape). We already have the Route shape, so why introduce a new way to route documents in a process? Well, the Process Route shape introduces a few key new features that open up a wide range of exciting possibilities when building Boomi processes. Specifically:
- The Process Route shape does not draw the routes on the process canvas
- Each "route" invoked by the Process Route shape is a sub-process which is deployed independently of the calling process
While these differences may not seem like too much at first glance, their implications are quite significant. Let's dig a little deeper.
Look Ma, No Lines!
While this may seem like a silly feature to tout, not drawing lines on the process canvas is an important aspect of Process Routes. Let's take a simple example where:
- We want to route documents down one of two possible paths
- We want to encapsulate the logic in each path in a separate sub-process
- Each route could have two possible outputs which we want to join together for the final output from the example.
The image below shows this example as a sub-process which could be built in AtomSphere today using the normal Route shape.
For a "simple" example, we end up with two route lines, followed by four result lines (the labels are overlaid, there are two lines coming out of each route sub-process). Now, imagine that we are using the route functionality to implement per-trading partner B2B functionality where each of 100 partners needs their own route sub-process. Using a normal Route shape with 10-20 routes can become very difficult to manage on the process canvas, let alone 100 route paths followed by 200 output lines!
Using the new Process Route shape, all of these lines go away. Almost everything shown in example above will be handled by the configuration of the Process Route Component. This allows the new routing functionality to scale up to hundreds, if not thousands of possible routes.
You may notice that I initially described the routing as "dynamic", what makes it so dynamic? Well, there are two reasons actually. The first is that while the Process Route shape and Process Call shape both invoke sub-processes, the sub-processes which the Process Route shape invokes are chosen dynamically at runtime. Secondly, and possibly even more importantly, the sub-processes which are invoked by the Process Route shape are actually deployed separately from the invoking process. In other words, the calling process may invoke sub-processes of which it had no knowledge at build time.
Your first thought may be about how complicated this is all starting to sound. In fact, using Process Routes is more complicated that simple Routes and Process Calls, but that added complexity buys some quite powerful functionality. Thinking back to the per-trading partner routing mentioned in the previous section, imagine a back-end B2B process which does some secondary handling of incoming documents. The documents may have been initially delivered via a variety of mechanisms to a common staging area. This secondary process now needs to grab a bunch of documents (from potentially multiple trading partners) from the staging area, convert them to a common format, and push them into an internal database. All of the logic for grabbing the documents and pushing the common format into the database can be encapsulated in a single, top-level Boomi process.
Once this top-level process is tested and deployed, it no longer needs to be touched when new trading partners are added to the system. Meanwhile, all the logic for doing the per-trading partner conversions can be delegated to the routes configured in the "Convert Document" Process Route Component (example below).
On-boarding a new trading partner is as simple as:
- Building the conversion sub-process
- Adding it as another route to this Process Route Component
- Deploying the updated Process Route Component and the new sub-process
Once these are deployed, the top-level process (which we did not have to touch) will start using them immediately. How's that for dynamic?
Additionally, narrowing the deployment process to just the Process Route Component and the new conversion sub-process can have a huge impact on time to production. Some companies have very stringent change management procedures, possibly requiring (re)testing of anything that is modified. Reducing the modifications to just the functionality which is actually changing could significantly reduce the amount of red-tape that must be waded through to get that new trading partner up and running.
Let's Go Exploring!
As I've shown above, the Process Route feature is clearly a big win for trading partner type functionality. Along similar lines, customers have mentioned use cases such as choosing an Atom Queue destination at runtime on a per-document basis and sending data to one of many endpoints which may each require separate credentials. All of these leverage the fact that the Process Route was built for easily managing a large number of routes.
Oddly enough, another possible use case may only have one process route, instead exploiting the deployment independence of the route sub-process. There may be an important bit of functionality in one sub-process which is used by many other processes, e.g. common error handling, logging, or pre/post processing logic. Today, if that sub-process is modified, all the calling processes must be redeployed. If each of those processes invoked this important sub-process using a Process Route shape, the deployment independence feature allows all of those processes to be updated by simply re-deploying the single sub-process.
So take the new Process Route shape for a spin and see how you can streamline your process configuration. Feel free to share your experiences below!
To learn more and step-by-step instructions on building processes with Process Route, see Tutorial: How to use the Process Route shape and component.
As of June 2016, Process Route is an optional feature currently available as a “Tech Preview” and is not intended for production use. If you would like to have this feature enabled in your account, contact your Dell Boomi representative.
James Ahlborn is the chief software architect for the AtomSphere platform. He has led major product designs since 2008 including Molecule/Private Cloud clustering, Connector SDK, Shared Web Server, Parallel Processing, and Atom Queues to name but a few.