WSO2 Developer’s Guide
上QQ阅读APP看书，第一时间看更新
上一章目录下一章

Debugging mediation

With debugging mediation, we will be able to debug our service code as we usually do with our Java applications, for instance. In this case, this feature allows us to check how the message is being changed after every step that happens inside our service. Thus, we can see how an operation performed by a mediator modifies the message.

To enable debugging mediation, you have to follow these steps:

  1. In the WSO2EI Tooling top menu, click on Run | Debug Configurations.
  2. Double-click on ESB Mediation Debugger, and a new configuration window will show.
  3. We keep the default values, except for the following:
    • Name: A name for the configuration; for instance, WSO2EIDebugging
    • Serverhost: The host in which we will perform the debugging; in this case, localhost

Note that we do not click on Debug yet, we remain in this screen. We have to wait for a special event during WOS2EI start up to press the debug button.

  1. Now we will start the WSO2EI in debug mode. For this purpose, we will start the server as usual, adding in the -Desb.debug=true command line:
    • On Linux or Mac OS: shintegrator.sh -Desb.debug=true
    • On Windows: integrator.bat --run -Desb.debug=true
  1. We can verify that the ESB has started up in debug mode, and the following messages are shown in the startup log. We have to keep an eye on the startup log, since we should return to the WSO2EI Tooling to click on the debug button when the marked message is shown:

We only have a minute to return to the WSO2EI Tooling to click on the debug button. Otherwise, the WSO2EI will start up without the debugging ability.

  1. When the message is shown, we should return to the WOS2EI Tooling. The debug configuration screen may still be there, waiting for us to finish it. Now, we will click on the debug button, and a new Message Envelope tab should appear in Eclipse:

Now, we are ready to debug our services. In order to illustrate how debugging works, we will work with a simple service that will just set a variable, change the message, and respond. We have still not gone far enough into how to implement our service logic. This will be explained in detail in later chapters.

However, you don't need to understand how the logic is implemented to learn how to debug a service. This is our sample sequence where the logic is implemented:

This sequence is attached as in sequence to a proxy, so that when invoking the proxy this sequence will be launched.

We have generated a new version of the carbon application we built in the previous section that includes the needed artifacts. This carbon application can be found in the book resources, and its name is My1stCompositeApplication_1.0.1.car. We just need to undeploy the previous version; the current version is 1.0.0, which must be replaced with version 1.0.1.

We will follow these steps to debug the service:

  1. The first thing we need prior to debugging our service is to set the breakpoints. We can do that by right-clicking over the mediator in which we want to set the breakpoint. In this case, we set a break point in each mediator:
  1. Check whether there is a red circle in the top-left corner over the mediators with a breakpoint.
  2. Now, we will invoke our My1stProxy service. We can do that by browsing to https://localhost:8243/services/My1stProxy?tryit, which looks like this:

This is a simple testing page that WSO2EI enables for each service deployed. It is called Tryit and we will go further into it later in the book.

  1. We will send a greeting message to the service, so we will replace the default request build by the tryit page with the following one:
<body> 
   &lt;message>How are you?</message> 
</body>

Hence, the tryit request should look as follows:

  1. Now, we will click on Send to send the message to our service; this will trigger the debug mode in WSO2EI Tooling.
  2. We will go to WSO2EI Tooling, and the debugging mode should have been triggered. The first time it is triggered, we should see a message like this:
  1. When we click on Yes, the debug perspective will open:
  1. Congratulations, now you are debugging your first service. We will describe the most useful section on the screen. We can recognize the artifact where debug stops because it has a red square.
  1. You can see the current content of the message in the Message Envelope tab or just by placing the mouse over the current mediator:
  1. In the Message Envelope tab, we can see the raw envelope on the left-hand side, as we said before, and on the right-hand side, we can see other low-level properties sent in the post request, such as Content-Length, host, and SOAP Action:
  1. In the top-right corner, we can check the values of the variables in the flow context:
  1. We can perform the usual debugging actions, such us steping over, terminating, or resuming the flow.
  2. We will step over to the next breakpoint and watch how the variable called MyProperty is populated with the value of the XML tag called &<message> in the request:
  1. We will jump to the next breakpoint, where the response is generated in the mediator, and the message content changes:
  1. Finally, we will finish the execution and check how that message is received in the testing page of the service:
上一章目录下一章