Developer Guide to BPEL Designer: Testing and Debugging BPEL Processes

Last Updated: 23 October 2006
Contributed by Bob May and Wallis Sholar, maintained by Dmitry Markovski

Contents

Developer Guide to BPEL Designer


Testing a BPEL Process

Testing a deployed business process application involves using test cases that act as remote partner services which send SOAP messages to the BPEL Service Engine runtime.

The BPEL Service Engine runtime receives the SOAP message and creates an instance of the BPEL process and starts executing the instance. A BPEL process can have many running instances. The BPEL Service Engine runtime receives a message and, using correlation, routes it to the appropriate instance of the process. If an instance does not exist yet, a new instance is created.

To test-run a deployed business process application, you need to configure test cases to act as remote partner services sending SOAP messages to the BPEL Service Engine runtime.

Creating and Running a Test Case

In order to obtain test results you must do the following:

  1. Add a test case and bind it to a BPEL operation.
  2. Set the test properties.
  3. Customize test input.
  4. Run the Tester.

All steps in this section assume the following:

Adding/Binding a Test Case

To add a test case and bind it to a BPEL operation:

  1. In the IDE Projects tab, open the Composite Application project to expose its Test folder.
  2. Right-click Test, and choose pop-up menu item New Test Case.
    This launches the New Test Case wizard.
  3. In the Enter the Test Case Name step, enter a name for the test case and click Next.
  4. In the Select the WSDL Document step, open the BPEL Module project, select the .wsdl file containing the operation you want to test, and then click Next.
  5. In the next step, select the operation you want to test, and then click Finish.
    In the project tree, under Test, a new folder is created in the form of an upper case T, containing two files: Input.xml and Output.xml.

If you viewed the test case in the Files tab, you would see Concurrent.properties as a third file.

Setting the Test Properties

To set the test properties:

  1. Right-click the test case and choose pop-menu item Properties.
  2. Set the properties of the test case as follows:
    Description : string
    User-entered text to help user know what the test is about.
    Destination : URL (from the .wsdl file's <soap:address location="THIS"> tag)
    Identifies the location of the web service to be tested.
    SoapAction (default: blank)
    Input File (read-only; generated by system)
    Name of input file.
    Output File (read-only; generated by system)
    Name of output file.
    Concurrent Threads : integer; default = 1
    Each thread can invoke the test case multiple times (see the following property). Thus, if conc=2 and inv=3, the test case will be run 6 times (two threads, each run thrice).
    Invokes Per Thread : integer; default = 1
    Number of times each thread invokes the test case.
    Test Timeout(sec) : integer; default = 30
    How long each thread has to finish. If it does not finish in the allotted time, then an exception is thrown.
    Calculate Throughput : boolean
    If the checkbox is selected, then throughput statistics are calculated. Example: If a test specifies two threads and three invokes per thread, and if the test takes 15 seconds for the 6 invocations, then the statistics report an average of 2.5 seconds each.
    Comparison Type : pull-down list:
    • identical: Considers the output and actual output as a stream of characters.
    • binary: Considers the output and actual output as a stream of bytes.
    • equals: Considers the output and actual output as a XML documents.
    Feature Status : pull-down list:
    • progress: Marks test completion as "success", regardless of actual outcome.
    • done: Records actual outcome of test.

Customizing Test Input

To customize test input:

  1. In the project tree, right-click Input.xml and click Edit.
  2. Modify its contents to your taste. For example, wherever you see <value>?string?</value> click within ?string? and replace it with a string of any length. However, within such strings, do not include the characters < (less-than sign) or & (ampersand) unless you use them with XML semantics.
  3. When you are satisfied, click Save.
  4. Right-click Output.xml and click Edit to examine its contents:
    • It is empty. This is a special state that triggers a special operation when the test is run.
    • Each time the test is run, the current output is compared to the contents of Output.xml; whatever differences are detected will be stored in the Actual_yymmddhhmmss.xml file under the test case folder. However, in the special case where Output.xml starts null, then the output is written to Output.xml.
    • In each run after the first, assuming Output.xml is no longer null, its contents are preserved. In other words, a previous output is never overwritten by new results.

Running the Tester

To run a single test case:

To run all test cases in a project:

Looking at Test Case Results

top


Debugging BPEL Processes

Debugging BPEL processes follows the same general principles as debugging Java applications. Debugging BPEL processes is accomplished by setting breakpoints in the source code or on the diagram and executing the process step-by-step within a debugging session.

Steps in Debugging BPEL Processes

The main steps in debugging BPEL processes are:

  1. Make sure that the Sun Java Application Server is running.
  2. Make sure that the BPEL engine DebugEnabled property is set to true.
  3. Open the BPEL process either in the Source view or Design view.
  4. Set breakpoints in the code or on the diagram. Optionally, add watches for XPath expressions in your process.
  5. Start a debugging session. Watch the BPEL Debugger Console window for confirmation that the debugging session has started.
  6. Within the debugging session, view running instances of BPEL possesses in the BPEL Process Instances window, examine the values of variables in the BPEL Variables window and observe the values of XPath expressions in the Watches window.
  7. When an instance stops at a breakpoint step through the code or the diagram to examine its execution.
  8. Finish the debugging session.

Starting and Finishing a BPEL Debugging Session

A debugging session starts when you attach the BPEL Debugger to the BPEL Service Engine. Only one debugging session can be running on the BPEL Service Engine.

After a debugging session starts, you can execute process instances step-by-step, inspecting process instance variables and/or values of the XPath expressions.

To prepare the debugging environment:

  1. In the Runtime window, make sure that the Sun Java System Application Server is running. The Application Server is running if it has subnodes and is marked with a green triangle.

    Application Server is running

  2. Set breakpoints into the BPEL source
    • To set breakpoints in the Source view, click next to the line you want to set the breakpoint at.

      Set a breakpoint in the source

    • To set breakpoints on the diagram, switch to the Design view, right-click the element and choose Toggle Breakpoint from the pop-up menu.

      Set a breakpoint on the diagram

      A red square appears at the top of the element with a breakpoint.

      Diagram Element with a Breakpoint

    • The Toggle Breakpoint pop-up menu command is also available for the elements in the Navigator BPEL Logical View. For the elements with breakpoints, the Navigator shows a small red box like the one in the following screenshot (ReceiveItinerary):

      Navigator Element with a Breakpoint

  3. Optionally, you can add watches to monitor XPath expressions. To add a watch, copy the XPath expression you want to monitor, choose Run > Add Watch from the main menu, and paste the expression into the Watch Expression field. Click OK.
    Note: You can also add XPath expressions that are not present in the code, but would be valuable from the debugging point of view.

    Set a breakpoint in the source

  4. The first time you debug, set the BPEL engine DebugEnabled property to true:
    • In the Runtime window, expand Servers > Sun Java System Application Server > Service Engines
    • Right-click the com.sun.bpelse-1.0-2 node and choose Properties

      BPEL Service Engine

    • Set DebugEnabled to true

To start a debugging session on the BPEL Engine:

  1. Choose Run > Attach Debugger.
  2. In the Attach dialog box, select BPEL Debugger as the debugger type.
  3. Ensure that the name of the host is localhost and the port is 3343.
  4. Click OK.

The IDE now establishes a debug session on the BPEL Engine. Watch the BPEL Debugger Console window for confirmation. The connection can take some time to complete. When it is completed successfully, you see the new session in the Sessions window and the following message in the BPEL Debugger Console:

22:17:55 Connecting to localhost:3343
22:17:55 Debug session started

If you have several debugging sessions (you may have a Java debugging session running at the same time) and want to change the current session, double-click the name of this session in the Sessions window. Alternatively, right-click the session you want to make current and select Make current.

This session becomes current and the BPEL Process Instances, Watches and BPEL Variables windows are updated to show the data related to the new current session.

When you want to finish a debugging session, open the pop-up menu for the session you want to stop and choose Finish in the Sessions window or select Finish Debugger Session on the toolbar. A message that the debugging session is finished is displayed in the BPEL Debugger Console.

To finish all debugging sessions, in the Sessions window, right-click any session and choose Finish All.

BPEL Debugger Windows

When a debugging session starts, the IDE displays debugger windows below the IDE editing area. The Sessions, BPEL Process Instances, Watches and BPEL Variables windows contain information related to BPEL processes running within the current debugging section.
Note: If a debugger window is not displayed, choose Window > Debugging > BPEL > window-name (for example, Window > Debugging > BPEL > BPEL Variables).

The Call Stack, Breakpoints and Watches are standard IDE debugger windows. The Call Stack window is not used in debugging BPEL processes, so you can ignore it. The Breakpoints window reflects all breakpoints currently set in the IDE, including breakpoints in BPEL processes. The Watches window lists all expressions that you have specified to watch while debugging.

To switch between debugger windows, click the tab with the window name.

Sessions Window

The Sessions window lists all debugging sessions, including Java and BPEL debugging sessions, that are currently running in the IDE. Only one session can be started for the BPEL Engine and only one session can be current (this session is shown in bold). Other debugger windows, such as BPEL Process Instances, Watches and BPEL Variables, display process instances, expressions and variables related only to the current debugging session.

The information provided for each session includes:

You can perform the following actions on sessions available in the pop-up menu:

BPEL Process Instances Window

The BPEL Process Instances window lists all BPEL process instances running on the BPEL Engine within the current debugging session. If the current session is not a BPEL Debugger session, this window is empty. The BPEL Process Instances window is populated when a debugging session is started on the BPEL Engine or a BPEL Debugger session becomes current.

The information displayed for each process instance includes the instance name and its state. Process instances can be in one of the the following states:

BPEL Variables Window

The BPEL Variables window shows the list of BPEL variables and their values for the current process instance and current position. The current position is a place at which the current process instance became suspended. When you change the current process instance, the records in the BPEL Variables window are updated to reflect the variables for the new current process instance and the new current position.

The information provided for each variable includes the variable name and value.

Watches Window

The Watches window shows a list of XPath expressions that you want to monitor. You add watches explicitly before or during the debugging session. The Watches window shows the expression and its value. The value of the expression may change as the process advances depending on the logic of your process.

Using Breakpoints to Debug BPEL Processes

Breakpoints are used to instruct the debugger to suspend execution of a process at that place of the source code. When a BPEL process reaches a breakpoint, it becomes suspended and you can perform debugging operations, such as examining the values of variables or stepping into your code.

To view and organize all breakpoints currently set in the IDE, open the Breakpoints window by choosing Windows > Debugging > BPEL > Breakpoints (Alt-Shift-5). For each breakpoint, you can see the name of the source file and the line where this breakpoint is located.

After you set breakpoints in your BPEL Process and start a debugging session, any process instance that reaches a breakpoint becomes suspended. You can view the status of process instances in the BPEL Process Instances window.

To debug a process instance that has reached a breakpoint:

Once the execution of a process instance is suspended, choose the following commands from the Run menu or on the toolbar:

You can remove a breakpoint from the BPEL source code by placing the cursor at the line with the breakpoint and choosing Run > Toggle Breakpoint, or clicking the left margin of the line that contains the breakpoint. Alternatively, on the diagram, you can right-click the element that has a breakpoint and choose Toggle Breakpoint from the pop-up menu.

top


Copyright and Trademark Notice