10 Managing the Topology

This chapter describes some operations that you can perform after you have set up the topology. These operations include monitoring, scaling, and backing up your topology.

This chapter contains the following sections:

Section 10.1, "Monitoring the Topology"
Section 10.2, "Deploying Composites and Artifacts in SOA Enterprise Deployment Topology"
Section 10.3, "Managing Space in the SOA Infrastructure Database"
Section 10.4, "Configuring UMS Drivers"
Section 10.5, "Scaling the Topology"
Section 10.6, "Performing Backups and Recoveries"
Section 10.7, "Troubleshooting"
Section 10.8, "Best Practices"

10.1 Monitoring the Topology

For information on monitoring the topology, see chapters 7 and 8 of the Oracle Fusion Middleware Administrator's Guide for Oracle SOA Suite.

10.2 Deploying Composites and Artifacts in SOA Enterprise Deployment Topology

When deploying SOA composites to a SOA Enterprise Deployment Topology, deploy to a specific server's address and not to the load balancer address (soa.mycompany.com). Deploying to the load balancer address may require direct connection from the deployer nodes to the external load balancer address which may require additional ports to be opened in the firewalls used by the system.

For B2B, deploy agreements and purge/import metadata ONLY from the GUI available in B2B console instead of using the command line utility. Using the command line utility for these operations may cause inconsistencies and errors in the B2B system.

When deploying SOA Fusion Order Demo, the following additional steps are required in addition to the deployment steps provided in the FOD's README file).

Change the nostage property to false in the build.xml file of the Web applications so that ear files are copied to each node. Edit the CreditCardAuthorization and OrderApprvalHumanTask build.xml files, located at FOD_dir\CreditCardAuthorization\bin and FOD_dir\OrderApprovalHumanTask\bin directories, and change the following field:

<target name="deploy-application">
     <wldeploy action="deploy" name="${war.name}"
       source="${deploy.ear.source}" library="false"
       nostage="false"
       user="${wls.user}" password="${wls.password}"
       verbose="false" adminurl="${wls.url}"
       remote="true" upload="true"
       targets="${server.targets}" />
   </target>

To:

<target name="deploy-application">
     <wldeploy action="deploy" name="${war.name}"
       source="${deploy.ear.source}" library="false"
       nostage="true"
       user="${wls.user}" password="${wls.password}"
       verbose="false" adminurl="${wls.url}"
       remote="true" upload="true"
       targets="${server.targets}" />
   </target>

Change the target for the Web applications so that deployments are targeted to the SOA Cluster and not to an individual server. Edit the build.properties file for FOD, located in the FOD_Dir/bin directory, and change the following field:
```
# wls target server (for shiphome set to server_soa, for ADRS use AdminServer) 
server.targets=SOA_Cluster (the SOA cluster name in your SOA EDG)
```

Change the JMS seed templates so that instead of regular Destinations, Uniform Distributed Destinations are used and the JMS artifacts are targeted to the EDG JMS Modules. Edit the createJMSResources.seed file, located in the FOD_DIR\bin\templates directory, and change:

# lookup the SOAJMSModule - it's a system resource
     jmsSOASystemResource = lookup("SOAJMSModule","JMSSystemResource")

     jmsResource = jmsSOASystemResource.getJMSResource()
    
     cfbean = jmsResource.lookupConnectionFactory('DemoSupplierTopicCF')
     if cfbean is None:
         print "Creating DemoSupplierTopicCF connection factory"
         demoConnectionFactory =
 jmsResource.createConnectionFactory('DemoSupplierTopicCF')
         demoConnectionFactory.setJNDIName('jms/DemoSupplierTopicCF')
         demoConnectionFactory.setSubDeploymentName('SOASubDeployment')
 .
     topicbean = jmsResource.lookupTopic('DemoSupplierTopic')
     if topicbean is None:
         print "Creating DemoSupplierTopic jms topic"
         demoJMSTopic = jmsResource.createTopic("DemoSupplierTopic")
         demoJMSTopic.setJNDIName('jms/DemoSupplierTopic')
         demoJMSTopic.setSubDeploymentName('SOASubDeployment')

To:

jmsSOASystemResource = lookup("SOAJMSModule","JMSSystemResource")

jmsResource = jmsSOASystemResource.getJMSResource()

 topicbean=jmsResource.lookupTopic('DemoSupplierTopic_UDD')

if topicbean is None: 
         print "Creating DemoSupplierTopicC jms topic"
         #create a udd - so clustering is automatically working and done
         demoJMSTopic = jmsResource.createUniformDistributedTopic("DemoSupplierTopic_UDD")

         demoJMSTopic.setJNDIName('@jms.topic.jndi@')
         #Replace the subdeployment name with the one that appears in the WLS AdminConsole as listed for the SOAJMSModule

         demoJMSTopic.setSubDeploymentName()

else: print "Found DemoSupplierTopic_UDD topic – noop"

10.3 Managing Space in the SOA Infrastructure Database

Although not all composites may use the database frequently, the service engines generate a considerable amount of data in the CUBE_INSTANCE and MEDIATOR_INSTANCE schemas. Lack of space in the database may prevent SOA composites from functioning. Watch for generic errors, such as “oracle.fabric.common.FabricInvocationException” in the Oracle Enterprise Manager Fusion Middleware Control console (dashboard for instances). Search also in the SOA server's logs for errors, such as:

Error Code: 1691
...
ORA-01691: unable to extend lob segment
SOAINFRA.SYS_LOB0000108469C00017$$ by 128 in tablespace SOAINFRA

These messages are typically indicators of space issues in the database that may likely require adding more data files or more space to the existing files. The SOA Database Administrator should determine the extension policy and parameters to be used when adding space. Additionally, old composite instances can be purged to reduce the SOA Infrastructure database's size. Oracle does not recommend using the Oracle Enterprise Manager Fusion Middleware Control for this type of operation as in most cases the operations cause a transaction time out. There are specific packages provided with the Repository Creation Utility to purge instances. For example:

DECLARE 
  FILTER INSTANCE_FILTER := INSTANCE_FILTER(); 
 
   MAX_INSTANCES NUMBER; 
  DELETED_INSTANCES NUMBER; 
  PURGE_PARTITIONED_DATA BOOLEAN := TRUE; 
 BEGIN 
   . 
  FILTER.COMPOSITE_PARTITION_NAME:='default'; 
  FILTER.COMPOSITE_NAME := 'FlatStructure'; 
  FILTER.COMPOSITE_REVISION := '10.0';   
  FILTER.STATE := fabric. STATE_UNKNOWN; 
  FILTER.MIN_CREATED_DATE := to_timestamp('2010-09-07','YYYY-MM-DD'); 
  FILTER.MAX_CREATED_DATE := to_timestamp('2010-09-08','YYYY-MM-DD'); 
  MAX_INSTANCES := 1000; 
 . 
  DELETED_INSTANCES := FABRIC.DELETE_COMPOSITE_INSTANCES( 
    FILTER => FILTER, 
    MAX_INSTANCES => MAX_INSTANCES, 
    PURGE_PARTITIONED_DATA => PURGE_PARTITIONED_DATA 
  );

This deletes the first 1000 instances of the FlatStructure composite (version 10) created between '2010-09-07' and '2010-09-08' that are in “UNKNOWN” state. Refer to Chapter 8, "Managing SOA Composite Applications" in the Oracle Fusion Middleware Administrator's Guide for Oracle SOA Suite for more details on the possible operations included in the sql packages provided. Always use the scripts provided for a correct purge. Deleting rows in just the composite_dn table may leave dangling references in other tables used by the Oracle Fusion Middleware SOA Infrastructure.

10.4 Configuring UMS Drivers

UMS driver configuration is not automatically propagated in a SOA or BAM cluster. This implies that users need to:

Apply the configuration of UMS drivers in each and every one of the servers in the EDG topology that is using the driver.
When server migration is used, servers are moved to a different node's domain directory. It is necessary to pre-create the UMS driver configuration in the failover node. The UMS driver configuration file location is:
```
ORACLE_BASE/admin/<domain_name>/mserver/<domain_name>/servers/<server_name>/tmp/_WL_user/<ums_driver_name>/*/configuration/driverconfig.xml
```
(where '*' represents a directory whose name is randomly generated by WLS during deployment, for example, "3682yq").

In order to create the file in preparation for possible failovers, users can force a server migration and copy the file from the source node. For example, for BAM:

Configure the driver for WLS_BAM1 in BAMHOST1.
Force a failover of WLS_BAM1 to BAMHOST2. Verify the directory structure for the UMS driver configuration in the failover node:
```
cd ORACLE_BASE/admin/<domain_name>/mserver/<domain_name>/servers/<server_name>/tmp/_WL_user/<ums_driver_name>/*/configuration/
```
(where '*' represents a directory whose name is randomly generated by WLS during deployment, for example, "3682yq").

Do a remote copy of the driver configuration file from BAMHOST1 to BAMHOST2:

BAMHOST1> scp ORACLE_BASE/admin/<domain_name>/mserver/<domain_name>/servers/<server_name>/tmp/_WL_user/<ums_driver_name>/*/configuration/driverconfig.xml  oracle@BAMHOST2:ORACLE_BASE/admin/<domain_name>/mserver/<domain_name>/servers/<server_name>/tmp/_WL_user/<ums_driver_name>/*/configuration/

It is required to restart the driver for these changes to take effect (that is, for the driver to consume the modified configuration). To restart the driver:

Log on to the Oracle WebLogic Administration console.
Expand the environment node on the navigation tree.
Click on Deployments.
Select the driver.
Click Stop->When work completes and confirm the operation.
Wait for the driver to transition to the "Prepared" state (refresh the administration console page, if required).
Select the driver again, and click Start->Servicing all requests and confirm the operation.

Make sure that you verify in Oracle Enterprise Manager Fusion Middleware Control that the properties for the driver have been preserved.

10.5 Scaling the Topology

You can scale out and or scale up the enterprise topology. When you scale up the topology, you add new managed servers to nodes that are already running on one or more managed servers. When you scale out the topology, you add new managed servers to new nodes.

This section covers includes the topics:

Section 10.5.1, "Scaling Up the Topology (Adding Managed Servers to Existing Nodes)"
Section 10.5.2, "Scaling Out the Topology (Adding Managed Servers to New Nodes)"

10.5.1 Scaling Up the Topology (Adding Managed Servers to Existing Nodes)

When you scale up the topology, you already have a node that runs a managed server that is configured with SOA components or a managed server with WSM-PM. The node contains a WebLogic Server home and an Oracle Fusion Middleware SOA home in shared storage. Use existing these installations (such as WebLogic Server home, Oracle Fusion Middleware home, and domain directories), when you create the new managed servers called WLS_SOA and WLS_WSM. You do not need to install WLS or SOA binaries at a new location or to run pack and unpack.

Note:

Because the BAM Server runs in active-passive, you cannot scale a BAM Server Managed Server. You can scale a BAM Web Applications server. The untargeting described in Section 7.6, "Untargeting the BAM Server System from WLS_BAM2" is required. The JMS configuration and the JMS configuration detailed in this section is not required.

Using the Oracle WebLogic Server Administration Console, clone WLS_SOA1 or WLS_WSM1 into a new managed server. The source managed server to clone should be one that already exists on the node where you want to run the new managed server.

To clone a managed server, complete these steps:
1. From the Domain Structure window of the Oracle WebLogic Server Administration Console, expand the Environment node and then Servers. The Summary of Servers page appears.
2. Click Lock and Edit and select the managed server that you want to clone (for example, WLS_SOA1).
3. Click Clone.
Name the new managed server WLS_SOAn, where n is a number that identifies the new managed server. In this case, assume that you are adding a new server to Node 1, where WLS_SOA1 was running.

The remainder of the steps assume that you are adding a new server to SOAHOST1, which is already running WLS_SOA1.
For the listen address, assign the host name or IP to use for this new managed server. If you are planning to use server migration as recommended for this server, enter the VIP (also called a floating IP) to enable it to move to another node. The VIP should be different from the one used by the managed server that is already running.
For WLS_WSM servers, run the Java Object Cache configuration utility again to include the new server in the JOC distributed cache as described in Section 4.17, "Configuring the Java Object Cache for Oracle WSM." You can use the same discover port for multiple WSM-PM servers in the same node. Repeat the steps provided in Section 4.17 for each WSM-PM server and the server list is updated.
Create JMS servers for SOA and UMS on the new managed server.

Note:
These steps are not required for scaling up the WSM_PM managed server, only for WLS_SOA managed servers. They are not required either to scale up the BAM Web Applications system.

Create the JMS servers for SOA, UMS and BPM (if applicable) as follows:
1. Use the Oracle WebLogic Server Administration Console to create a new persistent store for the new SOAJMSServer (which will be created in a later step) and name it, for example, SOAJMSFileStore_N. Specify the path for the store as recommended in Section 2.3, "Shared Storage and Recommended Directory Structure" as the directory for the JMS persistent stores:
```
ORACLE_BASE/admin/<domain_name>/cluster_name/jms/SOAJMSFileStore_N
```
  Note:
  This directory must exist before the managed server is started or the start operation will fail.
2. Create a new JMS server for SOA: for example, SOAJMSServer_N. Use the SOAJMSFileStore_N for this JMS server. Target the SOAJMSServer_N server to the recently created managed server (WLS_SOAn).
3. Create a new persistence store for the new UMS JMS server (which will be created in a later step) and name it, for example, UMSJMSFileStore_N. Specify the path for the store as recommended in Section 2.3, "Shared Storage and Recommended Directory Structure" as the directory for the JMS persistent stores:
```
ORACLE_BASE/admin/<domain_name>/cluster_name/jms/UMSJMSFileStore_N
```
  Note:
  This directory must exist before the managed server is started or the start operation will fail.
  
  Note:
  It is also possible to assign SOAJMSFileStore_N as the store for the new UMS JMS servers. For the purpose of clarity and isolation, individual persistent stores are used in the following steps.
4. Create a new JMS Server for UMS: for example, UMSJMSServer_N. Use the UMSJMSFileStore_N for this JMS server. Target the UMSJMSServer_N server to the recently created managed server (WLS_SOAn).
5. For BPM Systems only: Create a new persistence store for the new BPMJMSServer, for example, BPMJMSFileStore_N. Specify the path for the store. This should be a directory on shared storage as recommended in Section 2.3, "Shared Storage and Recommended Directory Structure."
  
  ORACLE_BASE/admin/domain_name/cluster_name/jms/BPMJMSFileStore_N.
  
  Note:
  This directory must exist before the managed server is started or the start operation fails.
  You can also assign SOAJMSFileStore_N as store for the new BPM JMS Servers. For the purpose of clarity and isolation, individual persistent stores are used in the following steps.
6. For BPM systems only: Create a new JMS Server for BPM, for example, BPMJMSServer_N. Use the BPMJMSFileStore_N for this JMSServer. Target the BPMJMSServer_N Server to the recently created Managed Server (WLS_SOAn).
7. Target the UMSJMSSystemResource to the SOA_Cluster as it may have changed during extend operations. To do this, expand the Services node and then expand the Messaging node. Choose JMS Modules from the Domain Structure window of the Oracle WebLogic Server Administration Console. The JMS Modules page appears. Click UMSJMSSytemResource and open the Targets tab. Make sure all of the servers in the SOA_Cluster appear selected (including the recently cloned WLS_SOAn).
8. Update the SubDeployment Targets for SOA, UMS and BPM JMS Modules (if applicable) to include the recently created JMS servers.
  
  To do this, expand the Services node and then expand the Messaging node. Choose JMS Modules from the Domain Structure window of the Oracle WebLogic Server Administration Console. The JMS Modules page appears. Click on the JMS module (for SOA: SOAJMSModule, for BPM: BPMJMSMOdule and for UMS: UMSSYtemResource) represented as a hyperlink in the Names column of the table. The Settings page for module appears. Open the SubDeployments tab. The subdeployment for the deployment module appears.
  
  Note:
  This subdeployment module name is a random name in the form of SOAJMSServerXXXXXX, UMSJMSServerXXXXXX, or BPMJMSServerXXXXXX, resulting from the Configuration Wizard JMS configuration for the first two servers (WLS_SOA1 and WLS_SOA2).
  
  Click on it. Add the new JMS Server (for UMS add UMSJMSServer_N, for SOA add SOAJMSServer_N). Click Save and Activate.
Configuring Oracle Coherence for deploying composites for the new server as described in Section 5.4, "Configuring Oracle Coherence for Deploying Composites."

Note:
Only the localhost field must be changed for the server. Replace the localhost with the listen address of the new server added:
Dtangosol.coherence.localhost=SOAHOST1VHNn
Configure the persistent store for the new server. This should be a location visible from other nodes as recommended in Section 2.3, "Shared Storage and Recommended Directory Structure."

From the Administration Console, select the Server_name , and then the Services tab. Under Default Store, in Directory, enter the path to the folder where you want the default persistent store to store its data files.
Disable host name verification for the new managed server. Before starting and verifying the WLS_SOAN managed server, you must disable host name verification. You can re-enable it after you have configured server certificates for the communication between the Oracle WebLogic Administration Server and the Node Manager in SOAHOSTn.

If the source server from which the new one has been cloned had already disabled hostname verification, these steps are not required (the hostname verification settings is propagated to the cloned server).To disable host name verification:
1. In the Oracle Fusion Middleware Enterprise Manager Console, select Oracle WebLogic Server Administration Console.
2. Expand the Environment node in the Domain Structure window.
3. Click Servers.
  
  The Summary of Servers page appears.
4. Select WLS_SOAn in the Names column of the table.
  
  The Settings page for server appears.
5. Click the SSL tab.
6. Click Advanced.
7. Set Hostname Verification to None.
8. Click Save.
Configure server migration for the new managed server.

Note:
Because this is a scale-up operation, the node should already contain a Node Manager and environment configured for server migration that includes netmask, interface, wlsifconfig script superuser privileges, and so on. The floating IP for the new SOA managed server should also be already present.

To configure server migration using the Oracle WebLogic Server Administration Console, complete these steps:
1. In the Domain Structure window, expand the Environment node and then click Servers. The Summary of Servers page appears.
2. Click the name of the server (represented as a hyperlink) in Name column of the table for which you want to configure migration. The settings page for the selected server appears.
3. Click the Migration subtab.
4. In the Migration Configuration section, select the servers that participate in migration in the Available window by clicking the right arrow. Select the same migration targets as for the servers that already exist on the node.
  
  For example, for new managed servers on SOAHOST1, which is already running WLS_SOA1, select SOAHOST2. For new managed servers on SOAHOST2, which is already running WLS_SOA2, select SOAHOST1.
  
  Note:
  The appropriate resources must be available to run the managed servers concurrently during migration.
5. Choose the Automatic Server Migration Enabled option. This enables the Node Manager to start a failed server on the target node automatically.
6. Click Save.
7. Restart the Administration Server, managed servers, and Node Manager.
  
  To restart the Administration Server, use the procedure in Section 4.7, "Starting the Administration Server on SOAHOST1.".
Update the cluster address to include the new server:
1. In the Administration Console, select Environment, and then Cluster.
2. Click the SOA_Cluster server.
  
  The Settings screen for the SOA_Cluster appears.
3. Click Lock and Edit.
4. Add the new server's address and port to the Cluster address field. For example: SOAHOST1VHN1:8011,SOAHOST2VHN1:8011,SOAHOST1VHN1 :8001
5. Save and activate the changes.
Test server migration for this new server. To test migration, perform the following from the node where you added the new server:
1. Stop the WLS_SOAn managed server.
  
  To do this, run kill -9 <pid> on the PID of the managed server. You can identify the PID of the node using ps -ef | grep WLS_SOAn.
2. Monitor the Node Manager Console for a message indicating that WLS_SOA1's floating IP has been disabled.
3. Wait for the Node Manager to attempt a second restart of WLS_SOAn. Node Manager waits for a fence period of 30 seconds before trying this restart.
4. Once Node Manager restarts the server, stop it again. The Node Manager should log a message indicating that the server will not be restarted again locally.

10.5.2 Scaling Out the Topology (Adding Managed Servers to New Nodes)

When you scaling out the topology, you add new managed servers configured with SOA and or WSM-PM to new nodes.

Before performing the steps in this section, check that you meet these requirements:

Prerequisites

There must be existing nodes running managed servers configured with SOA and WSM-PM within the topology
The new node can access the existing home directories for WebLogic Server and SOA. (Use the existing installations in shared storage for creating a new WLS_SOA or WLS_WSM managed server. You do not need to install WebLogic Server or SOA binaries in a new location but you do need to run pack and unpack to bootstrap the domain configuration in the new node.)
When an ORACLE_HOME or WL_HOME is shared by multiple servers in different nodes, it is recommended that you keep the Oracle Inventory and Middleware home list in those nodes updated for consistency in the installations and application of patches. To update the oraInventory in a node and "attach" an installation in a shared storage to it, use ORACLE_HOME/oui/bin/attachHome.sh. To update the Middleware home list to add or remove a WL_HOME, edit the <user_home>/bea/beahomelist file. See the steps below.

To scale out the topology, complete these steps:

On the new node, mount the existing FMW Home, which should include the SOA installation and the domain directory, and ensure that the new node has access to this directory, just like the rest of the nodes in the domain.
To attach ORACLE_HOME in shared storage to the local Oracle Inventory, execute the following command:
```
SOAHOSTn>cd ORACLE_COMMON_HOME/oui/bin/attachHome.sh
SOAHOSTn>./attachHome.sh -jreLoc ORACLE_BASE/fmw/jrockit_160_<version>
```
To update the Middleware home list, create (or edit, if another WebLogic installation exists in the node) the $HOME/bea/beahomelist file and add MW_HOME to it.
Log in to the Oracle WebLogic Administration Console.
Create a new machine for the new node that will be used, and add the machine to the domain.
Update the machine's Node Manager's address to map the IP of the node that is being used for scale out.
Use the Oracle WebLogic Server Administration Console to clone WLS_SOA1/WLS_WSM1 into a new managed server. Name it WLS_SOAn/WLS_WSM-PMn, where n is a number. Assign it to the new machine created above.

Note:
These steps assume that you are adding a new server to node n, where no managed server was running previously.
Assign the host name or IP to use for the new managed server for the listen address of the managed server.

If you are planning to use server migration for this server (which Oracle recommends) this should be the VIP (also called a floating IP) for the server. This VIP should be different from the one used for the existing managed server.
For WLS_WSM servers, run the Java Object Cache configuration utility again to include the new server in the JOC distributed cache as described in Section 4.17, "Configuring the Java Object Cache for Oracle WSM."
Create JMS Servers for SOA, BPM, (if applicable) and UMS on the new managed server.

Note:
These steps are not required for scaling out the WSM_PM managed server, only for WLS_SOA managed servers. They are not required either to scale up the BAM Web Applications system.

Create the JMS servers for SOA and UMS as follows:
1. Use the Oracle WebLogic Server Administration Console to create a new persistent store for the new SOAJMSServer (which will be created in a later step) and name it, for example, SOAJMSFileStore_N. Specify the path for the store as recommended in Section 2.3, "Shared Storage and Recommended Directory Structure" as the directory for the JMS persistent stores:
```
ORACLE_BASE/admin/domain_name/cluster_name/jms/SOAJMSFileStore_N
```
  Note:
  This directory must exist before the managed server is started or the start operation will fail.
2. Create a new JMS server for SOA, for example, SOAJMSServer_N. Use the SOAJMSFileStore_N for this JMS server. Target the SOAJMSServer_N Server to the recently created managed server (WLS_SOAn).
3. Create a new persistence store for the new UMSJMSServer, and name it, for example, UMSJMSFileStore_N. As the directory for the persistent store, specify the path recommended in Section 2.3, "Shared Storage and Recommended Directory Structure" as the directory for the JMS persistent stores:
```
ORACLE_BASE/admin/domain_name/cluster_name/jms/UMSJMSFileStore _N
```
  Note:
  This directory must exist before the managed server is started or the start operation will fail.
  
  Note:
  It is also possible to assign SOAJMSFileStore_N as the store for the new UMS JMS servers. For the purpose of clarity and isolation, individual persistent stores are used in the following steps.
4. Create a new JMS server for UMS: for example, UMSJMSServer_N. Use the UMSJMSFileStore_N for this JMS server. Target the UMSJMSServer_N Server to the recently created managed server (WLS_SOAn).
5. For BPM Systems only: Create a new persistence store for the new BPMJMSServer, for example, BPMJMSFileStore_N. Specify the path for the store. This should be a directory on shared storage as recommended in Section 2.3, "Shared Storage and Recommended Directory Structure."
  
  ORACLE_BASE/admin/domain_name/cluster_name/jms/BPMJMSFileStore_N.
  
  Note:
  This directory must exist before the managed server is started or the start operation fails.
  You can also assign SOAJMSFileStore_N as store for the new BPM JMS Servers. For the purpose of clarity and isolation, individual persistent stores are used in the following steps.
6. For BPM systems only: Create a new JMS Server for BPM, for example, BPMJMSServer_N. Use the BPMJMSFileStore_N for this JMSServer. Target the BPMJMSServer_N Server to the recently created Managed Server (WLS_SOAn).
7. Update the SubDeployment targets for the SOA JMS Module to include the recently created SOA JMS server. To do this, expand the Services node and then expand the Messaging node. Choose JMS Modules from the Domain Structure window of the Oracle WebLogic Server Administration Console. The JMS Modules page appears. Click SOAJMSModuleUDDs (represented as a hyperlink in the Names column of the table). The Settings page for SOAJMSModuleUDDs appears. Open the SubDeployments tab. The SOAJMSSubDM subdeployment appears.
  
  Note:
  This subdeployment module results from updating the JMS configuration for the first two servers (WLS_SOA1 and WLS_SOA2) with the Uniform Distributed Destination Script (soa-createUDD.py), which is required for the initial EDG topology setup.
  
  Click on it. Add the new JMS server for SOA called SOAJMSServer_N to this subdeployment. Click Save.
8. Target the UMSJMSSystemResource to the SOA_Cluster as it may have changed during extend operations. To do this, expand the Services node and then expand the Messaging node. Choose JMS Modules from the Domain Structure window of the Oracle WebLogic Server Administration Console. The JMS Modules page appears. Click UMSJMSSytemResource and open the Targets tab. Make sure all of the servers in the SOA_Cluster appear selected (including the recently cloned WLS_SOAn).
9. Update the SubDeployment Targets for SOA, UMS and BPM JMS Modules (if applicable) to include the recently created JMS servers.
  
  To do this, expand the Services node and then expand the Messaging node. Choose JMS Modules from the Domain Structure window of the Oracle WebLogic Server Administration Console. The JMS Modules page appears. Click on the JMS module (for SOA: SOAJMSModule, for BPM: BPMJMSMOdule and for UMS: UMSSYtemResource) represented as a hyperlink in the Names column of the table. The Settings page for module appears. Open the SubDeployments tab. The subdeployment for the deployment module appears.
  
  Note:
  This subdeployment module name is a random name in the form of SOAJMSServerXXXXXX, UMSJMSServerXXXXXX, or BPMJMSServerXXXXXX, resulting from the Configuration Wizard JMS configuration for the first two servers (WLS_SOA1 and WLS_SOA2).
  
  Click on it. Add the new JMS Server (for UMS add UMSJMSServer_N, for SOA add SOAJMSServer_N). Click Save and Activate.

Run the pack command on SOAHOST1 to create a template pack as follows:

SOAHOST1> cd ORACLE_COMMON_HOME/common/bin

SOAHOST1> ./pack.sh -managed=true -domain=ORACLE_BASE/admin/domain_name/aserver/domain_name
-template=soadomaintemplateScale.jar -template_name=soa_domain_templateScale

Run the following command on SOAHOST1 to copy the template file created to SOAHOSTN

SOAHOST1> scp soadomaintemplateScale.jar oracle@SOAHOSTN:/ ORACLE_COMMON_HOME/common/bin

Run the unpack command on SOAHOSTN to unpack the template in the managed server domain directory as follows:

SOAHOSTN> cd ORACLE_COMMON_HOME/common/bin

SOAHOSTN> ./unpack.sh -domain=ORACLE_BASE/admin/domain_name
/mserver/domain_name/
-template=soadomaintemplateScale.jar
-app_dir=ORACLE_BASE/admin/domain_name/mserver/applications

Configuring Oracle Coherence for deploying composites for the new server as described in Section 5.4, "Configuring Oracle Coherence for Deploying Composites."

Note:
Only the localhost field needs to be changed for the server. Replace the localhost with the listen address of the new server added:
Dtangosol.coherence.localhost=SOAHOST1VHNn
Configure the persistent store for the new server. This should be a location visible from other nodes as recommended in Section 2.3, "Shared Storage and Recommended Directory Structure."

From the Administration Console, select the Server_name, and then the Services tab. Under Default Store, in Directory, enter the path to the folder where you want the default persistent store to store its data files.
Disable host name verification for the new managed server. Before starting and verifying the WLS_SOAn managed server, you must disable host name verification. You can re-enable it after you have configured server certificates for the communication between the Oracle WebLogic Administration Server and the Node Manager in SOAHOSTn.

If the source server from which the new one has been cloned had already disabled hostname verification, these steps are not required (the hostname verification settings is propagated to the cloned server).To disable host name verification:
1. In the Oracle Fusion Middleware Enterprise Manager Console, select Oracle WebLogic Server Administration Console.
2. Expand the Environment node in the Domain Structure window.
3. Click Servers.
  
  The Summary of Servers page appears.
4. Select WLS_SOAn in the Names column of the table.
  
  The Settings page for server appears.
5. Click the SSL tab.
6. Click Advanced.
7. Set Hostname Verification to None.
8. Click Save.
Start Node Manager on the new node. To start Node Manager, use the installation in shared storage from the existing nodes, and start Node Manager by passing the host name of the new node as a parameter as follows:
```
SOAHOSTN> WL_HOME/server/bin/startNodeManager
```
Start and test the new managed server from the Oracle WebLogic Server Administration Console.
1. Ensure that the newly created managed server, WLS_SOAn, is running.
2. Access the application on the load balancer (https://soa.mycompany.com/soa-infra). The application should be functional.
  
  Note:
  The HTTP Servers in the topology should round robin requests to the newly added server (a few requests, depending on the number of servers in the cluster, may be required to hit the new server). Its is not required to add all servers in a cluster to the WebLogicCluster directive in Oracle HTTP Server's mod_wl_ohs.conf file. However, routing to new servers in the cluster takes place only if at least one of the servers listed in the WebLogicCluster directive is running.
Configure server migration for the new managed server.

Note:
Because this new node uses an existing shared storage installation, the node already is using a Node Manager and an environment configured for server migration that includes netmask, interface, wlsifconfig script superuser privileges. The floating IP for the new SOA Managed Server is already present in the new node.

Log into the Oracle WebLogic Server Administration Console and configure server migration following these steps:
1. Expand the Environment node in the Domain Structure windows and then choose Servers. The Summary of Servers page appears.
2. Select the server (represented as hyperlink) for which you want to configure migration from the Names column of the table. The Setting page for that server appears.
3. Click the Migration tab.
4. In the Available field of the Migration Configuration section, click the right arrow to select the machines to which to allow migration.
  
  Note:
  Specify the least-loaded machine as the migration target for the new server. The required capacity planning must be completed so that this node has enough available resources to sustain an additional managed server.
5. Select Automatic Server Migration Enabled. This enables the Node Manager to start a failed server on the target node automatically.
6. Click Save.
7. Restart the Administration Server, managed servers, and the Node Manager.
  
  To restart the Administration Server, use the procedure in Section 4.7, "Starting the Administration Server on SOAHOST1.".
Update the cluster address to include the new server:
1. In the Administration Console, select Environment, and then Cluster.
2. Click the SOA_Cluster server.
  
  The Settings screen for the SOA_Cluster appears.
3. Click Lock and Edit.
4. Add the new server's address and port to the Cluster address field. For example: SOAHOST1VHN1:8011,SOAHOST2VHN1:8011,SOAHOSTNVHN1:8001
5. Save and activate the changes.
Test server migration for this new server. Follow these steps from the node where you added the new server:
1. Abruptly stop the WLS_SOAn managed server by running kill -9 <pid> on the PID of the managed server. You can identify the PID of the node using ps -ef | grep WLS_SOAn.
2. In the Node Manager Console you should see a message indicating that WLS_SOA1's floating IP has been disabled.
3. Wait for the Node Manager to try a second restart of WLS_SOAn. Node Manager waits for a fence period of 30 seconds before trying this restart.
4. Once Node Manager restarts the server, stop it again. Now Node Manager should log a message indicating that the server will not be restarted again locally.

10.6 Performing Backups and Recoveries

Table 10-1 lists the static artifacts to back up in the 11g SOA enterprise deployment.

Table 10-1 Static Artifacts to Back Up in the 11g SOA Enterprise Deployment

Type	Host	Location	Tier
ORACLE HOME (DB)	CUSTDBHOST1 and CUSTDBHOST	The location is user-defined.	Data Tier
MW HOME (OHS)	WEBHOST1 and WEBHOST2	`ORACLE_HOME/fmw`	Web Tier
MW HOME (this includes the SOA home as well)	SOAHOST1 and SOAHOST2	`MW_HOME` The SOA home is also under MW_HOME: `ORACLE_HOME`	Application Tier
Installation-related files		OraInventory, `<user_home>/bea/beahomelist`, `oraInst.loc`, oratab	N/A

Table 10-2 lists the runtime artifacts to back up in the 11g SOA enterprise deployment.

Table 10-2 Run-Time Artifacts to Back Up in the 11g SOA Enterprise Deployment

Type	Host	Location	Tier
DOMAIN HOME	SOAHOST1 and SOAHOST2	`ORACLE_BASE/admin/<domain_name>/mserver/<domain_name>/`	Application Tier
Application artifacts (EAR and WAR files)	SOAHOST1 and SOAHOST2	Find the application artifacts by viewing all of the deployments through administration console	Application Tier
OHS instance home	WEBHOST1 and WEBHOST2	ORACLE_BASE/admin/<instance_name>	Web Tier
Oracle RAC databases	CUSTDBHOST1 and CUSTDBHOST2	The location is user-defined	Data Tier

For more information on backup and recovery of Oracle Fusion Middleware components, see Oracle Fusion Middleware Administrator's Guide.

Note:

ORACLE_HOME should be backed up if any changes are made to the XEngine configuration that are part of your B2B setup. These files are located under ORACLE_HOME/soa/thirdparty/edifecs/XEngine. To back up ORACLE_HOME, execute the following command:

SOAHOST1> tar -cvpf fmwhomeback.tar MW_HOME

10.7 Troubleshooting

This section covers the following topics:

Section 10.7.1, "Access to BAM Results in HTTP Error 404"
Section 10.7.2, "Page Not Found When Accessing soa-infra Application Through Load Balancer"
Section 10.7.3, "Error While Retrieving Oracle B2B Document Definitions"
Section 10.7.4, "Soa-infra Application Fails to Start Due to Deployment Framework Issues (Coherence)"
Section 10.7.5, "Incomplete Policy Migration After Failed Restart of SOA Server"
Section 10.7.6, "SOA, BAM, or WMS Servers Fail to Start Due to Maximum Number of Processes Available in Database"
Section 10.7.7, "Administration Server Fails to Start After a Manual Failover"
Section 10.7.8, "Error While Activating Changes in Administration Console"
Section 10.7.9, "SOA/BAM Server Not Failed Over After Server Migration"
Section 10.7.10, "SOA/BAM Server Not Reachable From Browser After Server Migration"
Section 10.7.11, "SOA Server Stops Responding after Being Active and Stressed for a Period of Time."
Section 10.7.12, "Exceptions While Performing Deploy/Purge/Import Operations in the B2B Console."
Section 10.7.13, "OAM Configuration Tool Does Not Remove URLs"
Section 10.7.14, "Redirecting of Users to Login Screen After Activating Changes in Administration Console"
Section 10.7.15, "Redirecting of Users to Administration Console's Home Page After Activating Changes to OAM"
Section 10.7.16, "Configured JOC Port Already in Use"

10.7.1 Access to BAM Results in HTTP Error 404

If accessing the BAM application results in the HTTP 404 error ("Not Found"), a probable cause is that the BAM server was started before the start of the database instance where BAM schemas reside. In this case, shut down the BAM instance and restart it after ensuring that the database is already up.

10.7.2 Page Not Found When Accessing soa-infra Application Through Load Balancer

Problem: A 404 "page not found" message is displayed in the web browser when you try to access the soa-infra application using the load balancer address. The error is intermittent and SOA Servers appear as "Running" in the WLS Administration Console.

Solution: Even when the SOA managed servers may be up and running, some of the applications contained in them may be in Admin, Prepared or other states different from Active. The soa-infra application may be unavailable while the SOA server is running. Check the Deployments page in the Administration Console to verify the status of the soa-infra application. It should be in "Active" state. Check the SOA Server's output log for errors pertaining to the soa-infra application and try to start it from the Deployments page in the Administration Console.

10.7.3 Error While Retrieving Oracle B2B Document Definitions

Problem: Error happens when trying to retrieve a document definition XSD from Oracle B2B. B2B resides in a cluster and is accessed through a load balancer. B2B console report the following:

An error occured while loading the document definitions. java.lang.IllegalArgumentException: Cluster address must be set when clustering is enabled.

Solution: This occurs if you do not set the frontend HTTP host and port for the Oracle WebLogic cluster where Oracle B2B resides. To eliminate this error, set the front end address for the SOA Cluster:

In the WebLogic Server Administration Console, in the Change Center section, click Lock & Edit.
In the left pane, choose the Environment in the Domain Structure window and then choose Clusters. The Summary of Clusters page appears.
Select the WLS_SOA cluster.
Select HTTP.
Set the values for the following:
- Frontend Host: soa.mycompany.com
- Frontend HTTPS Port: 443
- Frontend HTTP Port: 80
Click Save.
To activate the changes, click Activate Changes in the Change Center section of the Administration Console.
Restart the servers to make the Frontend Host directive in the cluster effective.

10.7.4 Soa-infra Application Fails to Start Due to Deployment Framework Issues (Coherence)

Problem: The soa-infra application fails to start after changes to the Coherence configuration for deployment have been applied. The SOA server output log reports the following:

Cluster communication initialization failed. If you are using multicast, Please make sure multicast is enabled on your network and that there is no interference on the address in use. Please see the documentation for more details.

Solutions:

When using multicast instead of unicast for cluster deployments of SOA composites, a message similar to the above may appear if a multicast conflict arises when starting the soa-infra application (that is, starting the managed server on which SOA runs). These messages, which occur when Oracle Coherence throws a runtime exception, also include the details of the exception itself. If such a message appears, check the multicast configuration in your network. Verify that you can ping multicast addresses. In addition, check for other clusters that may have the same multicast address but have a different cluster name in your network, as this may cause a conflict that prevents soa-infra from starting. If multicast is not enabled in your network, you can change the deployment framework to use unicast as described in Oracle Coherence Developer's Guide for Oracle Coherence.
When entering well-known address list for unicast (in server start parameters), make sure that the node's addresses entered for the localhost and clustered servers are correct. Error messages like:
```
oracle.integration.platform.blocks.deploy.CompositeDeploymentCoordinatorMessages errorUnableToStartCoherence
```
are reported in the server's output log if any of the addresses is not resolved correctly.

10.7.5 Incomplete Policy Migration After Failed Restart of SOA Server

Problem: The SOA server fails to start through the administration console before setting the Node Manager property startScriptEnabled=true. The server does not come up after the property is set either. The SOA Server output log reports the following:

SEVERE: <.> Unable to Encrypt data
Unable to Encrypt data.
Check installation/post-installation steps for errors. Check for errors during SOA server startup.

ORABPEL-35010
 .
Unable to Encrypt data.
Unable to Encrypt data.
Check installation/post-installation steps for errors. Check for errors
 during SOA server startup.
 .
 at oracle.bpel.services.common.util.EncryptionService.encrypt(EncryptionService.java:56)
...

Solution: Incomplete policy migration results from an unsuccessful start of the first SOA server in a cluster. To enable full migration, edit the <jazn-policy> element the system-jazn-data.xml file to grant permission to bpm-services.jar:

<grant>
  <grantee>
    <codesource>
<url>file:${oracle.home}/soa/modules/oracle.soa.workflow_11.1.1/bpm-
services.jar</url>
    </codesource>
  </grantee>
  <permissions>
    <permission>
      <class>java.security.AllPermission</class>
    </permission>
  </permissions>
</grant>

10.7.6 SOA, BAM, or WMS Servers Fail to Start Due to Maximum Number of Processes Available in Database

Problem: SOA, WSM or BAM Server fails to start. The domain has been extended for new types of managed server (for example, SOA extended for BAM) or the system has been scaled up (added new servers of the same type). The SOA/BAM or WSM Server output log reports the following:

<Warning> <JDBC> <BEA-001129> <Received exception while creating connection for pool "SOADataSource-rac0": Listener refused the connection with the following error:

ORA-12516, TNS:listener could not find available handler with matching protocol stack >

Solution: Verify the number of processes in the database and adjust accordingly. As the SYS user, issue the SHOW PARAMETER command:

SQL> SHOW PARAMETER processes

Set the initialization parameter using the following command:

SQL> ALTER SYSTEM SET processes=300 SCOPE=SPFILE

Restart the database.

Note:

The method that you use to change a parameter's value depends on whether the parameter is static or dynamic, and on whether your database uses a parameter file or a server parameter file. See the Oracle Database Administrator's Guide for details on parameter files, server parameter files, and how to change parameter values.

10.7.7 Administration Server Fails to Start After a Manual Failover

Problem: Administration Server fails to start after the Administration Server node failed and manual failover to another nodes is performed. The Administration Server output log reports the following:

<Feb 19, 2009 3:43:05 AM PST> <Warning> <EmbeddedLDAP> <BEA-171520> <Could not obtain an exclusive lock for directory: ORACLE_BASE/admin/soadomain/aserver/soadomain/servers/AdminServer/data/ldap/ldapfiles. Waiting for 10 seconds and then retrying in case existing WebLogic Server is still shutting down.>

Solution: When restoring a node after a node crash and using shared storage for the domain directory, you may see this error in the log for the Administration Server due to unsuccessful lock cleanup. To resolve this error, remove the file ORACLE_BASE/admin/<domain_name>/aserver/<domain_name>/servers/AdminServer/data/ldap/ldapfiles/ EmbeddedLDAP.lok.

10.7.8 Error While Activating Changes in Administration Console

Problem: Activation of changes in Administration Console fails after changes to a server's start configuration have been performed. The Administration Console reports the following when clicking "Activate Changes":

An error occurred during activation of changes, please see the log for details.
 [Management:141190]The commit phase of the configuration update failed with an exception:
In production mode, it's not allowed to set a clear text value to the property: PasswordEncrypted of ServerStartMBean

Solution: This may happen when start parameters are changed for a server in the Administration Console. In this case, either provide username/password information in the server start configuration in the Administration Console for the specific server whose configuration was being changed, or remove the <password-encrypted></password-encrypted> entry in the config.xml file (this requires a restart of the Administration Server).

10.7.9 SOA/BAM Server Not Failed Over After Server Migration

Problem: After reaching the maximum restart attempts by local Node Manager, Node Manager in the failover node tries to restart it, but the server does not come up. The server seems to be failed over as reported by Node Manager's output information. The VIP used by the SOA Server is not enabled in the failover node after Node Manager tries to migrate it (if config in the failover node does not report the VIP in any interface). Executing the command "sudo ifconfig $INTERFACE $ADDRESS $NETMASK" does not enable the IP in the failover node.

Solution: The rights and configuration for sudo execution should not prompt for a password. Verify the configuration of sudo with your system administrator so that sudo works without a password prompt.

10.7.10 SOA/BAM Server Not Reachable From Browser After Server Migration

Problem: Server migration is working (SOA/BAM Server is restarted in the failed over node) but the <Virtual Hostname>:8001/soa-infra URL is not reachable in the web browser. The server has been "killed" in its original host and Node Manager in the failover node reports that the VIP has been migrated and the server started. The VIP used by the SOA Server cannot be pinged from the client's node (that is, the node where the browser is being used).

Solution: The arping command executed by Node Mnager to update ARP caches did not broadcast the update properly. In this case, the node is not reachable to external nodes. Either update the nodemanager.properties file to include the MACBroadcast or execute a manual arping:

/sbin/arping -b -q -c 3 -A -I $INTERFACE $ADDRESS > $NullDevice 2>&1

Where $INTERFACE is the network interface where the Virtual IP is enabled and $ADDRESS is the virtual IP address.

10.7.11 SOA Server Stops Responding after Being Active and Stressed for a Period of Time

Problem: WLS_SOA starts properly and functions for a period of time, but becomes unresponsive after running an application that uses the Oracle File Adapter or Oracle FTP Adapter. The log file for the server reports the following:

<Error> <Server> <BEA-002606> <Unable to create
a server socket for listening on channel "Default". The address
X.X.X.X might be incorrect or another process is using port 8001:
@ java.net.SocketException: Too many open files.>

Solution: For composites with Oracle File and FTP Adapters, which are designed to consume a very large number of concurrent messages, set the number of open files parameter for your operating system to a greater value. For example, to set the number of open files parameter to 8192 for Linux, use the ulimit -n 8192 command. The value must be adjusted based on the expected system's load.

10.7.12 Exceptions While Performing Deploy/Purge/Import Operations in the B2B Console

Problem: Deployment of new agreements or purging/importing new metadata fails, and the output logs for the SWLS_SOA server reports "[java] MDS-02202: Content of the metadata object" for deployment or "postTransfer: MDS-00521: error while reading document..." for purge/import.

Solution: This is caused by timing and load balancing mechanism in the operation. The exceptions are unlikely to happen, so a retry of the operation will typically succeed. There is no cleanup or any other additional steps required.

10.7.13 OAM Configuration Tool Does Not Remove URLs

Problem: The OAM Configuration Tool has been used and a set of URLs was added to the policies in Oracle Access Manager. One of multiple URLs had a typo. Executing the OAM Configuration Tool again with the correct URLs completes successfully; however, when accessing Policy Manager, the incorrect URL is still there.

Solution: The OAM Configuration Tool only adds new URLs to existing policies when executed with the same app_domain name. To remove a URL, use the Policy Manager Console in OAM. Log on to the Access Administration site for OAM, click on My Policy Domains, click on the created policy domain (SOA_EDG), then on the Resources tab, and remove the incorrect URLs.

10.7.14 Redirecting of Users to Login Screen After Activating Changes in Administration Console

Problem: After configuring OHS and load balancer to access the Oracle WebLogic Administration Console, some activation changes cause the redirection to the login screen for the admin console.

Solution: This is the result of the console attempting to follow changes to port, channel, and security settings as a user makes these changes. For certain changes, the console may redirect to the Administration Server's listen address. Activation is completed regardless of the redirection. It is not required to log in again; users can simply update the URL to soa.mycompany.com/console/console.portal and directly access the home page for the Administration Console.

Note:

This problem will not occur if you have disabled tracking of the changes described in this section.

10.7.15 Redirecting of Users to Administration Console's Home Page After Activating Changes to OAM

Problem: After configuring OAM, some activation changes cause the redirection to the Administration Console's home page (instead of the context menu where the activation was performed).

Solution: This is expected when OAM SSO is configured and is the result of the redirections performed by the Administration Server. Activation is completed regardless of the redirection. If required, users may "manually" navigate again to the desired context menu.

10.7.16 Configured JOC Port Already in Use

Problem: Attempts to start a Managed Server that uses the Java Object Cache, such as OWSM or WebCenter Spaces Managed Servers, fail. The following errors appear in the logs:

J2EE JOC-058 distributed cache initialization failure
J2EE JOC-043 base exception:
J2EE JOC-803 unexpected EOF during read.

Solution: Another process is using the same port that JOC is attempting to obtain. Either stop that process, or reconfigure JOC for this cluster to use another port in the recommended port range.

10.7.17 SOA or BAM Server Fails to Start

The SOA or BAM server fails to start for the first time and reports parsing failure in config.xml.

Problem: A server that is being started for the first time using Node Manager fails to start. A message such as the following appears in the server's output log:

<Critical> <WebLogicServer> <eicfdcn35> <wls_server1> <main> <<WLS Kernel>> <> <> <1263329692528> <BEA-000386> <Server subsystem failed. Reason: weblogic.security.SecurityInitializationException: Authentication denied: Boot identity not valid; The user name and/or password from the boot identity file (boot.properties) is not valid. The boot identity may have been changed since the boot identity file was created. Please edit and update the boot identity file with the proper values of username and password. The first time the updated boot identity file is used to start the server, these new values are encrypted.

The Managed Server is trying to start for the first time, in MSI (managed server independence) mode. The Server has not been able to retrieve the appropriate configuration for the first start. The Managed Server must be able to communicate with the Administration Server on its first startup.

Solution: Make sure communication between the Administration Server´s listen address and the Managed Server´s listen address is possible (ping the Administration Server's listen address from the Managed Server's node, and telnet to the Administration Server's listen address and port). Once communication is enabled, pack and unpack the domain again to the new node or (if other servers are already running correctly in the same domain directory), delete the OARCLE_BASE/admin/domain_name/mserver/domain_name/servers/server_name/data/nodemanager/ directory and restart the server.

10.8 Best Practices

This section covers the following topics:

Section 10.8.1, "Preventing Timeouts for SQLNet Connections"
Section 10.8.2, "Auditing"

10.8.1 Preventing Timeouts for SQLNet Connections

Much of the EDG production deployment involves firewalls. Because database connections are made across firewalls, Oracle recommends that the firewall be configured so that the database connection is not timed out. For Oracle Real Application Clusters (Oracle RAC), the database connections are made on Oracle RAC VIPs and the database listener port. You must configure the firewall to not time out such connections. If such a configuration is not possible, set the*SQLNET.EXPIRE_TIME=n* parameter in the ORACLE_HOME/network/admin/sqlnet.ora file on the database server, where n is the time in minutes. Set this value to less than the known value of the timeout for the network device (that is, a firewall). For Oracle RAC, set this parameter in all of the Oracle home directories.

10.8.2 Auditing

Oracle Fusion Middleware Audit Framework is a new service in Oracle Fusion Middleware 11g, designed to provide a centralized audit framework for the middleware family of products. The framework provides audit service for platform components such as Oracle Platform Security Services (OPSS) and Oracle Web Services. It also provides a framework for JavaEE applications, starting with Oracle's own JavaEE components. JavaEE applications will be able to create application-specific audit events. For non-JavaEE Oracle components in the middleware such as C or JavaSE components, the audit framework also provides an end-to-end structure similar to that for JavaEE applications.

Figure 10-1 is a high-level architectural diagram of the Oracle Fusion Middleware Audit Framework.

Figure 10-1 Audit Event Flow

Description of "Figure 10-1 Audit Event Flow"

The Oracle Fusion Middleware Audit Framework consists of the following key components:

Audit APIs

These are APIs provided by the audit framework for any audit-aware components integrating with the Oracle Fusion Middleware Audit Framework. During runtime, applications may call these APIs where appropriate to audit the necessary information about a particular event happening in the application code. The interface allows applications to specify event details such as username and other attributes needed to provide the context of the event being audited.
Audit Events and Configuration

The Oracle Fusion Middleware Audit Framework provides a set of generic events for convenient mapping to application audit events. Some of these include common events such as authentication. The framework also allows applications to define application-specific events.

These event definitions and configurations are implemented as part of the audit service in Oracle Platform Security Services. Configurations can be updated through Enterprise Manager (UI) and WLST (command-line tool).
Audit Bus-stop

Bus-stops are local files containing audit data before they are pushed to the audit repository. In the event where no database repository is configured, these bus-stop files can be used as a file-based audit repository. The bus-stop files are simple text files that can be queried easily to look up specific audit events. When a DB-based repository is in place, the bus-stop acts as an intermediary between the component and the audit repository. The local files are periodically uploaded to the audit repository based on a configurable time interval.
Audit Loader

As the name implies, audit loader loads the files from the audit bus-stop into the audit repository. In the case of platform and JavaEE application audit, the audit loader is started as part of the JavaEE container start-up. In the case of system components, the audit loader is a periodically spawned process.
Audit Repository

Audit Repository contains a pre-defined Oracle Fusion Middleware Audit Framework schema, created by Repository Creation Utility (RCU). Once configured, all the audit loaders are aware of the repository and upload data to it periodically. The audit data in the audit repository is expected to be cumulative and will grow overtime. Ideally, this should not be an operational database used by any other applications - rather, it should be a standalone RDBMS used for audit purposes only. In a highly available configuration, Oracle recommends that you use an Oracle Real Application Clusters (Oracle RAC) database as the audit data store.
Oracle Business Intelligence Publisher

The data in the audit repository is exposed through pre-defined reports in Oracle Business Intelligence Publisher. The reports allow users to drill down the audit data based on various criteria. For example:
- Username
- Time Range
- Application Type
- Execution Context Identifier (ECID)

For more introductory information for the Oracle Fusion Middleware Audit Framework, see the "Introduction to Oracle Fusion Middleware Audit Framework" chapter in the Oracle Fusion Middleware Security Guide.

For information on how to configure the repository for Oracle Fusion Middleware Audit Framework, see the "Configuring and Managing Auditing" chapter in the Oracle Fusion Middleware Security Guide.

The EDG topology does not include Oracle Fusion Middleware Audit Framework configuration. The ability to generate audit data to the bus-stop files and the configuration of the audit loader will be available once the products are installed. The main consideration is the audit database repository where the audit data is stored. Because of the volume and the historical nature of the audit data, it is strongly recommended that customers use a separate database from the operational store or stores being used for other middleware components.