Using the BPEL Designer and Service Engine

Testing a BPEL Process

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

In simple words, the interaction process is as follows:

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.

Creating and Running a Test Case

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

  1. Add a test case to your BPEL project.

  2. Set the test properties.

  3. Customize the test input file.

  4. Run the test case.

All steps in this section assume the following:

Adding a Test Case to your BPEL Project

ProcedureTo add a test case and bind it to a BPEL operation

  1. In the NetBeans IDE Projects window, expand your Composite Application project to expose the Test folder.

  2. Right-click Test, and choose New Test Case from the pop-up menu. This launches the New Test Case wizard.

    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 click Next.

  5. In the Select the Operation to Test step, select the operation you want to test, and click Finish.

    In the Projects tree, a new folder is created under the Test node, containing two files: Input.xml and Output.xml.


    Note –

    If you view the test case in the Files window, you see Concurrent.properties as a third file.


Setting the Test Properties

ProcedureTo set the test properties

  1. In the Projects window, under the Composite Application > Test node, right-click the node for the test case and choose Properties from the pop-up menu.

  2. Set the properties of the test case as follows:

    • Description — string

    • 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 the input file. This file contains the input data for the test case.

    • Output File — (read-only; generated by system)

      Name of the output file. This file contains the output data for the test case.

    • 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

    • Comparison Type — drop-down list with the following options:

      • 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 — drop-down list with the following options:

      • progress — Marks test completion as "success", regardless of actual outcome.

      • done — Records actual outcome of test.

Customizing Test Input

ProcedureTo customize test input

  1. In the Projects window, expand the Test node and the node for a specific test case.

  2. Right-click Input and click Edit.

  3. Modify the contents as needed. 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.

  4. When you are satisfied, click Save.

  5. Right-click Output.xml and choose Edit to examine the contents:

    • If 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. If any differences are detected, they 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 Test Cases

To run a single test case

To run a single test case, right-click the node for your specific test case, and choose Run. Check the Output window for the results.

To run all test cases in a project

To run all test cases in a project, right-click your Composite Application project and choose Test (Alt+F6) from the pop-up menu. Check the Output window for the results.

Looking at Test Case Results

The first time you run your test, the results correctly report that it has failed. This happens because the output produced does not match the (empty) Output.xml file, and the file?s null content is replaced with the output of the first run. If you run the test again without changing the input, the second and subsequent runs report success, since the output matches the contents of Output.xml.

Test results are displayed in the Output window. Detailed results are also displayed in the JUnit Test Results window, which opens automatically when you run a test case. If you change the value in the Input.xml and re-run the test:

If you right-click the test case node and click Diff in the pop-up menu, the window displays the difference between the latest output and the contents of Output.xml.