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.

In simple words, the interaction process is the following: 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 yet exist, 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. Setting the Test Properties.

3. Customize test input.

4. Run the Tester.

All steps in this section assume the following:

• You have already Creating a new BPEL Module Project containing a WSDL file that defines an operation you want to test.

• You have successfully Building a BPEL Module Project.

• You have added your BPEL Module project to a Composite Application project as a JBI Module.

Adding/Binding a Test Case

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

1. In the IDE Projects window, 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, containing two files: Input.xml and Output.xml.

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

Setting the Test Properties

To 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

To customize test input:

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

2. Right-click Input.xml 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 click Edit to examine the 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. 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 the Tester

To run a single test case:

1. In the Projects window, expand the Composite Application project > Test, right-click the node for the specific test case and choose Run.

To run all test cases in a project:

1. Right-click the Composite Application project and choose Test Project from the pop-up menu.

Looking at Test Case Results

• The first run correctly reports that it 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.

• Test results are shown in the JUnit test results window, which opens automatically when you run a test case.

• If you run the test again without changing the input, second and subsequent runs report success, since the output matches the contents of Output.xml.

• If you change the value in the Input.xml and re-run the test, then:

  • If the feature-status property is set to progress, then the test indicates success even though a mismatch occurred.

  • If the feature-status property is set to done, then the test indicates failure.

• 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.