Mule 4 Best Practices for Successful Integrations
Developers mainly worry about making their logic and how to solve the issues they are facing. While efficiency and performance are essential, there are other practices we can apply to improve the project's maintainability and readiness that are useful for teamwork.
Developing a well-structured project following best practices will allow you to reach the next level.
In this article, we want to show you some of the most common and valuable best practices on Mule 4.
Example of our project structure recommendation.
Project File Structure
We recommend dividing your flows, errors, and configurations between files according to their functionality. This will make it easier to find something for anybody who can read your project. The following files will let you keep a reasonable and logical project structure.
Logic file structure
- Api.xml: When developing an API on Anypoint Studio, you can use your RAML as a base to create your project. Anypoint will create all the flows that you need inside a file. Our recommendation is to rename it to api.xml if it is called differently.
- Error.xml: On this file, we advise you to add the project global error handler and move the APIKit error here, making it easier to find project errors.
- Global.xml: This file will have all the configurations for your project. For any configurations you add, you should move them here. This will allow you to find all configurations in a single place.
- *.xml: Here, you will add any file you need for your project logic; these files are named using kebab case (e.g., main-file.xml)
Properties Files
Properties are used to avoid writing hard-coded values on our project configurations. Doing that will let us modify our values easily without updating the code. A property file is the recommended way to define them, making those properties quick and easy to find.
You can find on most of the projects sensitive data such as usernames and passwords, and you need to secure them. With an encrypted secure properties file, you can make them secure and not discoverable.
Resources files recommended structure.
- Messages.yaml: In this file the project messages should be added to find them quickly, such as log messages.
- config/{environment}-properties.yaml: We recommend having a properties file for each environment you need (dev, qa/sandbox, prod).
- The dev properties file should have all connections to test accounts, usually, local and dev environments have the same values.
- On prod properties file should have the real connections to be used when the project is released. Normally, this file is completed at the end of the development phase.
- Config/{environment}-secure-properties.yaml: We should have one of these files per environment, where the sensitive properties are set sensitive properties. Any value should be encrypted beforehand for security reasons.
Name Code Conventions
We have already talked about project structure, and now we need to talk about flows and the logic of our project. Here are some suggestions to help you improve our project's naming.
- Project name: Normally, the project name should be in the kebab case, like mule-best-practices as below.
Project name example
- Naming flows and sub-flows: When developing, it is recommended to use the kebab case to name flows and sub-flows. Also, as a best practice set the flow name when using a flow-reference connector to know easily what flow is referencing. For naming components is better to begin with the first letter capitalized.
The flow shows name conventions, this flow is not functional as is.
- Global configurations: Our configuration’s names are highly recommended to user camel case, for example apiHttpConfig.
Image to show examples of configuration names.
MUnits
Implementing unit tests will improve our code allowing us to test our flows, this helps us to find errors quickly to solve them.
A unit test on Mule should:
- Be unique per flow, having a descriptive name, in this way, you quickly identify the type of test.
- Have a test description on each MUnit.
- Validate the flow response.
- Mock all external references used in the flow, such as HTTP requests, database queries, or a flow reference.
- Have validations for successful and failure cases. Here are some situations where we need more scenarios:
- When we have a Validation Connector, each case should be tested.
- When we have a Choice component, each leg should be a test.
- Verify the number of calls of the most important connectors used in the flow. Loggers normally are not verified.
Example MUnit testing a successful scenario. This Unit Test has a mocked flow reference to avoid the call to the "get-car-details" flow. A Set Event was defined to add the variables the flow needs. In the Validation section, two connectors are verified, and the response is validated.
