This chapter contains the following sections:
Section 11.1, "Recovering Failed BPEL and Mediator Instances"
Section 11.3, "Running the SOA Fusion Order Demo Application in an EDG Environment"
Section 11.4, "Oracle Business Activity Monitoring (BAM) Configuration Properties"
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 thesoainfra
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
.
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 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>
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" />
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 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.
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").