Oracle Fusion Middleware Adapter for Oracle Applications User's Guide

Skip Headers

Contents

General Issues and Workarounds

This section describes the following issues and workarounds:

Sequence of Elements in XML and XSD Files Should Match

From this release (11.1.1.7.0), order of elements passed as input to an API using Adapter for Oracle Applications should strictly be the same as the order in which those elements appear under the sequence tag of the corresponding schema.

Please note that in previous releases, Adapter for Oracle Applications was non-restrictive and these elements could be passed in any order. However, the sequence of elements should now match the sequence in the corresponding schema.
Support for Business Events through Existing Partner Links

With the additional support for business event groups, perform the following steps to modify all existing partner links for outbound business events contained in an event group that is being listened to:

Important: This workaround is applicable only if Adapter for Oracle Applications is being used for listening to Event Groups. It is NOT needed if the Business Event is not part of any Event Group that is being listened to.
1. Updating the JCA property "MessageSelectorRule" for the existing Business Event partner links. This can be achieved by performing either one of the following steps:
  - Rerunning the Adapter Configuration (Recommended)
    
    Rerunning or editing the configuration wizard for an existing partner link of an outbound business event (on Oracle JDeveloper 11.1.1.6.0 and above) would update the artifacts with the appropriate MessageSelectorRule.
  - Manually Updating the JCA Properties
    
    Alternatively, modify the JCA property "MessageSelectorRule" for the business event partner link located in the file XXX_apps.jca, as stated below:
    
    Note: <EVENT_NAME> is to be replaced with the name of the Business Event.
    
    Change existing property from:
    
    <property name="MessageSelectorRule" value="tab.user_data.event_name = '<EVENT_NAME>'"/>
    
    To the following:
    
    <property name="MessageSelectorRule" value="tab.user_data.event_name = '<EVENT_NAME>' AND tab.user_data.getvalueforparameter('GROUP') IS NULL"/>
2. Delete the existing subscriber on WF_BPEL_Q of the corresponding Oracle Applications.
  1. Undeploy the SOA Composite application containing the Business Event partner link.
  2. Delete the subscriber using the following snippet:
    
    Note: <CONSUMER_NAME> is to be replaced with the name of the subscriber. It can be found in the XXX_apps.jca file as the value for the JCA property 'Consumer'.
```
begin 
subscriber := sys.aq$_agent('<CONSUMER_NAME>', NULL, NULL); 
dbms_aqadm.remove_subscriber(queue_name => 'WF_BPEL_Q', subscriber => subscriber); 
end; 
```
3. Redeploy the SOA Composite application.
For more information about business event groups, see Business Event Groups.
"DataSecurityCheck" Requires "IRepOverloadSeq" to be Passed for Overloaded Functions

Adapter for Oracle Applications uses the following two new JCA properties to handle access control for overloaded PL/SQL APIs. This feature works in conjunction with the grants created from the Integration Repository user interface, and it does not depend on any profile options.
- DataSecurityCheck
- IRepOverloadSeq
If a user wants the Function Security Authorization check to be performed, the following property information needs to be added in the WSDL file (XX_apps.jca):
```
<property name="DataSecurityCheck" value="yes"/>
```
However, the other property IRepOverloadSeq is derived automatically by Adapter for Oracle Applications at the design time during creation of the partner link. Based on these two properties, the function security check would be performed for the username, which is passed as a header property.

Please note that this security support would work with all interfaces which are available in the Integration Repository. For other interfaces, you need to enable the function security through the profile option "EBS Adapter for BPEL, Function Security Enabled" (EBS_ADAPTER_FUNCTION_SEC_ENABLED).

For more information about security support for overloaded functions, see Function Security Support for Overloaded Functions.
Populating Default Values for Record Types While Using PL/SQL APIs

Certain PL/SQL APIs exposed from Oracle E-Business Suite take record types as input. Such APIs expect default values to be populated for parameters within these record types for successful execution.

The default values are FND_API.G_MISS_CHAR for characters, FND_API.G_MISS_DATE for dates, and FND_API.G_MISS_NUM for numbers. Oracle Adapter for Oracle Applications can default these values when the parameters within the record type are passed as nil values, for example, as shown below:
```
<PRICE_LIST_REC>
<ATTRIBUTE1 xsi:nil="true"/>
<ATTRIBUTE2 xsi:nil="true"/>
<ATTRIBUTE3 xsi:nil="true"/>
...
</PRICE_LIST_REC>
```
This can be achieved with the help of a function in a Transform activity, or by directly passing the XML input with nil values and then assigning them to the record types within an Assign activity.
Recreating Wrapper Packages While Using Existing PL/SQL SOA Composites Against a Different Release Instance

When a user has a SOA composite of a PL/SQL API created against an Oracle E-Business Suite Release 11i instance and intends to use it against the Release 12 instance or vice versa, for the compatibility in the target instance, the wrapper package of the SOA composite must be recreated. This approach updates the signature in the generated wrapper SQL file for the target instance and avoids the possible confusion whether the signature is the same or has changed in the target instance.
WSDL Context Information Default Values

Applications context is used in passing header variables that may be required in a business activity or to complete a BPEL process. When setting the context, it takes into account the values passed for the header properties including Username, Responsibility, Responsibility Application, Security Group, and NLS Language.

If the values for the new header properties Responsibility Application, Security Group, and NLS Language are not passed, context information will be determined based on Username and Responsibility.

The default Username is SYSADMIN, the default Responsibility is SYSTEM ADMINISTRATOR, the default Security Group Key is Standard, and the default NLS Language is US.

You can change the default values specified in the generated WSDL. This is a static way of changing the context information. These values would apply to all invocations of the deployed business process. However, if you need to provide different context information for different invocations of the business process, then you can dynamically populate the header values. The context information can be specified by configuring an Invoke activity.

For more information about applications context, see Supporting for Normalized Message Properties.
Correlation ID Defaults to BPEL for XML Gateway Transactions

The Adapter Configuration wizard of Oracle 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:
1. Open the generated wrapper SQL script.
2. Copy all default clauses from the base-stored procedure into the corresponding wrapper.
3. Use SQL*Plus to reload the wrapper SQL script into the database.
4. 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" .../>
```
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:
1. 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.
2. Use the database adapter for stored procedures in the Adapter Configuration Wizard to generate and load the wrapper for this API.
3. 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)
```
4. 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
```
5. As a workaround, exit JDeveloper BPEL Designer and restart it after recreating the stored procedure, but before attempting to create the second partner link.

Troubleshooting and Workarounds

General Issues and Workarounds