Process integration packs PIPs that are delivered to work with Oracle AIA For every system type defined on the System - Application Registry page for

13-26 Developers Guide for Oracle Application Integration Architecture Foundation Pack switch

13.4.3 Introduction to the CAVSEndpointURL Value Designation

The CAVSEndPointURL value is set at design time as follows: ■ If the ABCS or Enterprise Business Flow EBF is invoking a synchronous service, then the CAVSEndPointURL value in the AIAConfigurationProperties.xml file is set to a default value of: http:host:portAIAValidationSystemServletsyncresponsesimulator ■ If the ABCS or EBF is invoking an asynchronous one-way service, then the CAVSEndPointURL value in the AIAConfigurationProperties.xml file is set to a default value of: http:host:portAIAValidationSystemServletasyncrequestrecipient ■ If the ABCS or EBF is invoking an asynchronous request-delayed response service, then the CAVSEndPointURL value in the AIAConfigurationProperties.xml file is set to a default value of: http:host:portAIAValidationSystemServletasyncresponsesimulator ■ If the ABCS or EBF is invoking a Response EBS, then the CAVSEndPointURL value in the AIAConfigurationProperties.xml file is set to a default value of: http:host:portAIAValidationSystemServletasyncresponserecipient

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

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 users 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 once the test scenario has been executed. This enables rerunning of the test scenario. This purge is accomplished as follows:

1. Process integration packs PIPs that are delivered to work with Oracle 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 System - Application Registry 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. To access the System - Application Registry page, access the AIA Home Page, click Go in the Setup area, Tip: Some requester ABCSs must communicate back directly with the calling participating application. For this type of partnerlink, the requester ABCS acts similarly to a provider ABCS because it is invoking a participating application Web service. Completing ABCS Development 13-27 and select the System tab. Figure 13–10 illustrates the system and CAVS-related entries. Figure 13–10 System and CAVS-related System Entries on the System-Application Registry Page 3. When testing a provider ABCS in isolation, the EBM is passed from the CAVS to the provider ABCS with the NamespacePrefixedEBMNameEBMHeaderTargetID 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 now contains the CAVS-specific Internal ID value set for the system on the System - Application Registry page. 5. When testing an entire flow requester ABCS-to-EBS-to-provider ABCS, you must set the Default.SystemID property of the provider ABCS to CAVS_XYZ, where XYZ is the system. To do this, edit the Default.SystemID property value in the AIAConfigurationProperties.xml file in the AIA_HOMEaia_ instancesINSTANCE_NAMEAIAMetaDataconfig directory. Access the Configuration page and click Reload to load the edit. You can now begin testing the entire flow.

13.5 Securing the ABCS

The participating applications are developed during different times with different concepts and implementation of authentication and authorization. When applications are integrated, you must pass authentication and authorization information between applications. The information related to security is exchanged between participating applications and ABCS. The AIA application security context standardizes the exchange of participating applications authentication and authorization information between various applications so that any application can be integrated with any other application.

13.5.1 How to Secure the ABCS

You should answer the following questions: Note: If the test scenario is an entire flow that includes multiple instances of the same system, then the approach described previously will not work. In this case, data created in the cross-reference will remain, making the same test case incapable of being rerun.