|Oracle® Fusion Middleware Enterprise Deployment Guide for Oracle SOA Suite
11g Release 1 (11.1.1)
Part Number E12036-02
This chapter contains the following sections:
This section describes how to check and recover failed instances in BPEL, Mediator and other service engines.
Note:For the steps that require you to run SQL statements, you connect to the database as the
To check for recoverable instances, run the following SQL statements in the database:
// Find recoverable activities SQL> select * from work_item where state = 1 and execution_type != 1; // Find recoverable invoke messages SQL> select * from dlv_message where dlv_type = 1 and state = 0; // Find recoverable callback messages SQL> select * from dlv_message where dlv_type = 2 and (state = 0 or state = 1);
To recover failed BPEL instances:
In Enterprise Manager, select <domain_name>, then Fusion Middleware, then SOA, then soa-infra (server_soa), then Service Engine, then BPEL Engine, and then Recovery.
To recover failed Mediator composite:
In Enterprise Manager, select Mediator composite, and then Fault and Recoverable Instances.
To check for rejected messages:
SQL> select * from rejected_message
To check data in the instance tracking table, run the following SQL query:
SQL> select ID, STATE from COMPOSITE_INSTANCE where CREATED_TIME > datetime
where datetime specifies the date and time to narrow the query.
The adapter enters data into the
COMPOSITE_INSTANCE table before anywhere else.
When the adapter publishes data to the Adapter BC, the BC inserts an entry into the
COMPOSITE_INSTANCE table with STATE as
0. After the message has been processed, the STATE becomes
1. In case of errors, STATE >=
To prevent denial of service attacks and recursive node attacks, set the envelope size and nesting limits in
SCABBindingProperties.xml as illustrated in Example 11-1.
Example 11-1 Configuring Envelope Size and Nesting Limits in SCABBindingProperties.xml
<bindingType type="ws"> <serviceBinding> <bindingProperty> <name>request-envelope-max-kilobytes</name> <type>xs:integer</type> <defaultValue>-1</defaultValue> </bindingProperty> <bindingProperty> <name>request-envelope-nest-level</name> <type>xs:integer</type> <defaultValue>-1</defaultValue> </bindingProperty> </serviceBinding>
For standalone Web services, configure the envelope size and nesting limits in
oracle-webservices.xml. For example:
<request-envelope-limits kilobytes="4" nest-level="6" />
Note:Setting the envelope and nesting limits to extremely high values, or setting no values at all, can lead to denial of service attacks.
To run the Fusion Order Demo Application (FOD) in an environment described in the Enterprise Deployment Guide, you must update the FOD's
createJMSResources.seed file (located at
./bin/templates) by replacing the SOAJMSModule with SOAJMSModuleUDDS as the system resource name before running the ANT task that creates the JMS artifacts required for the FulFillment Mediator demo application.
To increase or decrease the number of times BAM retries the in-flight transactions after a RAC failover, change the
MaxDBNodeFailoverRetries setting from its default of 5 times to another value. However, it is a best practice to maintain the default settings for
MaxDBNodeFailoverRetries. To disable BAM's RAC failover retry support, set
UseDBFailover to false. (The default value for this setting is true.) For information on using these settings, see "Oracle BAM Configuration Property Reference" in Oracle Fusion Middleware Administrator's Guide for Oracle SOA Suite.
When redeploying a SOA infrastructure application or resource adapter within the SOA cluster, the deployment plan along with the application bits should be accessible to all servers in the cluster. SOA applications and resource adapters are installed using nostage deployment mode. Because the administration sever does not copy the archive files from their source location when the nostage deployment mode is selected, each server must be able to access the same deployment plan. Use
ORACLE_BASE/admin/<domain_name>/<cluster_name>/dp as the location for the deployment plan and applications, which should be accessible from all nodes in the EDG topology (as per the recommendation in Section 2.3, "Shared Storage and Recommended Directory Structure").