| Oracle® Application Server Enterprise Deployment Guide 10g Release 3 (10.1.3.5.0) Part Number E15355-01 |
|
|
View PDF |
| Oracle® Application Server Enterprise Deployment Guide 10g Release 3 (10.1.3.5.0) Part Number E15355-01 |
|
|
View PDF |
Installing the Oracle Application Server Metadata Repository for the Security Infrastructure
Installing the Oracle Internet Directory Instances in the Data Tier
Configuring the Virtual Server to Use the Load Balancing Router
Testing the Oracle Internet Directory Instances
Installing the ORABPEL, ORAESB and ORAWSM Schemas
Enterprise Service Bus AQ Topics
Configuration of Oracle SOA Suite for Global Transactions
You must install the 10g(10.1.4.0.1) OracleAS Metadata Repository into the Real Application Clusters database before you install components into the Security DMZ. Oracle Application Server provides the Oracle Application Server Repository Creation Assistant, to create the OracleAS Metadata Repository in an existing database.
The 10g (10.1.4.0.1) OracleAS RepCA is available on the OracleAS RepCA CD-ROM or the Oracle Application Server DVD-ROM. You install the OracleAS RepCA in a separate Oracle home.
To install and execute the OracleAS Metadata Repository, perform the following steps:
Install the OracleAS RepCA into the Real Application Clusters database, following the steps in the Oracle Application Server Metadata Repository Creation Assistant User's Guide for Microsoft Windows for the platform you are using. You can find this guide in the Oracle Application Server documentation library (Getting Started tab).
Verify that the database meets the requirements specified in the "Database Requirements" section of the Oracle Application Server Metadata Repository Creation Assistant User's Guide for Microsoft Windows.
Also verify that the database computer has at least 512 MB of swap space available for execution of the OracleAS RepCA
Run the OracleAS RepCA.
The RepCA creates the schemas listed in the Oracle Application Server Metadata Repository Creation Assistant User's Guide for Microsoft Windows.
Perform the post-installation step described in the following Section 2.1.1.
You must configure the SQLNET.EXPIRE_TIME parameter in the sqlnet.ora file that exists in the application infrastructure database.
Open the file ORACLE_HOME/network/admin/sqlnet.ora file (UNIX) or the ORACLE_BASE/ ORACLE_HOME/network/admin/sqlnet.ora file (Windows).
Set the SQLNET.EXPIRE_TIME parameter to a value lower than the TCP session time out value for the Load Balancing Router and firewall.
Restart the listener by issuing these commands in ORACLE_HOME/bin:
prompt> lsnrctl stop prompt> lsnrctl start
Oracle recommends using the Oracle Enterprise Manager Cluster Managed Services Page to create database services that client applications will use to connect to the database. For complete instructions on creating database services, see the chapter on workload management in the Oracle Database Oracle Clusterware and Oracle Real Application Clusters Administration and Deployment Guide.
You can also use SQL*Plus to configure this using the following instructions:
Use the CREATE_SERVICE subprogram to create the soaedg.mycompany.com database service. Log on to SQL*Plus as the sysdba user and run the following command:
SQL> EXECUTE DBMS_SERVICE.CREATE_SERVICE (SERVICE_NAME => 'soaedg.mycompany.com', NETWORK_NAME => 'soaedg.mycompany.com', );
Add the service to the database and assign it to the instances using the srvctl command:
prompt> srvctl add service -d soadb -s soaedg -r soadb1,soadb2
Start the service using the srvctl command:
prompt> srvctl start service -d soadb -s soaedg
Note:
For more information about the
srvctl command, see the Oracle Real Application Clusters Administration and Deployment Guide.Oracle recommends using a specific database service for a product suite, even when the same database is shared. Oracle also recommends that the database service you use is different than the default database service. In the example described in the previous steps, the database is soadb.mycompany.com and the default service is one with the same name. The SOA install is configured to use the service soaedg.mycompany.com. Oracle recommends using a service named bamedg.mycompany.com for BAM.
For deployments using the Oracle RAC 10g Database, the database must be configured for distributed transaction processing (DTP). The DTP configuration can specify a preferred RAC instance for a particular database service, meaning that database service will be available on one host at a time. All data source connections to the service are thereby routed to the host. If the preferred instance fails, those connections will fail over to the specified secondary preferred instance.
DTP is required to maintain transactional consistency when different data source connections create multiple transaction branches as part of the same global transaction. These transaction branches are not visible across different RAC nodes and therefore all transaction branches must be contained within the same RAC node to ensure consistency. Since BPEL Process Manager and Enterprise Service Bus (ESB) each use their own data source connections, it is necessary to use this configuration whenever these two components interact as part of the same global transaction. Similarly, data source connections for inbound or outbound adapter endpoints from BPEL Process Manager or ESB can introduce separate data source connections and require DTP.
Note that Oracle RAC Database 11g does not require DTP, since transactions on one node are visible across the cluster. For more information see Services and Distributed Transaction Processing information located in the Oracle Real Application Clusters section in Oracle Real Application Clusters Administration and Deployment Guide 11g Release 1 (11.1) .
You can create a RAC service using the command line srvctl utility available with RAC database installations. You can specify an available RAC node as the preferred instance, with one or more RAC nodes as the secondary preferred instance using the following command:
> srvctl add service -d ORCL -s ORCLSVC -r ORCL1 -a ORCL2
In command example, the parameter values are as follows:
ORCL Database name ORCLSVC DTP service name ORCL1 Preferred instance ORCL2 Secondary instance
Execute the following database command as the SYS user to enable the service to support distributed transactions.
SQL> EXECUTE DBMS_SERVICE.MODIFY_SERVICE (service_name => 'ORCLSVC', dtp => true);
<For a deeper review of DTP and XA with Oracle RAC Database, refer to the Best Practices for Using XA with RAC>.
The preferred instance and secondary instances for RAC DTP services affect how load-balancing is achieved across RAC nodes. For environments with a cluster of SOA Suite nodes, it is possible to achieve RAC load-balancing using multiple RAC services with different preferred instances.
The following example commands create two services, each with a preferred instance:
> srvctl add service -d ORCL -s ORCLSVC1 -r ORCL1 -a ORCL2 … > srvctl add service -d ORCL -s ORCLSVC2 -r ORCL2 -a ORCL1
The SOA Suite data source connections for a specific node can then be configured to use either service, ORCLSVC1 or ORCLSVC2, thus balancing the data tier load across the two RAC instances. In the simple case of a two-node SOA Suite cluster, node 1 data sources should point to ORCLSVC1 and node 2 data sources should point to ORCLSVC2.This model can naturally be expanded to more Oracle Application Server instances and RAC instances. The more DTP services available (each configured with its own unique preferred instance) the more Oracle Application Servers can connect to their own DTP service and better distribute load-balancing against the database tier.
The speed of propagating changes between RAC instances can be configured using the MAX_COMMIT_PROPAGATION_DELAY database property.
The following scenarios describe when this property may require its value set to zero:
A BPEL process initiates an asynchronous invoke of an external service that immediately sends a response message
A BPEL process initiates a one-way invoke and uses a pick activity to process a correlated response message that is immediately received
In these scenarios, the BPEL system automatically hydrates the process instance data to the database at the point it expects to receive a response message. When the response message arrives, the BPEL system will rehydrate the process instance. If the response message arrives before the instance data has propagated to the RAC instance from which the BPEL process is rehydrated, an error will occur. Therefore, to insure proper behavior of the BPEL system, in environments where asynchronous response messages can return quickly (sub-second), the MAX_COMMIT_PROPAGATION_DELAY property value should be set to zero.
For more information on MAX_COMMIT_PROPAGATION_DELAY, refer to the Oracle RAC Administrator's Guide.
This section describes the steps to install the Oracle Internet Directory components (OIDHOST1 and OIDHOST2) on the Data Tier with the Metadata Repository. The procedures for the installations are very similar, but the selections in the configuration options screen differ.
Note:
Ensure that the clocks are synchronized between the two computers on which you intend to install the Oracle Internet Directory instances. Errors will occur if the clocks are not synchronized.The OracleAS Metadata Repository must be running before you install the first Oracle Internet Directory instance.
Follow these steps to install the 10g (10.1.4.0.1)Oracle Internet Directory on OIDHOST1:
Verify that your that the system, patch, kernel and other requirements are fulfilled. These are listed in the Oracle Application Server Quick Installation Guide in the Oracle Application Server platform documentation library for the platform and version you are using.
Verify that ports 389 and 636 are not in use by any service on the computer by issuing these commands for the operating system you are using. (If the port is not in use, no output is returned from the command.)
On UNIX:
netstat -an | grep "389"
netstat -an | grep "636"
On Microsoft Windows:
netstat -an | findstr:389
netstat -an | findstr:636
If the port is in use (if the command returns output identifying the port), you must free the port.
Copy the staticport.ini file from the Disk1/stage/Response directory to the Oracle home directory.
Edit the staticport.ini file to assign the following custom ports:
Oracle Internet Directory port = 389 Oracle Internet Directory (SSL) port = 636
Start the Oracle Universal Installer as follows:
On Unix
> runInstaller
On Microsoft Windows:
Double-click setup.exe
The Welcome screen appears.
Click Next.
On UNIX systems, the Specify Inventory Directory and Credentials screen appears.
Specify the directory you want to be the oraInventory directory and the operating system group that has permission to write to it.
Click Next.
On UNIX systems, a dialog appears, prompting you to run the oraInstRoot.sh script.
Open a window and run the script, following the prompts in the window.
Return to the Oracle Universal Installer screen and click Next.
The Specify File Locations screen appears with default locations for:
The product files for the installation (Source)
The name and path to an Oracle home (Destination)
Note:
It is a good idea to make the Oracle home directory path for OIDHOST1 the same as the path to the Oracle home location of OIDHOST2. For example, if the path to the Oracle home on OIDHOST1 is:/u01/app/oracle/product/AS10gOID
then the path to the Oracle home on OIDHOST2 should be:
/u01/app/oracle/product/AS10gOID
Specify the Destination Name and Path, if different from the default, and click Next.
The Select a Product to Install screen appears.
Select OracleAS Infrastructure 10g and click Next.
The Select Installation Type screen appears.
Select Identity Management and click Next.
The Upgrade Existing Oracle Application Server (10.1.2) Infrastructure screen appears.
Select Install New Oracle Application Server Infrastructure 10g (10.1.4.0.1) and click Next.
The Product-Specific Prerequisite Checks screen appears.
Click Next.
The Confirm Pre-Installation Requirements screen appears.
Ensure that the requirements are met, check the box for each, and click Next.
The Select Configuration Options screen appears.
Select Oracle Internet Directory, OracleAS Directory Integration and Provisioning, and High Availability and Replication and click Next.
The Specify Port Configuration Options screen appears.
Select Manual and click Next.
The Specify Repository screen appears.
Provide the DBA login and computer information and click Next.
Note:
The syntax for the host name and port field for a RAC database is:infradbhost1-V.mycompany.com:1521^infradbhost2-V.mycompany.com:1521^
The Select High Availability or Replication Option screen appears.
Select OracleAS Cluster (Identity Management) and click Next.
The Specify Namespace in Internet Directory screen appears.
Click Next to specify the default Suggested Namespace, or enter values for the Custom Namespace and click Next.
The Specify Instance Name and ias_admin Password screen appears.
Specify the instance name and password and click Next.
The Summary screen appears.
Review the selections to ensure that they are correct (if they are not, click Back to modify selections on previous screens), and click Install.
The Install screen appears with a progress bar. On UNIX systems, a dialog opens prompting you to run the root.sh script.
Open a window and run the script.
The Configuration Assistants screen appears. Multiple configuration assistants are launched in succession; this process can be lengthy. When it completes, the End of Installation screen appears.
Click Exit, and then confirm your choice to exit.
The OracleAS Metadata Repository and the first Oracle Internet Directory instance must be running before you perform this task. Follow these steps to install the 10g Release 2 (10.1.2) Oracle Internet Directory on OIDHOST2:
Ensure that the system, patch, kernel and other requirements are met. These are listed in the Oracle Application Server Quick Installation Guide in the Oracle Application Server platform documentation library for the platform and version you are using.
Ensure that ports 389 and 636 are not in use by any service on the computer by issuing these commands for the operating system you are using. (If the port is not in use, no output is returned from the command.)
On UNIX:
netstat -an | grep "389"
netstat -an | grep "636"
On Windows:
netstat -an | findstr:389
netstat -an | findstr:636
If the port is in use (if the command returns output identifying the port), you must free the port.
In UNIX:
Remove the entries for ports 389 and 636 in the /etc/services file and restart the services, or restart the computer.
In Windows:
Stop the component that is using the port.
Copy the staticport.ini file from the Disk1/stage/Response directory to the Oracle home directory.
Edit the staticport.ini file and uncomment, and update these entries:
Oracle Internet Directory port = 389 Oracle Internet Directory (SSL) port = 636
Start the Oracle Universal Installer as follows:
On UNIX, issue this command: runInstaller
On Windows, double-click setup.exe
The Welcome screen appears.
Click Next.
On UNIX systems, the Specify Inventory Directory and Credentials screen appears.
Specify the directory you want to be the oraInventory directory and the operating system group that has permission to write to it.
Click Next.
On UNIX systems, a dialog appears, prompting you to run the oraInstRoot.sh script.
Open a window and run the script, following the prompts in the window.
Return to the Oracle Universal Installer screen and click Next.
The Specify File Locations screen appears with default locations for:
The product files for the installation (Source)
The name and path to an Oracle home (Destination)
Note:
It is a good idea to make the Oracle home directory path for OIDHOST1 the same as the path to the Oracle home location of OIDHOST2. For example, if the path to the Oracle home on OIDHOST1 is:/u01/app/oracle/product/AS10gOID
then the path to the Oracle home on OIDHOST2 should be:
/u01/app/oracle/product/AS10gOID
Specify the Destination Name and Path, if different from the default, and click Next.
The Select a Product to Install screen appears.
Select OracleAS Infrastructure 10g and click Next.
The Select Installation Type screen appears.
Select Identity Management and click Next.
The Upgrade Existing Oracle Application Server (10.1.2) Infrastructure screen appears.
Select Install New Oracle Application Server Infrastructure 10g (10.1.4.0.1) and click Next.
The Product-Specific Prerequisite Checks screen appears.
Click Next.
The Confirm Pre-Installation Requirements screen appears.
Ensure that the requirements are met, check the box for each, and click Next.
The Select Configuration Options screen appears.
Select Oracle Internet Directory, OracleAS Directory Integration and Provisioning, and High Availability and Replication and click Next.
The Specify Port Configuration Options screen appears.
Select Manual and click Next.
The Specify Repository screen appears.
Provide the DBA login and computer information and click Next.
Note:
The syntax for the host name and port field for a RAC database is:infradbhost1-V.mycompany.com:1521^infradbhost2-V.mycompany.com:1521^
A dialog opens, prompting you to synchronize the system time of the primary Oracle Internet Directory computer and the system time on the computer on which you are installing.
Synchronize the system time on the computers and click OK.
The Specify ODS Password screen appears.
Specify the ODS password (by default, the ias_admin password) and click Next.
Specify the user name and password and click Next.
The Specify OID Login screen appears.
The Specify Instance Name and ias_admin Password screen appears.
Specify the instance name and password and click Next.
The Summary screen appears.
Review the selections to ensure that they are correct (if they are not, click Back to modify selections on previous screens), and click Install.
The Install screen appears with a progress bar. On UNIX systems, a dialog opens prompting you to run the root.sh script.
Open a window and run the script.
The Configuration Assistants screen appears. Multiple configuration assistants are launched in succession; this process can be lengthy. When it completes, the End of Installation screen appears.
Click Exit, and then confirm your choice to exit.
If you plan to use the Enterprise Deployment Architecture for mySOAcompany.com with JAZN-SSO/DAS, you must configure the Load Balancing Router to perform these functions:
Balance the requests received on ports 389 and 636 to oidhost1.mycompany.com and oidhost2.mycompany.com on ports 389 and 636.
Monitor the Oracle Internet Directory processes on both computers. If an Oracle Internet Directory process stops on one of the computers, the Load Balancing Router must route the LDAP traffic to the functioning computer.
Note:
Some tuning of the Load Balancing Router's monitoring interval and time out values may be required to ensure system availability. If the interval or time out value is too long, the Load Balancing Router will not detect service failures in time; if it is too short, the Load Balancing Router may erroneously detect that a server is down.For example:
A Load Balancing Router maps the virtual IP address oid.mycompany.com to two Oracle Internet Directory servers for round robin load balancing. In this example, the monitoring scheme attempts an ldapbind at 10-second intervals.
If the Oracle Internet Directory on APPHOST1 is down, then the Load Balancing Router directs all traffic to the Oracle Internet Directory on APPHOST2.However, there is a10-second interval during which the Load Balancing Router does not indicate that the Oracle Internet Directory on APPHOST1 is down as well as a 30-second time out period.
During the 30-second time out period, the Load Balancing Router continues to direct traffic to both Oracle Internet Directory servers in round robin mode. ldapbind failures will occur when it attempts connections to the Oracle Internet Directory on APPHOST1.
Ensure that you can connect to each Oracle Internet Directory instance and the Load Balancing Router, using this command:
ldapbind -p 389 -h OIDHOST1
ldapbind -p 389 -h OIDHOST2
ldapbind -p 389 -h oid.mycompany.com
Start the oidadmin tool on each Oracle Internet Directory instance in ORACLE_HOME/bin with this command:
oidadmin
The Data Tier configuration is now as shown in Figure 2-1.
The database for the SOA Suite must be of one of the versions listed in Table 2-1:
Table 2-1 Database versions supported for SOA Suite
| Database Series | Version |
|---|---|
|
Oracle9i Release 2 (9.2.x) |
9.2.0.7 or later |
|
Oracle Database 10g Release 1 (10.1.x) |
10.1.0.5 or later |
|
Oracle Database Express Edition 10g Release 2 (10.2.x) |
10.2.0.1 |
|
Oracle Database 10g Release 2 (10.2.x) |
10.2.0.2 or later |
Use the following commands to determine the database version:
sqlplus "sys/password as sysdba" sql> select version from product_component_version where product like 'Oracle%9i%' or product like 'Oracle%Database%';
Before you install the SOA Suite, you must install the ORABPEL, ORAESB, and ORAWSM schemas into the Oracle database (CUSTDBHOST1 and CUSTDBHOST2), according to the following database requirements:
Navigate to the Oracle Application Server Disk1/install/soa_schemas/irca directory.
Execute the irca.bat or irca.sh script.
Within a clustered setup, ESB uses AQ messaging topics for internal communication and asynchronous interaction with external endpoints. These topics are created using the SQL script $ORACLE_HOME/integration/esb/sql/oracle/create_esb_topics.sql. Modify this script to use database compatibility mode of '10.0' and run the script as the ORAESB user to create (or recreate) the AQ topics.
dbms_aqadm.create_queue_table( Queue_table => qtablename, Queue_payload_type => 'SYS.AQ$_JMS_TEXT_MESSAGE', multiple_consumers => true, compatible => '10.0');
The correct compatible value must also be used for user-defined AQ topics that participate in the transaction as well (for example, those connected to AQ adapters or JMS adapters for AQ-JMS)
Verify the compatible value with the below query:
SQL> SELECT QUEUE_TABLE, COMPATIBLE FROM USER_QUEUE_TABLES; QUEUE_TABLE COMPAT ------------------------------ ------ ESB_CONTROL 10.0.0 ESB_ERROR 10.0.0 ESB_ERROR_RETRY 10.0.0 ESB_JAVA_DEFERRED 10.0.0 ESB_MONITOR 10.0.0
The ESB makes use of an internal, database-based Oracle Streams Advanced Queuing (AQ) messaging queue for its asynchronous routing to ESB endpoints. This introduces a performance consideration when load-balancing data sources using DTP services as described above.For AQ in a RAC multi-node environment Oracle recommends setting instance affinity for a particular queue table and restricting all clients to access the queue table on a specified instance. Instance affinity for the queue table ensures that background processing of messages, like propagating messages and implementing timing properties like delay and expiration, run in the primary or failover instance of the queue. The AQ instance affinity and the preferred instances of the DTP services should be consistent. Therefore, the data sources for each SOA Suite node should point to a single DTP service (for example, ORCLSVC1).To implement the configuration that ties SOA Suite data sources and AQ processing to the same RAC node, perform the following steps:
Configure all SOA Suite data sources to use the same DTP service, (for example, ORCLSVC1).
Determine the appropriate RAC instance number for the primary and secondary instance values that correlate to the primary and secondary nodes of the DTP service.
SQL> SELECT INSTANCE_NUMBER,INSTANCE_NAME FROM V$INSTANCE;
Edit the file ESB_HOME/sql/oracle/create_esb_topics.sql file.
Use the following example in which the primary and secondary instance numbers from the previous step are used:
dbms_aqadm.create_queue_table( … ); dbms_aqadm.alter_queue_table( queue_table => qtablename, primary_instance => 1, secondary_instance => 2); dbms_aqadm.create_queue ( … );
Connect to the ORAESB schema and execute the SQL script.
This will recreate the ESB AQ topics and configure them for processing affinity to a specific RAC node.
As an option, you can execute the alter_queue_table without recreating the topics caused by running the script. You can do this by executing the alter_queue_table SQL command directly for each topic listed in the create_esb_topics.sql script.
While performing the listed steps may improve performance, it restricts database processing to one node of the RAC cluster and therefore limits scalability at the data tier.
Oracle recommends taking into consideration the scalability versus performance aspect when designing your deployment topology.
This section describes the requirements for configuration of Oracle SOA Suite components to provide consistency for global transactions (XA) during operation. This configuration also addresses deployment on an Oracle RAC Database 10g. This section also describes the steps to properly configure XA for both RAC and non-RAC environments. The required XA configurations are mostly the same for each environment, with only a few differences related to data source and database configuration for RAC instances.
The scope of this section is specific to Oracle SOA Suite and Oracle Application Server interaction and not the other areas of Oracle SOA Suite enterprise deployment. For more information about enterprise deployment see the Oracle Application Server Enterprise Deployment Guide.
Oracle SOA Suite is certified for XA using a specific set of required patches for Oracle SOA Suite, Oracle Application Server, and JDBC. For XA deployments on an Oracle RAC Database 10g, Oracle SOA Suite is supported against Oracle RAC Database versions 10.2.0.2.x and 11.1.0.6.x (and its supported configurations with Oracle Clusterware).
To find the list of the required patches, go to My Oracle Support (formerly MetaLink) and obtain OracleMetaLink Note 38108.1 “Required Patching for XA Deployments of SOA Suite Using RAC Databases"
My Oracle Support is available at:
BPEL Process Manager, ESB, and other adapters use data source connection pools managed by the OC4J container to connect with respective database schemas. Oracle Web Services Manager uses its own connection pooling mechanism described in Section 2.11.3, "OWSM Database Connections".
The XA configurations described are not RAC specific. With the exception of the RAC database connection string, they are required in either RAC or non-RAC environments.
The configurations apply to the following component connection pools:
BPEL Process Manager (orabpel)
ESB Runtime (esb-rt)
ESB Design-time (esb-dt)
Adapters for:
AQ
JMS Adapter with AQ-JMS
Database
E-Business Suite
The connection pools are defined in the ORACLE_HOME/j2ee/<containername>/config/data-sources.xml file. The BPEL Process Manager and ESBconnection pools are named BPELPM_CONNECTION_POOL, ESBPool, and ESBAQJMSPool. Naming of the adapter connection pools occurs when they are created.
For each connection pool per OC4J container, the following XA configurations are required.
The connection pool should be configured with the XA connection factory class, oracle.jdbc.xa.client.OracleXADataSource, to provide the data source connection with support for distributed transactions. For example,
<connection-factory factory-class="oracle.jdbc.xa.client.OracleXADataSource"
For deployments on RAC, the data source database connection string must be configured to use SERVICE_NAME (for example, ORCLSVC), with the TNSNAMES connection description for RAC.
Note that using SERVICE_NAME in the connection string is critical, and is not the same as SID. See Section 2.3, "Oracle RAC Database" for more details on RAC configuration.
url="jdbc:oracle:thin:@(DESCRIPTION= (ADDRESS_LIST=(LOAD_BALANCE=on) (ADDRESS=(PROTOCOL=tcp)(HOST=infradbhost1-V)(PORT=1521)) (ADDRESS=(PROTOCOL=tcp)(HOST=infradbhost2-V)(PORT=1521))) (CONNECT_DATA=(SERVICE_NAME=ORCLSVC)))"
Oracle SOA Suite uses the OC4J transaction manager within the Oracle Application Server as the transaction coordinator. When unexpected failures occur during transactions that span multiple data sources, it is the OC4J transaction manager that is responsible for proper recovery of transactions that were not complete. The OC4J transaction manager uses its own file-based or database transaction logs to store transaction information. Go to Section 2.11.4, "OC4J Transaction Manager Logging" for more information.
As part of the recovery process for database resources, the recovery manager requires database user credentials with the correct privileges to access the database transaction state information and to issue the appropriate commands (for example, to commit or rollback the resource transaction).
To setup the database user to perform this function:
Create a database user, (for example, xauser), and grant CONNECT and RESOURCE privileges using the following commands:
SQL> CREATE USER xauser IDENTIFIED BY welcome1; … SQL> GRANT CONNECT, RESOURCE TO xauser; …
Grant select privileges on DBA_PENDING_TRANSACTIONS and execute privileges on the SYS.DBMS_SYSTEM package using the following commands:
SQL> GRANT SELECT ON DBA_PENDING_TRANSACTIONS TO xauser; … SQL> GRANT EXECUTE ON SYS.DBMS_SYSTEM TO xauser;
Add the <xa-recovery-config> element inside the connectionfactory element of the connection pool definition to specify the database username and password for the recovery manager.
For example:
<connection-factory …>
<xa-recovery-config>
<password-credential>
<username>xauser</username>
<password>welcome1</password>
</password-credential>
</xa-recovery-config>
…
</connection-factory>
To use password obfuscation for the recovery manager, create an OC4J JAAS (Java Authentication and Authorization Service) user with the username and password that matches the database user credentials.
In the following example, the user is created as part of the jazn.com realm with the username and encrypted password stored in the $ORACLE_HOME/j2ee/<container>/config/system-jazn-data.xml file:
$OH/j2ee/oc4j_soa> java -jar ../home/jazn.jar -shell AbstractLoginModule username: oc4jadmin AbstractLoginModule password: JAZN:> adduser jazn.com xauser welcome1
Note the jazn.jar utility is available within the $ORACLE_HOME/j2ee/home directory, but must be run from the container directory (for example, $ORACLE_HOME/j2ee/oc4j_soa) where the data sources are defined
Once the user is created, update the data source password element with the notation for password indirection. OC4J will now lookup and utilize the encrypted password at runtime.
For example:
<connection-factory …>
<xa-recovery-config>
<password-credential>
<username>xauser</username>
<password>->xauser</password>
</password-credential>
</xa-recovery-config>
…
</connection-factory>
Restart the container for the new settings to take effect. Then repeat these steps for each container and data-sources.xml file. See the OracleAS JAAS Provider Admintool Reference for more information on password obfuscation.
Full documentation for configuring the OC4J Transaction Manager can be found in the Oracle Containers for J2EE Services Guide.
The following connection-pool attributes are recommended settings for all of the connection pools:
<connection-pool name="ESBPool" min-connections="50" initial-limit="0" max-connect-attempts="10" connection-retry-interval="5" max-connections="250">
For more information on connection pool attributes, please see the Oracle Containers for J2EE Services Guide.
Certain adapters utilize user-defined data source connections that must be configured with the same XA recovery and connection pool settings as described in Section 2.11.2.4. These adapters are:
AQ
JMS Adapter with AQ-JMS
Database
E-Business Suite
These adapter endpoints and corresponding data sources are created when you install Oracle SOA Suite as part of either a BPEL Process Manager or ESB deployment that uses adapters. Therefore, these steps are only necessary when such a deployment occurs.
Oracle recommends that you configure the data sources for these adapters in the data sources.xml file.
The data sources can also be configured directly within the adapter configuration file located at $ORACLE_HOME/j2ee/<containername>/application-deployments/default/<adapter>/oc4j-ra.xml.
By configuring the data source within the data-sources.xml file you use the full data source management implementation available in OC4J.
Oracle E-Business Integration Documentation for the Oracle Application Server Adapters for Files, FTP, Databases, and Enterprise Messaging User's Guide contain diagrams depicting where adapters derive their database connection information.
Oracle recommends using separate schemas and data sources for custom application data and AQ messaging topics. Either storing custom application data or creating custom AQ topics in the BPEL Process Manager or ESB schemas can cause performance or even deadlock issues.
After configuring the data source within the data-sources.xml file, edit the Database or AQ adapter oc4j-ra.xml file and set the connector factory configuration property for xADataSourceName property to the data source JNDI name. Additionally, verify that the non-XA dataSourceName property has no value.
The following is an example from the Database Adapter oc4j-ra.xml file:
<connector-factory location="eis/DB/BPELSamples" connector-name="Database Adapter"> <config-property name="xADataSourceName" value="jdbc/BPELSamplesDataSource"/> <config-propertyname="dataSourceName" value=""/> … </connector-factory>
JMS adapters that participate in global transactions must have the Transacted property value set to "false" within the oc4j-ra.xml file definition. This changes the default behavior that allows only one transaction session per JMS operation when the property is set "true". The same connector-factory definition must specify an XA connectionFactoryLocation configuration property with either XAQueueConnectionFactories or XATopicConnectionFactories in the property value.
For example:
<connector-factory location="eis/jms/myQueue" …/> … <config-property name="connectionFactoryLocation" value="java:comp/resource/ojmsdemo/XAQueueConnectionFactories/myQCF"/> <config-property name="isTransacted" value="false"/> … </connector-factory>
Note ojmsdemo from the connectionFactoryLocation property must match the resource provider name defined for the JMS resource in the $ORACLE_HOME/j2ee/<container-name>/config/application.xml.
For more documentation on OJMS and OC4J JMS adapter configuration, see section 5.2.1.6 Configuring for OJMS or 5.2.1.7 Configuring for OC4J JMS of the Oracle Application Server Adapters for Files, FTP, Databases, and Enterprise Messaging User's Guide in the Oracle E-Business Integration Documentation for the Oracle Application Server Adapters.
In addition to the above, JMS adapters operating against AQ-JMS (also called OJMS) within XA transactions also have the following recommended configurations:
Configure separate connector factories within oc4j-ra.xml for inbound and outbound messaging to the same schema.
This requires the creation of two different resource providers (each pointing to its own data source) within $ORACLE_HOME/j2ee/<containername>/config/application.xml.
For more information, see the Oracle Application Server Release Notes 10g Release 3, under JMS adapter in an XA scenario against AQ-JMS (OJMS).
Note this requirement is only necessary for XA configurations.
Data sources for AQ-JMS must be configured with the property txlevel set to global, and the manage-local-transactions property set to false.
Note the tx-level property defaults to global if not explicitly set, but the managelocal- transactions property defaults to true.
<managed-data-source name="AQSAMPLE_DS1" connection-pool-name="AQSAMPLE_POOL1" jndi-name="jdbc/aqSample1" tx-level="global" manage-local-transactions="false" login-timeout="0"/>
This above setting for manage-local-transactions allows the AQ-JMS provider to issue its non-transactional DDL statements (creating durable subscribers) without causing conflicts with global transactions.
Refer to the Oracle Containers for J2EE Services Guide, Managed Data Source Settings for details on these properties.
Configure the BPEL partnerlink or the ESB endpoint for the JMS adapter with a new property called cacheConnections that is set to "false".
Fast Connection Failover (FCF) is a well known RAC specific client feature provided by the JDBC Implicit Connection Cache (ICC), a feature of Oracle 10g JDBC drivers.
Fast Connection Failover is not supported by the JDBC ICC in 10g XA JDBC drivers. FCF only works with non-XA 10g JDBC drivers; thus, FCF configuration is not appropriate for setup.
This section describes how to enable OWSM to use its own database connection pooling mechanism, separate from the OC4J managed data sources for BPEL Process Manager and ESB. The only required configuration for using a RAC database is to modify the database connection strings with the appropriate TNSNAMES descriptor.
The following steps assume OWSM was previously installed with the Oracle Universal Installer.
Edit the $ORACLE_HOME/owsm/bin/coresv.properties file and update the dataload.messagelog.db.url property to use the RAC database connection string.
For example:
jdbc:oracle:thin:@(DESCRIPTION= (ADDRESS_LIST=(LOAD_BALANCE=on) (ADDRESS=(PROTOCOL=tcp)(HOST=infradbhost1-V)(PORT=1521)) (ADDRESS=(PROTOCOL=tcp)(HOST=infradbhost2-V)(PORT=1521))) (CONNECT_DATA=(SERVICE_NAME=ORCLSVC)))
Use the OWSM wsmadmin command line utility in the ORACLE_HOME\owsm\bin\wsmadmin directory to update and redeploy all the OWSM modules.
For example:
> wsmadmin copyDBConfig … > wsmadmin deploy all
Restart the Oracle Application Server container and log into OWSM.
Go to Policy Management and update the cfluent.messagelog.db.url component property with the same database connection string.
Refer to the Oracle Web Services Manager Deployment Guide for more information and descriptions of the wsmadmin commands
The OC4J transaction manager requires logging to maintain information regarding the state of transactions. The logging type can be configured for database or filed based persistence using the $ORACLE_HOME/j2ee/<containername>/config/transaction-manager.xml file.
Perform one of the following types of logging:
Configure the transaction logging for file-based persistence.
In this setup, the file-system should be on shared-disk storage to maintain availability of the transaction logs if the Oracle Application Server node fails. The default file based log location is the local file system ($ORACLE_HOME/j2ee/home/persistence/txlogs), use the location attribute to specify the shared-disk directory location.
<commit-coordinator retry-count="4">
<middle-tier>
<log type="file" location="/net/server1/txlogs" />
<recovery retry-interval = "30"/>
</middle-tier>
</commit-coordinator>
Note the transaction manager automatically creates a specific subdirectory for each OC4J container configured with this directory location.
As an alternative, complete the following steps for each OC4J container that is installed with BPEL Process Manager or ESB in order to use database-persisted transaction logging:
Create a native data source connection within the container data-source.xml file.
<native-data-source name="xaLogging"jndi-name="jdbc/xaLogging" data-source-class="oracle.jdbc.pool.OracleDataSource" url="jdbc:oracle:thin:@host:1521:orcl" />
Edit the transaction-manager.xml file to enable database-persisted transaction logging (for simplicity, consider using the same database user configured for the XA recovery manager).
<commit-coordinator retry-count="4">
<middle-tier>
<log type="database" location="jdbc/xaLogging">
<identity user="xauser" password="welcome1"/>
<database-logging-performance …/>
</log>
</middle-tier>
</commit-coordinator>
Log into the database and execute the SQL script at $ORACLE_HOME/j2ee/home/database/j2ee/jta/oracle/2pc_jdbcstore.sql to create the transaction manager schema.
See Database Store Attributes within the OC4J Transaction Support documentation for more information.
To obfuscate the password, follow the steps described earlier in this section and utilize the same notation for password indirection.
<commit-coordinator retry-count="4">
<middle-tier>
<log type="database" location="jdbc/xaLogging">
<identity user="xauser" password="->xauser"/>
<database-logging-performance …/>
</log>
</middle-tier>
</commit-coordinator>
Once the transaction manager persistence is configured as above and the container is restarted, the data sources defined in data-sources.xml will have a new attribute, commit-record-table-name. By default, the attribute value is an empty string.
This attribute is part of an optional configuration to enable Recoverable Last Resource Commit (RLRC), another feature of the OC4J transaction manager. It is safe to remove the attribute or leave the value empty if not using this feature. RLRC is related to the Last Resource Commit feature of OC4J transaction manager that allows for optimizing performance of global transactions with 1 non-XA database resource. To learn more about LRC and RLRC, see Oracle Containers for J2EE Services Guide 10g, Last Resource Commit and Oracle Application Server Release Notes 10g Release 3 (10.1.3.2), Support for Recoverable Last ResourceCommit.
Full documentation for configuring the OC4J Transaction Manager can be found in the Oracle Containers for J2EE Services Guide.
The JDBC related patches for this XA setup are first applied to the Oracle Database.
To find the list of the required patches, go to My Oracle Support (formerly MetaLink) and obtain OracleMetaLink Note 738108.1 for JDBC patch information.
My Oracle Support is available at:
Follow the patch README instructions to apply.The next step is to copy the updated JDBC files to the application server. Copy the Database ORACLE_HOME/jdbc/lib/* files to the Application Server ORACLE_HOME/jdbc/lib/ directory. Do this for each Application Server instance.
|
 Copyright © 2004, 2009, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|