| Oracle® Application Server Release Notes and New Features 10g Release 3 (10.1.3.5.1) Part Number E15342-03 |
|
|
View PDF |
This chapter describes issues associated with Oracle Application Server Technology adapters and Oracle Adapter for Oracle Applications, and new features. It includes the following topics:
Section 11.4, "xATransaction Property Has to Be Set to TRUE for Oracle MQ Series Adapter"
Section 11.8, "Workaround Required for Running the File2StoredProcedure Sample for Database Adapter"
Section 11.9, "Post-Update Requirement for the oc4j-ra.xml File"
When modeling a dequeue operation with AQ Adapter Wizard, the Adapter Configuration Wizard allows specifying both dequeue condition and the correlation ID. This is incorrect. The dequeue operation should specify only a dequeue condition or a correlation ID, and not both.
If both dequeue condition and the correlation ID are specified, then the dequeue operation will fail with an ORA-25240 error, as shown in the following example:
oracle.AQ.AQOracleSQLException: ORA-25240: message ID and dequeue condition/correlation ID specified in dequeue options
If you request a JNDI connection for MQ Series adapter, then you must specify a unique value in the connectionFactoryLocation property.
Oracle MQ Series Adapter works in either the XA mode or the non XA mode. If you have set the configurations for XA mode, then the adapter expects that all the future deployments are related to XA only. If you are working in the XA mode, and you set the xATransaction property as "false" in the JNDI connection setting, then the adapter throws an exception in the outbound operation.
In an XA transaction, the outbound JNDI must have the xATransaction property set to true in the oc4j.xml file, as shown in the following example:
<config-property name="xATransaction" value="true"/>
If the xATransaction property value is set to false, then the process throws the java.lang.NullPointerException exception.
In an outbound synchronous request/reply scenario, ensure that the request and reply parameters, QueueName and ReplyToQueueName are different. Using the same queue for both request and reply operations results in the process from being timed out.
In 10.1.3.5, there is no UI support to accommodate RFH2 headers in the MQAdapterOutboundHeader.wsdl file.
You must manually edit the the MQAdapterOutboundHeader.wsdl file as described in the following steps:
In the MQOutboundHeader element, add the following element
<element name="MQHeaderExtended" type="mq:MQHeaderExtended" minOccurs="0" />
Next, add the following code to the MQAdapterOutboundHeader.wsdl file:
<complexType name="MQHeaderExtended">
<sequence>
<element name="StrucId" type="mq:asd" minOccurs="1"/>
<element name="Version" type="mq:asd" minOccurs="1"/>
<element name="Encoding" type="mq:asd" minOccurs="1"/>
<element name="CodedCharSetId" type="mq:asd" minOccurs="1"/>
<element name="Format" type="mq:asd" minOccurs="1"/>
<element name="Flags" type="mq:asd" minOccurs="1"/>
<element name="NameValueCCSID" type="mq:asd" minOccurs="1"/>
<element name="JMSFolder" type="mq:asd" minOccurs="0"/>
<element name="USRFolder" type="mq:asd" minOccurs="0"/>
</sequence>
</complexType>
<complexType name="asd">
<simpleContent>
<extension base="string">
<attribute name="dataType" use="required" type="mq:PropTypeEnum"/>
<attribute name="value" use="required" type="string"/>
</extension>
</simpleContent>
</complexType>
When you insert a message with a replyToQueueName as some remote queue definition, and if the replyToQueueManager is not specified, then the queue manager resolves the destination queue name and queue manager name from the remote queue definition and populates the replyToQueueName and replyToQueueManagerName appropriately.
For example, consider a scenario in which the destination queue manager is QM2, queue name is QB, and R is the remote definition of this queue on queue manager QM1.
If you insert a message M with M.replyToQueueName="R" and do not specify the queue manager name, then MQSeries internally resolves the appropriate values as M.replyToQueueName="B" and M.replyToQueueManagerName="QM2". However, if you specify M.replyToQueueManagerName="QM1" along with M.replyToQueueName="R", then this auto-resolution is prevented and the operation works as expected.
This is because the destination queue manager and queue name resolved by a queue manger may not be accessible from the queue manager connection, which leads to MQ 2087 reason MQRC_UNKNOWN_REMOTE_Q_MGR.
To run the File2StoredProcedure sample located in bpel\samples\tutorials\122.DBAdapter, you must perform the following steps:
Add the following clause to the XSD file:
elementFormDefault="qualified"
Change the instance XML by removing "db:" and add the following namespace:
<InputParameters
xmlns="http://xmlns.oracle.com/pcbpel/adapter/db/SCOTT/ADDEMPLOYEES/">
...
</InputParameters>
Redeploy the sample with the new XSD file and invoke it with the updated instance XML.
Whenever you modify the oc4j-ra.xml file, you must restart the server for the changes to take effect.
This section describes the new features for Oracle Application Server 10g release 10.1.3.5 for the following adapters:
Oracle Application Server 10g release 10.1.3.5 includes the following new feature for the Oracle Adapter for Oracle Applications:
Header variables are used to provide applications context information required in the SOA Suite to process Concurrent Programs and PL/SQL APIs. To provide additional header support, Oracle Adapter for Oracle Applications can now accept the following three new header parameters along with the existing Username, Responsibility, and Org_ID parameters for setting applications context:
RespApplication: Responsibility Application Key which needs to be used to set the context.
SecurityGroup: Security Group Key which defaults to 'Standard' if not passed.
NLSLanguage: It is the language code for the request. NLS context would be set to the language code that is passed, if valid. It would default to 'US' if not passed.
Note:
Existing header parameterResponsibility used in earlier releases can now take Responsibility Key as well as Responsibility Name as input. If the header parameter NLSLanguage is set, and Responsibility Name is passed, the value passed for Responsibility is expected to be in the same language. However, Responsibility Key and all other header parameters are language independent.All these header parameters would be used together to set the applications context. Alternatively, passing just the Username and Responsibility would work as it did in the earlier releases.
In the case of a null or empty value, the following are the default values for the parameters:
Username: SYSADMIN
Responsibility: System Administrator
SecurityGroup: Standard
NLSLanguage: US
Design-Time Tasks for Assigning Header Variables
Create a new BPEL project.
Add a Partner Link.
Configure an Invoke activity:
Configure the basic information in the General tab including creating input and output variables for the Invoke activity.
Create a header variable in the Adapters tab and configure it with the Header_msg message type from the AppsContextHeader.wsdl file, as shown in Figure 11-1.
Add an Assign activity before the Invoke activity to assign header variables:
Select Copy Operation tab in the Assign dialog box and select Copy Operation... from the Create drop-down list.
To enter the header variable values in the Assign activity, in the From group, select Expression as the type and enter a username variable value such as 'operations'.
In the To group, navigate to Variables > Process > Variables > Variable_1 > Header >ns2:ProcedureHeaderType and select ns2:Username. The XPath field should contain your selected entry, as shown in Figure 11-2.
Figure 11-2 The Create Copy Operation Dialog

Click OK.
Use the same method to assign additional header variable values. For example, enter the following parameter values, as shown in Figure 11-3.
'Order Management' for Responsibility
'207' for ORG_ID
'ONT' for RespApplication
'Standard' for SecurityGroup
'US' for NLSLanguage
The following section describes the new feature for the MQ Series Adapter:
MQ Adapter must pass the persistence and expiry interval from inbound request message to the reply message in synchronous-request-response (inbound) scenario. You must set the CopyPersistenceFromInbound, and PropagateExpiryInterval properties to true so that the two inbound headers are copied to the Reply message headers.
The following sections describe the new features for the File and FTP Adapters:
In order for FTP Adapter to sort files by their time stamps, the support for LIST command has been added.
You can configure the FTP Adapter to use the LIST command for listing by setting the UseNlst property to false (UseNlst="false") in the inbound WSDL. If this property is set, then the adapter uses LIST as opposed to NLST.
You can configure the inbound Oracle File or FTP Adapter to sort files in a particular order. For example, you can configure the sorting parameters for Oracle File and FTP Adapters to process files in ascending or descending order by time stamps.
You must meet the following prerequisites for sorting scenarios of Oracle File and FTP Adapters:
Use a synchronous operation.
If you are using FTP Adapter, then set the UseNlst="false" property in the inbound WSDL.
Add the following property to the inbound WSDL:
To sort the file names by their modified time stamps in ascending order, you must use:
Sorter="oracle.tip.adapter.file.sorter.TimestampSorterAscending
To sort the file names by their modified time stamps in descending order, you must use:
Sorter="oracle.tip.adapter.file.sorter.TimestampSorterDescending
On the 10.1.3.5 installation, in $ORACLE_HOME/bpel/system/services/config/pc.properties, you must set the following parameter:
oracle.tip.adapter.file.numProcessorThreads=1
Restart the server.
This section describes documentation errata. It includes the following topic:
In the Database Adapter, help for the Unread Value field in the Adapter Configuration Wizard - Logical Delete page is incorrect.
The correct help for the Unread Value field must read as follows:
(Optional) Enter an explicit value to indicate that the row must be read.