correlationId magic in Mule 4

plektonlabs-mulesoft-4-correlationid-magic

Remember those old days, when you need to add the correlationId as a prefix in each and every log messages in Mule 3 just to keep track of an individual HTTP request in your Mule API? Those days are just gone. So does the pain of extra Muley works. Because it is automatically done for you by Mule 4.

Message Idempotent design pattern has already been implemented in Mule where correlationId is used to identify a unique Mule message; hence the HTTP request. This prevents redelivering the same HTTP request multiple times. Many MuleSoft developers tend to use some sort of identifiers in their log message so that each implementation thread can be traced down. correlationId is the most popular choice. You may be familiar with the following log messages.

<logger level="INFO" doc:name="request received" message="[#[correlationId]] Request received“ /> 
<logger level="INFO" doc:name="retrieved records" message="[#[correlationId]] Retrieved records from database“ />
<logger level="INFO" doc:name="created objects in SFDC" message="[#[correlationId]] Created records from SFDC“ />
<logger level="INFO" doc:name="response" message="[#[correlationId]] responsding back to client“ />

The point is: adding correlationId in each log message just adding additional work for developers. Developers usually don’t like this type of Muley work. We, Plekton Labs built many custom connectors, interceptors, and other solutions to do it automatically. But Mule 4 got released with the blessings. We no longer need to worry about it. Mule should do the Muley work anyway.

Along with other exciting updates, MuleSoft included correlationId in every log messages in the logger component. Moreover, it sends the same correlationId to different systems across transports. This helps a lot if you are using API-led connectivity model. A correlationId, used in the experience API, propagates back to all the different downstream layers and systems. If you are using a log-aggregator like splunk or graylog, then you can find the complete trace. The correlationId is tied with the event in each log message produced in Mule 4. It looks like the following in the application log:

INFO  2020-02-09 22:15:39,608 [[MuleRuntime].io.03: [mule4-batch-manager-demo].batch-management-work-manager @5a6d2c76] [event: 9cc421b0-4bb3-11ea-b0cc-8c85904d303b] com.plektonlabs.logmanager: Request received 

Note that MuleSoft uses the correlationId if the consumer provides it, otherwise autogenerates it. Thanks to MuleSoft for making life easier.

Share This Post

Share on facebook
Share on linkedin
Share on twitter
Share on email

More To Explore

Blog

The Use of APIs in the Business Supply chain

Supply chains that mostly rely on legacy EDI (electronic data interchange) systems, a technology introduced over half a century ago to support communication with business

Blog

The 5 Foundations of API Governance

For many, governance is a necessary but tedious task. But when done right, governance offers a clear direction, breaks down barriers, and enables different parts

How can we help?

A little about yourself and we're ready to go

We pride ourselves on swift communication and prompt responses. Let us know what you're thinking and how we can help you.

Contact Information​

Head Office
75 Cornwall Drive, Ajax ON L1T3G2

Toronto Office
602 – 8133 Warden Ave, Markham, ON L6G 1B3, Canada

Phone: +14168902757
Email: info@plektonlabs.com

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.