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.
