Templates are simple solutions to start building your own integration applications that help to accelerate ‘time to value’ for your company. We focused on creating templates in a particular way to meet a high quality bar and to help you maintain that bar when you choose to extend our templates or build your own. In this post, I wanted to run you through our principles, structure, and provide some advice when using one of our templates.
A template is:
- Complete for an atomic use case: In order to build something truly useful, the most important criteria was to develop a comprehensive solution focused on the main, atomic, value of the use case. Atomic means that its the base unit of value that can be compounded either by adding other flows in parallel or in a serial order.
- Reusable: It’s surprising how often different people have slightly different requirements for the same base use case. Even though our templates are designed to solve particular use cases, they conform the base to base patterns which are leveraged in many variations of the same base problem.
- Extendible: Templates are designed to grow into a complete Enterprise SaaS Integration. We built them with limited field mappings, data scopes, insert statements, definitions of ‘same’, and transformations, knowing that your specifics will be different than what we can predict. We provide all of the above knowing that you will have desires for each of those processing steps, but will want to customize each of them.
- High Quality: Knowing that our templates could be expanded to be deployed to your production environments, we built and tested the templates with production quality in mind and document any gaps that we find which may affect your decision to take one to production.
- Elegant: We aim to make the templates read like a integration story so that the flow is easily understood.
- Documented: As with any piece of software, documentation is helpful in realizing its value. We provide documentation to help you understand and get going with our templates as part of the git repository for each template.
Template Components & Best Practices:
When you first import a template in studio you will notice that it is nothing more than a Mule project which was built with you, the person who is going to take it further, in mind. We set up the template mule project in the following structure for your convenience:
-
Folder Structure: Since Mule Apps are Java based, then the structure is similar to Java application. More info on this.
-
Property Files: Property placeholders are used to parametrize the particular values to be defined for each template, such as credentials and options. To make matters more organized, our templates provide several files, each with the properties needed to get the template running, for different environments (Development, QA, User Acceptance Test and Production). When you are ready to run the template, you can choose which properties file to run in the mule.env environment variable which is found under src/main/resources.
-
XML Files: Even though all mule code can be packaged in one XML file, we provide our templates with the mule flows broken into four flows for the purpose of starting with the best organizational practice from the start. The files can be found in src/main/app.
- businessLogic.xml is the most interesting flow as it contains the code that solves this use case. This is where you will make modifications to implement your own solution to your need.
- endpoints.xml is the place for the inbound and outbound flows of the application.
- config.xml is where all the connectors, db, etc configurations are kept.
- errrorHandling.xml is where you handle how your integration will react depending on the different exceptions. This file holds a Choice Exception Strategy that is referenced by the main flow in the business logic.
-
Custom Java Classes: are the way to implement custom logic that is not provided with mule. You will find that some of our templates that use custom logic will have them in src/main/java.
-
Tests: Unit tests should be stored under src/main/java. We highly encourage building integration tests and unit tests. This is something that we are looking to add with the templates in future template releases.
-
Maven based project: Templates are Maven Based projects. That is why you will find a pom.xml on the root directory. Maven is not required but is useful and standard tool for managing and building Java Applications.
Get started
To get started with Anypoint Templates visit our Salesforce to Salesforce integration page where you will find our first set of templates and where to find them on github. We look forward to hearing what you think!
