In this document some best practices and remarks are gathered, which were determined by our engineers during their work on projects, where the integration platform MuleESB is used.
1) Naming conventions. Mule flow by itself and its components should have such names, which would give a clear understanding of what function they have. Standard names of components are allowed for transformation elements, but for other elements it is prefered to use more coherent names. For example:
- flow name should provide insight into processes in this flow;
- the basis, according to which the condition is built, can be pointed for Choice element;
- if it is possible, addresses and the way of data input/output can be pointed for connectors;
- for logging elements, if it is possible, the name should represent which information is being logged.
2) The whole code, which can be used in other projects, should be brought out to the specific project/library.
3) Standard in using property:
- All hardcode should be brought out to the settings files.
- All settings should be described in comments in detail.
4) There is a very powerful expression language in Mule, which allows making Mule components more dynamic. For example, Mule Expression Language allows dynamically defining addresses for http component. For this purpose, in the host field of http connector it is enough to use expressions of the following form:
- host=”#[xpath3(‘/request/host’)]” – in the case if different data come to the input of the http connector in the xml format.
- host=”#[payload]” – in the case if the address needs to be withdrawn from payload.
- host=”#[flowVars.host]” – in the case if the address needs to be withdrawn from flow variables.
Mule expressions can be used in almost all text-fields of the Mule components.
5) For every flow should be realized its own exception strategy for correct exception handling.
Example of mule xml:
<set-payload value="#[exception]" doc:name="Set Payload as Exception"/>
<component doc:name="IncomingExceptionHandler">
<spring-object bean="IncomingExceptionHandler"/>
</component>
IncomingExceptionHandler is a Java component (class) where the handling of the appeared exception and the formation of the answer can take place.
6) SFTP connector best practices.
Besides the standard settings of the sftp-server connectivity, also can be useful the following settings:
- Response timeout.
- Reconnection policy.
- Archive directory.
7) Dataweave transformation is a powerful data process tool, which allows converting data from/into CSV, Excel, XML, JSON, Java Object and other formats. One can specify mappings and default values, add conditional logic, filter data, group and build transformation chains.
The following operations on arrays are possible: selectors (for choosing elements), operators (map, concat, contains and etc.)
Also, Dateweave language for simple transformations can be used.
For example:
#[dw("{'payload': payload, 'interface': 'CompInvoice'}","application/json")]
8) Work with Queues. Mule allows working with different queues, which settings have a lot of common (name of the queue, operation – read/record), but with its specific features:
- VM is an in-memory queue, support transactions, but it can be used only for the message exchange among threads of an application, and not among several applications.
- AnypointMQ is a queue, provided by Mulesoft for the commercial usage and integrated into the Anypoint platform. It does not require a specific server for installation, but it does not support transactions.
- ActiveMQ is a popular open-source solution, which supports JMS. It supports transactions and message exchange among applications, but it requires a specific server for installation.
9) Profiling service. A standard java/oracle utility, jvisualvm.exe can be used for profiling. It can be found by the following way Windows C:\Program Files\Java\jdk1.8.0_65\bin\jvisualvm.exe (in the bin catalogue of the installed jdk). This utility allows tracking resources which are used by java applications). The application can be loaded and resources spends can be tracked under the concrete loadings.
10) MUnit tests: mule flows should be covered by MUnit tests. Testing should be carried out on the different levels. If a flow contains several subflows, then it is desirable to test each of subflows separately and the flow, which uses them. In this case, MUnit tests are a very good example of using flow and its separable parts. Basic algorithms need to be covered by unit tests. We recommend to use Data Driven Testing if it is possible.
11) Load testing. JMeter can be used for Mule application load testing. This tool allows checking application work in the conditions of a big amount of incoming requests from many users and providing testing results in the convenient form for an analysis.
12) Xml formatting.
- An extra component should be created for a smart/convenient text displaying in xml logs . When using this component it should be taking into consideration that it can change xml by adding to it spaces/inputs etc. that, as a result, might make xml invalid for web-services and various utilities for working with xml, so before logging one should save the source xml, and after logging one should return the previously saved xml.
- Sometimes, in xml request there are symbols of < type instead <> brackets, for correct work with xml, it is necessary to do the operation of data symbols change to <>. In this regard, an additional class may be used, which will change escape symbols.
13) Deploy of the application. Mule Plugin for Maven server can be used to deploy the application to the CloudHub. Such parameters, as Mule version, user name, password, environment, business group, application name, etc. can be configured.
14) All components are recommended to perform by spring beans.
Example:
