Mule Solution Design – Best Practices

Mule Solution Design – Best Practices

Anti-Patterns

Synchronous Patterns

• API (RESTful services) developed using RAML for all synchronous communication 
• API proxy used to proxy existing web services (SOAP/REST) 
• Use a Message Broker/VM for Async needs inside synchronous scenarios 

Asynchronous Patterns

• Mule support Asynchronous patterns via “Async” component,  Virtual Machine (VM) and Java Message Service (JMS) connectors 
• VM component can be used to convert non transactional components like http, ftp, tcp into transaction component which helps in rolling back transactions, retry mechanisms etc. 

• Asynchronous message handling is one of the keys to use Mule effectively. Mule support Asynchronous processing patterns in many different ways like 

• • Setting exchange-pattern of a message source to “one-way” enables asynchronous processing for a flow 
  • Asynchronous processing for a flow can be tuned by defining a queued-asynchronous-processing-strategy. Multiple queued-asynchronous-processing-strategy can be defined and set using the flow’s “processingStrategy” attributes 

Publish/Subscribe Patterns

• A Message Broker (AnypointMQ, ActiveMQ, Kafka, RabbitMQ, WMQ, etc) should be used for Asynchronous integrations to implement pub-sub model 

• Create topics based on application needs, topics can be classified by application, message types etc. 

File Handling

• File handling should always ensure zero file/message loss and should include a reprocessing strategy or backup in case of error files 
• Do not delete or overwrite input/output files  

• Be careful when using the autoDelete and the moveToDirectory attributes of the File Transport
• If streaming is enabled for each file that is processed, make sure that the stream is properly close after reading 
• Always ensure that the file/ message has been archived correctly once entered in the mule application / flow 
• Don’t save file contents / complete file / payload in session unless it’s required 

• Define correct file handling strategies, considering all the failure / success / transaction / unhandled error scenarios 
• Ensure that the directories used in the file handling have correct read / write permissions
• When a file reading process is scheduled, ensure that the same file is not picked up for processing when the next schedule starts. 
• Create directories like “working”, “error”, “processed” directories to manage files. For example, when a file is selected for processing, move it to the “working” directory, on successful processing move it to  the “processed” directory, if the process fails, move it to the “error” directory 

Large Data Handling

• Mule has out of the box  Batch Processing components that can be used for Data synchronization between systems for large data
  • Reference: https://docs.mulesoft.com/mule-user-guide/v/3.9/batch-processing 
• Data could be considered large in Mule if it’s > 20 MB (per request/transaction).  It  also depends on worker size, complexity of implementation, etc. 

• Dataweave, Streaming, etc can be used appropriately based on the use-case 

Error Handling

Consider the following categories of errors when designing Mule flows:

• Business Logic errors: Thrown by validations and conditions based on the use case requirements.
• Systems’ availability errors: Errors based on the source/target systems’ availability and re-connection strategies (Connection timeout, max retries reached, etc) 

In any of the previous cases don’t expose the exception message or the stack trace, instead, include descriptive messages mapped to internal error codes.

Don’t include error handling for the following categories:

• Development errors: To cover bad development practices, like bad parsing, bad transformation inputs, etc.