Comparison of the Methods Used for Querying over Multiple Tables

Oracle JCA Adapter for Database 9-53 A subset of queryByExample is to query by primary key, which can be implemented by passing in sample XML records where only the primary key attributes are set. Use queryByExample when you do not want to create a query using the visual query builder and want the flexibility of allowing the input record to share the same XML schema as the output records. The queryByExample operation is slightly less performant because a new SELECT must be prepared for each execution. This is because the attributes that are set in the example XML record can vary each time, and therefore the selection criteria vary. Input xmlRecord: Employee id lastNameSmithlastName Employee Output xmlRecord: EmployeeCollection Employee id5id lastNameSmithlastName .... Employee Employee id456id lastNameSmithlastName .... Employee EmployeeCollection Use Cases for Outbound Invoke Operations Outbound invoke operations are demonstrated in the following tutorial files: ■ Insert ■ Update ■ Delete ■ Merge ■ SelectAll ■ SelectAllByTitle ■ PureSQLSelect ■ QueryByExample To obtain these files, access the Oracle SOA Sample Code site, and select the Adapters tab. Use Cases for Pure SQL A new option in 10.1.3.1 enables you to specify any arbitrary SQL string, and an XML representing the inputs and outputs to the SQL is generated. Pure SQL operations are demonstrated in the following tutorial files: ■ UpdateAll ■ SelectCount 9-54 Oracle Fusion Middleware Users Guide for Technology Adapters ■ SelectGroupBy ■ SelectStar To obtain these files, access the Oracle SOA Sample Code site, and select the Adapters tab. Advanced Use Cases for Outbound Invoke Operations Advanced outbound invoke operations are demonstrated in the following tutorial files: ■ InsertWithClobs ■ XAInsert ■ NativeSequencingInsert To obtain these files, access the Oracle SOA Sample Code site, and select the Adapters tab.

9.4.2.2 Polling Strategies

The inbound receive enables you to listen to and detect events and changes in the database, which in turn can be the initiators of a business process. This is not a one-time action, but rather an activation. A polling thread is started, which polls a database table for new rows or events. Whenever a new row is inserted into the MOVIES table, the polling operation raises it to the SCA Run Time. The strategy is to poll every record once. The initial SELECT has to be repeated over time, to receive the rows that exist at the start and all new rows as they are inserted over time. However, a new row once read is not likely to be deleted, and therefore can possibly be read repeatedly with each polling. The various ways to poll for events, called polling strategies, also known as after-read strategies or publish strategies, range from simple and intrusive to sophisticated and nonintrusive. Each strategy employs a different solution for the problem of what to do after reading a row or event so as not to pick it up again in the next polling interval. The simplest and most intrusive solution is to delete the row so that you do not query it again. This section discusses the following polling operations that you can perform after the data is read from the database. This section also discusses the strategies and factors to help you determine which strategy to employ for a particular situation: ■ Delete the Rows that were Read ■ Update a Field in the [Table_Name] Table Logical Delete ■ Update a Sequencing Table ■ Update an External Sequencing Table on a Different Database ■ Control Table Strategy ■ Update a Sequencing File Delete the Rows that were Read Choose this operation to employ the physical delete polling strategy. This operation polls the database table for records and deletes them after processing. This strategy can be used to capture events related to INSERT operations and cannot capture database events related to DELETE and UPDATE operations on the parent table. This strategy