2 Preparing to Use the Composite Application Validation System

Before you start creating and running tests in the Composite Application Validation System (CAVS), take the time to gather your test requirements and plan your approach to using CAVS.

This chapter provides a high-level discussion of questions you should answer to help gather requirements for the tests you want to create and run in the CAVS.

This chapter includes the following sections:

2.1 What Can I Test Using CAVS?

The CAVS supports the following testing scenarios:

  • Create and execute test definitions against actual services in participating applications.

  • Create and execute test definitions that call services that call simulators, which simulate actual services in participating applications.

  • Use actual services in participating applications in cooperation with simulators to simulate any unavailable services.

2.2 What Are the Oracle AIA Components That I Need to Test?

Examine the components involved in the scenario that you need to test. Which of the following components does the scenario include?

  • Requester Application Business Connector Services (ABCSs)

  • Provider ABCSs

  • Enterprise Business Flows (EBFs)

  • Exposed services in participating applications

2.3 Which Message Exchange Pattern Is Being Used by the Components Being Tested?

This section includes the following topics:

Once you have assessed which components you need to test, identify the message exchange pattern (MEP) being used by the components to help you determine which types of CAVS test and simulator definitions you need to create. Based on the sequence of service calls and the MEPs employed, you can determine if you need to use synchronous, notify, or asynchronous two-way test definitions and/or simulator definitions.

This section discusses CAVS process flows for testing the following MEPs:

  • Synchronous (request-and-response)

  • Asynchronous (notify)

  • Asynchronous (two-way)

Note:

The information in this chapter provides CAVS processing details that can inform your creation of test and simulator definitions in the CAVS user interface (UI). As you prepare to define and run tests for a particular web service, refer to the section in this chapter that corresponds to the message exchange pattern of the service you want to test.

2.3.1 Describing CAVS Process Flows for Testing the Synchronous Message Exchange Pattern

The following diagrams describe CAVS process flows for testing a provider ABCS using a synchronous MEP.

These sample flows can be used as the basis for testing other artifacts as well, such as requester ABCSs, EBFs, or provider services.

Synchronous MEP Testing Flow Using a Test Definition

The requester participating application is replaced by the CAVS test definition. The test definition points to the URL of the requester ABCS. It uses a composed request message to invoke the ABCS and expects a message in response.

Figure 2-1 illustrates testing a synchronous MEP using a CAVS test definition.

Figure 2-1 Testing a Synchronous MEP Using a CAVS Test Definition

This image is described in surrounding text

Synchronous MEP Testing Flow Using a Test Definition and Simulator Definition

The requester participating application is replaced by the CAVS test definition. The test definition points to the URL of the requester ABCS. It uses a composed request message to invoke the ABCS and expects a message in response.

The provider participating application is replaced by the CAVS simulator definition. The provider ABCS is programmed to route to this simulator instead of the provider participating application. The simulator definition contains a predefined request and response message pair.

The simulator definition performs validations on message input from the provider ABCS and sends the message back to the provider ABCS. The provider ABCS sends the message back to the test definition, which validates this actual response against its predefined expected response.

Figure 2-2 illustrates testing a synchronous MEP using CAVS test and simulator definitions.

Figure 2-2 Testing a Synchronous MEP Using a CAVS Test Definition and Simulator Definition

This image is described in surrounding text

Synchronous MEP Testing Flow Using a Simulator Definition

The provider participating application is replaced by the CAVS simulator definition. The provider ABCS is programmed to route to this simulator instead of the provider participating application. The simulator definition contains a predefined request and response message pair.

The simulator definition performs validations on message input from the provider ABCS and sends the message back to the provider ABCS. The provider ABCS sends the message back to requester participating application.

Figure 2-3 illustrates testing a synchronous MEP using a CAVS simulator definition.

Figure 2-3 Testing a Synchronous MEP Using a CAVS Simulator Definition

This image is described in surrounding text

2.3.2 Describing CAVS Process Flows for Testing the Asynchronous (Notify) Message Exchange Pattern

The following diagrams describe CAVS process flows for testing a provider ABCS using an asynchronous (notify) MEP.

These sample flows can be used as the basis for testing other artifacts as well, such as the requester ABCS, EBF, or the provider service itself.

Asynchronous (Notify) MEP Testing Flow Using a Test Definition

The requester participating application is replaced by the CAVS test definition. The test definition points to the URL of the requester ABCS. It uses a composed request message to invoke the ABCS and does not expect a message in response.

Figure 2-4 illustrates testing an asynchronous (notify) MEP using a CAVS test definition.

Figure 2-4 Testing an Asynchronous (Notify) MEP Using a CAVS Test Definition

This image is described in surrounding text

Asynchronous (Notify) MEP Testing Flow Using a Test Definition and Simulator Definition

The requester participating application is replaced by the CAVS test definition. The test definition points to the URL of the requester ABCS. It uses a composed request message to invoke the ABCS and does not expect a message in response.

The provider participating application is replaced by the CAVS simulator definition. The provider ABCS is programmed to route to this simulator instead of the provider participating application. The simulator definition contains a predefined expected request message.

The simulator definition performs validations on message input from the provider ABCS.

Figure 2-5 illustrates testing an asynchronous (notify) MEP using CAVS test and simulator definitions.

Figure 2-5 Testing an Asynchronous (Notify) MEP Using a CAVS Test Definition and Simulator Definition

This image is described in surrounding text

Asynchronous (Notify) MEP Testing Flow Using a Simulator Definition

The provider participating application is replaced by the CAVS simulator definition. The requester ABCS is programmed to route to this simulator instead of the provider participating application. The simulator definition contains a predefined expected request message.

The simulator definition performs validations on message input from the provider ABCS.

Figure 2-6 illustrates testing an asynchronous (notify) MEP using a CAVS simulator definition.

Figure 2-6 Testing an Asynchronous (Notify) MEP Using a CAVS Simulator Definition

This image is described in surrounding text

2.3.3 Describing Flows for Testing the Asynchronous Two-Way Message Exchange Pattern

The following diagrams describe CAVS process flows for testing a provider ABCS using an asynchronous two-way MEP.

These sample flows can be used as the basis for testing other artifacts as well, such as the requester ABCS, EBF, or the provider service itself.

Asynchronous Two-Way MEP Testing Flow Using a Test Definition

The requester participating application is replaced by the CAVS test definition. The test definition points to the URL of the requester ABCS. It uses a composed request message to invoke the ABCS and expects an eventual message in response. The test definition includes a timeout value. If no response message is received within this timeout value, the test definition will experience a timeout failure.

Figure 2-7 illustrates testing an asynchronous (two-way) MEP using a CAVS test definition.

Figure 2-7 Testing an Asynchronous Two-Way MEP Using a CAVS Test Definition

This image is described in surrounding text

Asynchronous Two-Way MEP Testing Flow Using a Test Definition and Simulator Definition

The requester participating application is replaced by the CAVS test definition. The test definition points to the URL of the requester ABCS. It uses a composed request message to invoke the ABCS and expects an eventual message in response. The test definition includes a timeout value. If no response message is received within this timeout value, the test definition will experience a timeout failure.

The provider participating application is replaced by the CAVS simulator definition. The provider ABCS is programmed to route to this simulator instead of the provider participating application. The simulator definition contains a predefined request and response message pair.

The simulator definition performs validations on message input from the provider ABCS and sends the message back to the provider ABCS. The provider ABCS sends the message back to the test definition, which validates this actual response against its predefined expected response.

Figure 2-8 illustrates testing an asynchronous (two-way) MEP using CAVS test and simulator definitions.

Figure 2-8 Testing an Asynchronous Two-Way MEP Using a CAVS Test Definition and Simulator Definition

This image is described in surrounding text

Asynchronous Two-Way MEP Testing Flow Using a Simulator Definition

The provider ABCS is replaced by the CAVS simulator definition. The requester ABCS is programmed to route to this simulator instead of having the flow reach the provider ABCS.

The simulator definition contains a predefined request and response message pair, as well as a user-defined delay value. The simulator definition will delay its response by this amount of time to simulate the asynchronous two-way nature of the provider participating application.

The simulator definition performs validations on message input from the requester ABCS and sends the message back to the requester ABCS.

Figure 2-9 illustrates testing an asynchronous (two-way) MEP using a CAVS simulator definition.

Figure 2-9 Testing an Asynchronous Two-Way MEP Using a CAVS Simulator Definition

This image is described in surrounding text

2.4 Does the Scenario Need to be Unit or Flow Tested?

This section discusses different configurations for test and simulator definitions to achieve unit and flow tests.

This section includes the following topics:

2.4.1 Describing a Unit Test Configuration

This section will use a synchronous provider ABCS as the focus of the test example. However, this test configuration is not specific to message exchange patterns, so it can be applied to asynchronous (notify) and asynchronous two-way components as well.

To unit test a component, place a test definition before the component and a simulator definition after it. This isolates the focus of the test to the single component.

Figure 2-10 illustrates how to unit test a provider ABCS.

Figure 2-10 Unit Testing a Provider ABCS

This image is described in surrounding text

2.4.2 Describing a Flow Test Configuration

This section will use a synchronous provider ABCS as the focus of the test example. However, this test configuration is not specific to message exchange patterns, so it can be applied to asynchronous (notify) and asynchronous two-way components as well.

Once you have unit tested the components in a scenario, you can flow test the scenario. To flow test a scenario, place a test definition before the requester ABCS at the front of the scenario and a simulator definition after the provider ABCS at the end of the scenario, as shown in Figure 2-11.

Figure 2-11 Flow Testing a Scenario

This image is described in surrounding text

2.4.3 Describing a Complex Flow Test Configuration

This section uses an EBF as the focus of the test example. However, this test configuration is not specific to EBFs, so it can be applied to any service that conducts chatty conversations.

You can place a test definition before the requester ABCS at the front of a scenario and enable the EBF to make calls out to simulator definitions whenever required. You can then go on to replace some of the provider applications with simulators at the end of the scenario, as shown in Figure 2-12.

Figure 2-12 Complex Flow Testing an EBF

This image is described in surrounding text

2.5 Do I Have the Content I Need to Create the Definitions?

This section includes the following topic: Section 2.5.1, "How to Obtain Message XML Text from a BPEL Process".

Once you know what you need to test and which CAVS definitions you need to create, assess whether you have all of the content you need to create the definitions.

To create your test definitions and simulator definitions, you will primarily need request and response XML text.

If you are creating a Test Definition (or an asynchronous two-way simulator), you will need the endpoint URL of the web service you are testing.

The endpoint URL value can be found in the WSDL of the web service that you want to test.

When the endpoint URL is provided, CAVS will present you with available SOAP actions. Once you select the required SOAP action, CAVS will automatically generate the message stub for the service being called. You can then include data within the XML tags generated.

In either case, you can use the BPEL Console to obtain request and response XML text. Run the processes you are testing at least once with all participating applications and services in place and with the desired results. The XML messages generated by this successful run of the processes will provide your request and response XML for test and simulator definitions. The following section describes how to use the BPEL console to obtain these XML messages.

Note:

Obtaining response message XML text is only applicable when testing synchronous and asynchronous two-way processes.

2.5.1 How to Obtain Message XML Text from a BPEL Process

To obtain request and response message XML text:

  1. Access the BPEL Console for your AIA implementation.

  2. Click the Instances tab.

  3. In the BPEL Process drop-down list box, select the BPEL process for which you are creating a test definition and click Go. BPEL process instances for the selected BPEL process display in the List of BPEL Process Instances frame. Sort by Last Modified, if you want to access the most recent instance.

  4. Click the link for the instance you want to use for your request and response XML message text.

  5. Click the Flow link.

    Note:

    If the instance you selected contains any faults, you may want to consider selecting a different instance. However, if you are trying to test fault messaging in the BPEL, you must select a BPEL process instance that contains the fault.

  6. To obtain the Request Message XML text:

    1. Click the receiveInput element to get your test definition request message XML text.

    2. Click the Copy details to clipboard link at the bottom of the pop-up box displaying input Variable data.

    3. Open an XML editor and paste the XML text into a blank document.

    4. Remove the opening and closing inputVariable (XYZ_InputVariable, in the case of a non-BPEL service, such as a participating application service) and part elements.

    5. Copy and paste the remaining XML text in the default SOAP envelope provided in the Request Message field on the Test Definition page or Simulator Definition page. Paste the XML text into the area indicated by the Paste your SOAP Message Content here placeholder text.

  7. To obtain the Response Message XML text:

    Note:

    Obtaining response message XML text is only applicable when testing a synchronous process.

    1. Click the reply Output element to get your test definition response message XML text.

    2. Click the Copy details to clipboard link at the bottom of the pop-up box displaying output Variable data.

    3. Open an XML editor and paste the XML text into a blank document.

    4. Remove the opening and closing inputVariable (XYZ_InputVariable, in the case of a non-BPEL service, such as a participating application service) and part elements.

    5. Copy and paste the remaining XML text in the default SOAP envelope provided in the Response Message field on the Test Definition page or Simulator Definition page.