12 Miscellaneous

This chapter contains the following sections:

12.1 Recovering Failed BPEL and Mediator Instances

This section describes how to check and recover failed instances in BPEL, Mediator and other service engines.


For the steps that require you to run SQL statements, you connect to the database as the soainfra schema.
  • 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 >= 2.

12.2 Configuring Web Services to Prevent Denial of Service and Recursive Node Attacks

Configure SCABindingProperties.xml and oracle-webservices.xml to configure Web services against denial of service attack and recursive node attack.

Configuring SCABindingProperties.xml

To prevent denial of service attacks and recursive node attacks, set the envelope size and nesting limits in SCABBindingProperties.xml as illustrated in Example 12-1.

Example 12-1 Configuring Envelope Size and Nesting Limits in SCABBindingProperties.xml

<bindingType type="ws">

Configuring oracle-webservices.xml

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" />


Setting the envelope and nesting limits to extremely high values, or setting no values at all, can lead to denial of service attacks.

12.3 Running the SOA Fusion Order Demo Application in an EDG Environment

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.

12.4 Oracle Business Activity Monitoring (BAM) Configuration Properties

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 UseDBFailover and 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.

12.5 Using Shared Storage for Deployment Plans and SOA Infrastructure Applications Updates

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").