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:

Applications Context Information Default Values

Applications context is used in passing header variables that may be required in the SOA Suite to process Concurrent Programs and PL/SQL APIs. When setting the context, it takes into account the values passed for the header variables 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.

In the case of a null or empty value, 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. 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 passed through an Assign activity.
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, and 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" .../>
```
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 Oracle 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:
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 workround, exit JDeveloper BPEL Designer and restart it after recreating the stored procedure, but before attempting to create the second partner link.