Over the last few months we’ve been actively building and releasing new Anypoint Templates. Anypoint Templates are designed to make it easier and faster to go from a blank canvas to a production application.They’re bit for bit Mule applications requiring only Anypoint Studio to build and design, and are deployable both on-premises and in the cloud.
Anypoint Templates are based on five common data integration patterns and can be customized and extended to fit your integration needs. So even if your use case involves different endpoints or connectors than those included in the template, they still offer a great starting point.
Where do Anypoint Templates fit?
Here is where templates fit into our stack of solutions:
As stated earlier, each template is based on a data integration pattern:
- Migration
- Broadcast
- Bi-directional Sync
- Correlation
- Aggregation
In general, each integration has the intention of performing one of these base integration patterns of data movement. If you haven’t already, be sure to check out the full blog series on these base patterns as well as our “Top 5 Salesforce Integration Patterns” whitepaper.
A template is a base data integration pattern applied to a specific business value. For example, a common use case that we have templatized is the desire to synchronize materials in SAP to your products in Salesforce. For this, we created an SAP to Salesforce Product Broadcast template.
Almost Perfect
You’ll notice that all of our templates follow a convention of: System1 to System2, Object to Object, Pattern. However, the nature of the integration space makes it so that these templates will never satisfy the use case with a 100% match. From our experience, in the cases where the template is “exact,” the user will still need to spend a few days to customize and configure it. This involves things like adding custom fields, configuring outbound notifications or events, adjusting the mapping, modifying queries, etc…. We try to make our templates as specific to a business need as possible so that our customers have to do the least amount of work, but still have the flexibility to customize as they need.
The best way to imagine our templates is the following:
Another nuance that we had to account for when developing these templates was how they fit into the “orchestration of integration.” What I mean by that is, in order to become a connected company, you can’t simply create 500+ independent integrations. There is a maturity model to the architecture of integration. However, what we tend to see is that most customers new to integration have done what is commonly referred to as “point to point” integration.
The Point-to-point Dilemma
Point to point looks like this: a project is needed yesterday, and the fastest way to do that is to write a simple application, which we will run on one of our servers that pulls data from and pushes data into two applications. This application is usually invisible, undiscoverable, and in many cases not known about at all. This means that when another person or team goes to integrate with one of the systems, they may not know about the previous integration, about what it does, and how it behaves. These are the most dangerous integrations because they create a sense of paranoia about making any changes because even the slightest change can break connections. This leads to a very slow moving organization with heavy administration rules and procedures. A lot of the time, your integration ecosystems ends up looks something like this:
Most of the enterprises that I have worked with understand that this is a problem, and none of them intentionally set it up this way. This is usually a bi-product of missing tools to handle integrations properly at the time of need for an urgent integration. A good integration platform supports the need for fast direct integrations that are not point-to-point because they are not built in isolation of the company’s integration. The XML which defines behavior that the Mule runtime will execute is very different from the custom code on a custom application server. The Mule runtime executes this direct application in addition to any other number of integrations deployed to it, as opposed to the point-to-point application whose only scope is this one specific point-to-point integration.
Hub and Spoke
As the integration maturity model evolves, we start to see the integration of the “hub and spoke” model. In this model one system is designated as the “owner of the data”. For example:
- Salesforce may own the customer
- Workday may own the employee
- SAP may own the product
- Oracle EBS may own the order
- ServiceNow may own the request
In this model, your integrations will consist mostly of events that tell these owners to “create objects”. Hiring an employee in an Applicant Tracking System (ATS) may tell Workday to create a pre-hire, and an opportunity being won in Salesforce may tell Oracle EBS to create an order. In general, the “master” data which comprises the fields that do not change outside that specific system are not updated. Meaning, Workday should not accept a request to change a social security number of an employee, just like Oracle EBS should not accept requests from other systems to change the price of the order.
Loosely Coupled
Lastly, the most mature model of integration creates a distributed arrangement of systems which interact through a pub-sub model. This is what is generally referred to as “loosely coupled” systems. Here, systems broadcast events that occur within them, either via events, notifications, or with the help of polling from Mule, and places those events inside queues (generally). Then, on the receiving ends, the systems that care about those events will looks for messages of that type inside those queues and consume it. The role of Mule in this orchestration is to help catch those events from various systems, place those messages into queues in a desired object model (usually referred to as a canonical model) so that it is easier to consume those objects by other systems. Then, Mule pulls from those queues in other flows where it can transform the object to the model of the receiving system and insert it into those systems. Having a loosely coupled system gives you the flexibility to add additional publishers and subscribers without having to modify or re-deploy the existing orchestrations. It also allows you to instrument, monitor, and manage these integrations much more clearly by allowing you to direct which messages go where from outside the scope of the application (via configurations that can be modified at runtime).
Our templates are designed for each of these maturity models, and currently ship looking like direct integrations. They are built to be easily assembled into hub and spoke models, or to add queues where we do flow referencing to allow for a pub-sub models. We intentionally designed each of the flows to be atomic so that it can be of value as a standalone application.
Templates at CONNECT
I’ll be covering all of this and more at CONNECT London in the session, “Getting Connected with the Anypoint Platform: Connectors and Templates”. It’s a great opportunity for you to join me for a deeper discussion about each of these topics and ask about your specific integration needs. Register for CONNECT London now. See you there!
Getting Connected with Anypoint Connectors and Templates
Learn how to connect enterprise applications using Anypoint Platform. Hear how to build your own connectors using DevKit, how to leverage MuleSoft’s pre-built Anypoint Connectors, and see how Anypoint Templates help you build integrations more easily and get up and running more quickly.
Featured Speakers:
Darko Vukovic, Senior Product Manager, MuleSoft
Nick Borth, Senior Product Manager, MuleSoft
Register now »
As always, please feel free to reach out if you have any questions or would like to get additional information. Comments are welcome below, or reach out to us on Twitter @MuleSoft, LinkedIn, Facebook, or on our Forums.
