Troubleshooting and Workarounds

This appendix covers the following topics:

General Issues and Workarounds

General Issues and Workarounds

This section describes the following issues and workarounds:

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.