Skip Headers

Oracle Application Server Adapter for Oracle Applications User's Guide
10g (10.1.3.5.0)
Part Number E14293-01
Go to Table of Contents
Contents
Go to previous page
Previous
Go to next page
Next

Introduction to OracleAS Adapter for Oracle Applications

This chapter covers the following topics:

Overview of OracleAS Adapter for Oracle Applications

Oracle Applications is a set of integrated business applications that runs entirely on the Internet. Oracle Applications offers you the following:

Oracle Applications are built on a unified information architecture that consolidates data from Oracle and non-Oracle applications and enables a consistent definition of customers, suppliers, partners, and employees across the entire enterprise. This results in a suite of applications that can give you information, such as current performance metrics, financial ratios, profit and loss summaries. To connect Oracle Applications to non-Oracle applications, you use OracleAS Adapter for Oracle Applications.

OracleAS Adapter for Oracle Applications not only provides comprehensive, bidirectional, multimodal, synchronous, and asynchronous connectivity to Oracle Applications, but also supports for all modules of Oracle E-Business Suite in Release 12 and Release 11i including custom integration interfaces in various versions of Oracle E-Business Suite.

Major Features

OracleAS Adapter for Oracle Applications provides the following features:

Architecture

OracleAS Adapter for Oracle Applications is based on J2CA 1.0 standards and deployed as a resource adapter in the same Oracle Application Server Containers for J2EE (OC4J) container as BPEL Process Manager. The architecture of OracleAS Adapter for Oracle Applications is similar to the architecture of technology adapters.

OracleAS Adapter for Oracle Applications Architecture

the picture is described in the document text

Installing OracleAS Adapter for Oracle Applications

The installation of the Oracle Application Server Adapter for Oracle Applications happens out-of-the-box with the Oracle BPEL Process Manager (PM) product. OracleAS Adapter for Oracle Applications is deployed using the Oracle BPEL PM in Oracle JDeveloper.

Note: Refer to the "Notes on Installing Oracle BPEL Process Manager" section, Oracle Application Server Integration Business Activity Monitoring User's Guide for more details about installing Oracle BPEL Process Manager.

Integration with Oracle BPEL Process Manager

Based on the service-oriented architecture (SOA), Oracle BPEL Process Manager (BPEL PM) provides a comprehensive solution for creating, deploying, and managing Oracle BPEL Process Manager business processes.

OracleAS Adapter for Oracle Applications can easily expose public integration interface within Oracle E-Business Suite as standard Web services. These services can be created and configured in the Oracle JDeveloper at design time either using BPEL Designer or ESB Designer. At run time, Oracle E-Business Suite integration flows are deployed in the BPEL PM Server / ESB Server for execution of the services to complete the integration.

Design Time

During design time, the integration interface is exposed as a Web service represented by WSDL and schema files. This Web service participates in the BPEL PM orchestration process via the process activities like Invoke, Assign, Transform, and other activities if necessary through simple configuration steps.

The Oracle JDeveloper BPEL Designer, a graphical drag and drop environment, is used to design BPEL-based process flows and Web services orchestration.

When you create a partner link in JDeveloper BPEL Designer, the Adapter Configuration Wizard starts which enables you to select and configure the OracleAS Adapters for Oracle Applications. With proper database and service connection setups, you can select an interface in or out from Oracle E-Business Suite and add the XML schema. When configuration is complete, the wizard generates a WSDL file corresponding to the XML schema for the partner link.

Additional process activities are added to the BPEL process if necessary to assign parameters and invoke the service.

Run Time

Before deploying the BPEL process to Oracle BPEL server, necessary run-time parameters, system settings, and application setup must be properly configured for a successful deployment and service integrations.

Note: Agent Listeners should also be up and running if needed for certain interface types used in Oracle E-Business Suite.

While deploying the BPEL process, the WSIF Provider converts the Web service invocation from BPEL PM Invoke activity to an outbound interaction call and performs the reverse conversion in the other direction as a Web service response for a synchronous request-response message pattern. The WSIF Provider also supports the one-way asynchronous outbound interaction invocation such as integration with XML Gateway outbound message maps and outbound business events.

Testing the BPEL Process at Run Time

After deploying the BPEL process, you should validate the design by testing the deployed BPEL process. It can be done by manually initiating the BPEL process from the BPEL Console to test the interface integration contained in your BPEL process.

For detailed design-time and run-time tasks for each integration interface, see the individual interface chapter explained later in this book.

New Features in This Release

This section describes the new features that have been added in OracleAS Adapter for Oracle Applications 10g (10.1.3.5.0).

Additional Support for Header Variables

Header variables are used to provide applications context information required in the SOA Suite to process Concurrent Programs and PL/SQL APIs.

Adapter for Oracle Applications can now accept the following three new header parameters along with the existing Username, Responsibility, and Org_ID parameters for setting applications context:

Note: Existing header parameter Responsibility used in the earlier releases can now take Responsibility Key as well as Responsibility Name as input. If the header parameter NLSLanguage is set, and Responsibility Name is passed, the value passed for Responsibility is expected to be in the same language. However, Responsibility Key as well as all other header parameters are language independent.

All these header parameters would be used together to set the applications context. Alternatively, passing just the Username and Responsibility would work as it did in the earlier releases.

For more information, see Supporting for Applications Context Header Variables.