此内容没有您所选择的语言版本。

Chapter 7. Debugging a routing context

This tutorial shows how to use the Camel debugger to find logic errors for a locally running routing context.

Goals

In this tutorial you complete the following tasks:

Set breakpoints on the nodes of interest in the two routes
In the Debug perspective, step through the routes and examine the values of message variables
Step through the routes again, changing the value of a message variable and observing the effect

Prerequisites

To start this tutorial, you need the ZooOrderApp project resulting from one of the following:

Complete the Chapter 6, Adding another route to the routing context tutorial.
or
Complete the Chapter 2, Setting up your environment tutorial and replace your project’s blueprint.xml file with the provided blueprintContexts/blueprint3.xml file, as described in the section called “About the resource files”.

Setting breakpoints

In the Debugger, you can set both conditional and unconditional breakpoints. In this tutorial, you only set unconditional breakpoints. To learn how to set conditional breakpoints (that are triggered when a specific condition is met during the debugging session), see the Tooling User Guide.

To set unconditional breakpoints:

If necessary, open your ZooOrderApp/src/main/resources/OSGI-INF/blueprint/blueprint.xml in the route editor.
In Project Explorer, expand Camel Contexts src/main/resources/OSGI-INF/blueprint/blueprint.xml to expose both route entries.
Double-click the Route_route1 entry to switch focus to Route_route1 in the Design tab.
On the canvas, select the Choice_choice1 node, and then click its icon to set an unconditional breakpoint:
Note
In the route editor, you can disable or delete a specific breakpoint by clicking the node’s icon or its icon, respectively. You can delete all set breakpoints by right-clicking the canvas and selecting Delete all breakpoints.
Set unconditional breakpoints on the following Route_Route1 nodes:
- Log_log1
- SetHeader_setHeader1
- To_Invalid
- Log_log2
- SetHeader_setHeader2
- To_Fulfill
In Project Explorer, double-click Route_route2 under src/main/resources/OSGI-INF/blueprint to open Route_route2 on the canvas.
Set unconditional breakpoints on the following Route_Route2 nodes:
- Choice_choice2
- SetHeader_setHead_usa
- Log_usa
- To_US
- SetHeader_setHead_ger
- Log_ger
- To_GER

Stepping through the routing context

You can step through the routing context in two ways:

Step over ( ) - Jumps to the next node of execution in the routing context, regardless of breakpoints.
Resume ( ) - Jumps to the next active breakpoint in the routing context.
1. In Project Explorer, expand the ZooOrderApp project’s Camel Contexts folder to expose the blueprint.xml file.
2. Right-click the blueprint.xml file to open its context menu, and then click Debug As Local Camel Context (without tests).
  The Camel debugger suspends execution at the first breakpoint it encounters and asks whether you want to open the Debug perspective now:
3. Click Yes.
  Note
  If you click No, the confirmation pane appears several more times. After the third refusal, it disappears, and the Camel debugger resumes execution. To interact with the debugger at this point, you need to open the Debug perspective by clicking Window Open Perspective > Debug.
  The Debug perspective opens with the routing context suspended at _choice1 in _route1 [blueprint.xml] as shown in the Debug view:
  Note
  Breakpoints are held for a maximum of five minutes before the debugger automatically resumes, moving on to the next breakpoint or to the end of the routing context, whichever comes next.
4. In the Variables view, expand the nodes to expose the variables and values available for each node.
  As you step through the routing context, the variables whose values have changed since the last breakpoint are highlighted in yellow. You might need to expand the nodes at each breakpoint to reveal variables that have changed.
5. Click to step to the next breakpoint, _log2 in _route1 [blueprint.xml]:
6. Expand the nodes in the Variables view to examine the variables that have changed since the last breakpoint at _choice1 in Route1 [blueprintxt.xml].
7. Click to step to the next breakpoint, _setHeader2 in Route1 [blueprint.xml].
  Examine the variables that changed (highlighted in yellow) since the breakpoint at _log2 in Route1 [blueprint.xml].
8. In the Debug view, click _log2 in _route1 [blueprint.xml] to populate the Variables view with the variable values from the breakpoint _log2 in _route1 [blueprint.xml] for a quick comparison.
  In the Debug view, you can switch between breakpoints within the same message flow to quickly compare and monitor changing variable values in the Variables view.
  Note
  Message flows can vary in length. For messages that transit the InvalidOrders branch of Route_route1, the message flow is short. For messages that transit the ValidOrders branch of Route_route1, which continues on to Route_route2, the message flow is longer.
9. Continue stepping through the routing context. When one message completes the routing context and the next message enters it, the new message flow appears in the Debug view, tagged with a new breadcrumb ID:
  In this case, ID-janemurpheysmbp-home-55846-1471374645179-0-3 identifies the second message flow, corresponding to message2.xml having entered the routing context. Breadcrumb IDs are incremented by 2.
  Note
  Exchange and Message IDs are identical and remain unchanged throughout a message’s passage through the routing context. Their IDs are constructed from the message flow’s breadcrumb ID, and incremented by 1. So, in the case of message2.xml, its ExchangeId and MessageId are ID-janemurpheysmbp-home-55846-1471374645179-0-4.
10. When message3.xml enters the breakpoint _choice1 in _route_route1 [blueprint.xml], examine the Processor variables. The values displayed are the metrics accumulated for message1.xml and message2.xml, which previously transited the routing context:
  Timing metrics are in milliseconds.
11. Continue stepping each message through the routing context, examining variables and console output at each processing step. When message6.xml enters the breakpoint To_GER in Route2 [blueprint.xml], the debugger begins shutting down the breadcrumb threads.
12. In the Menu bar, click to terminate the Camel debugger. The Console terminates, but you must manually clear the output.
  Note
  With a thread or endpoint selected under the Camel Context node in the Debug view, you must click twice - first to terminate the thread or endpoint and second to terminate the Camel Context, thus the session.
13. In the Menu bar, right-click to open the context menu, and then select Close to close Debug perspective.
  Developer Studio automatically returns to the perspective from which you launched the Camel debugger.
14. In Project Explorer, right-click the project and then select Refresh to refresh the display.
  Note
  If you terminated the session prematurely, before all messages transited the routing context, you might see, under the ZooOrderApp/src/data folder, a message like this: message3.xml.camelLock. You need to remove it before you run the debugger on the project again. To do so, double-click the .camelLock message to open its context menu, and then select Delete. When asked, click OK to confirm deletion.
15. Expand the ZooOrderApp/target/messages/ directories to check that the messages were delivered to their expected destinations:

Leave the routing context as is, with all breakpoints set and enabled.

Changing the value of a variable

In this section, you add variables to a watch list to easily check how their values change as messages pass through the routing context. You change the value of a variable in the body of a message and then observe how the change affects the message’s route through the routing context.

To rerun the Camel debugger on the ZooOrderApp project, right-click the blueprint.xml file and then click Debug As Local Camel Context (without tests).
With message1 stopped at the first breakpoint, _choice1 in _route1 [blueprint.xml], add the variables NodeId and RouteId (in the Exchange category) and MessageBody and CamelFileName (in the Message category) to the watch list.
For each of the four variables:
1. In the Variables view, expand the appropriate category to expose the target variable:
2. Right-click the variable (in this case, NodeId in the Exchange category) to open the context menu and select Watch:
  The Expressions tab opens, listing the variable you selected to watch:
  Note
  Creating a watch list makes it easy for you to quickly check the current value of multiple variables of interest.
Step message1 through the routing context until it reaches the fourth breakpoint, _Fulfill in _route1 [blueprint.xml].
In the Variables view, expand the Message category.
Add the variable Destination to the watch list.
The Expressions view should now contain these variables:
Note
- The pane below the list of variables displays the value of the selected variable.
- The Expressions view retains all variables that you add to the list until you explicitly remove them.
Step message1 through the rest of the routing context and then step message2 all of the way through.
Stop message3 at _choice1 in _route1 [blueprint.xml].
In the Variables view, expand the Message category to expose the MessageBody variable.
Right-click MessageBody to open its context menu, and select Change Value:
Change the value of quantity from 15 to 10 (to change it from an invalid order to a valid order):
This changes the in-memory value only (it does not edit the message3.xml file).
Click OK.
Switch to the Expressions view, and select the MessageBody variable.
The pane below the list of variables displays the entire body of message3, making it easy to check the current value of order items:
Click to step to the next breakpoint.
Instead of following the branch leading to To_Invalid, message3 now follows the branch leading toTo_Fulfill and Route_route2.

Narrowing the Camel debugger’s focus

You can temporarily narrow and then re-expand the debugger’s focus by disabling and re-enabling breakpoints:

Step message4 through the routing context, checking the Debug view, the Variables view, and the Console output at each step.
Stop message4 at _choice1 in _route1 [blueprint.xml].
Switch to the Breakpoints view, and clear each check box next to the breakpoints listed below _choice1. Clearing the check box of a breakpoint temporarily disables it.
Click to step to the next breakpoint:
The debugger skips over the disabled breakpoints and jumps to _FulFill in _route1 [blueprint.xml].
Click again to step to the next breakpoint:
The debugger jumps to _GER in _route2 [blueprint.xml].
Click repeatedly to quickly step message5 and message6 through the routing context.
Switch to the Breakpoints view, and check the boxes next to all breakpoints to reenable them.

Verifying the effect of changing a message variable value

To stop the debugger and check the results of changing the value of `message1’s quantity variable:

In the tool bar, click to terminate the Camel debugger:
Click the Console’s button to clear the output.
Close the Debug perspective and return to the perspective from which you launched the Camel debugger.
In Project Explorer, refresh the display.
Expand the ZooOrderApp/target/messages/ directories to check whether the messages were delivered as expected:
You should see that only message1 was sent to the invalidOrders and that message3.xml appears in the validOrders/Germany folder.

Next steps

In the Chapter 8, Tracing a message through a route tutorial, you trace messages through your routing context to determine where you can optimize and fine tune your routing context’s performance.