2 Adapter Life-Cycle Management

Installing Oracle JCA Adapters

Oracle JCA Adapters and Oracle Adapter for Oracle Applications are available as part of the Oracle Fusion Middleware install. In addition, these adapters support both Oracle WebLogic Server and middle tier deployments. Packaged-application adapters and legacy adapters are available as part of the Oracle Applications Adapter CD. These adapters support middle tier deployment only.

Starting and Stopping Oracle JCA Adapters

Oracle JCA Adapters are deployed as JCA 1.5 resource adapters. Therefore, to start or stop an adapter, every resource adapter must implement the start (BootstrapContext) and stop methods as part of the SPI interface. Oracle JCA Adapters are started when an SOA composite using them starts a JCA outbound interaction. Adapters can also be started when an SOA composite is itself loaded for inbound interactions or when adapters publish events to the Oracle BPEL process.

Once you have started an adapter, you can stop the adapter by shutting down the Oracle WebLogic Server or by stopping the J2EE application within Oracle Fusion Middleware. In this release, the JCA Binding Component acts as a part of the JCA 1.5 container.

Physically Deploying Oracle JCA Adapters

Oracle JCA Adapters are deployed as JCA 1.5 resource adapters in an Oracle WebLogic Server container. Adapters are packaged as Resource Adapter Archive (RAR) files using the Java Archive (JAR) format. The physical deployment of adapters involves using the RAR file and registering the adapters as connectors with the underlying Oracle WebLogic Server or the middle tier platform. The RAR file contains the ra.xml file, which is the deployment descriptor XML file containing deployment-specific information about the resource adapter. In addition, the RAR file contains declarative information about the contract between Oracle WebLogic Server and the resource adapter.

In addition to the ra.xml file in the.rar file, adapters package the weblogic-ra.xml template file. The weblogic-ra.xml file is used to define resource adapter ConnectorFactory objects (logical deployment). The weblogic-ra.xml file is the Oracle WebLogic Server-specific deployment descriptor for a resource adapter. It contains deployment configurations for deploying resource adapters to Oracle WebLogic Server, which includes the back-end application connection information as specified in the deployment descriptor of the resource adapter, Java Naming and Directory Interface (JNDI) name to be used, connection pooling parameters, resource principal mapping mechanism, and configurations.

For more information about creating connection factory, see Oracle Fusion Middleware Installation Guide for Oracle WebLogic Server.

Adding an Adapter Connection Factory

The logical deployment of adapters refers to the creation of ConnectionFactory objects in the weblogic-ra.xml deployment descriptor file. To add the connection information and assign to a JNDI name, edit the corresponding weblogic-ra.xml file of the resource adapter by either using Oracle WebLogic Server Administration Console or WLST scripts. The weblogic-ra.xml file contains run-time connection parameters for an adapter.

For more information about creating connection factory, see Oracle Fusion Middleware Installation Guide for Oracle WebLogic Server.

The following steps describe how to set up a Database connection factory in the Oracle WebLogic Server Administration Console.

This section includes the following topics:

• Creating a Data Source

• Creating a Connection Pool

Handling Deployment Plan When Working on a Remote Oracle SOA Server

If the Adminserver is running on computer A and the Oracle SOA server is running on computer B, then you must copy the deployment plan file to computer B before you activate changes made on the Oracle SOA server. If you try to activate changes without copying the deployment plan to the Oracle SOA Server computer, then a NullPointerException is thrown.

Setting the Trace Level of Oracle JCA Adapters

Set the trace level as follows:

• Oracle JCA Adapters and Oracle Adapter for Oracle Applications: Set the log level to, for example, TRACE:32 in the logger oracle.soa.adapter.

  For more information about setting trace levels for adapters, see Oracle Fusion Middleware Administrator's Guide.

• Packaged-application adapters: For outbound interactions, set the Loglevel property for packaged-application adapters in the weblogic-ra.xml file.

• Legacy adapters: The trace level for Oracle Connect, and the mainframe server can be set by using Oracle Studio.

The following are the steps to set the trace level by using the Oracle Enterprise Manager Console:

1. Navigate to http://servername:portnumber/em.

   The Oracle Enterprise Manager Console home page is displayed.

2. Right-click soa-infra from the SOA Folder in the Navigator tree in the left pane.

   A menu is displayed.

3. Select Logs, and the Log Configuration, as shown in Figure 2-1.

   Figure 2-1 Navigating to the Log Configuration Page

   
   Description of "Figure 2-1 Navigating to the Log Configuration Page"
   
   

   The Log Configuration page is displayed.

4. Locate oracle.soa.adapter in the Logger Name list, and change the log level in the Oracle Diagnostic Logging Level (Java Level) field. In this example, select Trace:32 (FINEST) from the list, as shown in Figure 2-2.

   Note:

   To ensure that log levels persist across component restarts, select Loggers With Persistent Log Level State from the View list. By default, the log level is set for runtime loggers. Runtime loggers do not persist across component restarts.

   Figure 2-2 The Log Configuration Page

   
   Description of "Figure 2-2 The Log Configuration Page"
   
   

Viewing Adapter Logs

You can view the logs for Oracle JCA Adapters as follows:

• Oracle JCA Adapters and Oracle Adapter for Oracle Applications: These adapters implement the LogManager interface of JCA Binding Component, which redirects log files in the Oracle Diagnostic Logging (ODL) format. For both outbound and inbound interactions, the log files are redirected to the soa-diagnostic.log file.

  The log files for Oracle SOA Suite that is deployed to the server-soa managed server are located in:

  MW_HOME/user_projects/domains/domain_name/servers/server-soa/logs/soa-diagnostic.log

  For more information about searching and viewing log files, see Oracle Fusion Middleware Administrator's Guide.

• Packaged-application adapters: These adapters do not implement the LogManager interface because it is not part of the J2CA 1.5 standard. Therefore, for system components the log outputs are redirected to

  ORACLE_INSTANCE\diagnostics\logs\component_type\component_name. For outbound interactions, the logs are directed to the same location. On the other hand, for inbound interactions, logs are redirected to soa-diagnostic.log.

• Legacy adapters: In addition to the J2CA resource adapter, legacy adapters consists of Oracle Connect, which consists of native adapters for communicating with the mainframe application and data stores. Oracle Connect logs can be viewed using Oracle Studio, which is the mainframe adapter design-time tool and Oracle Connect management tool. Oracle Connect generates various types of logs, such as the daemon log, workspace log, and server process log.

Using Header Properties for Oracle JCA Adapters

Oracle JCA Adapters expose the underlying back-end operation specific properties as header elements and allow the manipulation of these elements within a business process.

For more information about Oracle JCA Adapters, see Appendix A, "Oracle JCA Adapter Properties."

Note that you can add, delete, or revert Oracle JCA Adapters properties from the Oracle Enterprise Manager Console. Based on how the adapters behave when properties are added, deleted, or updated from the Oracle Enterprise Manager Console, they are classified as follows:

• The InteractionSpec or ActivationSpec Properties

• Endpoint Properties

Describing XML Data Structure

The record implementation for Oracle JCA Adapters is XMLRecord. All adapter interactions are started with XMLRecord. Each JCA record must be an implementation of oracle.tip.adapter.api.record.XMLRecord. Each instance of XMLRecord contains the RecordElement. RecordElements payload that contains data. In addition, each RecordElement contains one BLOB of data, which can either be a UTF-8-encoded XML string or a binary opaque byte stream.

XMLRecord consists of the following methods:

• getPayloadRecordElement: Retrieves the payload RecordElement.

• setPayloadRecordElement: Sets the payload record element of the XMLRecord.

Error Handling

The Oracle JCA Adapters provide error handling capabilities, as listed in the following sections.

This section includes the following topics:

• Handling Rejected Messages

• Handling Connection Errors

• Handling Message Errors

select * from rejected_message

Handling Connection Errors

Oracle JCA Adapters and Oracle Adapter for Oracle Applications handle connection errors for the following interactions:

• Outbound Interaction

• Inbound Interaction

Outbound Interaction

Oracle JCA Adapters and Oracle Adapter for Oracle Applications raise the oracle.tip.adapter.api.exception.PCRetriableResourceException exception for transient connection errors, which are recoverable connection errors. For example, a database listener may not have started and this might be giving connection errors.

There are two types of rejection handlers, the retryable exception and the non-retryable exception:

• Retryable Exceptions for Outbound Interaction

• Nonretryable Exceptions for Outbound Interaction

Retryable Exceptions for Outbound Interaction

In the case of retryable exceptions, you must set the value of jca.retry.count to the number of times that you want the retry to be carried out. For example, if you set the value of jca.retry.count to 10, then the retry occurs 10 times. However, if you have not set any value for jca.retry.count, then the retry is carried out by the fault policy, if you have included it as part of the composite

The following code snippet is an example of setting values in the composite.xml file for retryable exceptions for outbound interactions:

<reference name="Outbound">
  <interface.wsdl interface="http://xmlns...#wsdl.interface(Outbound_PortType)"/>
  <binding.jca config="Outbound_jms.jca">
    <property name="jca.retry.count">5</property>
    <property name="jca.retry.interval">1</property>
    <property name="jca.retry.backoff">2</property>
    <property name="jca.retry.maxInterval">6</property>
    <property name="jca.retry.maxPeriod">30</property>
  </binding.jca>
</reference>

Note that reply activity failure retries is one less than the jca.retry.count value that you specify. For example, if the jca.retry.count is 5, then you would expect the adapter to retry six times ((1 try plus 5 retries). However, it retries only four times, and you see only 5 instances in the Oracle Enterprise Manager Console.

Nonretryable Exceptions for Outbound Interaction

You can handle nonretryable exceptions for outbound interactions, by defining the maximum number of reconnection attempts that can be made through the fault-policy.xml file. In this file specify the parameters for reconnection attempts, as shown in the following example:

<faultName xmlns:bpelx="http://schemas.oracle.com/bpel/extension" name="bpelx:bindingFault">
            <condition>
                <action ref="ora-retry"/>
            </condition>
        </faultName>
      <Actions>
        <Action id="ora-retry">
            <retry>
                <retryCount>10</retryCount>
                <retryInterval>2</retryInterval>
                <exponentialBackoff>2</exponentialBackoff>
            </retry>
        </Action>
      </Actions>

A fault policy must be associated with a reference end point of the composite in fault-bindings.xml file, as shown in the following example:

<?xml version="1.0" encoding="UTF-8"?>
<faultPolicyBindings version="2.0.1" xmlns="http://schemas.oracle.com/bpel/faultpolicy" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <reference faultPolicy="ConnectionFaults">
      <name>writeMessageToQueue</name>
    </reference>
</faultPolicyBindings>

In this example, the reconnection parameter settings specify the JCA Binding Component run time to retry 10 times and the retry interval exponentially increases by multiples of 2 starting with 2 seconds.

Note:

Fault policy does not work for the outbound adapters in XA mode. For example, if you want the Fault policy to retry when the outbound adapter fails, then it does not retry and any outbound adapter that has been successful before this failure occurred does not rollback.

After the configured number of retries is reached, the Service Infrastructure Invocation exception is thrown. All time measurements are specified in seconds.

The propagation of the type of the Service Infrastructure Invocation exception is important in order to allow inbound adapters to respond to errors reported by outbound adapters. shows the fault propagation in the case of when an adapter calls Oracle BPEL Process Manager synchronously and then the Oracle BPEL Process Manager calls a down-stream adapter. In Figure 2-3, a Service Infrastructure Invocation exception propagates from the down-stream adapter, through Oracle BPEL Process Manager, and to the caller adapter.

Figure 2-3 Fault Propagation

Description of "Figure 2-3 Fault Propagation"

Inbound Interaction

All Oracle JCA Adapters (except for Oracle Socket Adapter) as well as legacy adapters support a pull model for connecting to the back-end application for receiving events. The packaged-application adapters (except for Oracle Adapter for Oracle Applications), however, support a push model for receiving events from EISs (Enterprise Information System). Connection-related issues are considered recoverable and most inbound adapters keep retrying until the adapters are able to establish connection with the EIS. However, if the inbound adapter encounters an irrecoverable error, for example, then if the inbound adapter is unable to delete from the EIS after a message has been published, then it deactivates the endpoint to prevent poisoned messages.

The packaged-application adapters (besides Oracle EBS Adapter) support a push model for receiving events from the back-end application. Hence, the concept of a connection does not apply. The inbound endpoints are usually an HTTP listener, TCP/IP listener, FTP listener, MQSeries listener and so on and their onMessage method is triggered whenever an event arrives.

There are two types of rejection handlers: the retryable exception and the non-retryable exception.

• Retryable Exceptions for Inbound Interaction

• Nonretryable Exceptions for Inbound Interaction

Retryable Exceptions for Inbound Interaction

In the case of retryable exceptions, you must set the value of jca.retry.count to the number of times that you want the retry to be carried out. For example, if you set the value of jca.retry.count to 10, then the retry occurs 10 times. However, if you have not set any value for jca.retry.count, then the retry is carried out indefinitely.

The following code snippet is an example of setting values for retryable exceptions for inbound interactions:

<service name="Inbound">
  <interface.wsdl interface="http://xmlns...#wsdl.interface(Inbound_PortType)"/>
  <binding.jca config="Inbound_db.jca">
    <property name="jca.retry.interval">5</property>
    <property name="jca.retry.interval">1</property>
    <property name="jca.retry.backoff">2</property>
    <property name="jca.retry.maxInterval">6</property>
  </binding.jca>
</service>

Note that reply activity failure retries is one less than the jca.retry.count value that you specify. For example, if the jca.retry.count is 5, then you would expect the adapter to retry six times ((1 try plus 5 retries). However, it retries only four times, and you see only 5 instances in the Oracle Enterprise Manager Console.

Note:

Infinite retries by inbound adapters for errors results in creating multiple composite instances because for every retry a separate composite instance is created. For example, consider an inbound adapter that is enqueueing a message. This data is inserted into two tables A and B. If for some reason the insert operation for table B fails, then instead of rolling back the inbound adapter retries to insert data to table B infinitely.

Nonretryable Exceptions for Inbound Interaction

The following properties are supported inbound:

• jca.retry.count

  Specifies the maximum number of retries before rejection.

• jca.retry.interval

  Specifies the time interval between retries (measured in seconds.)

• jca.retry.backoff

  Specifies the retry interval growth factor (positive integer.)

• jca.retry.maxInterval

  Specifies the maximum value of retry interval, that is, a cap if backoff > 1

• jca.retry.all

  If this property is set to true, then even non-retriable exceptions are retried based on the value specified in the jca.retry.count property.

The preceding list of properties are specified in the composite.xml file in Oracle JDeveloper, as shown in the following example:

 <service name="Inbound">
   <interface.wsdl interface="http://xmlns...#wsdl.interface(Inbound_PortType)"/>
   <binding.jca config="Inbound_db.jca">
         <property name="jca.retry.interval">5</property>
         <property name="jca.retry.interval">1</property>
       <property name="jca.retry.backoff">2</property>
       <property name="jca.retry.maxInterval">6</property>
     </binding.jca>
</service>

Handling Message Errors

This section describes how to handle message errors by means of a sample scenario.

Consider an example, where there are two composites, Composite 1 and Composite 2 each having an Oracle BPEL process and there is a mix of local as well as XA resources, as shown in Figure 2-4.

Figure 2-4 Sample Scenario: Handling Message Errors

Description of "Figure 2-4 Sample Scenario: Handling Message Errors"

In a positive scenario, that is, when the message is successfully delivered to all the queues (Q1, Q2 and Q3) the transaction commits successfully.

If the message cannot be delivered to Q1 (or to any one of the queues) whereas the message is delivered to queues Q2 and Q3, then the transaction must roll back all the three messages because all are XA resources and there is an exception in one of its units. The rollback exception is thrown only for the second composite where Q1 failed, and the transactions commits Q2 and Q3 instead of rolling back the messages for all the three queues.

In order that the transaction rolls back all the queues even if only one fails, and the other two have messages successfully delivered to them, you must make the following change in the composite.xml file of the called composite (Composite2):

Changes in composite.xml of Composite2

<component name="BPELProcess1">
<implementation.bpel src="BPELProcess1.bpel"/>
<property name="bpel.config.transaction">required</property>
</component>

Note that if you set bpel.config.transaction="required", then the Oracle BPEL engine effectively processes the synchronous request without creating a new transaction, rather, it uses the caller's transaction. Therefore, if at any point the transaction gets rolled back, nothing done in that transaction will commit.

How Oracle JCA Adapters Ensure No Message Loss

This section describes how adapters ensure no message loss.

Transactional adapters allow the Enterprise Information System (EIS) to participate in one-phase or two-phase commits (local transactions or global/distributed transactions). These commits are controlled either by the adapter (inbound) or by the Oracle User Messaging Service (UMS) (outbound). Non-transactional adapters implement their own schemes to ensure delivery, without the use of transactional semantics.

Streaming Large Payload

Oracle JCA Adapters support large payload processing for both inbound and outbound processing. However, only the following adapters support the streaming feature explicitly:

• Oracle File Adapter

  For more information, see Oracle File Adapter Scalable DOM.

• Oracle AQ Adapter

  For more information, see Stream Payload Support.

• Oracle JMS Adapter

  For more information, see Supports Streaming Large Payload.

• Oracle Database Adapter

  For more information, see Streaming Large Payload.

The other adapters do not have explicit support for both.

Composite Availability and Inbound Adapters

The Oracle WebLogic Server migration is used on WebLogic platform so that if a managed server or machine fails, then it automatically restarts on the same or another machine and inbound adapters to a composite on the failed server will then resume functioning. Meanwhile, inbound adapters in other cluster members continue working servicing messages.

For more information about composite availability and inbound adapters, see the Oracle Fusion Middleware High Availability Guide.

Manually Deploying an Adapter RAR File

This section describes how to manually deploy any adapter RAR file that does not have a jar file associated with it.

If you deploy any adapter RAR file that only contains META-INF/ra.xml and META-INF/weblogic-ra.xml and does not contain the jar file adapter required for creating JNDIs, then while deploying, you must change the deployment order to a higher value (say 500) so that the Oracle WebLogic Server can deploy this RAR file after the jar file of this adapter is loaded.

For example, to deploy the DBAdapter_NewJndis.rar file that contains only META-INF/ra.xml and META-INF /weblogic-ra.xml and does not contain the jar file adapter (DbAdapter.jar) required while instantiating the new JNDIs. In this case, after deploying the DBAdapter_NewJndis.rar file, you must change the deployment order to a higher value. This ensures that the Oracle WebLogic Server deploys the DBAdapter_NewJndi.rar file correctly even if you restart the Oracle WebLogic Server.

The following are the steps to manually deploy an adapter RAR file that does not have a jar file associated with it:

1. Navigate to the Oracle WebLogic Server Administration Console: http://servername:portnumber/console.

2. Use the required credentials to open the Home page of the Oracle WebLogic Server Administration Console.

   The Home page of the Oracle WebLogic Server Administration Console is displayed.

3. Select Deployments in the Domain Structure pane.

   The Oracle WebLogic Server Administration Console Summary of Deployments page is displayed.

4. Click Install.

   The Install Application Assistant page is displayed.

5. Enter the path of the application directory or file in the Path field, and then click Next.

6. Select the servers to which you want to deploy this application, and then click Next.

   The Optional Settings page is displayed.

7. Modify these settings or accept the defaults, and then click Next.

   The Review your choices and click Finish page is displayed.

8. Click Finish to complete the deployment.

9. After you deploy the RAR file, under Summary of Deployments, click the name of the RAR file that you deployed.

   The Settings page is displayed.

10. Change the value of Deployment Order field to a value that is higher than the default value. For example, 500.

    This ensures that the newly deployed RAR file is always loaded after the supporting classes are loaded by the Oracle WebLogic Server.

Defining Adapter Interface by Importing an Existing WSDL

You can define an adapter interface in the Adapter Configuration Wizard Adapter Interface page, as shown in Figure 2-5, by using either of the following methods:

• Using a WSDL that is generated using the operation name and schema that you specify in the Adapter Configuration Wizard in the pages that appear subsequent to the Adapter Configuration Wizard Adapter Interface page.

• Importing an existing WSDL.

Figure 2-5 Adapter Configuration Wizard Adapter Interface Page

Description of "Figure 2-5 Adapter Configuration Wizard Adapter Interface Page"

This section describes how to define an adapter interface by importing an existing WSDL. You can use this feature to create an adapter service or reference by using existing WSDLs. The option to choose an existing WSDL is supported for the following adapters only:

• Oracle AQ Adapter

• Oracle File Adapter

• Oracle FTP Adapter

• Oracle JMS Adapter

• Oracle MQ Series Adapter

• Oracle Socket Adapter

If you select the option of defining the adapter interface by importing an existing WSDL, then some functionalities on subsequent wizard pages are disabled. For example, since the WSDL defines the operation name and the message schema, the subsequent operation name and schema element fields are automatically filled in and you cannot modify it, as shown in Figure 2-6. However, if you do not choose to use an existing WSDL, then the adapter wizards will behave exactly as before.

Figure 2-6 Operation Page for Oracle AQ Adapter with Fields Automatically Populated

Description of "Figure 2-6 Operation Page for Oracle AQ Adapter with Fields Automatically Populated"

Note that the Adapter Configuration Wizard for Oracle MQ Series Adapter, Oracle JMS Adapter, and the Oracle AQ Adapter appears a bit different from the other adapters. It has the additional option to select a callback the port type and operation. Subsequent options in the Adapter Configuration Wizard are enabled or disabled depending on what port types and operations you select.

For example, while using the Adapter Configuration Wizard for defining Oracle MQ Series Adapter, if a callback is selected, then only the Send Message to MQ and Get Reply/Reports and the Get Message from MQ and Send Reply/Reports Asynchronous options are enabled. If a callback is not selected, then only the Put Message into MQ and Get Message from MQ options are enabled. If a WSDL operation that has a synchronous reply is selected, then only the Get Message from MQ and Send Reply/Reports Synchronous option is enabled.

Note that in all cases of using an existing WSDL, the options to use CICS or IMS schemas are disabled.

Creating an Application Server Connection for Oracle JCA Adapters

You must establish connectivity between the design-time environment and the server you want to deploy it to. To establish such connectivity, you must create an application server connection.

The following are the steps to create an application server connection:

1. In the File menu, click New.

   The New Gallery page is displayed, as shown in Figure 2-7.

   Figure 2-7 The New Gallery Page

   
   Description of "Figure 2-7 The New Gallery Page"
   
   

2. In the All Technologies tab, under General categories, select Connections.

   A list of the different connections that you can make is displayed in the Items pane on the right side of the New Gallery page.

3. Select Application Server Connection, and then click OK.

   The Create Application Server Connection page is displayed, as shown in Figure 2-8.

   Figure 2-8 The Create Application Server Connection Name & Type Page

   
   Description of "Figure 2-8 The Create Application Server Connection Name & Type Page"
   
   

4. Enter a connection name in the Connection Name field. For example, AppsServerConnection1.

5. Select WebLogic 10.3. for Connection Type and click Next.

   The Authentication page is displayed, as shown in Figure 2-9.

   Figure 2-9 The Create Application Server Connection Authentication Page

   
   Description of "Figure 2-9 The Create Application Server Connection Authentication Page"
   
   

6. Enter the user name and password, and then click Next.

   The Create Application Server Connection Configuration page is displayed, as shown in Figure 2-10.

   Figure 2-10 The Create Application Server Connection Configuration Page

   
   Description of "Figure 2-10 The Create Application Server Connection Configuration Page"
   
   

7. Enter the host name, the port details, and the domain server name in the Configuration page.

8. Click Next.

   The Create Application Server Connection Test page is displayed, as shown in Figure 2-11.

   Figure 2-11 The Create Application Server Connection Test Page

   
   Description of "Figure 2-11 The Create Application Server Connection Test Page"
   
   

9. Click Test Connection. A success message is displayed in the Status pane.

10. Click Finish.

    You have created a server connection.

Deploying Oracle JCA Adapter Applications from Oracle JDeveloper

You deploy an SOA composite application from Oracle JDeveloper.

Oracle JDeveloper requires the use of profiles for SOA projects and applications to be deployed. This section describes how to create and deploy profiles with Oracle JDeveloper.

This section describes how you deploy an application profile for the SOA project and the application.

To deploy the application, you must perform the following steps:

1. Right-click the project that you want to deploy, and select Deploy > project_name, to Application_Server_Connection_Name, as shown in Figure 2-12.

   The SOA Deployment Configuration dialog is displayed.

   Figure 2-12 Application Profile Deployment

   
   Description of "Figure 2-12 Application Profile Deployment"
   
   

2. Use the default settings, as shown in Figure 2-13.

   Figure 2-13 The SOA Deployment Configuration Dialog

   
   Description of "Figure 2-13 The SOA Deployment Configuration Dialog"
   
   

3. Click OK.

   The Authorization request dialog is displayed.

4. Enter the user name and password, and then click OK.

   The project is compiled and deployed to the Managed Server. You can view the deployment log clicking the Deployment tab in the design area.

   If you want to redeploy the same version of a SOA composite application, you cannot change the composite name. You can deploy with the same revision number if you selected the Overwrite any existing composites with the same revision ID check box on the SOA Deployment Configuration dialog. However, if you do not do so, then the following error message is deployed in the deployment log:

   pr 29, 2009 1:55:57 AM
   oracle.integration.platform.blocks.deploy.servlet.CompositeDeployerMessages severeSendError
   SEVERE: Sending back error message:
   Error during composite deployment: oracle.fabric.common.FabricDeploymentException:
   Composite with same revision ID already exists:
   default/<application name>!<revision id>.
   Please set the overwrite flag or use different revision ID.
   Abort deployment...
   

Testing Applications

You can run and test instances of deployed SOA composite applications from Oracle Enterprise Manager Grid Control Console. This enables you to:

• Manage a composite application.

• Initiate an instance of a composite.

• Track an instance of a composite.

• View detailed component instance audit trails.

For more information about testing applications, see Oracle Fusion Middleware Administrator's Guide for Oracle SOA Suite.

Batching and Debatching Support

The batching and debatching functionality is supported only by Oracle JCA Adapter for Files and Oracle JCA Adapter for FTP, and Oracle JCA Adapter for Databases. Oracle JCA Adapter for File and Oracle JCA Adapter for FTP consist of a Reader to debatch a single huge file into several batches. You need to specify the batch size during the design-time configuration. In addition, the adapter includes a Writer to batch a set of messages into a single file.

Oracle JCA Adapter for Databases consists of a Publish component to poll a set of tables to detect events. This component can raise events to the BPEL process one record at a time or multiple records at a time.

Migrating Repositories

All the JCA files generated by the Adapter Configuration Wizard have a reference to the JNDI name. The reference is defined in the weblogic-ra.xml file, which is the adapter's deployment descriptor. The JNDI name is the key when you want to migrate from a development environment to a test environment to a production environment. You should update the weblogic-ra.xml file to have the same JNDI name in all three environments: development, testing, and production. You should specify values for deployment time properties, such as retry interval and retry count, and then redeploy to testing environment or production environment. The weblogic-ra.xml will identify the end point as a development EIS or testing EIS or production EIS. For example, consider that when running through the Database Adapter Service Wizard, you specify eis/DB/custStore as the JNDI name for the createCustomer service. After modeling the composite by using this adapter service, you should deploy it to the development, test, or production environments without making any changes. But before you do this, ensure that you have a corresponding JNDI entry for eis/DB/custStore in each of your various environments pointing to the right EIS instance.

Recommended Setting for Data Sources Used by Oracle JCA Adapters

This section describes the recommended setting for non-XA and XA data sources used by Oracle JCA Adapters.

The following are the recommended settings for multi data sources:

• test-frequency-seconds should be 5

• algorithm-type should be Load-Balancing

• data-source-list should point to a list of comma-separated child data sources. For example, ("JDBC Data Source-0,JDBC Data Source-1")

Note that if your endpoint property resides in a RAC database, then it is recommended that you use multi data sources.

Table 2-1 lists the recommended setting for XA and non-XA data sources used by Oracle JCA Adapters.

jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=host-vip)(PORT=1521))(CONNECT_DATA=(SERVICE_NAME=service_name)(INSTANCE_NAME=inst1)))

<property>
<name>oracle.net.CONNECT_TIMEOUT</name>
<value>10000</value>
</property>

In addition to applying the settings mentioned in Table 2-1, you must perform the steps documented in the Programming WebLogic JTA guide available in the following link:

http://download.oracle.com/docs/cd/E12840_01/wls/docs103/jta/thirdpartytx.html#wp1084836

These steps are required for data sources using XA driver. After performing the steps mentioned in the preceding link, you must run the following SQL statements to enable WLS JTA recovery to work:

grant select on sys.dba_pending_transactions to public
GRANT FORCE ANY TRANSACTION TO public
grant execute on sys.dbms_xa to public