18 Common Configuration and Management Tasks for an Enterprise Deployment

This chapter describes configuration and management tasks you will likely need to perform on the enterprise deployment environment.

This chapter contains the following sections:

Configuration and Management Tasks for All Enterprise Deployments
Configuration and Management Tasks for an Oracle SOA Suite Enterprise Deployment

18.1 Configuration and Management Tasks for All Enterprise Deployments

The following sections provide information about some typical configuration and management tasks you are likely need to perform on an Oracle Fusion Middleware enterprise deployment:

Section 18.1.1, "Verifying Manual Failover of the Administration Server"
Section 18.1.2, "Enabling SSL Communication Between the Middle Tier and the Hardware Load Balancer"

18.1.1 Verifying Manual Failover of the Administration Server

In case a host computer fails, you can fail over the Administration Server to another host. The following sections provide the steps to verify the failover and failback of the Administration Server from SOAHOST1 and SOAHOST2.

Assumptions:

The Administration Server is configured to listen on ADMINVHN, and not on localhost or ANY address.

For more information about the ADMINVHN virtual IP address, see Section 5.2, "Reserving the Required IP Addresses for an Enterprise Deployment".
These procedures assume that the Administration Server domain home (ASERVER_HOME) has been mounted on both host computers. This ensures that the Administration Server domain configuration files and the persistent stores are saved on the shared storage device.
The Administration Server is failed over from SOAHOST1 to SOAHOST2, and the two nodes have these IPs:
- SOAHOST1: 100.200.140.165
- SOAHOST2: 100.200.140.205
- ADMINVHN : 100.200.140.206. This is the Virtual IP where the Administration Server is running, assigned to ethX:Y, available in SOAHOST1 and SOAHOST2.
Oracle WebLogic Server and Oracle Fusion Middleware components have been installed in SOAHOST2 as described in the specific configuration chapters in this guide.

Specifically, both host computers use the exact same path to reference the binary files in the Oracle home.

This section contains the following topics:

Section 18.1.1.1, "Failing Over the Administration Server to a Different Host"
Section 18.1.1.2, "Validating Access to the Administration Server on SOAHOST2 Through Oracle HTTP Server"
Section 18.1.1.3, "Failing the Administration Server Back to SOAHOST1"

18.1.1.1 Failing Over the Administration Server to a Different Host

The following procedure shows how to fail over the Administration Server to a different node (SOAHOST2). Note that even after failover, the Administration Server will still use the same Oracle WebLogic Server machine (which is a logical machine, not a physical machine).

To fail over the Administration Server to a different host:

Stop the Administration Server.
Stop the Node Manager in the Administration Server domain directory (ASERVER_HOME).
Migrate the ADMINVHN virtual IP address to the second host:
1. Run the following command as root on SOAHOST1 (where X:Y is the current interface used by ADMINVHN):
```
/sbin/ifconfig ethX:Y down
```
2. Run the following command as root on SOAHOST2:
```
/sbin/ifconfig <interface:index> ADMINVHN netmask <netmask>
```
  For example:
```
/sbin/ifconfig eth0:1 100.200.140.206 netmask 255.255.255.0
```
  Note:
  Ensure that the netmask and interface to be used to match the available network configuration in SOAHOST2.
Update the routing tables using arping, for example:
```
/sbin/arping -q -U -c 3 -I eth0 100.200.140.206
```
Start the Node Manager in the Adminstration Server domain home on SOAHOST2.

For more information, see Section 10.6.1, "Starting the Node Manager in the Administration Server Domain Home on SOAHOST1"
Start the Administration Server on SOAHOST2.

For more information, see Section 10.6.3, "Starting the Administration Server".
Test that you can access the Administration Server on SOAHOST2 as follows:
1. Ensure that you can access the Oracle WebLogic Server Administration Console using the following URL:
```
http://ADMINVHN:7001/console
```
2. Check that you can access and verify the status of components in Fusion Middleware Control using the following URL:
```
http://ADMINVHN:7001/em
```

18.1.1.2 Validating Access to the Administration Server on SOAHOST2 Through Oracle HTTP Server

Perform the same steps as in Section 11.7.4, "Validating the Virtual Server Configuration on the Load Balancer". This is to check that you can access the Administration Server when it is running on SOAHOST2.

18.1.1.3 Failing the Administration Server Back to SOAHOST1

This step checks that you can fail back the Administration Server, that is, stop it on SOAHOST2 and run it on by migrating ADMINVHN back to SOAHOST1 node.

To migrate ADMINVHN back to SOAHOST1:

Stop the Administration Server.
Stop the Node Manager in the Adminstration Server domain home on SOAHOST2.
Run the following command as root on SOAHOST2.
```
/sbin/ifconfig ethZ:N down
```
Run the following command as root on SOAHOST1:
```
/sbin/ifconfig ethX:Y 100.200.140.206 netmask 255.255.255.0
```
Note:
Ensure that the netmask and interface to be used match the available network configuration in SOAHOST1

Update the routing tables using arping on SOAHOST1:

/sbin/arping -q -U -c 3 -I ethZ 100.200.140.206

Start the Node Manager in the Administration Server domain home on SOAHOST1.
Start the Administration Server on SOAHOST1.
Test that you can access the Oracle WebLogic Server Administration Console using the following URL:
```
http://ADMINVHN:7001/console
```
Check that you can access and verify the status of components in the Oracle Enterprise Manager using the following URL:
```
http://ADMINVHN:7001/em
```

18.1.2 Enabling SSL Communication Between the Middle Tier and the Hardware Load Balancer

The following sections describe how to enable SSL communication between the middle tier and the hardware load balancer:

Section 18.1.2.1, "When is SSL Communication Between the Middle Tier and Load Balancer Necessary?"
Section 18.1.2.2, "Generating Self-Signed Certificates Using the utils.CertGen Utility"
Section 18.1.2.3, "Creating an Identity Keystore Using the utils.ImportPrivateKey Utility"
Section 18.1.2.4, "Creating a Trust Keystore Using the Keytool Utility"
Section 18.1.2.5, "Importing the Load Balancer's Certificate into theTrust Store"
Section 18.1.2.6, "Adding the Updated Trust Store to the Oracle WebLogic Server Start Scripts"
Section 18.1.2.7, "Configuring Node Manager to Use the Custom Keystores"
Section 18.1.2.8, "Configuring WebLogic Servers to Use the Custom Keystores"
Section 18.1.2.9, "Testing Composites Using SSL Endpoints"

Note:

This step is applicable if the hardware load balancer is configured with SSL and the front end address of the system has been secured accordingly.

18.1.2.1 When is SSL Communication Between the Middle Tier and Load Balancer Necessary?

In an enterprise deployment, there are scenarios where the software running on the middle tier must access the front-end SSL address of the hardware load balancer. In these scenarios, an appropriate SSL handshake must take place between the load balancer and the invoking servers. This handshake is not possible unless the Administration Server and Managed Servers on the middle tier are started using the appropriate SSL configuration.

For example, in an Oracle SOA Suite enterprise deployment, the following examples apply:

Oracle Business Process Management requires access to the front-end load balancer URL when it attempts to retrieve role information through specific Web services.
Oracle Service Bus performs invocations to endpoints exposed in the Load Balancer SSL virtual servers.
Oracle SOA Suite composite applications and services often generate callbacks that need to perform invocations using the SSL address exposed in the load balancer.
Finally, when you test a SOA Web services endpoint in Oracle Enterprise Manager Fusion Middleware Control, the Fusion Middleware Control software running on the Administration Server must access the load balancer front-end to validate the endpoint.

18.1.2.2 Generating Self-Signed Certificates Using the utils.CertGen Utility

This section describes the procedure for creating self-signed certificates on SOAHOST1. Create these certificates using the network name or alias of the host.

The directory where keystores and trust keystores are maintained must be on shared storage that is accessible from all nodes so that when the servers fail over (manually or with server migration), the appropriate certificates can be accessed from the failover node. Oracle recommends using central or shared stores for the certificates used for different purposes (for example, SSL set up for HTTP invocations). In this case, SOAHOST2 uses the cert directory created for SOAHOST1 certificates.

For information on using trust CA certificates instead, see the information about configuring identity and trust in Oracle Fusion Middleware Securing Oracle WebLogic Server.

About Passwords

The passwords used in this guide are used only as examples. Use secure passwords in a production environment. For example, use passwords that include both uppercase and lowercase characters as well as numbers.

To create self-signed certificates:

Set up your environment by running the WL_HOME/server/bin/setWLSEnv.sh script:

In the Bourne shell, run the following command:
```
. setWLSEnv.sh
```
Verify that the CLASSPATH environment variable is set:
```
echo $CLASSPATH
```
Create a user-defined directory for the certificates:
```
mkdir ASERVER_HOME/certs
```
Change directory to the user-defined directory.
```
cd ASERVER_HOME/certs
```

Run the utils.CertGen tool from the user-defined directory to create the certificates for both the physical hostnames and the virtual hostnames used by servers in the node

Syntax:

java utils.CertGen key_passphrase cert_file_name key_file_name [export | domestic] [hostname]

Examples:

java utils.CertGen password ADMINVHN.example.com_cert \
      ADMINVHN.example.com_key domestic ADMINVHN.example.com

java utils.CertGen password SOAHOST1.example.com_cert \
      SOAHOST1.example.com_key domestic SOAHOST1.example.com

java utils.CertGen password SOAHOST1VHN1.example.com_cert \
      SOAHOST1VHN1.example.com_key domestic SOAHOST1VHN1.example.com

18.1.2.3 Creating an Identity Keystore Using the utils.ImportPrivateKey Utility

This section describes how to create an Identity Keystore on SOAHOST1.example.com.

In previous sections you have created certificates and keys that reside in a shared storage. In this section, the certificate and private key for both SOAHOST1 and SOAHOST1VHN1 are imported into a new Identity Store. Make sure that you use a different alias for each of the certificate/key pair imported.

Note:

The Identity Store is created (if none exists) when you import a certificate and the corresponding key into the Identity Store using the utils.ImportPrivateKey utility.

Import the certificate and private key for ADMINVHN, SOAHOST1 and SOAHOST1VHN1 into the Identity Store. Make sure that you use a different alias for each of the certificate/key pair imported.

Syntax:

java utils.ImportPrivateKey keystore_file keystore_password certificate_alias_to_use private_key_passphrase certificate_file private_key_file keystore_type

Note:

Default keystore_type is jks.

Examples:

java utils.ImportPrivateKey appIdentityKeyStore.jks password
            appIdentity1 password
            ASERVER_HOME/certs/SOAHOST1.example.com_cert.pem 
            ASERVER_HOME/certs/SOAHOST1.example.com_key.pem 

java utils.ImportPrivateKey appIdentityKeyStore.jks password
            appIdentity2 password
            ASERVER_HOME/certs/SOAHOST1VHN1.example.com_cert.pem
            ASERVER_HOME/certs/SOAHOST1VHN1.example.com_key.pem

java utils.ImportPrivateKey appIdentityKeyStore.jks password
            appIdentity3 password
            ASERVER_HOME/certs/ADMINVHN.example.com_cert.pem
            ASERVER_HOME/certs/ADMINVHN.example.com_key.pem

Repeat the above step for all the remaining hosts used in the system (SOAHOST2, SOAHOST2VHN1, WEBHOST1, WEBHOST2, and, if OSB or BAM servers are used SOAHOST1VHN2, SOAHOST2VHN2, and so forth.)

18.1.2.4 Creating a Trust Keystore Using the Keytool Utility

To create the Trust Keystore on SOAHOST1.example.com.

Copy the standard java keystore to create the new trust keystore since it already contains most of the root CA certificates needed. Oracle does not recommend modifying the standard Java trust key store directly. Copy the standard Java keystore CA certificates located under the WL_HOME/server/lib directory to the same directory as the certificates. For example:
```
cp WL_HOME/server/lib/cacerts ASERVER_HOME/certs/appTrustKeyStore.jks
```
The default password for the standard Java keystore is changeit. Oracle recommends always changing the default password. Use the keytool utility to do this. The syntax is:
```
keytool -storepasswd -new NewPassword -keystore TrustKeyStore -storepass Original_Password
```
For example:
```
keytool -storepasswd -new password -keystore appTrustKeyStore.jks -storepass changeit
```

The CA certificate CertGenCA.der is used to sign all certificates generated by the utils.CertGen tool and is located at WL_HOME/server/lib directory. This CA certificate must be imported into the appTrustKeyStore using the keytool utility. The syntax is:

keytool -import -v -noprompt -trustcacerts -alias AliasName -file CAFileLocation -keystore KeyStoreLocation -storepass KeyStore_Password

For example:

keytool -import -v -noprompt -trustcacerts -alias clientCACert -file WL_HOME/server/lib/CertGenCA.der -keystore appTrustKeyStore.jks -storepass password

18.1.2.5 Importing the Load Balancer's Certificate into theTrust Store

For the SSL handshake to behave properly, the load balancer's certificate needs to be added to the WLS servers trust store. For adding it, follow these steps:

Access the site on SSL with a browser (this add the server's certificate to the browser's repository).
From the browser's certificate management tool, export the certificate to a file that is on the SOA server's file system (with a file name like soa.example.com)
Use the keytool to import the load balancer's certificate into the truststore:
```
keytool -import -file soa.exmaple.com -v -keystore appTrustKeyStore.jks
```

18.1.2.6 Adding the Updated Trust Store to the Oracle WebLogic Server Start Scripts

The setDomainEnv.sh script is provided by Oracle WebLogic Server and can be used to start the Administration Server and the Managed Servers in the domain.

To ensure each server can access the updated trust store, edit the setDomainEnv.sh script in each of the domain home directories in the enterprise deployment:

Replace reference to the existing DemoTrustStore entry with the following.

Note that all the values for EXTRA_JAVA_PROPERTIES must be on one line in the file, followed by the export command on a new line:

EXTRA_JAVA_PROPERTIES="${EXTRA_JAVA_PROPERTIES}
         -Dsoa.archives.dir=${SOA_ORACLE_HOME}/soa            ...
         -Djavax.net.ssl.trustStore=/u01/oracle/certs/appTrustKeyStore.jks..."
export EXTRA_JAVA_PROPERTIES

Make the same change to the setDomainEnv.sh file in the MSERVER_HOME/bin directory on SOAHOST1, SOAHOST2, WEBHOST1, and WEBHOST2.

Alternatively, you can use the setUserOverrides.sh file to place these options, this way they will not get overwritten when the domain's scripts are extended with the configuration wizard or updated with unpack operations. For more information, see "Customizing Domain Wide Server Parameters" in Administering Server Startup and Shutdown for Oracle WebLogic Server.

18.1.2.7 Configuring Node Manager to Use the Custom Keystores

To configure the Node Manager to use the custom keystores, add the following lines to the end of the nodemanager.properties files located both in ASERVER_HOME/nodemanager and MSERVER_HOME/nodemanager directories in all nodes:

KeyStores=CustomIdentityAndCustomTrust
CustomIdentityKeyStoreFileName=Identity KeyStore
CustomIdentityKeyStorePassPhrase=Identity KeyStore Passwd
CustomIdentityAlias=Identity Key Store Alias
CustomIdentityPrivateKeyPassPhrase=Private Key used when creating Certificate

Make sure to use the correct value for CustomIdentityAlias for Node Manager's listen address. For example on SOAHOST1, use appIdentity1 according to the steps in "Creating a Trust Keystore Using the Keytool Utility."

(appIdentity1 mapped to the SOAHOST1 listen address).
Example for Node 1:
KeyStores=CustomIdentityAndCustomTrust
CustomIdentityKeyStoreFileName=/u01/oracle/config/domains/soaedg_domain/certs/appIdentityKeyStore.jks
CustomIdentityKeyStorePassPhrase=password
CustomIdentityAlias=appIdentity1
CustomIdentityPrivateKeyPassPhrase=password

The passphrase entries in the nodemanager.properties file are encrypted when you start Node Manager as described in "Starting the Node Manager on SOAHOST1." For security reasons, minimize the time the entries in the nodemanager.properties file are left unencrypted. After you edit the file, start Node Manager as soon as possible so that the entries are encrypted.

18.1.2.8 Configuring WebLogic Servers to Use the Custom Keystores

Configure the WebLogic Servers to use the custom keystores using the Oracle WebLogic Server Administration Console. Complete this procedure for the Administration Server, the WLS_SOAn servers and other servers requiring access to the front end LBR on SSL.

The example directory path given in Step 6 is just an example. Oracle does not recommend putting keystores into the aserver directory, but recommends putting the keystore in shared storage. Having a separate directory for certificates is a better solution.

To configure the identity and trust keystores:

Log in to the Administration Console, and click Lock & Edit.
In the left pane, expand Environment, and select Servers.
Click the name of the server for which you want to configure the identity and trust keystores.
Select Configuration, and then Keystores.
In the Keystores field, click Change, and select Custom Identity and Custom Trust method for storing and managing private keys/digital certificate pairs and trusted CA certificates, and click Save.
In the Identity section, define attributes for the identity keystore.
- Custom Identity Keystore: Enter the fully qualified path to the identity keystore:
```
ASERVER_HOME/certs/appIdentityKeyStore.jks 
```
- Custom Identity Keystore Type: Leave this field blank, it defaults to JKS.
- Custom Identity Keystore Passphrase: Enter the password Keystore_Password you provided in "Creating an Identity Keystore Using the utils.ImportPrivateKey Utility."
  
  This attribute may be optional or required depending on the type of keystore. All keystores require the passphrase in order to write to the keystore. However, some keystores do not require the passphrase to read from the keystore. WebLogic Server reads only from the keystore, so whether or not you define this property depends on the requirements of the keystore.
In the Trust section, define properties for the trust keystore:
- Custom Trust Keystore: Enter the fully qualified path to the trust keystore:
```
ASERVER_HOME/certs/appTrustKeyStore.jks 
```
- Custom Trust Keystore Type: Leave this field blank, it defaults to JKS.
- Custom Trust Keystore Passphrase: The password you provided in as New_Password in "Creating a Trust Keystore Using the Keytool Utility."
  
  As mentioned in the previous step, this attribute may be optional or required depending on the type of keystore.
Click Save.
To activate these changes, in the Change Center of the Administration Console, click Activate Changes.
Click Lock & Edit.
Select Configuration, then SSL.
In the Private Key Alias field, enter the alias you used for the host name the managed server listens on.

In the Private Key Passphrase and the Confirm Private Key Passphrase fields, enter the password for the keystore that you created in "Creating an Identity Keystore Using the utils.ImportPrivateKey Utility."
Click Save.
Click Activate Changes in the Administration Console's Change Center to make the changes take effect.
Restart the server for which the changes have been applied. The fact that servers can be restarted using the Administration Console/Node Manager is a good verification that the communication between Node Manager, Administration Server and the managed servers is correct.

18.1.2.9 Testing Composites Using SSL Endpoints

Once SSL has been enabled, composites endpoints can be verified on SSL from Oracle Enterprise Manager FMW Control. To test a SSL endpoint follow this steps:

Enter the following URL into a browser to display the Fusion Middleware Control login screen:
```
http://ADMINVHN:7001/em
```
In this example:
- Replace ADMINVHN with the host name assigned to the ADMINVHN Virtual IP address in Section 5.3, "Identifying and Obtaining Software Downloads for an Enterprise Deployment."
- Port 7001 is the typical port used for the Administration Server console and Fusion Middleware Control. However, you should use the actual URL that was displayed at the end of the Configuration Wizard session when you created the domain.
Log in to Fusion Middleware Control using the Administration Server credentials.
From the tree on the left, expand SOA. Click soa-infra(WLS_SOAn) and select the partition that the composite was deployed to.
Select the composite.
From the right pane, click on the Test tab.
In the WSDL or WADL address, replace http://soa.example.com:80 with https://soa.example.com:443.
Click Parse WSDL or WADL.
Verify that the Endpoint URL shown is SSL.
Test the composite. If the response is as expected for the web service, the SSL communication between the Administration Server and the Load Balancer has been configured properly.

18.2 Configuration and Management Tasks for an Oracle SOA Suite Enterprise Deployment

The following sections describe some of the key configuration and management tasks you will likely need to perform on an Oracle SOA Suite enterprise deployment:

Section 18.2.1, "Configuring Roles for Administration of Oracle SOA Suite Products"
Section 18.2.2, "Deploying Oracle SOA Suite Composite Applications to an Enterprise Deployment"
Section 18.2.3, "Failing Back Oracle BAM Services After Automatic Service Migration Occurs"
Section 18.2.4, "Using Shared Storage for Deployment Plans and SOA Infrastructure Applications Updates"
Section 18.2.5, "Managing Database Growth in an Oracle SOA Suite Enterprise Deployment"
Section 18.2.6, "Performing Backups and Recoveries in the SOA Enterprise Deployments"

18.2.1 Configuring Roles for Administration of Oracle SOA Suite Products

Each Oracle SOA Suite enterprise deployment consists of multiple Oracle SOA Suite products. Some of the Oracle SOA Suite products have specific administration users, roles, or groups that are used to control administration access to each product.

However, for an enterprise deployment, which consists of multiple Oracle SOA Suite products, you can use a single LDAP-based authorization provider and a single administration user and group to control access to all aspects of the deployment. For more information about creating the authorization provider and provisioning the enterprise deployment administration user and group, see Section 10.9.

To be sure that you can manage each product effectively within the single enterprise deployment domain, you must understand which products require specific administration roles or groups, you must know how to add any specifc product administration roles to the single, common enterprise deployment administration group, and if necessary, you must know how to add the enterprise deployment administration user to any required product-specific administration groups.

For more information, see the following topics:

Section 18.2.1.1, "Summary of Oracle SOA Suite Products with Specific Administration Roles"
Section 18.2.1.3, "Adding a Product-Specific Administration Role to the Enterprise Deployment Administration Group"

18.2.1.1 Summary of Oracle SOA Suite Products with Specific Administration Roles

Table 18-1 lists the Oracle SOA Suite products that have specific administration roles, which must be added to the enterprise deployment administration group.

For the purposes of the Oracle SOA Suite enterprise deployment, use the SOA Administrators group, which was defined in the LDAP Authorization Provider for the enterprise deployment.

Use the information in the table and the instructions in Section 18.2.1.3 to add the required administration roles to the enterprise deployment Administration group.

Table 18-1 Summary of Oracle SOA Suite Products with Administration Roles

Product	Application Stripe	Administration Role to be Assigned to the SOA Administrators Group
Oracle Web Services Manager	wsm-pm	policy.updater
SOA Infrastructure	soa-infra	SOAAdmin
Oracle Service Bus	Service_Bus_Console	MiddlewareAdministrator
Enterprise Scheduler Service	ESSAPP	ESSAdmin
Oracle B2B	b2bui	B2BAdmin

18.2.1.2 Summary of Oracle SOA Suite Products with Specific Administration Groups

Table 18-2 lists the Oracle SOA Suite products that need to use specific administration groups.

For each of these components, the common enterprise deployment Administration user must be added to the product-specific Administration group; otherwise, you won't be able to manage the product resources using the enterprise manager administration user that you created in Section 10.9.5, "Provisioning an Enterprise Deployment Administration User and Group".

Use the information in Table 18-2 and the instructions in Section 18.2.1.4 to add the required administration roles to the enterprise deployment Administration group.

Table 18-2 Oracle SOA Suite Products with a Product-Specific Administration Group

Product	Product-Specific Administration Group
Oracle Business Activity Monitoring	BAMAdministrators
Oracle Business Process Management	Administrators
Oracle Service Bus Integration	IntegrationAdministrators

18.2.1.3 Adding a Product-Specific Administration Role to the Enterprise Deployment Administration Group

For products that require a product-specific administration role, use the following procedure to add the role to the enterprise deployment administration group:

Use the Oracle WebLogic Server Administration Server credentials to log in to Oracle Enterprise Manager Fusion Middleware Control.

These are the credentials you created when you initially configured the domain and created the Oracle WebLogic Server Administration user name (typically, weblogic) and password.
From the WebLogic Domain menu, select Security, and then Application Roles.
For each production-specific application role in Table 18-2 select the corresponding application stripe from the Application Stripe drop-down menu.
Click Search Application Roles icon to display all the application roles available in the domain.
Select the row for the application role you are adding to the enterprise deployment administration group.

Description of the illustration ''edg_em_selecting_admin_role.gif''
Click the Edit icon to edit the role.
Click the Add icon on the Edit Application Role page.
In the Add Principal dialog box, select Group from the Type drop-down menu.
Enter SOA Administrators in the Principal Name Starts With field. Click right arrow to search.
Select SOA Administrators and click OK.

Description of the illustration ''edg_em_edit_role_add_princ.gif''
Click OK on the Edit Application Role page.

18.2.1.4 Adding the Enterprise Deployment Administration User to a Product-Specific Administration Group

For products with a product-specific administration group, use the following procedure to add the enterprise deployment administration user to the group. This will allow you to manage the product using the enterprise manager administrator user:

Create an ldif file called product_admin_group.ldif similar to the one shown below:
```
dn: cn=product-specific_group_name, cn=groups, dc=us, dc=oracle, dc=com
displayname: product-specific_group_display_name
objectclass: top
objectclass: groupOfUniqueNames
objectclass: orclGroup
uniquemember: cn=weblogic_soa,cn=users,dc=us,dc=oracle,dc=com
cn: product-specific_group_name
description: Administrators Group for the OSB Domain
```
In this example, replace product-specific_group_name with the actual name of the product administrator group, as shown in Table 18-2.

Replace product-specific_group_display_name with the display name for the group that appears in the management console for the LDAP server and in the Oracle WebLogic Server Administration Console.

Use the ldif file to add the enterprise deployment administrator user to the product-specific administration group.

For Oracle Unified Directory:

OUD_INSTANCE_HOME/bin/ldapmodify -a 
                                 -D "cn=Administrator" 
                                 -X 
                                 -p 1389 
                                 -f product_admin_group.ldif

For Oracle Internet Directory:

OID_ORACLE_HOME/bin/ldapadd -h oid.example.com 
                            -p 389 
                            -D cn="orcladmin" 
                            -w <password> 
                            -c 
                            -v 
                            -f product_admin_group.ldif

18.2.2 Deploying Oracle SOA Suite Composite Applications to an Enterprise Deployment

Oracle SOA Suite applications are deployed as composites, consisting of different kinds of Oracle SOA Suite components. SOA composite applications include the following:

Service components such as Oracle Mediator for routing, BPEL processes for orchestration, BAM processes for orchestration (if Oracle BAM Suite is also installed), human tasks for workflow approvals, spring for integrating Java interfaces into SOA composite applications, and decision services for working with business rules.
Binding components (services and references) for connecting SOA composite applications to external services, applications, and technologies.

These components are assembled into a single SOA composite application.

When you deploy an Oracle SOA Suite composite application to an Oracle SOA Suite enterprise deployment, be sure to deploy each composite to a specific server or cluster address and not to the load balancer address (soa.example.com).

Deploying composites to the load balancer address often requires direct connection from the deployer nodes to the external load balancer address. As a result, you will have to open additional ports in the firewalls.

For more information about Oracle SOA Suite composite applications, see the following sections in Administering Oracle SOA Suite and Oracle Business Process Management Suite:

18.2.3 Failing Back Oracle BAM Services After Automatic Service Migration Occurs

The instructions for configuring Oracle BAM in Chapter 16 include the instructions for configuring automatic service migration for the server-specific, pinned JMS and JTA services required by Oracle BAM.

However, if Automatic Service Migration occurs, Oracle WebLogic Server does not support failing back services to their original server when a server is back online and rejoins the cluster.

As a result, after the Automatic Service Migration migrates specific JMS services to a backup server during a fail-over, it does not migrate the services back to the original server after the original server is back online. Instead, you must migrate the services back to the original server manually.

To fail back a service to its original server, follow these steps:

If you have not already done so, in the Change Center of the Administration Console, click Lock & Edit.
In the Domain Structure tree, expand Environment, expand Clusters, and then select Migratable Targets.
To migrate one or more migratable targets at once, on the Summary of Migratable Targets page:
1. Click the Control tab.
2. Use the check boxes to select one or more migratable targets to migrate.
3. Click Migrate.
4. Use the New hosting server drop-down to select a new server for the migratable targets.
5. Click OK.
  
  A request is submitted to migrate the JMS-related service and the configuration edit lock is released. In the Migratable Targets table, the Status of Last Migration column indicates whether the requested migration has succeeded or failed.
To migrate a specific migratable target, on the Summary of Migratable Targets page:
1. Select the migratable target to migrate.
2. Click the Control tab.
3. Reselect the migratable target to migrate.
4. Click Migrate.
5. Use the New hosting server drop-down to select a new server for the migratable target.
6. Click OK.

18.2.4 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.

To ensure deployment plan location is available to all servers in the domain, use the Deployment Plan home location described in Section 7.4, "File System and Directory Variables Used in This Guide" and represented by the DEPLOY_PLAN_HOME variable in the Enterprise Deployment Workbook.

18.2.5 Managing Database Growth in an Oracle SOA Suite Enterprise Deployment

When the amount of data in the Oracle SOA Suite database grows very large, maintaining the database can become difficult, especially in an Oracle SOA Suite enterprise deployment where potentially many composite applications are deployed.

For more information, review the following sections in Administering Oracle SOA Suite and Oracle Business Process Management Suite:

18.2.6 Performing Backups and Recoveries in the SOA Enterprise Deployments

This section provides some guidelines for making sure you back up the necessary directories and configuration data for an Oracle SOA Suite enterprise deployment.

For general information about backing up and recovering Oracle Fusion Middleware products, see the following sections in Administering Oracle Fusion Middleware:

Table 18-3 lists the static artifacts to back up in a typical Oracle SOA Suite enterprise deployment.

Table 18-3 Static Artifacts to Back Up in the Oracle SOA Suite Enterprise Deployment

Type	Host	Tier
Database Oracle home	DBHOST1 and DBHOST2	Data Tier
Oracle Fusion Middleware Oracle home	WEBHOST1 and WEBHOST2	Web Tier
Oracle Fusion Middleware Oracle home	SOAHOST1 and SOAHOST2	Application Tier
Installation-related files	WEBHOST1, WEHOST2, and shared storage	N/A

Table 18-4 lists the runtime artifacts to back up in a typical Oracle SOA Suite enterprise deployment.

Table 18-4 Run-Time Artifacts to Back Up in the Oracle SOA Suite Enterprise Deployment

Type	Host	Tier
Administration Server domain home (ASERVER_HOME)	SOAHOST1 and SOAHOST2	Application Tier
Application home (APPLICATION_HOME)	SOAHOST1 and SOAHOST2	Application Tier
Oracle RAC databases	DBHOST1 and DBHOST2	Data Tier
Scripts and Customizations	SOAHOST1 and SOAHOST2	Application Tier
Deployment Plan home (DEPLOY_PLAN_HOME)	SOAHOST1 and SOAHOST2	Application Tier