CorrelationId Magic in Mule 4
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.
Get William Richard’s stories in your inbox
Join Medium for free to get updates from this writer.
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 hel………….. Click to continue reading
