Tel Telephone : +91-7337539091 Website : http://global-techhub.blogspot.

com
Email : ameerg.eai@gmail.com

Ameer Basha
MuleSoft Development – Best Practices & Naming Conventions
Introduction
Given the importance and value that APIs represent for numerous businesses, it’s important to consider
API development best practices when designing and building APIs using MuleSoft. The APIs that have
the most value and use for the enterprise are more like products than code. They are designed to be
consumed by specific audiences (e.g., mobile developers), they are well-documented, and they are
versioned so users can have certain expectations of the API maintenance and lifecycle. API development
best practices enable the full API lifecycle from design, build, test, through to deployment.

Overview
Anypoint Studio

Studio updates

➢ Keep your Anypoint Studio up-to-date (Install Studio Updates when available)

Mule Runtime

➢ It’s really important the coherence of the Mule Runtimes version within the SDLC. If you
developed and tested your application using a Mule Runtime 3.9.0, deploy it to a worker with
the same Runtime version.
➢ Upgrade your projects constantly to the latest patch-version 3.9.x/4.0.x/4.1.x (Install the new
Runtimes from the Studio Update Site or from the Mule Runtime Update Site).
➢ If you want to migrate your applications to a minor-new-version or a major-new-version (e.g.
3.9.x or 4.x) follow the migration guides provided in the MuleSoft public documentation

https://docs.mulesoft.com/release-notes/

Mule Projects in Anypoint Studio

➢ Use Maven for creating a New Mule Project.

➢ Include a .gitignore file in every Mule Project.
➢ Add APIKit components getting the RAML from Design Center.

Project Files Structure

MuleSoft Development – Best Practices & Naming Conventions 1

 ➢ Create a separate xml for the global elements (e.g. configuration elements).
➢ Create a separate xml for each use-case/functionality or resource-implementation.
➢ Create a separate package for each use-case/functionality.
➢ Create separate xmls for common structures/logic.
➢ Create different packages for the resources (dataweave, wsdls, examples, etc).

XML identation and formatting

➢ Define a line width in your Anypoint Studio XML editor preferences, e.g. 140
➢ Indent all your xml (mule xmls, pom.xml, log4j2.xml, etc) files before committing to the
source code repository

Properties per environment

➢ Use property placeholders to externalise properties. Use a placeholder in the location-name
of the file to identify the environment.

<context:property-placeholder location=”customer-api-${mule.env}.properties” />

Mule Components

Dataweave

➢ To transform/enrich the data, dates transformation and build error/response messages

instead of custom scripting code (Java, Groovy, etc)
➢ When dealing with large payloads, include the directive indent=false to improve the client’s
parsing performance and to reduce the response payload size.
➢ Define the input content-type to avoid verbosive messages in the Log e.g.
➢ Use inline dataweave scripts on the development phase, then pass it to an external file to
have a clean xml and reusable scripts.

MuleSoft Development – Best Practices & Naming Conventions 2

HTTP Listener

Use the following placeholders:

➢ ${http.private.port} when deploying to CloudHub using HTTP and using a Dedicated Load
Balancer (http.private.port is a reserved key in CloudHub that resolves to 8091)
➢ ${https.private.port} when deploying to CloudHub using HTTPS and using a Dedicated Load
Balancer (https.private.port is a reserved key in CloudHub that resolves to 8092)

If HTTPS is required (e.g. in the DLB upstream protocol or for the CloudHub shared load balancer) use
the HTTP Listener with a TLS Context reference, configuring the key-store with a key-pair values
generated with keytool.

HTTP Request

Request to APIs with self-signed certificates

MuleSoft Development – Best Practices & Naming Conventions 3

When consuming APIs that are exposed with a self-signed certificate, use the HTTP Requester with a
TLS Context reference, configuring the trust store with the self-signed certificate or including the
“insecure=true” attribute to avoid the certificate validation (useful when running locally, don’t use this
in prod).

HTTP Request Status Code Validator

By default the HTTP Request expects a 2xx status code from the target system, if there’s a different
status code in the response it will throw an Exception. If you want to control different responses by
adding some business logic, you have to configure the range of status codes considered as ‘valid’, by
doing that you can put some logic after the HTTP Request, e.g. a Choice to take decisions based on the
status code.

Web Service Consumer

➢ Import the wsdls and the xsds in your project

➢ Use the Webservice Consumer component and point it to the local wsdl

Database Connector

➢ Use parameterized queries

➢ Use dynamic queries only if you don’t have another choice, remember to validate the inputs
previously (using dynamic queries could cause SQL-Injection vulnerability

APIKit

MuleSoft Development – Best Practices & Naming Conventions 4

 ➢ Use the APIKit features to generate the flows automatically
➢ Use the APIKit Exception Strategy to catch connector related exceptions
➢ It’s a good practice to disable the APIKit Console under all exposed environments (e.g.
CloudHub environments, production -onPrem) as:
o If the API Console is used without caution, you can affect real objects/data due to the fact
that you don’t have a ‘mocking-services’ option. When using API Portals (Exchange
Public/Private Portal) you can enable mocking services.
o If an API Portal exists, the API Console is a redundancy.
o If there are no policies applied, the API Console is a risk, due to point #1.

Validator

➢ Use Validator instead of throwing exceptions with Groovy Scripts

Flows Reusability

➢ Use Flow references to separate and reuse common logic. The flow diagram should be clear,
showing the steps of the use case.

SSL

➢ Always use HTTPS listeners, if your applications are exposed on the internet or if you have
internal security regulations. HTTPS can also be terminated at load balancer level when using
Dedicated Load Balancer or where the user is hosting their own load balancer on-premises.
➢ In NYU, there is a Dedicated Load Balancer configured. HTTPS in listener in Mule applications
is not mandatory because the SSL termination is done on the DLB.

Secure Application Properties

➢ Sensitive application properties such as access credentials and passwords can be obfuscated
in CloudHub by using the Secure Application Properties feature.
➢ Such feature can be used in conjunction with the Mule Credentials Vault that allows users to
encrypt properties within the application properties files.
o Use AES algorithm with a CBC mode.

MuleSoft Development – Best Practices & Naming Conventions 5

 o Define a 128 bits key, if you want to use a 256 bits key, the JCE Unlimited Strength
Jurisdiction Policy Files need to be installed in each workstation

Java custom code/Scripting

➢ Only if there is no other choice.

Cache

➢ Use the Cache scope whenever possible, to wrap HTTP calls / flows / logic that
obtain/produce information that doesn’t change frequently
➢ Define a ttl (time to live) based on an analysis, it shouldn’t be arbitrary

Unit and Integration Testing

➢ Create significative Unit tests using MUnit

➢ Create significative Integration tests using MUnit

Mule Deploy Maven Plugin

➢ Include the Mule Maven Deploy Plugin in each application

Debugging & Troubleshooting

Use Anypoint Studio Debugger to debug your Mule Applications.

Wire Logging

To enable a more detailed logging to see all the HTTP requests and responses, configure the following
loggers in src/main/resources/log4j2.xml

Naming Conventions

MuleSoft Development – Best Practices & Naming Conventions 6

Category Convention Pattern Examples

Mule Projects kebab-case {domain}-{subdomain}-{layer}-{type} customers-sys-api

{process-or-integration-name} identity-sys-api
cloudhub-log-
aggregator

Maven Group fixed name edu.nyu edu.nyu

Id

Mule XML files kebab-case {significant-name}.xml customers-api.xml

delete-
customer.xml
common.xml

Global kebab-case {significant-name} http-listener-

Elements config

Mule - separated {domain}-{subdomain}-{layer}- Customers-sys-

properties files {environment}.properties dev.properties

Mule dot NA http.listener.host

properties keys separated

Dataweave package {dw}.{classifier} dw

resources notation dw.customers

packages
{dw}_{classifier}
dw.customers.accounts

dw.health_check

Dataweave kebab-case {significant-name}.dwl build-error-

Scripts message.dwl

MuleSoft Development – Best Practices & Naming Conventions 7

 JSON Examples kebab-case {method}-{significant-name}- delete-customers-
{request|response}-example response-example

Mule flows kebab-case {significant-description}-flow send-user-to-

queue-flow

API HTTP base NA {domain}/{subdomain}/{layer}/ /students/sys/v1/*

path (On Prem) {version}/*

API HTTP base NA NA /api/*

path
(Cloudhub)

Conclusion
In this article, I have provided some basic MuleSoft coding standards and namining standards. There is
no such thing as a naming convention for Mule. You could try to apply the same rules Mule community
developers follow, but those are not strictly for Mule Applications.

At the same time it does make sense to follow the same naming conventions than the IoC container of
Spring given that Mule is a sort of specialization of it. Organization to Organization these standards
changes.

Download
S. No File Name Size Download
1 MuleSoft Development – Best Practices & Naming Conventions.pdf 1.0 MB Download

MuleSoft Development – Best Practices & Naming Conventions 8