MuleSoft development made easy with templates

Introduction

Development, including build and unit testing, takes a major percentage of the time we spend on any project or program we embark on using MuleSoft. If development teams do not have the proper planning nor right set of artifacts, mistakes are likely. This blog will provide tips to prevent these mistakes and ease a few common developer pain points. Make sure to read through to find a step-by-step video tutorial to guide you as well.

Developer pain points

Here are a few pain points developers may experience when starting a new MuleSoft project/program in an enterprise.

• Lack of common libraries: Developers spend time creating integrations from scratch for each project
• Lack of comprehensive project templates: Leads to hard coding of the connection parameters
• Lack of common connections: Makes creating these artifacts repetitive?

These pain points can increase the development time and effort to achieve the code.? However, in one of my recent projects, when I took MuleSoft templates along with me. I was able to deliver a project with 16 APIs in just 6 weeks with production quality.?

Considerations for the common assets

When creating or customizing common templates or libraries we will need to make the following considerations.

Start with thinking what are common elements such as:

• Health check
• Common API Errors with most common HTTP Error Status Codes?
• Common Security Elements starting with Basic Authentication with Username and Password Combinations?
• An API Template with the above-mentioned Common Libraries and with a basic health check call at the root level
• Common Connections that would be used across the projects?
• To have property files defined for local, dev, qa, sit, uat, perf and production
• Create a folder for DataWeave scripts and keep all your scripts
• Come up with a Common Folder structure?
• Every Enterprise may have different needs and those elements need to be identified and are to be incorporated into the template

For example, ABC Corp may have heavy Salesforce-driven program(s) across the enterprise and their template will have a Salesforce connection apart from the common connections I have already mentioned.

What Design Libraries we would need

The following are some basic common libraries that are to be set in place and to be published to Anypoint Exchange.?

• Health Check Library: This library contains health-related information from an API. This can be implemented simply to say an API is up and running, or not running, or you can customize the implementation to get the health of the API and underlying source or target system’s health.

• Common Errors Library: This library will essentially have all the HTTP Error codes that are commonly used in REST APIs.

• Common Security Library: This library contains the basic authentication defined in it. Depending on the enterprise needs, it can be customized to use other complex security related items.?

Considerations while creating or customizing Code Templates

We will need a robust folder structure for creating our code template.?

• /src/main/mule: This folder will have all our Mule flows. Create the following files under this folder.?
• api-routes.xml: This file will contain all the resultant flows generated out of the scaffolding process.?
• health-check.xml: This flow will be the implementation of the health check call.?
• global-config.xml: This file will have all the common connections used across the project.?
• error-hanlder-api.xml: This will have the implementation of the error handling routines.

/src/main/resources

• api: This folder will have the api definition.?
• api.examples: This folder will contain all the examples from the api definitions.
• api.libraries: This folder will have all the libraries developed as part API will be here.?
• dwl: This folder will have all the dwl scripts
• keystores: This folder will have keystore certs.?
• properties: This folder will have all property files for all environments.?

This structure can change as per the requirements for your project. This is a sample folder structure as part of the template.?

Identify the common source and target systems and incorporate those connections into your global-config.xml file and its properties defined in the properties files.?

For example, A Customer ABC is a more Salesforce driven organization, Hence we can make the Salesforce connection part of our global-config.?

Some Best Practices

While writing code for your API definitions, Always have a separate XML file with meaningful legible name which reflects what you are implementing. Your global configuration file has mean names for your connections that are easily read and understood.?Keep self service for your APIs when naming them. Always have a self-signed cert incorporated into your Code Template.? Make sure to avoid putting DataWeave code inline and create separate files for your DataWeave transformations.?Make all common connections part of your code template.?

Video tutorial

Conclusions

In summary, I wanted to bring all that you need while you define a new design/project template on your new project/program. These common assets and code templates have helped me in great detail and in fact on my last project I was able to cut down the development time by at least 25%.

Author

Aravind Ramadugu, MuleSoft Mentor, Accenture