Testing and Debugging

This section discusses how you can use the seamless IDE integration of the UltraESB to test, debug and fix the solution that you develop before deploying it on production or even in integration environment. With almost all the other ESBs testing a solution will require you to build the artifact and deploy it on an integration environment to test it. This process leads to a major drawback of the software testing theories. In software engineering, the modern software life-cycle contains 2 phases of testing as follows;

  1. Developer testing (White-Box testing) - to make sure the solution that you develop works at least on the proper flow

  2. Integration testing (Black-Box testing) - to make sure that the solution delivers what it meant to be, on an environment which is nearly equal to that of the target production environment and the testing of the exception flows.

While the integration testing (quality assurance) of-course needs an integration environment and a deployable artifact for testing, the developer testing just need to make sure that the functionality that the developers develop are correct. This is very close to writing unit tests for verifying the functionality that is being developed. This chapter mainly focuses on the developer testing and debugging of the solution within the IDE while the integration testing requires an integration environment and a deployment.

The rest of this documentation selects a sample solution and shows you how to run it within the IDE, test it, debug it and fix the issues if there are any to complete the development phase of the solution.

Sample Solution

The Solution Development section extensively describes how you can develop a solution, for this section we are going to select a sample solution that will help the explanation of the rest of the functionality testing and debugging.

This solution is a simple "hello-world" deployment unit with the configuration which consists of a proxy service, 2 endpoints and 2 sequences. The following code segments shows the ultra-unit.xml file with the sample configuration that we are going to use in the testing and debugging.

Sample deployment unit configuration

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xmlns:u="http://www.adroitlogic.org/ultraesb"
  xsi:schemaLocation="
http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-4.2.xsd
http://www.adroitlogic.org/ultraesb http://schemas.adroitlogic.org/ultraesb/v2_6/ultraesb-artifacts.xsd">

  <u:proxy id="MyFirstProxy">
    <u:transport id="http-8280"/>
    <u:target inSequence="MyFirstSequence" inDestination="MyFirstEndpoint">
      <u:outSequence>
        <u:java><![CDATA[
          System.out.println("Reply payload : " + mediation.readPayloadAsString(msg));
        ]]></u:java>
      </u:outSequence>
      <u:outDestination>
        <u:address type="response"/>
      </u:outDestination>
    </u:target>
  </u:proxy>

  <u:endpoint id="MyFirstEndpoint">
    <u:address>http://localhost:9000/service/EchoService</u:address>
  </u:endpoint>

  <u:sequence id="MyFirstSequence">
    <u:class name="sample.SimpleJavaMediation1"/>
  </u:sequence>

</beans>

The above configuration contains a proxy service named "MyProxyService" with the in sequence of the proxy service being referred to a defined sequence with the identifier "MyFirstSequence", in destination referred to a defined endpoint with the identifier"MyFirstEndpoint", the out sequence and out destination both in-lined as a Java fragment sequence and a response type endpoint respectively.

The sequence "MyFirstSequence" has been defined as a byte code sequence, referring to the class with a fully qualified class name "sample.SimpleJavaMediation1", a sample byte code sequence shipped with UltraESB, of which the source can be found under the conf > mediation > src > java file path in the UltraESB installation home.

Adding your own sequence class
Your own byte code sequence can also be referred as in the sample class that we used for the configuration, in which case you need to add the source file of that class in addition to the binary file into the UltraRuntime project, as we are going to use the IDE to test and debug this solution.

You may follow the guide with this configuration, in which case you need to copy this configuration and replace the content of your ultra-unit.xml or use your own developed deployment unit configuration and map the relevant sections to your configuration in following the guide.

Running the Solution

For running the UltraESB with the above configuration or the configuration you developed in the deployment unit, there is a built in UltraESB runtime configuration. This profile loads the content from the standard conf directory so any deployment units will be loaded and installed at startup apart from the ultra-root.xml configuration.

Switch to the UltraESB runtime configuration as shown below (1) and run it (2) to run the ESB with the given configuration.

running

When you click on the Run button on the top tool bar, you will be able to see the Run panel in the bottom of the window as follows, with the console log written into the panel.

run pane

That is just what you need to do to run the solution you developed, regardless of the fact whether you have sequences/endpoints in-lined or referred and the sequences could be bytecode, Java fragments or whatever theĀ  types, etc.. This makes it easy to run the solution while developing and it drops the development time drastically as you are just on the IDE and no need to start the ESB separately or deploy the solution to test in on a separate location.

Testing the Solution

Now that the solution that we have been developing is running, we can test it to see whether you see the expected behaviour from the complete application by sending a sample message through the running solution.

SOA Toolbox

For testing the solution, the SOA Toolbox can be used, which supports many convenient tools. In this particular case we have to expose a service named "EchoService" running on the port 9000 on the localhost as the back-end service, and a client to invoke the proxy service in our solution. While you can use any mock service (depending on your requirement of the actual service and its behaviour, or even you could use the actual service that you are targeting to switch to at production if it is of no harm to test over it) to replace the back-end service emulated by the toolbox, we recommend using the SOA Toolbox as the client.

SOA Toolbox supports many advance features for sending sample test messages emulating slow connections etc.. which make it really usable for testing the solution. The complete guide on the SOA Toolbox helps you understand the advance features of the Toolbox and how to use those.

Start the toolbox shipped in with the UltraESB to spin a server and a client to invoke this solution and test it.

In Unix based systems, navigate to the "bin" directory of the UltraESB installation, using a console.

$ cd /opt/ultraesb-2.6.1/bin
$ ./toolbox.sh

On Windows based systems, use the file explorer to navigate to the "bin" directory of the UltraESB installation and double click on the "toolbox.bat" file to launch the Toolbox.

Running the back-end service

SOA Toolbox ships with a service named "EchoService" configured to deploy on Jetty Server, so we are going to run that service as the back-end service for this illustration on testing the solution.

Click on the "File" menu and select New > Jetty Server from the cascading menu or alternatively the Ctrl+J shortcut key to create a new Jetty Server instance which hosts the sample services used by UltraESB.

toolbox jetty server menu

Now you should see the Jetty Server panel tab on the Toolbox application. Click on the "Start Jetty" button on the top of the pane just after the port as shown below by (1), to start the Jetty Server with the sample EchoService hosted on it;

toolbox jetty server pane scaled

You should see the Start Jetty button as a disabled button and the Stop Jetty button as an active button, once the sample Jetty server has completed starting. Once it is started, the EchoService on port 9000 having the service URL http://localhost:9000/service/EchoService should be ready.

Invoking the proxy via the client

Next we use the HTTP/S client of the Toolbox to invoke the proxy service that we have developed.

Click on the "File" menu and select New > HTTP/S Client from the cascading menu or alternatively the Ctrl+C shortcut key to create a new HTTP/S Client instance which can be used to post any HTTP/S message.

toolbox http client menu ug

Now you should see the HTTP/S Client panel tab on the Toolbox application. Using this client application we can invoke the proxy service that we have developed in our solution. To invoke the proxy service, follow the steps given below, and the respective action on the screen shot.

  1. Type the URL of the invoking service to be "http://localhost:8280/service/MyFirstProxy".

  2. Check the HTTP method on the right side of the URL to be "POST" meaning that we are going to do a HTTP POST request to the given URL.

  3. Then select the HTTP message body to be sent to the service. There are 4 pre-sets available out of which we are going to use the first one, so click on the "1" pre-set message body.

  4. Observe the message body filled in with the pre-set message 1 on the request pane

  5. Click on the "Send" button in the middle of the request and response panes to invoke the proxy service with the given message body.

  6. On the response pane you should be able to see the response, if the proxy is working from an external users point of view