Message Tracing
WSO2 ESB Services / APIs for Enterprise level applications, usually consume services deployed in other WSO2 products like DSS, BRS or use services deployed in some legacy or third party application in order to complete the service request.
This means you have multiple endpoints configured and used, across different sequences encompassing the service.
Keeping track of these internal message flows between various services is important to debug service flows. This is more important and complex when debugging services which involves service timeouts and client or backend service errors.
Thankfully, as per the WS-Addressing specification, each message is assigned a unique message identifier or Message ID.
WSO2’s Synapse Engine takes care of the same and every Message is assigned a unique Message ID.
Its available as MessageID and its a Synapse context message property that can be retrieved using the get-property() function in the Property mediator.
<property name="msgID" expression="get-property('MessageID')"/>
For a sample flow like the following, the MessageID will vary across different integration points like ESB ↔ DSS, ESB ↔ TPL Application, etc.,
 |
| Sample service flow |
This brings us to the core of the issue, how to track the message from the client Request (1) to the ESB and then subsequent calls to DSS services, backend services, etc., and finally the Response to the client.
This can be handled in a simple way as follows:
Read the MessageID from the incoming client request through property mediator and assign to a custom property, say msgID.
<property name="msgID" expression="getproperty('MessageID')"/>Log the custom property across different sequences and debug statements, as follows.
<log level="custom">
<property expression="get-property('msgID')" name="***MESSAGE_ID***" xmlns:ns="http://org.apache.synapse/xsd" xmlns:ns2="http://org.apache.synapse/xsd"/>
</log>
This will enable tracking the entire message or service flow using a single MessageID
From a reusability and code quality standpoint, you can have these common log statements in a separate sequence and include this sequence in other In or Out sequences.
This will also be useful to maintain these sequences in Governance Registry.
Happy Coding..!!!