A Mule application for processing orders must log the order ID for every log message
output.
What is a best practice to enrich every log message with the order ID?
A. Use flow variables within every logger processor to log the order ID
B. Set a flow variable and edit the log4/2.xml file to output the variable as part of the
message pattern
C. Create a custom XML SDK component to wrap the logger processor and automatically
add the order ID within the connector
D. Use the Tracing module to set logging variables with a Mapped Diagnostic Context
D. Use the Tracing module to set logging variables with a Mapped Diagnostic Context
Explanation:
The best practice for enriching all log messages with contextual data (like an order ID) in a Mule application is to use the MuleSoft Tracing Module, which integrates with Log4j2’s Mapped Diagnostic Context (MDC).
Mapped Diagnostic Context (MDC) allows you to:
➜ Set key-value pairs (e.g., orderId=12345) for the current processing thread.
➜ Automatically include these values in all log messages, without modifying every individual logger.
This is cleaner and more scalable than adding the order ID manually in every log step.
📘 How it works:
➜ Use tracing:set-trace-variable to set the orderId.
➜ Update log4j2.xml to include %X{orderId} in the log pattern.
❌ Why other options are incorrect:
A. Use flow variables within every logger processor to log the order ID
🔸 Incorrect: This is repetitive and error-prone — you'd need to manually add the variable to every logger.
B. Set a flow variable and edit the log4j2.xml file to output the variable as part of the message pattern
🔸 Incorrect: log4j2.xml can only access MDC values, not Mule flow variables directly.
C. Create a custom XML SDK component to wrap the logger processor
🔸 Incorrect: Overengineering. Not necessary when MDC via Tracing module already handles this elegantly.