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 Moustafa@MoustafaRefaat.com 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 (https://en.wikipedia.org/wiki/Multitier_architecture ).
    
  • 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.
    

General

• 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.