Using Logs for Troubleshooting in Intel® SOA Expressway

Intel® SOA Expressway is often used as XML Gateway or Service Gateway and therefore often a consolidation point for XML/SOAP/REST traffic going across a domain. Users often want to use SOA Expressway’s logs to trouble shoot where the problems may lie in services based distributed computing environment.

Intel SOA Expressway provides sophisticated logging capabilities that allow the user to audit and trace any message sent or received through the system. This same facility is also used when debugging applications to see what went wrong. In this blog we will see how easy it is to investigate application failures using the transaction log and variable dumps. Expressway has seven levels of logging, and with transaction logs turned on, the full payload of data sent and received can be examined in detail. To get started, we will first create a simple workflow, run the application, and then inspect the debug output available for that application.

Create the application.
Let’s create the test application that performs a simple operation on an XML document. In this example we’ll take the input string and wrap it with an XML tag <Output>, like this:
Input string -> <Output>Input string</Output>
This simple application will make it easy for us to test the debugging capabilities of Expressway. In our example, we’ll create a simple application and deliberately send messages that will trigger errors to demonstrate debugging. To create the application, start Intel® Services Designer, select File -> New->Intel SOA Expressway Project in the main menu and give that project a name and choose the “simple application” type.

Initially, the new application consists of a workflow file (with .bpel extension), the WSDL file (web service declaration), and an XSD file (data type definitions used in both workflow and WSDL). The simple application template creates a workflow that contains only Receive and Reply actions. We’re going to add some logic between them to process the input. The WSDL created by the template will work fine for our application, so we’re going to leave it as is. The schema, however, created by the template is too simplistic for our case so we’ll change it a bit. Also we’ll add a data file for use in the application.

First, let’s modify the schema of the output message. For this application, we allow any XML content in it (<xsd:any>).
Schema of output mesage

Second, let’s create the XML document that will be a template for output message, and save it in our project, in the same folder with Workflow and WSDL files.
Template of output message

Then, let’s add some logic to the workflow.

In this example we need to read the document contents to a variable. For the sake of simplicity, we’ll take a local document bundled with the application. To do this, pick Data->XML Builder from the palette, match the type to the output message’s type, and build an XPath expression with the extension function soae-xf:document() with the name of the XML document as a parameter. When we give the name “Template” to this action the new variable with the same name will be automatically created to store the result. You can see the XMLBuilder action between the Receive and Result in the following screen shot:
Load ouput message template from a document using XML Builder

Next, we need to modify the document to produce the output message. To do this pick Data->Expression in the palette and place the action to the diagram. The expression action will hold the result. Type “Result” to the name box and then choose $Receive.payload expression in the expression pop-up. This tells the expression set to access the payload from the previous step. Finally, override the expression’s destination to $Template/Output, as shown below. This will modify the $Template variable, instead of creating a new variable.
Create output message

In the last step we can choose the $Template variable to hold the reply. In cases where Expressway is acting as a proxy, the reply might be from a back-end server or partner web service, but for this example the reply is back to the sender without an additional service call.
Send the response

To deploy the application right-click the project name in the project tree, choose Deploy As-> Intel SOAE Application in the pop-up menu, and then type the hostname name of the machine running SOAE Expressway.

Running the application
Once the application has deployed with no errors, it should be ready to receive messages – let’s send some through.
For sending messages I’m going to use the soapUI [1] tool which is a nice GPL tool for dealing with SOAP traffic Create a new project using SOAP UI using File->New->SOAPUI Project and set the initial WSDL to the WSDL from the Expressway application. You’ll need to choose an operation to invoke (there’s only one operation in our application). Once the WSDL is selected, soapUI will automatically create a valid input message for that operation, based on the WSDL.

In the raw request view I’ve typed “Hello” as the request content and changed the destination address. You can see this in the following picture:
Request message

You can press the green button on the toolbar to send the message and see the result.
The fault message from application
Here is where things get interesting – the response message doesn’t contain “Hello” and shows an error instead. Let’s find out what happened.

Investigating the failure
First we’ll use the dashboard to get some basic information. The dashboard will allow is to instantly see if the request passed or failed. Next, we’re going to inspect the transaction logs and see what happened to the application.

Let’s open the management console and take a look at the dashboard: it shows that one request has recently failed.
Management Console dashboard

To get more information we need to adjust the log levels and send one more message (by default, only high-level information is written to the logs). Under “Global Logs Levels” on the web interface we can set the “Workflow Engine” component level to TRACE, l which turns on the transaction logs.

Let’s send the message again and observe what happens. The transaction log will show a failed transaction:
Transaction log in logs browser

You can drill-down into the failure by clicking the arrow to get more information. Here we can see the error message that we’ve received (“Uncaught BPEL fault…”) as well as additional trace entries just before the failure.
Transaction log drill down

Open the log exception entry by clicking the “+” next to it. The error message tells that something’s wrong with the expression $Template/Output – it unexpectedly returned an empty node set.
Exception message

Now let’s look through the previous log entries by clicking “<” button to find most recent variable values prior to the error.
Variable contents

We can see now that the Template variable really doesn’t contain the <Output> element. In order application we’ve tried to write some data to $Template/Output so its’ no surprise that the workflow engine ran into a problem.

Fix the bug and try again
The problem with the sample application was caused by the template for the output message. It’s loaded by the function soae-xf:document(), which was called in the XML Builder action (the Template action in our original application). To fix the problem, we should add an artificial root element to the XML document, as shown below. Once this is done, the XML Builder would work normally, as it strips the root element of the loaded document. Alternatively, we may also use an Expression action, which doesn’t strip the root element of the loaded document.

After modifying the application by adding an artificial root element we can redeploy it and send one more message.
Corrected template of output message

This time the message is processed smoothly. The output looks good: the text “Hello” is wrapped with the <Output> element with the appropriate namespace declaration.
Successful reply from the application

The dashboard also shows that the last request was processed successfully. The original failed requests are summed on the dashboard.

If we look at the logs, we’ll see that the transaction has completed successfully. The previous (failed) transaction is shown here as well.
Suggessful transaction in logs browser

The variable dump shows the output message. If you use the “” (next) buttons, you can see how the variables were modified during the workflow execution.
Variable values

SOA Expressway provides the capabilities for detecting and troubleshooting application problems and bugs through the use of the transaction logs. If an error was detected, you can inspect the data being processed and see how the variables were changed at every step of execution of the workflow. For more information check out or

[1] soapUI –

For more complete information about compiler optimizations, see our Optimization Notice.