Oracle Application Server Adapter for Oracle Applications User's Guide 10g (10.1.3.4.0) Part Number E10536-01 | Contents | Previous | Next |
This chapter covers the following topics:
Oracle Applications is a set of integrated business applications that runs entirely on the Internet. Oracle Applications offers you the following:
Reduced costs
Increased revenue across front-office and back-office functions
Access to current, accurate, and consistent data
The applications in 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 provides comprehensive, bidirectional, multimodal, synchronous, and asynchronous connectivity to Oracle Applications. The Adapter supports for all modules of Oracle Applications in Release 12 and Release 11i including selecting custom integration interface types based on the version of Oracle E-Business Suite.
Important: Please note that the support for various versions of Oracle E-Business Suite has the following conditions:
OracleAS Adapter for Oracle Applications supports only those versions of Oracle E-Business Suite Release 11i which work with OWF.G.Rollup 7 applied.
OracleAS Adapter for Oracle Applications version 10.1.3.3 supports Oracle E-Business Suite Release 12.0.
To enable the "Native E-Business Suite Connectivity using J2EE Data Sources" feature, the minimum requirement for Oracle E-Business Suite Release 11i is FND Rollup 6 and for Oracle E-Business Suite Release 12 is 12.0.4 release.
See "Oracle Application Sever Adapter for Oracle Applications Documentation Update, Release 10g" OracleMetaLink Document 464164.1 for details.
OracleAS Adapter for Oracle Applications includes the following features:
It supports open standards, including J2EE Connector Architecture (J2CA), Extensible Markup Language (XML), Web Service Invocation Framework (WSIF), Web Service Inspection Language (WSIL), and Web Service Definition Language (WSDL).
It uses a JDeveloper based design-time tool for dynamically browsing the Oracle Applications interface and configuring the adapter metadata.
It integrates applications based on open standards, such as IFX, OAG, RosettaNet, and UCCnet by interfacing with XML Gateway.
It generates adapter metadata as WSDL files with J2CA extension.
Note: See Oracle Application Server Adapter Concepts on OTN for more information.
It supports multiple languages and multiple organization setups based on the concept of applications context.
It leverages and supports Oracle User Management function security to allow authorized users to access and execute APIs that they are exposed through the BPEL process to update Oracle Applications.
Note: This overview includes details about features and capabilities that are new in the current release of OracleAS Adapter for Oracle Applications. For more information, see New Features in This Release.
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
OracleAS Adapter for Oracle Applications acts as a highly flexible integration interface for Oracle Applications. The adapter supports the following interface types for integrating with Oracle Applications:
Oracle XML Gateway
XML Gateway enables bidirectional integration with Oracle Applications. It helps you to insert and retrieve data from Oracle Applications. XML Gateway is a higher-level interface that exposes OAGIS-formatted XML documents for commonly used Oracle Application business objects and business interfaces. XML Gateway integrates with interface tables, Oracle Workflow Business Event System (BES), and interface views to insert and retrieve data from Oracle Applications. It maps the underlying table data to XML and back.
Business events
A business event is an occurrence in an internet application that might be significant to other objects in a system or to external agents. An example of a business event can be the creation of a new sales order or changes to an existing order.
Oracle Workflow uses the Business Event System that leverages the Oracle Advanced Queuing (AQ) infrastructure to communicate and manage business events between systems. The Business Event System consists of an Event Manager and workflow process event activities. The Event Manager lets you register subscriptions to significant events; event activities representing business events within workflow processes let you model complex business flows or logics within workflow processes.
When a local event occurs, the subscribing code is executed in the same transaction as the code that raised the event. Subscription processing can include executing custom code on the event information, sending event information to a workflow process, and sending event information to other queues or systems.
Concurrent programs
Concurrent programs enable you to move data from interface tables to base tables.
Interface tables
Interface tables enable you to insert or update data into Oracle Applications. The associated concurrent program should be running to move the data from the interface tables to base tables.
Interface views
Interface views help you to retrieve data from Oracle Applications using the application tables.
PL/SQL APIs
These APIs enable you to insert and update data in Oracle Applications using PL/SQL.
Oracle e-Commerce (EDI) Gateway
Oracle e-Commerce Gateway provides a common, standards-based approach for Electronic Data Interchange (EDI) integration between Oracle Applications and third party applications.
Please note that OracleAS Adapter for Oracle Applications also supports the following integration interface types that are exposed by the Oracle Applications Module Browser, not by Oracle Integration Repository:
Customized XML Gateway maps
Customized PL/SQL APIs
Note: Business events integration interface type is also exposed by Oracle Applications Module Browser, not by Oracle Integration Repository.
Oracle Integration Repository, an integral part of Oracle E-Business Suite, is a prebuilt catalog of information about the numerous public integration interfaces delivered with Oracle applications, known as business interfaces. It provides a comprehensive view of the interface mechanisms available for Oracle E-Business Suite's business interfaces. These interfaces are exposed because their definitions were annotated at design time as required by Oracle Integration Repository.
Oracle Integration Repository can only provide information about an integration interface that has been specifically annotated by the developer to make it public. OracleAS Adapter for Oracle Applications takes advantage of the annotations that have already been created to make the following business interface types visible in the Oracle Applications Module Browser:
XML Gateway message maps
PL/SQL APIs
Concurrent programs
Open Interface tables
Interface views
e-Commerce Gateway EDI messages
These business interfaces are exposed as Web services, and are available for process orchestration through the Oracle BPEL Process Manager.
For more information about Oracle Integration Repository, see Oracle Integration Repository User's Guide. These guide is part of the Oracle Applications documentation library. Oracle Applications documentation can be accessed with the following link:
http://www.oracle.com/technology/documentation/applications.html
To extend the support for Oracle E-Business Suite, OracleAS Adapter for Oracle Applications enhances the capability of implicitly utilizing Oracle Integration Repository to support custom interfaces, such as customized PL/SQL APIs, with reference to the following versions of Oracle E-Business Suite:
Important: Please note that the support for various versions of Oracle E-Business Suite has the following conditions:
OracleAS Adapter for Oracle Applications supports only those versions of Oracle E-Business Suite Release 11i which work with OWF.G.Rollup 7 applied.
OracleAS Adapter for Oracle Applications version 10.1.3.3 supports Oracle E-Business Suite Release 12.0.
To enable the "Native E-Business Suite Connectivity using J2EE Data Sources" feature, the minimum requirement for Oracle E-Business Suite Release 11i is FND Rollup 6 and for Oracle E-Business Suite Release 12 is 12.0.4 release.
See "Oracle Application Sever Adapter for Oracle Applications Documentation Update, Release 10g" OracleMetaLink Document 464164.1 for details.
From the business service creation and runtime perspectives, OracleAS Adapter for Oracle Applications treats customized PL/SQL APIs as part of the seeded PL/SQL APIs. The only difference is that the customized PL/SQL APIs can be exposed by the Oracle Applications Module Browser during the design time.
Support for Oracle E-Business Suite Release 12
From Release 12, Oracle Integration Repository is shipped as part of the E-Business Suite which enables OracleAS Adapter for Oracle Applications to directly connect to the live database of Oracle Integration Repository querying for the public interfaces and then displaying the list of customized PL/SQL APIs under the Other Interfaces node in the Oracle Applications Module Browser.
Supporting Custom Integration Interfaces in Release 12
Please note that OracleAS Adapter for Oracle Applications allows you to extract the Integration Repository data file from the live database you connect to Oracle Applications and create a local copy of the Integration Repository in your workplace. Next time when you look for public interfaces, the system can retrieve data from the cache backend connection in your workplace.
For detailed information about connecting to Oracle E-Business Suite Release 12, please refer to the Creating a Partner Link or Adding a Partner Link design-time task for each integration interface.
Support for Oracle E-Business Suite Release 11i10
To support the Release 11i10 version of Oracle E-Business Suite, OracleAS Adapter for Oracle Applications connects to the live database of Oracle Integration Repository and stores the data file within the Adapter for query. At the design time, OracleAS Adapter for Oracle Applications queries public interfaces from the native XML data file of the Integration Repository located in the Adapter and displays the list of custom integration interfaces under the Other Interfaces node in the Oracle Applications Module Browser.
Supporting Custom Integration Interfaces in Release 11i10
Support for Oracle E-Business Suite Pre-Release 11i10
To support the pre-Release 11i10 versions of Oracle E-Business Suite, OracleAS Adapter for Oracle Applications connects to the live database of Oracle Integration Repository for all interface types. Since there is no differentiation between public, private, and customized PL/SQL APIs in the pre-Release 11i10 versions of Oracle E-Business Suite, OracleAS Adapter for Oracle Applications displays them all under the node of each module through Oracle Applications Module Browser.
Before making a selection from the browser for the pre-Release 11i10, you must select an interface type you want to use in the Adapter Configuration Wizard. All interfaces of your selected type will be displayed in the browser.
For example, you will find a list of concurrent programs associated with e-Commerce (EDI) Gateway displayed in the Oracle Application Module Browser as follows if the EDI Gateway interface type is selected.
Supporting Custom Integration Interfaces in pre-Release 11i10
When you make a selection through the module browser at design time, OracleAS Adapter for Oracle Applications validates your selected API against the database. If it exists in the database for a particular version of your instance, then the associated WSDL file will be generated successfully.
This section describes the new features that have been added in OracleAS Adapter for Oracle Applications 10g (10.1.3.4.0).
Security is the most critical feature that is designed to guard application content from unauthorized access. By leveraging Oracle User Management function security, OracleAS Adapter for Oracle Applications now provides a security feature which only allows users with authorized privileges to execute APIs that they are exposed through the BPEL process to update Oracle Applications. This feature protects application programming interfaces (APIs) from unauthorized access or execution without security checks.
Please note that OracleAS Adapter for Oracle Applications provides this security support as an optional feature. If you want all login users to access and execute APIs without security checks, you can turn the security feature off using the "EBS Adapter for BPEL, Function Security Enabled" (EBS_ADAPTER_FUNCTION_SEC_ENABLED) profile option. If the function security feature is enabled, all API calls for PL/SQL APIs, Oracle e-Commerce Gateway, and concurrent programs will be checked for user security before they are invoked.
OracleAS Adapter for Oracle Applications now uses a new mechanism to authenticate users at run time and get the connection to Oracle Applications databases through the use of J2EE data sources. Since J2EE data sources are defined in OC4J container that runs the BPEL processes, this approach is native to Oracle E-Business Suite in defining the connection pool to access the application database.
With this new mechanism, account details information including application login user name and password that was required as part of the configuration for database connection is now added together with the dbc file location as input parameters during the J2EE data source creation.
Note: To have this feature available, you must apply necessary patches to enable the connectivity between Oracle E-Business Suite and an external Oracle Application Server at run time for Oracle E-Business Suite Release 12 and Release 11i10. See "Oracle Application Sever Adapter for Oracle Applications Documentation Update, Release 10g" OracleMetaLink Document 464164.1 for details.
Applications context is required for secured transaction processing into and out of Oracle Applications.
Applications context is a combination of Organization ID, Username and Responsibility. To establish applications context, the Organization ID is implicitly derived from the Oracle Applications setup data.
To understand applications context, you need to understand first how Organization ID and multiple organizations are related.
Multiple organizations can be sets of books, business groups, legal entities, operating units, or inventory organizations. You can define multiple organizations and the relationships between them in a single installation of Oracle Applications.
Multilevel organization hierarchies can be defined with a business group at the top of each hierarchy. When you define new organizations, they are automatically assigned to the business group associated with your current session. Each organization is part of a business group. The business group is usually the top box on an enterprise organization chart.
Business Group Hierarchy
Example of a Multiple-Organization Setup
Using the accounting, distribution, and materials management functions in Oracle Applications, you define the relationships among inventory organizations, operating units, legal entities, and sets of books to create a multilevel company structure, as shown in the following diagram.
A Multiple-Organization Transaction
Consider two different organizations in your company: One is a French sales office and the other is a German warehouse. There is a sales order transaction with the customer, and this illustrates how the entire Order-to-Deliver process would work:
The customer places a sales order with the French sales office.
The German warehouse delivers the product shipment to the customer.
The German warehouse issues an inter-company invoice to the French sales office.
The French sales office makes the inter-company payment to the German warehouse.
The French sales office sends the customer invoice to the customer.
The customer makes payment to the French sales office.
The database architecture is the same for a multiple-organization and non-multiple-organization installation, and uses the standard install tools feature that automatically creates synonyms in the APPS schema for each base product table and defines these synonyms with the same name as the base product tables. For example, the PO Oracle schema has a table named PO_HEADERS_ALL and the APPS schema has a corresponding synonym of the same name, PO_HEADERS_ALL. The PO_HEADERS_ALL synonym can be used to access unpartitioned data.
Schema Synonyms
Multi-Organization Access Control (MOAC) Security by Operating Units
While setting up the system profile values, the username and responsibility are tied up with the organization or operating units.
Multiple-Organization System Profiles
To have a secured way for users to only access or report on data for the operating units they have access to, OracleAS Adapter for Oracle Applications uses the MOAC security feature to determine the operating unit access and derive the Organization ID based on relevant profile values.
With MOAC, a system administrator can predefine the scope of access privileges as a security profile, and then use the profile option MO: Security Profile to associate the security profile with a responsibility. By using this approach, multiple operating units are associated with a security profile and that security profile is then assigned to a responsibility. Therefore, through the access control of security profiles, users can access data in multiple operating units without changing responsibility.
Security profiles are defined based on organization hierarchies. For example, a sales company consists of USA and UK operating units; the USA operating unit has Western Region Sales and East Region Sales. Sales managers are responsible for both USA and UK sales; supervisors are responsible for either USA or UK, and sales representatives are only responsible for their designated sales regions. The Sales organization hierarchy can be illustrated as follows:
Sales Organization Hierarchy
To secure sales data within the company, relevant operating units can be associated with predefined security profiles. For example, all sales data access privileges are grouped into the Vision Sales security profile; USA Sales security profile is for USA related data, and regional security profiles are for designated regional data. The system administrator can associate these security profiles containing multiple operating units with users through appropriate responsibilities. Therefore, sales supervisors can easily access sales data in the Eastern or Western region without changing their responsibilities. The following diagram illustrates the relationship between security profiles, responsibilities, and operating units for this sales company:
Relationship Diagram Between Security Profiles, Responsibilities, and Operating Units
Responsibility Determines Operating Units
Because responsibilities are associated with security profiles that linked to operating units, your responsibility is the key in determining which operating units you will have the access privileges.
The following diagram illustrates how Oracle Applications use the profile options in a multi-organization environment:
Building Applications Context for Multiple Organizations
When the system integrator runs, the process achieves the integration with Oracle Applications using PL/SQL APIs.
The Apps.Initialize process takes the parameters of Username and Responsibility.
With these parameters, a lookup on all System Profile Values assigned to that responsibility is done to determine the Operating Unit within a multi-organization environment.
The Operating Unit is modeled as Organization ID derived from the security profile value.
The data is read and written into the Oracle Applications with the parameters of Username, Responsibility and Organization ID.
Based on the concept of applications context supported in a multi-organization environment, OracleAS Adapter for Oracle Applications provides the following features:
Instead of implicitly deriving organization information from a profile value during the Oracle Applications setups, OracleAS Adapter for Oracle Applications provides a mechanism which allows Organization ID information can be directly entered through the header variable creation during the design time to support multiple organization setups.
OracleAS Adapter for Oracle Applications uses the header variable to include Username, Responsibility, and Organization ID, the three essential elements for applications context. Once you declare the header variable and assign appropriate values to each parameter contained in the header for a business activity through a PL/SQL API or an interface which requires the applications context to be set, these values in the header will be passed and used as an input to the rest of activities in the BPEL process.
Note: Integration interface types that require applications context to be set are PL/SQL APIs, concurrent programs, and EDI programs.
Creating and Assigning Header Variable
The advantage of having this header variable mechanism in supporting multiple organization setups is that with only one single BPEL process, organization information can be easily placed into multiple organizations within the E-Business Suite if the Organization ID value has been specified in the header. While in the past, since Organization ID is implicitly derived from the profile value based on an application logon user's username and responsibility; therefore, only that associated organization for the invocation of the deployed BPEL process can be inserted.
With the example described earlier in the Multiple Organization Setup section, when a change order is placed within the French sales office, a sales manager from the French office logs on to the system to update the order which invokes a PL/SQL API for that change. If the Organization ID contained in the header variable has been assigned with a value, such as 207 for the French sales office, the Organization ID associated with the sales manager will be set to French sales office for the invocation of the API.
Note: For Oracle E-Business Suite Release 12, Organization ID parameter is automatically included in the header variable along with Username and Responsibility. For Release 11.5.10, you must apply back port patch 4549743 to Oracle Applications instance in order to have Organization ID displayed in the header.
OracleAS Adapter for Oracle Applications uses the following procedures to complete the design-time tasks to support Organization ID in multiple organization setups:
Configure an Invoke Activity and Create the Header Variable
This activity involves the following tasks:
Configure an Invoke Activity in the General tab
Configure an Invoke activity by linking the activity to the partner link you just created. This opens the General tab in the Edit Invoke dialog box with Partner Link and Operation information populated. You will create Input Variable and Output Variable for the Invoke activity.
Create the Header Variable in the Adapters tab
Create the header variable used in applications context for Oracle Applications to identify the application user and the user's associated organization information.
Assign Organization ID Using an Assign Activity
After creating the header variable, you need to configure an Assign activity by placing it before the Invoke activity.
Select Copy Operation tab in the Assign dialog box and select Copy Operation... from the Create drop-down list.
In the From group, enter an ORG_ID value, such as '207', in the Expression field. In the To group, locate the variable header where you declare the variable and assign the Organization ID to ORG_ID parameter of the header.
Assigning Value to ORG_ID
By leveraging the Multiple Language Support (MLS) feature from Oracle E-Business Suite, OracleAS Adapter for Oracle Applications allows a logon user's default language to be dynamically displayed at runtime when the system deploys a BPEL process through an API requested by the user. When an application user retrieves data from the system for a transaction or receives error messages while executing APIs, the user will find the data or error messages displayed in his or her default language. Additionally, if the user has dates set up based on a region, after data retrieval, that user will find the dates returned with the format and time zone information corresponding to the default information specified in his or her preference page.
To understand how OracleAS Adapter for Oracle Applications supports the MLS feature, you need to first understand how data is retrieved from the application database.
Many of the APIs that OracleAS Adapter for Oracle Applications invokes query database views and these views present data in the default language of the applications user that is used to invoke the APIs. In other words, these APIs exposed within OracleAS Adapter for Oracle Applications are language aware. When an application user requests a transaction through the execution of APIs, data queries from the database views must have been initialized with the default language specified by the user in the preference page.
To identify the default language used in the database session for data query and retrieval, OracleAS Adapter for Oracle Applications will first examine the ICX: Language profile value at all levels including user, responsibility, application, and site. If it is not set at any of those levels, OracleAS Adapter for Oracle Applications then takes NLS_LANGUAGE parameter from the database instance National Language Support (NLS) parameters. The NLS parameters initialized in the session are:
NLS_LANGUAGE
NLS_SORT
NLS_DATE_FORMAT
NLS_DATE_LANGUAGE
NLS_NUMERIC_CHARACTERS
NLS_TERRITORY
Dynamically Displaying Language Based on User's Default Language
For example, when a user with a default language Japanese logs into the system and performs a transaction through the execution of APIs that the user defined in the Partner link of the BPEL process, OracleAS Adapter for Oracle Applications uses the username of the logon Japanese user and responsibility to identify the default language code, such as JA for Japanese, used in the database session. Consequently, the NLS context parameters are set in Japanese. That user will therefore see all queried data or error messages displayed in Japanese which corresponds to the user's default language set in the General Preference page of Oracle Applications.
Note: The default language set in the General Preference page updates the ICX: Language profile option.
Please refer to the Set Preferences section, Getting Started with Oracle Applications chapter, Oracle Applications User’s Guide for the information on how to set the default language used by the applications user.
To implement the MLS support feature, perform the following design-time tasks before you configure an Invoke activity so that the variable can be passed to the activity:
You can optionally define the username and responsibility to be used in the execution of the API by setting a header variable {http://xmlns.oracle.com/pcbpel/adapter/appscontext/}Header_msg. This declaration provides context information for Oracle Applications to identify the application user that will be executing the API.
Note: Since the header variable declaration provides context information for Oracle Applications to identify the application user, OracleAS Adapter for Oracle Applications not only uses this variable declaration to support the MLS feature, but also to support other features that utilize the concept of applications context including the Organization ID support in multiple organization setups.
Declaring Header Variable
Because the declaration of this header variable is optional, if you do not declare the variable, the default username is SYSADMIN and the default responsibility is System Administrator.
After declaring the header variable, you must assign the variable value using an Assign activity. For example, in the From group, enter an username, such as 'Operation', in the Expression field. In the To group, locate the variable header where you declare the variable and assign the value to username variable.
Assigning a Variable Value
The username defined in the header variable will be used to derive the NLS variables which will be set in the context of the session that executes the API you defined in the Partner link of the BPEL process.
Security is the most critical feature that is designed to guard application content from unauthorized access. By leveraging Oracle User Management function security, Oracle Application Server Adapter for Oracle Applications provides a security feature which only allows users with authorized privileges to execute APIs that they are exposed through the BPEL process to update Oracle Applications. This protects application programming interfaces (APIs) from unauthorized access or execution without security checks.
Please note that Oracle Application Server Adapter for Oracle Applications provides this security support as an optional feature. If you want all login users to access and execute APIs without security checks, you can turn the security feature off using the "EBS Adapter for BPEL, Function Security Enabled" (EBS_ADAPTER_FUNCTION_SEC_ENABLED) profile option.
If it is set to 'Y', then the function security feature is enabled and all API calls for PL/SQL APIs, Oracle e-Commerce Gateway, and concurrent programs will be checked for user security before they are invoked.
If it is set to 'N' (default value), then the function security feature is disabled. No security check is implemented during the invocation of all API calls.
Note: To have this function security feature available, appropriate patches need to be applied to your environment. See "Oracle Application Sever Adapter for Oracle Applications Documentation Update, Release 10g" OracleMetaLink Document 464164.1 for details.
This section includes the following topics:
Function security is the basic access control in Oracle Applications. It restricts user access to individual menus and menu options within the system regardless of which application data in the row. Since APIs are stored procedures that enable you to insert and update data in Oracle Applications, when having the function security layer enforced on the access to an API, it actually implicitly restricts the data access to the application.
To allow appropriate users with right privileges to execute APIs, OracleAS Adapter for Oracle Applications leverages Oracle User Management Role-Based Access Control security (RBAC) to reinforce the function security through user roles and whether a user can access an API is determined by the roles granted to the user. A role can be configured to consolidate the responsibilities, permissions, permission sets, and function security policies that users require to perform a specific function. This simplifies mass updates of user permissions because changes can be done through roles which will inherit the new sets of permissions automatically. Based on the job functions, each role can be assigned a specific permission or permission set if needed. For example, a procurement organization may include 'Buyer', 'Purchasing Manager', and 'Purchasing Support' roles. The 'Purchasing Manager' role would include a permission set that contains all Purchase Order (PO) Creation, PO Change, and Contract PO related APIs allowing the manager role to perform a job function while the Buyer or Support role may not have the access privileges.
In OracleAS Adapter for Oracle Applications, all annotated APIs resided in Oracle Integration Repository are registered on the FND_FORM_FUNCTIONS table so that the function security (FND_FORM_FUNCTIONS) can be applied. This allows the creation of a secured function for each API.
Important: For Oracle E-Business Suite Release 12, all annotated APIs in Oracle Integration Repository are registered on the FND_FORM_FUNCTIONS table. However, if it is for the Release 11i, you have to apply a function security patch that populates this information on that table. Refer to "Oracle Application Sever Adapter for Oracle Applications Documentation Update, Release 10g" OracleMetaLink Document 464164.1 for details.
By leveraging the concept of permission sets, OracleAS Adapter for Oracle Applications allows related APIs to be grouped and sequenced under one permission set; each permission set can be associated with a function role and then assigned to users through security grants. When a user logs on to the E-Business Suite and tries to access an API exposed through the BPEL process, if the security feature is enabled, the function security API will be invoked to validate whether the user is authorized to have the execution privileges on the API.
For example, if a user does not have the access privileges for a PL/SQL API exposed through a BPEL process, the execution of that BPEL process will fail while trying to invoke the PL/SQL API as shown in the following diagram:
Without the authorized privileges, the Function Security Validation Exception message will be raised indicating that the user does not have the privilege for a specific PL/SQL API.
For more information on Function Security and RBAC security models, see Oracle Applications System Administrator's Guide - Security for details.
To secure the API invocation only to a user with appropriate execution privileges, OracleAS Adapter for Oracle Applications uses the following steps to create security grants to users through user roles:
Use the following steps to create a permission set:
Log in to Oracle E-Business Suite using the System Administrator responsibility.
Select Application: Menu from the Navigator to access the Menus window.
Enter the following menu information:
Menu: Enter an appropriate menu name (such as 'OE_PROCESS_LINE_PS')
User Menu Name: Enter an appropriate user menu name (such as 'Order Manager Process Line Permission Set')
Menu Type: Permission Set
Description: Enter description information for this menu
Add all the functions that you want to group on this Permission Set by entering values for Seq and Function.
Enter the Seq field.
In the Function column, search for the functions you want to assign to this permission set.
Select an appropriate function name by performing a search in the Functions window. For example the syntax for searching public PL/SQL APIs is:PLSQL:<package name>:<procedure name>. You can enter %PLSQL:OE% in the Find field and click Find to execute the search.
Searching for Functions
Based on your BPEL process, select appropriate functions and then grant the permissions to the APIs that you will be invoking from the BPEL process.
For example, for a sales order line change BPEL process, you select sales order line change related functions contained in the order change PL/SQL API and group them as a permission set, and then grant the permission set to an appropriate user through a role.
See: Creating a User Role.
Permission Set Menu
Save the Permission Set.
Permission sets are granted through user roles. Therefore, you must first create a role and then assign the role to a user.
Use the following steps to create a user role:
Log in to Oracle E-Business Suite using the User Management responsibility.
Select Roles & Role Inheritance from the Navigator to access the Roles & Role Inheritance page.
Click Create Role to access the Create Role page.
Enter the following information to create a role:
Category: Select Miscellaneous from the drop-down list
Role Code: Enter an appropriate role code (such as 'EBS_ADAPTER_ROLE')
Display Name: Enter appropriate information for the display name (such as 'EBS Adapter Role')
Description: Enter appropriate information for the description (such as 'EBS Adapter Role')
Application: Select an appropriate application (such as 'Application Object Library')
Active Date: Enter an appropriate date which is earlier than or equal to today's date so that the role can become valid right away
Save the information and click Create Grant.
Enter the following information in the Create Grant: Define Grant page:
Name: Enter an appropriate name (such as 'EBS_ADAPTER_GRANT')
Description: Enter description information for this grant
Click Next.
In the Create Grant: Define Object Parameters and Select Set page, select the Permission Set you created earlier in the Creating a Permission Set section and click Next.
Click Finish.
Use the following steps to grant a permission set to a user through a role:
Log in to Oracle E-Business Suite using the User Management responsibility.
Select Users from the Navigator to access the User Maintenance page.
Search for the user you want to assign the role and click Go.
Select the Update icon next to the user name that you want to assign the role.
In the Update User page, click Assign Roles to have the Search window populated which allows you to search for the role that you created earlier.
Select the role (such as 'EBS_ADAPTER_ROLE') and save your update.
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 Oracle Application Server Integration Business Activity Monitoring User's Guide for more details about installing Oracle BPEL Process Manager. Refer to the section "Notes on Installing Oracle BPEL Process Manager."
In addition to the interfaces that are made available through Oracle Integration Repository, OracleAS Adapter for Oracle Applications enables you to use business events, customized PL/SQL APIs, customized XML Gateway maps, and selected concurrent programs, all of which you can explore using the Oracle Applications Module Browser.
Oracle Applications Module Browser
The Oracle Applications Module Browser is a key component of OracleAS Adapter for Oracle Applications. You use the Module Browser to select the interface needed to define a partner link. The Module Browser combines interface data from Oracle Integration Repository with information about the additional interfaces supported by OracleAS Adapter, organized in a tree hierarchy as follows:
ProductFamilies
|-[product_family]
| |-[product]
| |-[business_entity]
| |-XML Gateway ([n])
| |-EDI ([n])
| |-PLSQL ([n])
| | |-[package_name]
| |-OpenInterfaces ([n])
| |-[OpenInterface_name]
| |-Tables ([n])
| |-Views ([n])
| |-ConcurrentPrograms ([n])
|-Other Interfaces
|-Business Events
|-Custom Objects
|-PLSQL APIs
| |-[package_name]
|-XMLGateway Maps
|-Inbound
|-Outbound
Note: The items under Other Interfaces, as well as certain PL/SQL APIs and concurrent programs under the [product family] hierarchy, are available through OracleAS Adapter for Oracle Applications, but not through Oracle Integration Repository.
The Oracle Integration Repository interface data populates the [product_family] sections, grouped according to the products and business entities to which they belong. Each interface type heading is followed by a number [n] indicating how many of that type are listed in that section.
Business events appear under Other Interfaces. Customized XML Gateway maps appear under Other Interfaces > Custom Objects, categorized as either inbound or outbound.
Customized PL/SQL APIs appear in two places:
Procedures within a package that's already exposed via Oracle Integration Repository appear under the package name within a product family hierarchy.
Procedures within a completely new package appear under the package name, under Other Interfaces > Custom Objects.
This section describes the following issues and workarounds:
WSDL Context Information Default Values
In the current release, BPEL Process manager generates WSDL code containing context information, including the username and responsibility of an Oracle Applications user who has sufficient privileges (based on the applications context of Organization ID, Username and Responsibility) to run the program.
By default the Username value is set to SYSADMIN and the Responsibility value is set to SYSTEM ADMINISTRATOR. To change these values, you must manually edit the WSDL file.
Correlation ID Defaults to BPEL for XML Gateway Transactions
The Adapter Configuration wizard of OracleAS Adapter for Oracle Applications does not specify a correlation ID for XML Gateway transactions for inbound or outbound interfaces. Instead, a default correlation ID of BPEL is automatically set in the WSDL file. To make this configuration work, you must configure Oracle Applications to set the same correlation ID value of BPEL for the corresponding XML Gateway transactions.
If you want the Adapter to use a different correlation ID than the default, you need to configure a correlation ID in Oracle Applications, then edit the Correlation="BPEL" line contained in the <jca:operation> section of the adapter service WSDL. Replace BPEL with the string value of the correlation ID you specified in Oracle Applications.
Workaround for Stored Procedures Using Complex Types and the DEFAULT Clause
When working with stored procedures for which the Adapter Configuration wizard must generate wrapper SQL stored procedures, there is a current limitation on DEFAULT clauses not being carried over to the generated wrapper stored procedures.
As a workaround, perform the following steps one time only for a given stored procedure:
Open the generated wrapper SQL script.
Copy all default clauses from the base-stored procedure into the corresponding wrapper.
Use SQL*Plus to reload the wrapper SQL script into the database.
Edit the generated XSD. If a parameter has a DEFAULT clause, its corresponding element in the XSD must have the extra attribute: db:default="true"
For example, with the following SQL:
FINANCE$INVOICE(isTrue INTEGER DEFAULT 1, value NUMBER DEFAULT 0)
The elements in the XSD for isTrue and value must have the new attribute:
<element name="ISTRUE" ... db:default="true" .../>
<element name="VALUE" ... db:default="true" .../>
One-time Workaround for Concurrent Programs and E-Commerce Gateway Interfaces
When working with Concurrent Programs and E-Commerce Gateway interfaces, you must perform the following workaround exactly once for a given E-Business Suite instance.
Note: This is to work around the known issue with the Adapter Configuration wizard being unable to preserve DEFAULT clauses for PL/SQL wrappers that it generates underneath the covers.
Load the following SQL file into the apps schema (using SQL*Plus) before launching the Oracle Applications adapter of the Adapter Configuration wizard to create services for either Concurrent Programs or E-Commerce Gateway Interfaces.
ORACLE_HOME\bpel\samples\tutorials\150.AppsAdapter\OrderImportConcurrentProgram\bpel\XX_BPEL_FND_REQUEST_SUBMIT_REQUEST.sql
Cannot Create a Partner Link If the Underlying API Has Been Recreated
The generation of a wrapper for an API that was recreated with the same name, but with a different set of parameters, will fail.
Note: This can happen for both packaged procedures and top-level or root procedures that require generated wrappers.
The following example illustrates the problem:
Create the initial API that, in this case, is defined at the top level:
SQL> create procedure test (a number, b varchar2, c BOOLEAN)
The BOOLEAN parameter indicates that a wrapper is necessary.
Use the database adapter for stored procedures in the Adapter Configuration wizard to generate and load the wrapper for this API.
Drop the API, then recreate it with a different set of parameters:
SQL> drop procedure test
SQL> create procedure test (a number, b varchar2, c number, d BOOLEAN)
An attempt to generate a partner link for this API using the Adapter Configuration wizard will fail with the following message:
The wrapper procedure, TOPLEVEL$TEST, could not be found
As a workround, exit JDeveloper BPEL Designer and restart it after recreating the stored procedure, but before attempting to create the second partner link.
Copyright © 2005, 2008, Oracle and/or its affiliates. All rights reserved.