11 Purging CAVS-Related Cross-Reference Entries to Enable Rerunning of Test Scenarios

This chapter describes how to purge Composite Application Validation System (CAVS)-related cross-reference entries to allow test scenarios to be rerun.

This chapter includes the following sections:

11.1 Introduction to Purging CAVS-Related Cross-Reference Entries

When a participating application is involved in a CAVS testing flow, execution of tests can potentially modify data in a participating application. Therefore, consecutive running of the same test may not generate the same results. The CAVS is not designed to prevent this kind of data tampering because it supports the user s intention to include a real participating application in the flow. The CAVS has no control over modifications that are performed in participating applications.

However, this issue does not apply if your CAVS test scenario uses test definitions and simulator definitions to replace all participating applications and other dependencies. In this case, all cross-reference data is purged after the test scenario has been executed. This enables rerunning of the test scenario.

11.2 How to Purge CAVS-Related Cross-Reference Entries to Enable Rerunning of Test Scenarios

To purge CAVS-related cross-reference entries to enable rerunning of test scenarios:

  1. Process integration packs (PIPs) that are delivered to work with Oracle Application Integration Architecture (AIA) Foundation Packs are delivered with cross-reference systems in place. They are named CAVS_<XYZ>, where <XYZ> is the participating application system.

    For example, for systems EBIZ and SEBL, the PIP is delivered with cross-reference systems CAVS_EBIZ and CAVS_SEBL.

  2. For every system type defined on the Systems page for which you want to make test scenarios rerunnable (<XYZ>), create a related CAVS system (CAVS_<XYZ>). The System Type field value for the CAVS-related entry should match the name of the system for which it is created.

    For more information about the Systems page, see "Building AIA Integration Flows" in Oracle Fusion Middleware Developer's Guide for Oracle Application Integration Architecture Foundation Pack.

  3. When testing a provider Application Business Connector Service (ABCS) in isolation, the Enterprise Business Message (EBM) will be passed from the CAVS to the provider ABCS with the NamespacePrefixedEBMName/EBMHeader/Target/ID element set as CAVS_<XYZ>.

  4. When testing a requester ABCS in isolation, the element in the Application Business Message (ABM) that normally contains the Internal ID value will now contain the CAVS-specific Internal ID value set for the system on the Systems page.

  5. When testing an entire flow (requester ABCS-to-Enterprise Business Service [EBS] -to-provider ABCS), you must set the Default.SystemID property of the provider ABCS to CAVS_<XYZ>, where <XYZ> is the system.

    1. To do this, edit the Default.SystemID property value in the AIAConfigurationProperties.xml file in the <AIA_HOME>/aia_instances/$INSTANCE_NAME/AIAMetaData/config directory.

    2. Reload updates to the AIAConfigurationProperties.xml file.

      For more information about reloading updates to AIAConfigurationProperties.xml, see "Building AIA Integration Flows" in Oracle Fusion Middleware Developer's Guide for Oracle Application Integration Architecture Foundation Pack.

    3. You can now commence testing the entire flow.

Note:

If the test scenario is an entire flow that includes multiple instances of the same system, this approach will not work. In this case, data created in the cross-reference will remain making the same test case non-rerunnable.