MuleSoft: Coding Standards

Establishing coding standards is essential for successful implementation of a program. The smooth functioning of software programs is vital for the success of most organizations. Coding standards are a series of procedure for a specific programming language that determines the programming style, procedures, methods, for various aspects of the program written in that language. A coding standard ensures that all developers writing the code in a language write according to the guidelines specified. This makes the code easy to understand and provides consistency in the code. The completed source code should indicate as if the code has been written by a single developer in a single session. In the following sections I provide a sample coding standard for MuleSoft code. Please let me know your thoughts by email or through the comments.

Guiding principles

This section contains some general rules and guidance integration development should follow. Any deviations from the standard practices must be discussed with, and validated by, the technical lead on the project. This list is not intended to be exhaustive and may be supplemented during the life of the project:

    • Client first: The code must meet requirements. The solution must be cost-effective.
    • The code must be as readable as possible.
    • The code must be as simple as possible.
    • The code should reasonably isolate code that can be reused.
    • Use common design patterns where applicable.
    • Reuse a library instead of rolling your own solution to an already-solved problem.
    • Do ask if you are unsure of anything.
    • Do ensure that any modifications to the design or architecture are thought-through, well-designed and conform to n-tier architecture design principles ( ).
    • Do reach out to authors of work items if alternative approaches exist for a given requirement, or if you have any concerns about any assigned work items, e.g. missing acceptance criteria.
    • Do avoid duplication of code.
    • Do add any objects that have been modified to version control as soon as possible.
    • Do alert responsible team members as to any issues or defects that you may discover while executing unrelated work items.
    • Don’t add code to troubleshoot or rectify a defect in any environment other than the development environment.


  • All mule elements supporting the “name” attribute for object reference should be camel case starting with a lowercase letter.
  • For mule elements that support the “Notes” section, write comments describing the purpose, functionality etc., as if you would write comments in a Java/Scala/C#/ Python function or method definition.
  • Breakup flows into separate flows or sub flows which:
    • Makes the graphical view more intuitive
    • Makes XML code easier to read
    • Enables code reuse through the reuse of flows /sub-flows
    • Provides separation between an interface and implementation
    • Easier to test
  • Always define Error handling for all flows.
  • Encapsulate global elements in a configuration file.
  • Create multiple applications, separated by functionality.
  • If deployment is on premises use a domain project to share global configuration elements between applications, which helps with:
    • Consistency between applications.
    • Expose multiple services within the domain on the same port.
    • Share the. Connection to persistent storage.
    • Utilize VM connector for communications between applications.
  • Use Application properties to provide easier way to manage configurations for different environments.
  • Create a YAML properties file the “src/main/resources” folder “{env}-config.yaml”.
  • Define Metadata in “src/main/resources/application-types.xml” for all canonical schemas, all connectors that do not create the metadata automatically.

MuleSoft Development Standards for Project Naming Convention

  • SystemAPI Apps: {source}sapi
  • ProcessAPI Apps: {process}papi
  • ExperienceAPI Apps – {Web/Mobile/Machine}eapi
  • Integration APPs – {sourceSystem}and{targetSystem}int == These are batch/or scheduled integrations

    Note that: Not all implementations would have all these types of projects.

MuleSoft Development Standards for Transformations/ DataWeave

  • Write comments.
  • Keep the code simple.
  • Provide sample data for various scenarios to test the transformation with.
  • Define a utility.dwl that stores all the common dataweave functions such as common currency, time, string conversions.
  • Save the code in an external DWL file in the src/main/resources folder for complex transformations should be stored in external DWLs (as its performance intensive).
  • Use of Dataweave libraries before writing your own dataweave functions.

MuleSoft Development Standards for Flows

  • Minimize flow complexity to improve performance.
  • Each variable defined in the flow is used by the process.
  • Transactions are used appropriately.
  • All calls to external components are wrapped in an exception-handling Scope.
  • No DataWeave contains an excessive amount of code that could alternately be included in an external component.
  • All Loops have clearly defined exit conditions.
  • All variables are explicitly instantiated.
  • All Flows has trace points inserted to enable debugging in later environments.

MuleSoft Leading Practices for Deployment and Administration

Figure 1: Continuous Integration and Continuous Deployment

Utilize Anypoint platform support for CI/CD using

  • The Mule Maven plugin to automate building, packaging and deployment of Mule Applications.
  • The MUnit Maven plugin to automate test execution.

MuleSoft Leading Practices for Testing

  • It is recommended to have the following test cycles before deployment into the production environment:
    • Unit testing the artifacts (build phase). Build MUnit Tests for all flows
    • End-to-end integration testing (SIT)
    • User acceptance testing (UAT)
    • Performance testing
  • Before deployment the solution should have been successfully tested while running under user accounts with permissions identical to the production environment.
  • Messages are validated against their schema as per the use case requirements.
  • At a minimum, the developer should conduct development unit tests & end-to-end system integration tests for every interface before certifying the interface ready for release for the QA phase of testing.

MuleSoft: Understanding Exception Handling

I have been approached by several developers taking the Any point Platform Development: Fundamentals (Mule 4) training about the Exception Handling and the different scenarios in Module 10. The way it is described can be confusing. So here is how I understand it. Any MuleSoft flow like the one below

How this would be executed? Any Point studio and MuleSoft Runtime would convert it into a Java byte code. So it would be generated as a method or a function in Java. MuleSoft would put the code for this function within a Try -catch scope. If you have defined exceptions handlers in the error handling module it will emit code to catch and handle those exceptions. If there is not and there is a global error handler, it will emit code for the catch exceptions of the global error handler. Here is the thing that catches developers by surprise. If you have defined local handlers, then those cases are the only cases that would be handled and not the combination of the local cases and global error handler case, only one of them if there is a local error handler defined then that is it if there is not then the global error handler is emitted as catch cases

The 2nd point is On Error Propagate and On Error Continue options. If you chooser on Error Propagate then the coded emitted will throw the caught exception at the end of each catch. If you chose On Error continue then the Exception is not thrown. Think of it as if the code written below If you have been a Java , C#, C++. Or Python developer you should understand this basic programming concepts.

public void MianMethod(){
try {
} catch (Exception E)
// default handler or global handler if defined
public void OnErrorPropagate() throws EOFException
throw new EOFException();
catch( EOFException e)
throw e;
public void OnErrorContinue()
throw new EOFException();
catch( EOFException e)

Hope this helps

MuleSoft: MCD Level 1 Mule 4 Certification Experience

OK Passed the Exam. How was it. I cannot tell you what the questions was and frankly I do not quite remember them. But here are my thoughts about the exam.

  1. You must go through the training course (which is free online, do all the exercises as there are concepts that are not in the slides or materials. And do the DYI exercises. I personally did them maybe 4 or 5 times. And I took the 3.8 online free course though that might confuse you as there changes between 3.8 and 4.0 like flowVars which is gone completely.
  2. I would recommend going quickly over the mule runtime documentation. And just trying to build a practical example.
  3. An understanding of Java and Spring either MVC or Boot frameworks would help but not necessary as it will help you understand how flows are translated into Spring code then compiled
  4. If you have time on your hands, go to git hub and download the free Sample for MuleSoft from MuleSoft and the open source code. Yes, that is an overkill.
  5. Now how about the questions, They are mostly tricky questions, most of the answers are extremely similar. You have to consider them thoroughly and find the best answer. Many are very simply minor colon, or semi-colon difference. Very low level syntax error so yeah if you have special glasses for the computer use them!.
  6. If you are taking the course from Home make sure you turn off your cell phone, phone etc. and do not speak to yourself. And yes you will not be able to use your big screen TV, you will be limited to the laptop screen.
  7. Hope this helps. I wish I can say it was easy I answered it in almost halftime with reviews, but I was really annoyed by the questions and every question is just trying to trick you.

MuleSoft: File:List Interesting Observation

Working with MuleSoft file connector, I was expecting that the File->List ( operation would return a list of fileInfo objects (you know path, size etc) but it actually it returns a list of the contents of the files in the directory. This seemed odd to me as the documentation states

“The List operation returns a List of Messages, where each message represents any file or folder found within the Directory Path (directoryPath). By default, the operation does not read or list files or folders within any sub-folders of directoryPath.
To list files or folders within any sub-folders, you can set the recursive parameter to

Here is the sample I was working with

I was intending to put a read file operation in the foreach however that just gave me an error

Here is sample of the logged messages

That was a head scratch-er I thought I had done some mistake in the list parameters, but it seems that is how the file connector list operator works. Below you will see that part of the message for each fine the typeAttributes have the fileInfo information.

Implement Rest API in MuleSoft, Azure Logic Apps, Asp.Net core or Spring-Boot? MuleSoft: Step1- Defining an API in RAML

I have been working lately on comparing on comparing different technologies to build web API’s.. One of the main concerns was if we wanted to build a simple API service which technology would be easier, more productive to develop the service with. To provide a reference comparison I will build the same web service (in MuleSoft, Azure Logic App, Asp.Net Core, Spring Boot) and provide my notes as I go. The web service would provide the following functionality

  1. CRUD operations on an Authors entity
  2. CRUD operations on BOOKS entities where books are related to authors

All the Read (queries) should support:

  1. Filtering
  2. Searching
  3. Paging
  4. Supports Levels two and three in Richardson Maturity Model(see my previous post . This means based on the Accept header of the request return the results as either:
    1. Pure JSON
    2. With HATEOUS

I will start with MuleSoft implementation.

Step 1. Define the API in RAML

With MuleSoft you get AnyPoint portal and you get the design center, which helps you designing the API RAML. There is API Designer visual Editor which can help you in the beginning.




Though it has many weakness such as:

  1. Once when you switch to RAML editor you cannot go back.
  2. You cannot define your own Media Types you have to use form the list.


To finalize the API definition in RAML I had to manually edit though the editor was helping to get started. Below is a fragment of the API in RAML (The full solution will be published on my GitHub )

Notice in the RAML that I have defined two responses for the Get operation of the Authors Resources. Full RAML is at (

#%RAML 1.0

title: GTBooks

description: |

GTBooks Example

version: ‘1.0’






baseUri: /api/v1.0




description: This is a new DataType

type: object



required: true

example: Moustafa Refaat

description: Author Name

type: string


required: true

example: Canadian

description: ‘Author Nationality ‘

type: string


required: true

example: ‘2018-12-09’

description: Author Date of Birth

type: date-only


required: false

example: ‘2018-12-09’

description: Author Date of Beath

type: date-only



description: This is a new DataType

type: CreateAuthor



required: true

example: 1

description: Author Id

type: integer


required: true

maximum: 200

minimum: 8

example: 10

description: Author Age

type: integer



description: Author with Hateoas information LINKS

type: Author



required: true

description: Property description

type: array


required: true

type: Link




description: Hateoas LINK

type: object



required: true

example: /Book/10

description: URL Link

type: string


required: true

example: GetBook

description: Operation

type: string


required: true

example: GET

description: ‘HTTP Method Get, PUT,..’

type: string







type: array


type: Author


type: array


type: AuthorHateoas

‘304’: {}

‘400’: {}

‘500’: {}



example: ‘application/json ‘

description: application/json or application/hateaos+json

type: string



required: false

example: Example

description: sort by

type: string


required: false

example: Example

description: Property description

type: string


(.. to be continued)