Designer > BPEL Unit Testing > Editing a B-unit File

Editing a B-unit File

You can design your own B-unit tests with the help of the B-unit editor. Double-click a B-unit file in Project Explorer to open the B-unit editor.

The B-unit editor displays the Design tab, containing an Outline pane and a Details pane. The Outline displays different sections of a B-unit file that you can select to edit in the Details pane.

The following is a description of each node in the B-unit Outline. For more details, select the node name.

• BPEL Unit (Root)

Specifies the BPEL, WSDL, Schema and other resources used in the test. The resources provide data that creates the set of deployed processes and resources for the Process Server engine. When the B-unit test is started, all of these resources are deployed to the engine much as they would be when the standard engine starts up. The standard static analysis rules for Informatica Business Process Developer are run against each BPEL process identified in the B-unit to ensure that there are no errors in the BPEL or environment.

The Trace option controls console logging output. It is enabled by default and can be useful for tracking down assertion failures if the B-unit view does not provide adequate debugging information.

• Extensions and Extension Activities

Extensions specify Logical People Groups that are WS-HT (Human Task) Extensions. Extension Activities specify People activities that are BPEL for People Extension activities.

• Invokes

Specifies invoke activities.

• Alarms

Specifies Wait activities and onAlarm handlers for picks and event handlers. The alarms and invokes elements contain information about each alarm and invoke within the process that is expected to execute during the test. These elements should be thought of as re-active in the sense that they react to the execution of an alarm or invoke within the process. They do not cause an alarm or invoke to execute, but rather wait for the engine to signal that an alarm or invoke has executed and then match that activity within the process to a declaration within the B-unit. Once matched, the B-unit declaration will provide assertions, simulated response/fault/alarm.

• Commands

Sends messages to the B-unit test engine to execute the test logic. The commands element contains all of the commands that are sent into the engine when the B-unit test executes. These elements should be thought of as active in the sense that they are actions taken by B-unit when it starts the test. Each command is executed in sequence. If the command has an asynch="true" attribute then this command is executed on a separate thread. The B-unit test is considered completed when all commands complete. The most common command is the sendMessage command and is the only required command for each B-unit.

BPEL Unit (Root)

Open a B-unit file in the B-unit editor, and select BPEL Unit from the Outline view.

The detail view displays the BPEL, WSDL and other resources used in the B-unit test.

To add resources, specify name, location and type URI. If you are using an XQuery module, the type URI is:

http://modules.active-endpoints.com/2009/07/xquery

At the bottom of the panel is the Trace selection. You can turn trace on or off to control console logging output.

The child elements of BPEL Unit are:

•Extensions
•Extension Activities
•Invokes
•Commands
•Alarms

To add a child element, right-mouse click on BPEL Unit, and select Add.

See also, Editing a B-unit File.

Extensions and Extension Activities

Open a B-unit file in the B-unit editor, and select Extensions or Extension Activities from the Outline view. To add an extension, right-mouse click on BPEL Unit.

Extensions

Extensions specify context information required to run a B-unit that are typically defined in a process deployment description. Currently, extensions specify Logical People Groups that are WS-HT Extensions, and can be used within People activities.

You can define the value for a Logical People Group exactly as you define it in the People tab of the Process Deployment Descriptor Editor. For details about static, dynamic and People Query values.

Extension Activities

Extension Activities refer to People activities. You can assert what goes into a People activity and also to specify a response from the People activity if it includes a task (and not a notification).

You can define a People activity for a B-unit test as follows:

1. Select or add an Extension Activity (a People activity). If this activity is within a loop (for example, a For Each), you can specify a Count for the expected number of times to execute the activity.
2. Add at least one iteration that is the Default iteration. This is the default for how each iteration should run.
3. For each iteration, add the Response type that is the outcome of a task:

- Completed. Specify the Output data returned from the task. The data can be Imported or created Inline. By default, the data is set to be imported. You can set a preference for inline, if desired.

If the data is imported, and if desired, you can add your own XSL files to transform the XML data returned from the task. This allows you to reuse the commonality within the data for different iterations while changing only a few elements of the data. See Tips on Using Parameterized XSL for Input and Assert Data.

If desired, specify the context data; that is, the names of task initiator, actual task owner, and other assignments for the task.

- Failed. Select a Fault to return.
- Expired. The task reached its expiration date, if the expiration is set.
- Skipped. The task was skipped, if the Skippable option is selected in the task.

4. Add Asserts

- Assert Match. Specify a Label that is documentation for this Assert, message part and query for the assert, and a pattern to match on. An example might be to match on data returned from one of the B4P custom functions.
- Assert Equals. Specify the data that should match the data returned.
- Assert Task. Asserts the task details (for example, subject, presentation, and escalations).

See also, Editing a B-unit File and Tips on Using Parameterized XSL for Input and Assert Data.

Invokes

Open a B-unit file in the B-unit editor, and select Invokes from the Outline view. To add an invoke, right-mouse click on BPEL Unit.

A common use case for an invoke is to provide a simulated response for a service that your process is invoking. When an invoke activity within the process executes, the B-unit engine looks for a matching invoke element within the B-unit file. If found, this invoke element provides the ability to do assertions on the input data passed to the invoke as well as provide a message that simulates the response from the service invoke.

B-unit invoke elements can be configured for one-way and two-way service invokes. Both styles of invokes can have assertions on the input data but only two-way service invokes are allowed to have a response.

You can define an invoke for a B-unit test as follows:

1. Select or add an Invoke. Add an Invoke by right-mouse clicking on BPEL Unit.
2. Specify the Name or Location Path of the invoke. If this activity is within a loop (for example, a For Each), you can specify a Count for the expected number of times to execute the activity. Specify a Delay if you want to delay before returning the response. The delay allows for better handling of onEvent and onAlarm events.
3. Add a default iteration.
4. Add the Response type expected:

- Simulated Response. Specify the Output data.
- Subprocess. The invoke is a BPEL process, deployed as a subprocess, making the main process eligible for termination and compensation handling.
- Process. The invoke is a BPEL process, deployed as a "process" invoke handler.
- Simulated Fault. The invoke returns a fault.

5. Add Asserts.

- Assert Match. Specify a Label that is documentation for this Assert, message part and query for the assert, and a Pattern to match on.
- Assert Equals. Specify the input data passed to the invoke.

About Message Part Data

Some information about a message and its associated parts are generated automatically in the B-unit editor when you perform certain actions including:

•Fill in values for process name, partner link and operation for a Send Message.
•Select Simulated Response for an invoke assertion (or extension assertion).
•Select a fault name for a Simulated Fault.

See also, Editing a B-unit File, Tips on Using Assertions, and Tips on Using Parameterized XSL for Input and Assert Data.

Alarms

Open a B-unit file in the B-unit editor, and select Alarms from the Outline view. To add an alarm, right-mouse click on BPEL Unit.

Alarms refer to the wait activity and the onAlarm events in picks and event handlers. You can assert on an alarm deadline or duration.

You can define an alarm for a B-unit test as follows:

1. Select or add an alarm. Add an alarm by right-mouse clicking on BPEL Unit.
2. Specify the Process and Location Path of the alarm-based activity.

- Add the Simulated Duration of the alarm. This is the time the B-unit test will wait for the alarm to be triggered.
- If this activity is within a loop (for example, a For Each), you can specify a Count for the expected number of times to execute the activity.

3. Add a default alarm, and add the duration for the B-unit test to use.
4. Add an Assert.

- Assert Deadline. Specify the actual deadline, converted to a duration, for the B-unit test. Specify a Precision value that is the period of time within which the deadline should fire. This value is specified in seconds.
- Assert Duration. Same as deadline.

5. Add an assert iteration, if desired. If the alarm-based activity is within a loop, add an Index for this iteration. The index is the nth iteration within the count, specified for the alarm.

See also Editing a B-unit File and Editing a B-unit FileTips on Using Assertions

Commands

Open a B-unit file in the B-unit editor, and select Commands from the Outline view. To add a command, right-mouse click on BPEL Unit.

Commands send messages to the B-unit test engine to execute the test logic.

The commands you can add are as follows:

Command	Description
Send Message	Sends WSDL messages to the test engine. Select an Operation for the specified partner link. Delivery Options. - Async. Controls whether or not two receives can execute in a row, without waiting for the reply associated with the first receive to complete - Delay. Wait value that the B-unit waits before starting to check the Timeout. - Timeout. Sets a value for the how long the test engine should wait for process completion. This setting ensures that the invokes complete with the correct count. - Message Context. Optionally specify the meta-data for the incoming message, including the authenticated principal, and other message header data.
Wait Until	Checks for the execution completion of the process. - Delay. Wait value that the B-unit waits before starting to check the Timeout. - Timeout. Sets a value for the how long the test engine should wait for process completion. This setting ensures that the invokes complete with the correct count. - Fail on Timeout. Enable this check box to fail the test if the process does not complete within the timeout value.
Terminate Process	Terminates a process instance for one of the processes in the B-unit test, if you are running more than one process.
Assert Process State	Asserts the execution state of the process that you specify. - Process State. Running, suspended, complete, faulted, final. Select final to assert completed and faulted states. - Process Id. Used only if you are running the test on multiple BPEL files. - Delay. Wait value that the B-unit waits before starting to check the Timeout. - Wait for Async. If you have Async selected in a Send Message command for the same process, this property allows you to wait to assert the process state until all asynchronous activities have completed.

See also, Editing a B-unit File.