| Oracle® Application Server Release Notes 10g Release 3 (10.1.3.1.0) for Linux x86 Part Number B31014-11 |
|
|
View PDF |
| Oracle® Application Server Release Notes 10g Release 3 (10.1.3.1.0) for Linux x86 Part Number B31014-11 |
|
|
View PDF |
This chapter describes issues associated with Oracle Application Server Adapters. It includes the following topics:
Section 7.1, "Oracle Application Server Adapter for Files/FTP Issues and Workarounds"
Section 7.2, "Oracle Application Server Adapter for Java Message Service Issues and Workarounds"
Section 7.3, "Oracle Application Server Adapter for Advanced Queuing Issues and Workarounds"
Section 7.4, "Oracle Application Server Adapter for Database Issues and Workarounds"
Section 7.5, "Oracle Application Server Adapter for MQSeries Issues and Workarounds"
Section 7.6, "Oracle Application Server Adapter for Oracle Applications Issues and Workarounds"
This section describes the following issues and workaround related to Oracle Application Server Adapter for Files (file adapter) and Oracle Application Server Adapter for FTP (FTP adapter):
When you use correlation sets with file adapter by using the empty BPEL project template, the property aliases get created in the partnerlink wsdl files. However, if you edit the adapter partnerlink, the property aliases are removed from the wsdl file. This can cause some compilation issues for the BPEL project.
To overcome this issue, you need to manually edit the partnerlinks wsdl files by using the source view.
Perform the following steps to set up Maverick on FTP adapter:
Download licensed maverick-all.jar from the following location:
http://www.3sp.com/requestEvaluation.do?productCode=MAVERIC
Copy maverick-all.jar to the directory where FTP adapter is installed.
For Oracle Enterprise Service Bus or Oracle BPEL Process Manager installed on Oracle Application Server middle tier, copy the maverick-all.jar to the ORACLE_HOME\j2ee\homemid\connectors\FtpAdapter\FtpAdapter directory.
For standalone installation, you need to copy the maverick-all.jar to the ORACLE_HOME\j2ee\home\connectors\FtpAdapter\FtpAdapter directory.
Rename the license file to SshImplLicense.lic and copy it to the directory to which you copied the maverick-all.jar file.
On command prompt, go to the FTP adapter directory.
For Oracle Enterprise Service Bus or Oracle BPEL Process Manager installed on Oracle Application Server middle tier:
ORACLE _HOME\j2ee\homemid\connectors\FtpAdapter\FtpAdapter
For standalone installation:
ORACLE_HOME\j2ee\home\connectors\FtpAdapter\FtpAdapter
Run the following command:
jar uvf ftpAdapter.jar SshImplLicense.lic
Restart the server.
This section describes the following issues and workarounds:
Section 7.2.1, "JMS adapter in an XA scenario against AQ-JMS (OJMS)"
Section 7.2.2, "ESB Cannot Run JMS Adapter (OEMS JMS provider) in Non-Managed Mode"
Section 7.2.3, "Regression Stress - Dequeue Fails with AQJMSException in AQJMS Advanced Scenario"
You must use separate Resource Providers for inbound and outbound AQJMS Adapters:
You must set a new partnerlink property (BPEL) or endpoint property (ESB) called "cacheConnections" to false. If this is not specified, then the default value is true (which is the default in both 10.1.2 and 10.1.3).
You should use separate OJMS resource providers (defined J2EE_HOME/config/application.xml) for inbound and outbound JMS destinations (queues or topics) participating in the same global transaction.
JMS Adapter cannot use connection information from WSDL to run in non-managed mode. It reports missing connection factory.
Even in non-managed mode, some adapters have pre-requisites; you should not assume that non-managed equates no server configuration is required. For instance, the JMS Adapter requires a resource provider to be configured inapplication.xml and potentially data-sources.xml (if the resource provider refers to a data source). If these pre-requisites exist ahead of time, then non-managed mode would also work for ESB. Exact same issue pertains to BPEL as well. Note that this is applicable only for OEMS JMS provider.
Under heavy system load, that is, when the load for inbound and outbound for AQ JMS adapters is high, dequeue fails with an AQjmsException.
To address this issue, use the following workaround:
Create two separate physical connection pools (that is, use two separate (AQ) JMS resource providers). Each JMS WSDL (Enqueue and Dequeue) then points to a different JCA JNDI Connection Factory, which in turn would point to two separate JMS connection factories, each using one of the two resource providers, as shown in the following examples:
Enqueue WSDL
<jca:address location="eis/aqjms1" />
Dequeue WSDL
<jca:address location="eis/aqjms2" />
JmsAdapter/oc4j-ra.xml
<connector-factory location="eis/aqjms1" ... <config-property name="connectionFactoryLocation" value="java:comp/resource/aqjms1/QueueConnectionFactories/qcf"/> ... <connector-factory location="eis/aqjms2" ... <config-property name="connectionFactoryLocation" value="java:comp/resource/aqjms2/QueueConnectionFactories/qcf"/> ...
j2ee/home/config/application.xml
<resource-provider class="oracle.jms.OjmsContext" name="aqjms1"> <description>OJMS Context using thin JDBC</description> <property name="url"value="jdbc:oracle:thin:scott/tiger@localhost:1521:ORCL" /> <resource-provider class="oracle.jms.OjmsContext" name="aqjms2"> <description>OJMS Context using thin JDBC</description> <property name="url" value="jdbc:oracle:thin:scott/tiger@localhost:1521:ORCL" />
Note:
Even when the scenario works fine under regression stress, you will still see theAQJMSException in the log. You can use this workaround to avoid this exception.When using Topics with OJMS (AQ based JMS), AQ JMS Topic hangs, and does not dequeue even though there are messages at topic.
The JMS adapter subscriber (inbound) WSDL should use a JCA connection factory (for example, eis/OJms/myConnectionFactory1) which uses an OJMS resource provider (for example, resprov1), which is based on a URL (for example, jdbc:oracle:thin:@host:1521:orcl).
The following list exemplifies the workaround mentioned in the preceding paragraph:
MyJmsSubsriber.wsdl
...
<service name="JmsSubscribe">
<port name="jmsSubscribe_pt" binding="tns:jmsSubscribe_binding">
<jca:address location="eis/OJms/myConnectionFactory1"/>
...
J2EE_HOME/application-deployments/default/JmsAdapter/oc4j-ra.xml
<connector-factory location="eis/OJms/myConnectionFactory1" connector-name="Jms Adapter"> <config-property name="connectionFactoryLocation" value="java:comp/resource/resprov1/QueueConnectionFactories/myQCF"/>
J2EE_HOME/config/application.xml
<orion-application ...
...
<resource-provider class="oracle.jms.OjmsContext" name="resprov1">
<property name="url" value="jdbc:oracle:thin:@host:1521:orcl" />
<property name="username" value="scott" />
<property name="password" value="tiger" />
</resource-provider>
The following types of correlation schemas are available for JMS Adapter message correlation within Oracle BPEL Process Manager:
This is one of the choices available for JMS Adapter message correlation within BPEL process: Native adapter correlation when a BPEL invoke is followed by BPEL receive.
Note:
Native adapter correlation is applicable only to AQ, JMS and MQ Series adapters.The messaging Adapters like JMS have support for native correlation and perform automatic correlation between an outbound (BPEL invoke) message and an inbound (BPEL receive) message mimicking a request-response scenario. The Correlation ID of the incoming message has to be set to the Message ID of the outgoing JMS message. This needs to be implemented in the JMS application that is sending the reply on the other end. The underlying Adapter Framework (AF) stores a hashmap table whose entries map the Message Id of the outgoing JMS message with that of the native BPEL correlation ID. However Adapter native correlations can be used only in certain specific cases involving an invoke followed by a receive pointing to the same PartnerLink activity. You need to use the BPEL correlation sets for all other cases.
The following correlation sets are available:
Based on JMS and AQ headers (available to JMS and AQ adapters only)
Based on payload (available to all adapters)
Correlation sets are a BPEL mechanism that provides for the correlation of asynchronous messages based on message body contents. Correlation sets needs to be defined when the interactions are not simple invoke-receive activities.
This section describes the following issue and workaround:
When there are large number of messages (more than 100K) in an AQ queue, dequeuing in the AQ adapter can be very slow. The problem is a performance issue with the 10.x.x version of the database. However, the previous versions of the database work fine.
When you encounter this issue, run one of the following commands to generate statistics for the queue or topic table:
dbms_stats.gather_table_stats('JMSUSER', 'QTAB')
or
dbms_stats.gather_schema_stats('JMSUSER')
where QTAB is the Queue/Topic table and JMSUSER is the user/schema. Note that statistics should be refreshed every time a large number of rows are updated, inserted, or deleted.
This section describes the following issues and workarounds:
Section 7.4.1, "DB Adapter Wizard Shows Empty (Blank) Page After Creating DB Connection"
Section 7.4.2, "Faulted DBAdapter Instances Do Not Appear in BPEL Console"
After migration of 10.1.2.0.2 122.DBAdapter/InsertWithCatch (when you open in JDeveloper 10.1.3.1), if you open the project, and double-click the DB adapter partnerlink, then you will get a message stating that your UI connection is missing. After you create the UI connection, and click the Next button, you will get a blank page.
The issue here is that the Next button should be disabled, which in this case, isn't. The workaround is ensure a connection exists and is selected, and not to click the Next button otherwise.
Faulted DBAdapter instances do not appear in BPEL console because the BPEL auditing is tied to the JTA transaction, that is, auditing can only occur if the JTA transaction commits.
The faulted instance does not appear if a XA/JTA DBAdapter invoke fails, and the JTA transaction cannot (must not) be committed. This problem also occurs with server timeouts, where the JTA transaction is marked rollback only. However, in 10.1.3.1 DBAdapter is configured for JTA out of the box so this problem is now apparent all the time.
Report of success or failure has to be tied to JTA, but you cannot report failure and rollback the transaction at the same time. If the instance is successful you must audit through JTA, but if unsuccessful you theoretically cannot (you are writing as part of a transaction which can never commit.)
This section describes the following issues and workarounds:
You must apply patch 5594751 before using the Oracle Application Server Adapter for MQSeries. The patch is available at the following location:
https://www.metalink.oracle.com/
This section describes the following issues and workarounds:
Issue: While configuring Oracle Application Server Adapter for Oracle Applications to create business event outbound messages, users must specify the schema file location and select the schema element that defines the messages for the event payload using the Adapter Configuration Wizard in Oracle JDeveloper. However, if users are not sure about the event payload data type or the schema details, then users may not have the correct WDSL file generated corresponding to a selected business event.
Resolution: To resolve this issue, Oracle Application Server Adapter for Oracle Applications provides an updated schema selection page allowing you to select the business event payload schema from one of the following options through the Wizard:
No Schema
Any Schema
Specify Schema
When you select either the "No Schema" or "Any Schema" option, there is no need to further specify the schema information for your business event service. The associated WSDL file corresponding to your specified business event service will be generated. If you select the "Specify Schema" option, then you must specify the location of schema file and then select the schema element that defines the payload of outbound business event.
For more information, refer to Oracle Application Server Adapter for Oracle Applications User's Guide (B28351-03) for details.
This section describes documentation errata. It includes the following topic:
Section 7.7.1, "Incorrect Values of the hostOSType and Indextype Parameters"
Section 7.7.4, "Implication of Dequeue Condition in AQ Adapters"
Section 7.7.5, "XMLType Is Supported in the 10.1.3.1 Release"
Section 6.4.2 "Modify the oc4j-ra.xml File" of Oracle Application Server Adapters for Files, FTP, Databases, and Enterprise Messaging User's Guide contains incorrect values of the hostOSType and Indextype parameters.
The value of hostOSType should be specified as z/os or Z/OS and Indextype of the MQSeries queues should be set to MQIT_GROUP_ID.
Section 6.3.8 "Message Segmentation" of Oracle Application Server Adapters for Files, FTP, Databases, and Enterprise Messaging User's Guide contains incorrect property name. The property name in this section should be SegmentIfReqd. For example:
SegmentIfReqd="true"
Section 3.2.1.3 "Adding a Partner Link" of Oracle Application Server Adapters for Files, FTP, Databases, and Enterprise Messaging User's Guide has missing information about using Data Source. While creating a server connection while defining an AQ adapter service, you can use Data Source when oc4j-ra.xml is not configured with the correct jndi location for connector factory. Consider the following code snippet from the adapter service wsdl:
<jca:address location="eis/AQ/aqSample" UIConnectionName="aqSample" />
If the adapter service is configured as shown in the preceding example and oc4j-ra.xml does not have an entry for "eis/AQ/aqSample", then the data source value specified by "Data Source" will be used. Additionally, the data source should be defined in the data-sources.xml file as well.
Section 3.1.1.2 "Dequeue and Enqueue Features" of Oracle Application Server Adapters for Files, FTP, Databases, and Enterprise Messaging User's Guide has missing information about the implication of Dequeue condition.
Dequeue condition is an Advanced Queuing product feature that AQ adapter uses. A dequeue condition is specified as part of the AQDequeueOption object, which is internally used by the Dequeue AQ API. If a dequeue condition is specified and no messages meet the specified condition, then no dequeue will happen.
A dequeue condition element is a Boolean expression using syntax similar to the WHERE clause of a SQL query. This Boolean expression can include conditions on message properties, user object payload data properties, and PL/SQL or SQL functions. Message properties include priority, corrid, and other columns in the queue table.
Section 3.1.1 "AQ Adapter Features" of Oracle Application Server Adapters for Files, FTP, Databases, and Enterprise Messaging User's Guide contains incorrect information about XML type not being supported by AQ adapters. XML type is supported by AQ adapters from release 10.1.3 onwards.
|
 Copyright © 2010, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|