What are the General Development Best Practices in MuleSoft

Question

What are some common best practices one needs to consider while developing Apps in MuleSoft for clients, focusing Anypoint Studio 7.x.x and Mule 4.

List down your recommendations, which you have followed with any clients.

Please Note: I asked this general question to have a dedicated section of MuleSoft Development Best Practices on SO, rather than having similar titles where users having their personal agendas\user driven case scenario.

Answer 1

Mule Developers must considered this to be a critical topic.

Given below are the wide range of MuleSoft best practices which are involved during App development phase.

Development best practices are commonly divided into three categories:

1. Mule General Best Practices
2. Mule Munits Best Practices
3. Mule Error Handling and Exception Scenario Best Practices

Mule General Best Practices

Note: Suggestions are placed in <>. These are just best practices, not a compulsion.

1. Naming Conventions
   • Flow and SubFlow Names. <Must use camelCase>
   • XML files and properties files <Must be all lower case with '-' in between words>
   • Other common files (Examples, JSON files, Scripts) <Must use camelCase>
   • All the rest (Components, Transformers, Scopes, Flow Controls). <First letters of each word must be capitalized. Spaces must be used between words>
2. Property Parameterization
   • Configuration Properties. <All configurations must be declared as *key=value* in the property files>
   • Environment Based Properties. <Configuration properties must be segregated into files based on the *Environment* we deploy the app. Example "config-dev.properties", "config-qa.properties", "config-prod.properties">
   • Runtime Property Variables. <Should be used to fetch appropriate ".properties" files needed for the environment we deploy. Example, name your environment files as "/config-${env}.properties" using Configuration properties in global elements and pass 'env=dev' or 'env=qa' as a Runtime variables in Run Configurations. We can also pass global arguments like 'crypto.key=w4ref$%wrfw3', used to decrypt encrypted values>
3. Externalizing Transform Message Code to dw Script files. <A common rule of thumb is to use script files when the lines of code is greater than 10>
4. RAML and Project Files Folder Structuring
   • Place all the .properties files in src/main/resources/properties
   • Place all dw script files in src/main/resources/scripts.
   • Place the RAML examples, libraries, dataTypes, securitySchemes and Traits in dedicated folders while designing in Design Center.
   • Keep a separate file for API Kit Router and all its generated flow.
   • Error handling must have its own separate file. Error flows must not be seen anywhere else apart from this file.
5. Move all Connector Configurations/Global Elements into a separate 'global-config.xml' file. <This keep the rest of mule xml files clean and tidy>
6. Hard coded values
   • Must be aware of which code values you must 'Hard code' and which ones not.
   • Most Global elemental configurations must be property parameterized rather hardcoded. Example, 'Reconnection Strategy, 'Connection Idle Timeouts', 'Max Idle Timeouts', 'host', 'port', 'usernames', 'passwords' and more.
7. Property Value Encryption. Critical Information must be encrypted. <Using secure-properties-tools.jar or Mule property editor>
8. Autohide sensitive Property Values passed in Runtime Manager Tab of cloud hub. <Achieved using 'mule-artifact.json'>
9. Using functions, local/global variables in Transform messages to enforce DRY
10. Add detailed inline XML comments for flows, choice, etc.
11. Add descriptive multiline code comments for any complex transformations in Transform messages.
12. Replace long repeating 'if/else' statements 'with match/case' in data weave.
13. If flows are getting big using more choice routers. Refactor each choice scope into its own subflow.

    A good rule of thumb is that if you have to scroll the Mule canvas back and forth to see the whole flow, it's too complex and should be rewritten.

14. Avoid Mule Async Scope Calls as much as you can. It caused data integrity issue, based on several developer complaints.
15. Do not use mule-objectstores for fast-long repeated operations. Know your TPS. Always clear your object stores in your mule cyclic execution in relevance to the requirement from time to time.
16. Keep a track of each 'variable' initialized in the flow executions. Always make sure to clear or remove variables once finished using them. <Helps you to have a clean process, removing unnecessary code manipulation and heap limitations>
17. Change your mule loggers from 'INFO' to 'DEBUG' after done development. <Helps you by not over-burdening the Mule APP when deployed in cloudhub. Keeps the mule health monitor in check, so that the APP does not auto restart>

Make sure to never cross an App's 70 percentage CPU usage shown in dashboards. Create Apps accordingly. 18. Be always aware of Data losses caused by Fatal Errors\Application Restarts. <Always use a backup data centers like AWS, Database, Object stores, Mule Load Balancers etc>

Mule Munits Best Practices

1. Never forget to use Spy and Asserts.
2. Scenarios based test cases.
   • Success Scenarios. <Have one major test case to run through the entire API once>
   • Failure Scenarios. <Have multiple test cases for each flow or subflows, testing for all possible failure situations, like testing mapping, choice routing etc>
   • Always mock all external service calls, like HTTP, DB, SQS Connectors. <Never call your actual endpoints in Munits>
   • Consider to put your test payloads in 'src/test/resources/testExample.json' but not directly in the Mocks or Events. <use #[MunitTools::getResourceAsString('testExample.json')]>
3. Include the files needed under 'src/test/resources' for Munit Test Runs, similar to having 'src/main/resources'.

Mule Error Handling and Exception Scenario Best Practices

1. All Error status codes must be included appropriately as per the requirement.
2. Errors must be separately specified in a 'global-error-handling.xml' file.
3. All Exceptions\Errors must be properly branched as given below
   • System Exceptions <Source related data exceptions>
   • Business Exceptions <Target\End System exceptions (Not to be bothered by the Mule APP, but must be handled)>
   • System\Application Errors
4. Admiring the usage of object stores and Data Queues for failed messages and record reprocessing.
5. Having a Retry mechanism for all HTTP based errors.

---

Can you imagine all the hours of pain we can avoid by following some simple recommendations.

Hope you this helps !