Debugging Message Processing

When debugging an application, you first want to verify that the overall flow of the application is as expected. Using the simple loan broker as an example, you want to check that the endpoints coded in the configuration file are executing correctly and in sequence.

Looking at the loan broker configuration XML file, and knowing how you designed the application, you expect processing to flow as follows:

To make sure that the application correctly handles errors, we input an incorrect loan amount and check the result. We enter a number such as "2,760.00" knowing that the application does not do a string to number conversion. As expected, the browser displays an error:

Next, we use the Flow Analyzer to make sure that the what happened matches our expectations. The parameters for tracking the loan broker application are already set up, and sure enough we see that only the loan-broker-sync flow executed. We click the flow and the Message Flow pane lists the message processors that were invoked.

We then check the before and after message payloads for each message processor, to make sure that the processor performed its expected task correctly. As the previous figure shows, click a message processor, such as HttpRequestToMap, and you can see its before processing message payload and the payload after it does its processing. In this example, what we see is exactly as expected: The flow received a request passed in as a browser parameter, /?amount=2,760.00, which it mapped to an object, amount=2,760.00. Checking further, we can see that the ScriptTransformer processor caught the error in specifying the number, and the ExceptionTransformer and ObjectToString processors handle preparing the error message returned to the browser.

Next, we verify that the application can handle correctly formatted rate requests, submitting a rate request via the browser for a loan of $1000. The application responds with the best rate.

To make it easier to follow the application flow, we click the Clear button (circled below) to clear out the previously collected data, then submit our request. The Flow Analyzer shows all the flows that occurred to handle this single request:

Now you can step through each flow in the Message List and examine the message flows and message payloads for each processing step. Click a message id row in the Message List table and details for that flow appear in the Message Details section. For example, the figure below shows the message processing details for the loan-broker-sync flow when it is first invoked by the application.

To handle an incoming request, the flow relies on eight message processors, listed in the Message Processor section in the Message Flow pane. Click each message processor in the flow to see its before and after message payload and its inbound, invocation, and outbound meta-data properties. In the above figure, we clicked the first message processor handling the inbound endpoint and see that its payload is the loan amount parameter from the request.

We check that the subsequent message processors are doing their job properly. For example, we click HttpRequestToMap and see that it maps the amount parameter.

Similarly, ScriptTransformer does its transformation work and adds the default loan duration time (not shown). Next, we see that the component processor takes the transformed loan request, does the required component binding to ready the request for a rate quote.

We continue checking each message processor and the payloads for this one flow. Once we determine that processing is as expected, we look at the details of the next flow in the Message List. Or, we skip to the flow where we think there might be a problem. In the figure below, we see that bank5 received the rate request and returned what appears to be the lowest rate.

We check the last invocation of the loan-broker-sync flow and see that it uses four message processors, with the last one converting the rate object to a string so that it can be displayed in the browser.