Row Set Support Using a Strongly or Weakly Typed XSD

9-32 Oracle Fusion Middleware Users Guide for Technology Adapters ■ SQL Server 2008 table valued functions and CLR functions are not supported. The Oracle Database Adapter supports strongly typed XSD for the following third-party databases: ■ Microsoft SQL Server 2005 ■ Microsoft SQL Server 2008 ■ IBM DB2 UDB 9.7 The Oracle Database Adapter does not support strongly typed XSD for the following third-party databases: ■ IBM DB2 AS400 ■ MySQL ■ Informix Dynamic Server ■ Sybase 15.0.2 For more information, see: ■ Section 9.7, Stored Procedure and Function Support ■ Section 9.7.7.1, Row Set Support Using a Strongly Typed XSD ■ Section 9.7.7.2, Row Set Support Using a Weakly Typed XSD

9.3.4 Proxy Authentication Support

You can connect to your Oracle data store by using Proxy Authentication. On a per-invoke basis, you can set a combination of the following new header properties: ■ jca.db.ProxyUserName: to use the OracleConnection.PROXYTYPE_USER_ PASSWORD proxy type, set this property to the proxy user name as a java.lang.String. ■ jca.db.ProxyPassword: to use the OracleConnection.PROXYTYPE_USER_ PASSWORD proxy type, set this property to the proxy user password as a java.lang.String. ■ jca.db.ProxyCertificate: to use the OracleConnection.PROXYTYPE_ CERTIFICATE proxy type, set this property to a base64Binary encoded byte[] array containing a valid certificate. This is a more encrypted way of passing the credentials of the user, who is to be proxied, to the database. The certificate contains the distinguished name encoded in it. One way of generating the certificate is by creating a wallet and then decoding the wallet to get the certificate. The wallet can be created using runutl mkwallet. It is then necessary to authenticate using the generated certificate. ■ jca.db.ProxyDistinguishedName: to use the OracleConnection.PROXYTYPE_DISTINGUISHED_NAME proxy type, set this property to the proxy distinguished name as a java.lang.String. This is a global name in lieu of the password of the user being proxied for. ■ jca.db.ProxyRoles: regardless of what proxy type you use, you can optionally set this property to define the roles associated with the proxy user as a String[] array where each java.lang.String corresponds to a role name. ■ jca.db.ProxyIsThickDriver: if you are using the OCI driver, set this property to a value of true to accommodate differences in the JDBC-level API between the thick and thin drivers. Oracle JCA Adapter for Database 9-33 To run the invoke, a proxy connection is obtained from the data source. For more information, see Chapter 10, Proxy Authentication, in the Oracle Database JDBC Developers Guide and Reference

9.3.5 Streaming Large Payload

To enable support to stream payload, you must select the Enable Streaming check box while specifying polling options, as shown in Figure 9–26 . When you enable this feature, the payload is streamed to a database instead of getting manipulated in SOA run time as in a memory DOM. You use this feature while handling large payloads. When you select the Enable Streaming check box, a corresponding Boolean property StreamPayload is appended to the ActivationSpec properties defined in the respective .jca file.

9.3.6 Schema Validation

The SchemaValidation [falsetrue] property is a new activation specification property that has been added, and this can be configured in a .jca file. When set to true, all XML files produced by the polling Oracle Database Adapter for Receive activities is validated against the XSD file. On failure, the XML record is rejected but still marked as processed by the Oracle Database Adapter. Databases provide structured storage and the XSD file is generated by the Oracle Database Adapter Wizard itself. However, if you edit the auto generated XSD and add your own restrictions, you may want to start validation. For instance, if you import a VARCHAR50 field, the auto-generated XSD has the max-length 50 restriction. However, if your BPEL process for some reason can only handle values of fixed length 22, it may want to validate the XML file.

9.3.7 High Availability

The Oracle Database Adapter supports high availability in an active-active setup. In an active-active setup, distributed polling techniques can be used for inbound Database Adapters to ensure that the same data is not retrieved more than once. For more information, see Section 9.3.8.1, Distributed Polling First Best Practice: SELECT FOR UPDATE SKIP LOCKED. Similar to other adapters, an Oracle Database Adapter can also be configured for singleton behavior within an active-passive setup. This allows a high performance multithreaded inbound Oracle Database Adapter instance running in an active-passive setup, to follow a fan out pattern and invoke multiple composite instances across a cluster. The Oracle Database Adapter also supports the high availability feature when there is a database failure or restart. The DB adapter picks up again without any message loss. For information on XA and non-XA data sources , see Section 2.21, Recommended Setting for Data Sources Used by Oracle JCA Adapters .

9.3.8 Scalability

The following sections describe best practice for multiple Oracle Database Adapter process instances deployed to multiple Oracle BPEL PM or Mediator nodes, including: ■ Section 9.3.8.1, Distributed Polling First Best Practice: SELECT FOR UPDATE SKIP LOCKED ■ Section 9.3.8.2, Distributed Polling Second Best Practice: Tuning on a Single Node First 9-34 Oracle Fusion Middleware Users Guide for Technology Adapters

9.3.8.1 Distributed Polling First Best Practice: SELECT FOR UPDATE SKIP LOCKED

The first best practice for multiple Oracle Database Adapter process instances deployed to multiple Oracle BPEL PM or Mediator nodes is to use the Adapter Configuration Wizard to set both the Distributed Polling check box in the Adapter Configuration Wizard and to set MaxTransactionSize. Increase concurrency by setting the adapter _db.JCA property NumberOfThreads. On an Oracle database, this will automatically use the syntax SELECT FOR UPDATE SKIP LOCKED. Concurrent threads will each try to select and lock the available rows, but the locks are only obtained on fetch. If an about to be fetched row is already locked, the next unlocked row will be locked and fetched instead. If many threads all execute the same polling query at the same time, they should all relatively quickly obtain a disjoint subset of unprocessed rows. On a non-Oracle database the SELECT FOR UPDATE will safely insure that the same row cannot be processed multiple times, however you may get less scalability. You should consider either using additionally a partition field or the second best practice which is essentially multi-threading on a single node with fan-out see Section 9.3.8.2, Distributed Polling Second Best Practice: Tuning on a Single Node First . When configuring this best practice, consider the following: ■ Section 9.3.8.1.1, Configuring PollingInterval, MaxTransactionSize, and ActivationInstances ■ Section 9.3.8.1.2, Partition Field ■ Section 9.3.8.1.3, activationInstances ■ Section 9.3.8.1.4, Indexing and Null Values ■ Section 9.3.8.1.5, Disabling Skip Locking ■ Section 9.3.8.1.6, MarkReservedValue ■ Section 9.3.8.1.7, SequencingPollingStrategy Last Read or Last Updated

9.3.8.1.1 Configuring PollingInterval, MaxTransactionSize, and ActivationInstances

In a distributed scenario, each polling instance will try to balance the load by not greedily attempting to process all unprocessed rows by itself. What that means is that at a time, an instance will only fetch at most MaxTransactionSize rows. When using skip locking, if a full MaxTransactionSize rows are fetched, the next MaxTransactionSize rows can be immediately fetched continuously. This is because concurrent threads do no block each other when using skip locking, so there is no danger of one instance fetching all the rows. However, with skip locking disabled, all threads will try to lock the same rows, and only one will succeed. Consequently, once this thread has processed MaxTransactionSize rows, it will pause until the next polling interval, to allow other threads to also lock and process rows. Hence, the maximum throughput with distributed polling enabled but uses SkipLocking disabled is: NumberOfThreads x MaxTransactionSizePollingInterval Note: A distributed approach is required to insure that multiple activation instances do not process the same rows.