|Oracle Fusion Middleware Adapter for Oracle Applications User's Guide|
11g Release 1 (220.127.116.11.0)
Part Number E10537-04
This appendix covers the following topics:
This section describes the following issues and workarounds:
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.
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 18.104.22.168.0) 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"/>
Delete the Existing Subscriber on WF_BPEL_Q of the corresponding Oracle Applications.
Undeploy the SOA Composite application containing the Business Event partner link.
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;
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.
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:
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" .../>
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 workaround, exit JDeveloper BPEL Designer and restart it after recreating the stored procedure, but before attempting to create the second partner link.
Copyright © 2005, 2011, Oracle and/or its affiliates. All rights reserved.