Skip Headers
Oracle® Fusion Middleware Enterprise Deployment Guide for Oracle SOA Suite
11g Release 1 (11.1.1)

Part Number E12036-10
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Index
Index
Go to Master Index
Master Index
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
PDF · Mobi · ePub

10 Extending the Domain to Include Oracle BPM

This chapter describes the procedures for extending the domain to include Oracle BPM.

This chapter contains the following section:

10.1 Overview of Extending the Domain to include Oracle BPM

You can install and configure Oracle BPM in a Fusion Middleware installation in the following two ways:

Table 10-1 Steps for Extending tan existing Domain to include SOA and BPM

Step Description More Information

Enabling VIP2 on SOAHOST1 and VIP3 on SOAHOST2

Enable a virtual IP mapping for each of the hostnames.

Section 10.2.1, "Enabling VIP2 on SOAHOST1 and VIP3 on SOAHOST2"

Run the Configuration Wizard to Extend the Domain

Run the Configuration Wizard from the SOA home directory to extend a domain containing an Administration Server and Oracle Web Services Manager to support SOA and BPM components.

Section 10.2.2, "Running the Configuration Wizard on SOAHOST1 to Extend the Current Domain"

Configure Oracle Coherence for Deploying Composites

Configure Oracle Coherence in order to use unicast communication for deploying composites.

Section 10.2.4, "Configuring Oracle Coherence for Deploying Composites"

Setting Connection Destination Identifiers for B2B Queues

Set the Create Destination Identifier (CDI) for JMS Destination Member calls.

Section 10.2.5, "Setting Connection Destination Identifiers for B2B Queues"

Disabling Host Name Verification for the WLS_SOAn Managed Servers

Set up the appropriate certificates to authenticate the different nodes with the Administration Server after you have completed the procedures to extend the domain for Oracle BPM.

Section 10.2.6, "Disabling Host Name Verification for the WLS_SOAn Managed Servers"

Propagate the Domain Changes to the Managed Server Domain Directory

Propagate the start scripts and classpath configuration from the Administration Server's domain directory to the managed server domain directory.

Section 10.2.7, "Propagating the Domain Changes to the Managed Server Domain Directory"

Start and Validate the WLS_SOA1 Managed Server

Start and validate the WLS_SOA1 managed server using the Oracle WebLogic Server Administration Console.

Section 10.2.8, "Starting and Validating the WLS_SOA1 Managed Server"

Propagate the Domain Configuration to SOAHOST2

Propagate the Domain Configuration to SOAHOST2 Using the Unpack Utility.

Section 10.2.9, "Propagating the Domain Configuration to SOAHOST2 Using the Unpack Utility"

Extract the XEngine Files in SOAHOST2

To enable B2B's XEngine in SOAHOST2, extract the content of the XEngine tar manually.

Section 10.2.10, "Extracting the XEngine Files in SOAHOST2"

Start and Validate the WLS_SOA2 Managed Server

Start the WLS_SOA2 managed server and check that it is configured correctly.

Section 10.2.11, "Starting and Validating the WLS_SOA2 Managed Server"

Configure the Oracle HTTP Server for WLS_SOAn Managed Servers

Enable Oracle HTTP Server to route to the SOA_Cluster.

Section 10.2.12, "Configuring Oracle HTTP Server for WLS_SOAn Managed Servers"

Validating Access Through Oracle HTTP Server

Verify that the server status is reported as Running.

Section 10.2.13, "Validating Access Through Oracle HTTP Server"

Setting the Frontend HTTP Host and Port

Set the frontend HTTP host and port for the Oracle WebLogic Server cluster.

Section 10.2.14, "Setting the Frontend HTTP Host and Port"

Configure a Default Persistence Store for Transaction Recovery

To leverage the migration capability of the Transaction Recovery Service for the servers within a cluster, store the transaction log in a location accessible to a server and its backup servers.

Section 10.2.15, "Configuring a Default Persistence Store for Transaction Recovery"

Enable High Availability for Oracle File and FTP Adapters

Make Oracle File and FTP Adapters highly available for outbound operations using the database mutex locking operation.

Section 10.2.16, "Enabling High Availability for Oracle File and FTP Adapters"


Table 10-2 Steps for Extending an Existing Domain that Already includes SOA

Step Description More Information

Run the Configuration Wizard on SOAHOST1 to Extend a SOA Domain to Include BPM

Run the Configuration Wizard from the SOA home directory to extend a domain containing an Administration Server and Oracle Web Services Manager to support SOA and BPM components.

Section 10.3.1, "Running the Configuration Wizard on SOAHOST1 to Extend a SOA Domain to Include BPM"

Propagate the Domain Configuration to the managed server directory in SOAHOST1 and to SOAHOST2

Oracle BPM Suite requires some updates to the WebLogic Server start scripts. Propagate these changes using the pack and unpack commands.

Section 10.3.2, "Propagating the Domain Configuration to the managed server directory in SOAHOST1 and to SOAHOST2"

Start the BPM Suite Components

For configuration changes and start scripts to be effective, restart the WLS_SOAn server to which BPM has been added.

Section 10.3.3, "Starting the BPM Suite Components"

Configure Oracle HTTP Server for the WLS_SOAn Managed Servers

Enable Oracle HTTP Server to route to BPM web applications by setting the WebLogicCluster parameter to the list of nodes in the cluster.

Section 10.3.4, "Configuring Oracle HTTP Server for the WLS_SOAn Managed Servers"

Validating Access Through Oracle HTTP Server

Verify URLs to ensure that appropriate routing and failover is working from the HTTP Server to the BPM Suite Components.

Section 10.3.5, "Validating Access Through Oracle HTTP Server"


Prerequisites for Extending the Domain to Include Oracle BPM

Before extending the current domain, ensure that your existing deployment meets the following prerequisites:

10.2 Option 1: Extending a Domain to Include SOA and BPM

This section describes how to extend a domain with SOA and BPM components using the Configuration Wizard. You can extend the resulting domain to add BPM. It is assumed that a SOA ORACLE_HOME (binaries) has already been installed, patched to latest patch set if applicable, and is available from SOAHOST1 and SOAHOST2. it is also assumed that a domain with an Administration Server has been created. This is the domain that is extended in this chapter to support SOA components.

Note:

Oracle strongly recommends reading the release notes for any additional installation and deployment considerations prior to starting the setup process.

This section contains the following topics:

10.2.1 Enabling VIP2 on SOAHOST1 and VIP3 on SOAHOST2

Associate the WLS_SOA1 Server and WLS_SOA2 with virtual hostnames (SOAHOST1VHN1 and SOAHOST2VHN1). Check that these virtual hostnames are enabled by DNS or /etc/hosts resolution in your system and that they map to the appropriate virtual IPs (VIP2 and VIP3). These procedures are required for server migration.

To enable the virtual IP on Linux:

  1. Run the ifconfig command as root:

    /sbin/ifconfig <interface:index> IPAddress netmask netmask
    /sbin/arping -q -U -c 3 -I interface IPAddress
    

    For example:

    /sbin/ifconfig ethX:Y 100.200.140.206 netmask 255.255.255.0
    
  2. Enable your network to register the new location of the virtual IP, for example:

    /sbin/arping -q -U -c 3 -I ethX 100.200.140.206
    
  3. Validate that the address is available by pinging it from another node, for example

    /bin/ping 100.200.140.206
    

    In this example ethX is the ethernet interface (eth0 or eth1) and Y is the index (0, 1, 2).

10.2.2 Running the Configuration Wizard on SOAHOST1 to Extend the Current Domain

Run the Configuration Wizard from the SOA home directory to extend a domain containing an Administration Server and Oracle Web Services Manager to support SOA and BPM components.

To extend the domain for Oracle BPM:

  1. Ensure that the database where you installed the repository is running. For Oracle RAC databases, Oracle recommends all instances remain running, so that the validation check later in the process is more reliable.

  2. Change the directory to the location of the Configuration Wizard. This is within the SOA home directory.

    cd ORACLE_COMMON_HOME/common/bin
    
  3. Start the Oracle Fusion Middleware Configuration Wizard:

    ./config.sh
    
  4. In the Welcome screen, select Extend an Existing WebLogic Domain, and click Next.

  5. In the WebLogic Domain Directory screen, select the WebLogic domain directory ORACLE_BASE/admin/domain_name/aserver/domain_name, and click Next.

  6. In the Select Extension Source screen, do the following:

    • Select Extend my domain automatically to support the following added products. Select the following products:

    • Select the following products:

      • Oracle BPM Suite - 11.1.1.0 [soa]

      • Oracle SOA Suite - 11.1.1.0 [soa] (this should be selected automatically when selecting Oracle BPM Suite)

      • Oracle WSM Policy Manager 11.1.1.0 [oracle_common] (this should be selected automatically when selecting Oracle BPM Suite)

      • Oracle Enterprise Manager - 11.1.1.0 [oracle_common]

      • Oracle JRF - 11.1.1.0 [oracle_common] (this should be selected automatically and grayed out)

      If you accidentally deselect some of the targets, make sure the following are selected:

      • Oracle SOA

      • Oracle BPM Suite

      Click Next.

  7. In the Configure JDBC Components Schema screen, do the following:

    • Select the SOA Infrastructure, User Messaging Service, and SOA MDS Schema.

    • For the Oracle RAC configuration for component schemas, select Convert to GridLink.

    Click Next.

  8. The Configure Gridlink RAC Component Schema screen appears (Figure 10-1).

    Figure 10-1 Configure GridLink RAC Component Schema Screen

    Configure RAC Multi Data Source Component Schema screen

    In this screen enter values for the following fields, specifying the connect information for the Oracle RAC database that was seeded with RCU:

    • Driver: Select Oracle's driver (Thin) for GridLinkConnections,Versions:10 and later.

    • Service Name: Enter the service name of the database using lowercase characters. For example:

      soaedg.mycompany.com

    • Username: Enter the database schema owner name of the corresponding component. The user names shown in (replace table reference) assume that soedg was used as prefix for schema creation from RCU.

    • Password: Enter the password for the database schema owner.

    • Select Enable FAN

    • Make sure Enable SSL is unchecked (alternatively if ssl is selected for ONS notifications to be encrypted, provide the appropriate wallet and wallet password).

    • Service listener: Enter the SCAN address and port for the RAC database being used. You can identify this address by querying the appropriate parameter in the database using the TCP protocol:

      SQL>show parameter remote_listener;
      
      NAME              TYPE                VALUE
      -------------------------------------------------------------
      remote_listener   string    db-scan.mycompany.com:1521
      

      Note:

      For Oracle Database 11g Release 1 (11.1), use the virtual IP and port of each database instance listener, for example:

      custdbhost1-vip.mycompany.com (port 1521)
      

      and

      custdbhost2-vip.mycompany.com (1521)
      

      For Oracle Database 10g, use multi data sources to connect to an Oracle RAC database. For information about configuring multi data sources see Appendix A, "Using Multi Data Sources with Oracle RAC."

    • ONS Host: Enter the SCAN address for the Oracle RAC database and the ONS remote port as reported by the database:

      [orcl@db-scan1 ~]$ srvctl config nodeapps -s
       
      ONS exists: Local port 6100, remote port 6200, EM port 2016 
      

      Note:

      For Oracle Database 11g Release 1 (11.1), use the hostname and port of each database's ONS service, for example

      custdbhost1.mycompany.com (port 6200)
      

      and

      custdbhost2.mycompany.com (6200)
      
  9. In the Test JDBC Data Sources screen, the connections should be tested automatically. The Status column displays the results. Ensure that all connections were successful. If not, click Previous to return to the previous screen and correct your entries.

    Click Next when all the connections are successful.

  10. In the Optional Configuration screen, select the following:

    • JMS Distributed Destinations

    • Managed Servers, Clusters, and Machines

    • Deployments and Services

    Click Next.

  11. In the Select JMS Distributed Destination Type screen, Select UDD from the drop-down list for all Fusion Middleware Components' JMS Modules.

    Note:

    Oracle does not support using WDDs for Fusion Middleware components

  12. In the Configure Managed Servers screen, add the required managed servers.

    A server named soa_server1 is created automatically. Rename this to WLS_SOA1 and add a new server named WLS_SOA2. Give these servers the attributes listed in Table 10-3. Do not modify the other servers that appear in this screen; leave them as they are.

    Table 10-3 Managed Servers

    Name Listen Address Listen Port SSL Listen Port SSL Enabled

    WLS_SOA1

    SOAHOST1VHN1

    8001

    n/a

    No

    WLS_SOA2

    SOAHOST2VHN1

    8001

    n/a

    No


    Click Next.

  13. In the Configure Clusters screen, add the cluster listed in Table 10-4. Do not modify the other clusters that display in this screen; leave them as they are.

    Table 10-4 Cluster

    Name Cluster Messaging Mode Multicast Address Multicast Port Cluster Address

    SOA_Cluster

    unicast

    n/a

    n/a

    SOAHOST1VHN1:8001,SOAHOST2VHN1:8001


    Click Next.

  14. In the Assign Servers to Clusters screen, assign servers to clusters as follows:

    • SOA_Cluster:

      • WLS_SOA1

      • WLS_SOA2

    Click Next.

  15. In the Configure Machines screen, do the following:

    • Click Delete to remove the default LocalMachine.

    • Click the Unix Machine tab. SOAHOST1 and SOAHOST2 machines appear with the following entries Table 10-5):

      Table 10-5 Machines

      Name Node Manager Listen Address

      SOAHOST1

      SOAHOST1

      SOAHOST2

      SOAHOST2

      ADMINHOST

      localhost


    Leave all other fields to their default values.

    Click Next.

  16. In the Assign Servers to Machines screen, assign the servers to machines according to the following table:

    Table 10-6 Assigning Servers to Machines

    Server Machine

    AdminServer

    ADMINHOST

    WLS_SOA1

    SOAHOST1

    WLS_SOA2

    SOAHOST2

    WLS_WSM1

    SOAHOST1

    WLS_WSM2

    SOAHOST2


    Click Next.

  17. In the Target Deployments to Clusters or Servers screen, ensure the following targets:

    • Target WSM-PM only to WSM-PM_Cluster.

    • Target the oracle.sdp.*, oracle.BPM.*, and oracle.soa.* deployments only to SOA_Cluster.

    • The oracle.rules.* library should be targeted only to Admin Server and SOA_Cluster.

    Click Next.

  18. In the Target Services to Clusters or Servers screen, target the mds-owsm, mdw-owsm-rac0 and mds-owsm-rac1 datasources to the WSM-PM_Cluster and the AdminServer and Click Next.

  19. In the Configure JMS File Stores screen, enter the shared directory location specified for your JMS stores as recommended in Section 4.3, "About Recommended Locations for the Different Directories." For example:

    ORACLE_BASE/admin/domain_name/soa_cluster_name/jms
    

    Select Direct-write policy for all stores.

    Click Next.

  20. In the Configuration Summary screen click Extend.

  21. In the Creating Domain screen, click Done.

    You must restart the Administration Server for this configuration to take effect. to restart the Administration Server, use the procedure in Section 8.4.3, "Starting the Administration Server on SOAHOST1."

10.2.3 Validating GridLink Data Sources

When the servers are started, verify that the GridLink data sources are correctly configured and that the ONS setup is correct. Perform this procedure for every GridLink data source created.

To validate the GridLink data sources configuration:

  1. Log on to the Oracle WebLogic Administration Console.

  2. In the Domain Structure tree, expand Services, and select Data Sources.

  3. Click one of the new data sources.

  4. Click the Monitoring tab and select one of the servers.

  5. Click the Statistics tab and select one of the servers.

  6. Click the ONS tab, and then click the Testing tab.

  7. Select the server and click Test ONS.

    If both tests are successful, the configuration is correct. If the ONS test fails, verify that the ONS service is running in the RAC database nodes:

    orcl@db-scan1 ~]$ srvctl status scan_listener
    SCAN Listener LISTENER_SCAN1 is enabled
    SCAN listener LISTENER_SCAN1 is running on node db-scan1
    SCAN Listener LISTENER_SCAN2 is enabled
    SCAN listener LISTENER_SCAN2 is running on node db-scan2
    SCAN Listener LISTENER_SCAN3 is enabled
    SCAN listener LISTENER_SCAN3 is running on node db-scan2
     
    [orcl@db-scan1 ~]$ srvctl config nodeapps -s 
    ONS exists: Local port 6100, remote port 6200, EM port 2016
     
    [orcl@db-scan1 ~]$ srvctl status nodeapps | grep ONS
    ONS is enabled
    ONS daemon is running on node: db-scan1
    ONS daemon is running on node: db-scan2
    

Run the ONS test from every WebLogic server that uses the data source.

10.2.4 Configuring Oracle Coherence for Deploying Composites

Although deploying composites uses multicast communication by default, Oracle recommends using unicast communication in SOA enterprise deployments. Use unicast if you disable multicast communication for security reasons.

Unicast communication does not enable nodes to discover other cluster members in this way. Consequently, you must specify the nodes that belong to the cluster. You do not need to specify all of the nodes of a cluster, however. You need only specify enough nodes so that a new node added to the cluster can discover one of the existing nodes. As a result, when a new node has joined the cluster, it is able to discover all of the other nodes in the cluster. Additionally, in configurations such as SOA enterprise deployments where multiple IPs are available in the same system, you must configure Oracle Coherence to use a specific host name to create the Oracle Coherence cluster.

Note:

An incorrect configuration of the Oracle Coherence framework used for deployment may prevent the SOA system from starting. The deployment framework must be properly customized for the network environment on which the SOA system runs. Oracle recommends the configuration described in this section.

10.2.4.1 Enabling Communication for Deployment Using Unicast Communication

Specify the nodes using the tangosol.coherence.wka<n> system property, where <n> is a number between 1 and 9. You can specify up to 9 nodes. Start the numbering at 1. This numbering must be sequential and must not contain gaps. In addition, specify the host name used by Oracle Coherence to create a cluster through the tangosol.coherence.localhost system property. This local host name should be the virtual host name used by the SOA server as the listener addresses (SOAHOST1VHN1 and SOAHOST2VHN1). Set this property by adding the -Dtangosol.coherence.localhost parameters to the Arguments field of the Oracle WebLogic Server Administration Console's Server Start tab (Figure 10-2).

Tip:

To guarantee high availability during deployments of SOA composites, specify enough nodes so that at least one of them is running at any given time.

Note:

SOAHOST1VHN1 is the virtual host name that maps to the virtual IP where WLS_SOA1 listening (in SOAHOST1). SOAHOST2VHN1 is the virtual host name that maps to the virtual IP where WLS_SOA2 is listening (in SOAHOST2).

Figure 10-2 Setting the Host Name Using the Start Server Tab of Oracle WebLogic Server Administration Console

Description of Figure 10-2 follows
Description of "Figure 10-2 Setting the Host Name Using the Start Server Tab of Oracle WebLogic Server Administration Console"

10.2.4.2 Specifying the Host Name Used by Oracle Coherence

Use the Administration Console to specify a host name used by Oracle Coherence.

To add the host name used by Oracle Coherence:

  1. Log into the Oracle WebLogic Server Administration Console.

  2. In the Domain Structure window, expand the Environment node.

  3. Click Servers. The Summary of Servers page appears.

  4. Click the name of the server (WLS_SOA1 or WLS_SOA2, which are represented as hyperlinks) in Name column of the table. The settings page for the selected server appears.

  5. Click Lock & Edit.

  6. Click the Server Start tab (illustrated in Figure 10-2).

  7. Enter the following for WLS_SOA1 and WLS_SOA2 into the Arguments field.

    Note:

    There should be no breaks in lines between the different -D parameters. Do not copy or paste the text to your Administration Console's arguments text field. It may result in HTML tags being inserted in the Java arguments. The text should not contain other text characters than those included the example above.

    Note:

    The Coherence cluster used for deployment uses port 8088 by default. This port can be changed by specifying a different port (for example, 8089) with the -Dtangosol.coherence.wkan.port and -Dtangosol.coherence.localport startup parameters. For example:

    WLS_SOA1 (enter the following into the Arguments field on a single line, without a carriage return):

    -Dtangosol.coherence.wka1=SOAHOST1VHN1
    -Dtangosol.coherence.wka2=SOAHOST2VHN1
    -Dtangosol.coherence.localhost=SOAHOST1VHN1
    -Dtangosol.coherence.localport=8089
    -Dtangosol.coherence.wka1.port=8089
    -Dtangosol.coherence.wka2.port=8089
    

    WLS_SOA2 (enter the following into the Arguments field on a single line, without a carriage return):

    -Dtangosol.coherence.wka1=SOAHOST1VHN1
    -Dtangosol.coherence.wka2=SOAHOST2VHN1
    -Dtangosol.coherence.localhost=SOAHOST1VHN1
    -Dtangosol.coherence.localport=8089
    -Dtangosol.coherence.wka1.port=8089
    -Dtangosol.coherence.wka2.port=8089
    

    For more information about Coherence Clusters see the Oracle Coherence Developer's Guide.

    For WLS_SOA1, enter the following:

    -Dtangosol.coherence.wka1=SOAHOST1VHN1
    -Dtangosol.coherence.wka2=SOAHOST2VHN1
    -Dtangosol.coherence.localhost=SOAHOST1VHN1
    

    For WLS_SOA2, enter the following:

    -Dtangosol.coherence.wka1=SOAHOST1VHN1
    -Dtangosol.coherence.wka2=SOAHOST2VHN1
    -Dtangosol.coherence.localhost=SOAHOST2VHN1
    
  8. Click Save and Activate Changes.

Note:

You must ensure that these variables are passed to the managed server correctly. (They should be reflected in the server's output log.) Failure of the Oracle Coherence framework can prevent the soa-infra application from starting.

Note:

The multicast and unicast addresses are different from the ones used by the WebLogic Server cluster for cluster communication. SOA guarantees that composites are deployed to members of a single WebLogic Server cluster even though the communication protocol for the two entities (the WebLogic Server cluster and the groups to which composites are deployed) are different.

10.2.5 Setting Connection Destination Identifiers for B2B Queues

Oracle B2B uses specific JMS Destination Member calls, and requires setting the Create Destination Identifier (CDI) for these calls to succeed. To set up the CDI:

  1. Log into the Oracle WebLogic Server Administration Console.

  2. In the Domain Structure window, expand the Services node, and then the Messaging node.

  3. Click JMS Modules, and then SOAJMSModule.

  4. Click Lock & Edit.

  5. Click the dist_B2BEventQueue_auto, Configuration, and the General tab, and then click Advanced.

  6. In the Create Destination Identifier field, add the following jndi name for the queue:

    jms/b2b/B2BEventQueue

  7. Repeat these steps, creating the following Create Destination Identifiers for the queues listed below:

    • B2B_OUT_QUEUE: jms/b2b/B2B_IN_QUEUE

    • B2B_IN_QUEUE: jms/b2b/B2B_OUT_QUEUE

    • B2BBroadcastTopic: jms/b2b/B2BBroadcastTopic

    • XmlSchemaChangeNotificationTopic: jms/fabric/XmlSchemaChangeNotificationTopic

  8. Click Save and Active Changes.

10.2.6 Disabling Host Name Verification for the WLS_SOAn Managed Servers

For the enterprise deployment described in this guide, you set up the appropriate certificates to authenticate the different nodes with the Administration Server after you have completed the procedures to extend the domain for Oracle BPM. Therefore, you must disable the host name verification for the WLS_SOAn managed server to avoid errors when managing the different WebLogic Servers. You enable host name verification again once the Enterprise Deployment topology configuration is complete. See Section 13.3, "Enabling Host Name Verification Certificates for Node Manager in SOAHOST1" for more information.

To disable host name verification:

  1. Log in to Oracle WebLogic Server Administration Console.

  2. Click Lock & Edit.

  3. Expand the Environment node in the Domain Structure window.

  4. Click Servers.

    The Summary of Servers page appears.

  5. Select WLS_SOA1 (represented as a hyperlink) from the Names column of the table.

    The Settings page appears.

  6. Select the SSL tab.

  7. Expand the Advanced section of the page.

  8. Set Hostname Verification to None.

  9. Click Save.

  10. Repeat Steps 4 through 8 for the WLS_SOA2 server.

  11. Save and activate the changes.

  12. This change requires a restart of the Administration Server and Node Managers.

    1. To restart the Administration Server see Section 8.4.3, "Starting the Administration Server on SOAHOST1.".

    2. To restart Node Manager on SOAHOST1see Section 9.5.2, "Restarting the Node Manager on SOAHOST1."

      Repeat for Node Manager in SOAHOST2

10.2.7 Propagating the Domain Changes to the Managed Server Domain Directory

Propagate the start scripts and classpath configuration from the Administration Server's domain directory to the managed server domain directory.

To propagate start scripts and classpath configuration:

  1. Create a copy of the managed server domain directory and the managed server applications directory.

  2. Run the pack command on SOAHOST1 to create a template pack:

    cd ORACLE_COMMON_HOME/common/bin
    
    ./pack.sh -managed=true -domain=ORACLE_BASE/admin/
    domain_name/aserver/domain_name -template=soadomaintemplateExtSOABPM.jar
     -template_name=soa_domain_templateExtSOABPM
    
  3. Run the unpack command on SOAHOST1 to unpack the propagated template to the domain directory of the managed server:

    ./unpack.sh -domain=ORACLE_BASE/admin/
    domain_name/mserver/domain_name -overwrite_domain=true
    -template=soadomaintemplateExtSOABPM.jar 
    -app_dir=ORACLE_BASE/admin/domain_name/mserver/applications
    

    Note:

    The -overwrite_domain option in the unpack command, allows unpacking a managed server template into an existing domain and existing applications directories. For any file that is overwritten, a backup copy of the original is created. If any modifications had been applied to the start scripts and ear files in the managed server domain directory they must be restored after this unpack operation.

Note:

The configuration steps provided in this enterprise deployment topology are documented with the assumption that a local (per node) domain directory is used for each managed server.

10.2.8 Starting and Validating the WLS_SOA1 Managed Server

Start and validate the WLS_SOA1 managed server using the Oracle WebLogic Server Administration Console.

To start the WLS_SOA1 managed server and check that it is configured correctly:

  1. Start the WLS_SOA1 managed server using the Oracle WebLogic Server Administration Console as follows:

    1. Expand the Environment node in the Domain Structure window.

    2. Choose Servers.

      The Summary of Servers screen appears.

    3. Click the Control tab.

    4. Select WLS_SOA1, then click Start.

  2. Verify that the server status is reported as Running. If the server is shown as Starting or Resuming, wait for the server status to change to Started. If another status is reported, such as Admin or Failed, check the server output log files for errors. See Chapter 16, "Troubleshooting the Topology in an Enterprise Deployment" for possible causes.

  3. Access the following URLs:

    http://SOAHOST1VHN1:8001/soa-infra/ to verify status of WLS_SOA1.

    http://SOAHOST1VHN1:8001/soa/composer/ to verify status of SOA process composer.

    http://SOAHOST1VHN1:8001/integration/worklistapp/ to verify status of the worklist application.

    http://SOAHOST1VHN1:8001/b2bconsole/ to verify status of B2B.

    http://SOAHOST1VHN1:8001/sdpmessaging/userprefs-ui/ to verify status of messaging system preferences

    http://SOAHOST1VHN1:8001/BPM/composer/ and login to the composer application.

    http://SOAHOST1VHN1:8001/BPM/workspace/ and login to the workspace application.

10.2.9 Propagating the Domain Configuration to SOAHOST2 Using the Unpack Utility

To propagate the domain configuration to SOAHOST2:

  1. Run the following command on SOAHOST1 to copy the template file created in the previous step to SOAHOST2.

    cd ORACLE_COMMON_HOME/common/bin
    
    scp soadomaintemplateExtSOABPM.jar oracle@node2:ORACLE_COMMON_HOME/common/bin
    
  2. Run the unpack command on SOAHOST2 to unpack the propagated template:

    cd ORACLE_COMMON_HOME/common/bin
    
    ./unpack.sh -domain=ORACLE_BASE/admin/domain_name/mserver/domain_name 
    -overwrite_domain=true -template=soadomaintemplateExtSOABPM.jar 
    -app_dir=ORACLE_BASE/admin/domain_name/mserver/applications
    

    Note:

    The -overwrite_domain option in the unpack command, allows unpacking a managed server template into an existing domain and existing applications directories. For any file that is overwritten, a backup copy of the original is created. If any modifications had been applied to the start scripts and ear files in the managed server domain directory they must be restored after this unpack operation.

    Note:

    The configuration steps provided in this enterprise deployment topology are documented with the assumption that a local (per node) domain directory is used for each managed server.

10.2.10 Extracting the XEngine Files in SOAHOST2

To enable B2B's XEngine in SOAHOST2, you need to extract the content of the XEngine tar manually:

cd ORACLE_HOME/soa/thirdparty/edifecs
tar -xzvf XEngine.tar.gz

10.2.11 Starting and Validating the WLS_SOA2 Managed Server

To start the WLS_SOA2 managed server and check that it is configured correctly:

  1. Start the WLS_SOA2 managed server using the Oracle WebLogic Server Administration Console as follows:

    1. Expand the Environment node in the Domain Structure window.

    2. Choose Servers.

      The Summary of Servers screen appears.

    3. Click the Control tab.

    4. Select WLS_SOA2 and then click Start.

  2. Verify that the server status is reported as Running. If the server is shown as Starting or Resuming, wait for the server status to change to Started. If another status is reported, such as Admin or Failed, check the server output log files for errors. See Chapter 16, "Troubleshooting the Topology in an Enterprise Deployment" for possible causes.

  3. Access the following URLs:

    http://SOAHOST2VHN1:8001/soa-infra to verify status of WLS_SOA2.

    http://SOAHOST2VHN1:8001/soa/composer to verify status of soa process composer.

    Note:

    The configuration is incorrect if no policies or assertion templates appear.

    http://SOAHOST2VHN1:8001/integration/worklistapp to verify status of the worklist application.

    http://SOAHOST2VHN1:8001/b2bconsole to verify status of B2B.

    http://SOAHOST2VHN1:8001/sdpmessaging/userprefs-ui to verify status of messaging system preferences

    http://SOAHOST2VHN1:8001/BPM/composer and login to the composer application.

    http://SOAHOST2VHN1:8001/BPM/workspace and login to the workspace application.

10.2.12 Configuring Oracle HTTP Server for WLS_SOAn Managed Servers

To enable Oracle HTTP Server to route to the SOA_Cluster, which contains the WLS_SOAn managed servers, set the WebLogicCluster parameter to the list of nodes in the cluster.

To enable Oracle HTTP Server to route to the SOA_Cluster:

  1. On WEBHOST1 and WEBHOST2, add directives to the soa.vh.conf file located in the following directory:

    ORACLE_BASE/admin/instance_name/config/OHS/component_name/moduleconf
    

    Note that this assumes you created the soa_vh.conf file using the instructions in Section 7.6, "Defining Virtual Hosts."

    Add the following directives inside the <VirtualHost> tags:

    # BPM
    <Location /BPM/composer>
        SetHandler weblogic-handler
        WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
        WLProxySSL ON
        WLProxySSLPassThrough ON
    </Location>
    
    # BPM
    <Location /BPM/workspace>
        SetHandler weblogic-handler
        WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
        WLProxySSL ON
        WLProxySSLPassThrough ON
    </Location>
    

    The soa_vh.conf file will appear as it does in Example 10-1.

  2. Restart Oracle HTTP Server on WEBHOST1 and WEBHOST2:

    WEBHOST1> ORACLE_BASE/admin/instance_name/bin/opmnctl restartproc ias-component=ohs1
    WEBHOST2> ORACLE_BASE/admin/instance_name/bin/opmnctl restartproc ias-component=ohs2
    

Example 10-1 soa_vh.conf file

<VirtualHost *:7777>
    ServerName https://soa.mycompany.com:443
    ServerAdmin you@your.address
    RewriteEngine On
    RewriteOptions inherit

<Location /soa-infra>
    SetHandler weblogic-handler
    WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
    WLProxySSL ON
    WLProxySSLPassThrough ON
</Location>

# SOA inspection.wsil
<Location /inspection.wsil>
    SetHandler weblogic-handler
    WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
    WLProxySSL ON
    WLProxySSLPassThrough ON
</Location>

# Worklist
<Location /integration>
    SetHandler weblogic-handler
    WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
    WLProxySSL ON
    WLProxySSLPassThrough ON
</Location>

# B2B
<Location /b2bconsole>
    SetHandler weblogic-handler
    WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
    WLProxySSL ON
    WLProxySSLPassThrough ON
</Location>

# UMS prefs
<Location /sdpmessaging/userprefs-ui>
    SetHandler weblogic-handler
    WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
    WLProxySSL ON
    WLProxySSLPassThrough ON
</Location>

# Default to-do taskflow
<Location /DefaultToDoTaskFlow>
    SetHandler weblogic-handler
    WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
    WLProxySSL ON
    WLProxySSLPassThrough ON
</Location>

# Workflow
<Location /workflow>
    SetHandler weblogic-handler
    WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
    WLProxySSL ON
    WLProxySSLPassThrough ON
</Location>

#Required if attachments are added for workflow tasks
 <Location /ADFAttachmentHelper> 
    SetHandler weblogic-handler 
    WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001 
    WLProxySSL ON
    WLProxySSLPassThrough ON
</Location>

# SOA composer application 
 <Location /soa/composer> 
     SetHandler weblogic-handler 
     WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001 
    WLProxySSL ON
    WLProxySSLPassThrough ON
</Location>

# BPM
<Location /BPM/composer>
    SetHandler weblogic-handler
    WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
    WLProxySSL ON
    WLProxySSLPassThrough ON
</Location>

# BPM
<Location /BPM/workspace>
    SetHandler weblogic-handler
    WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
    WLProxySSL ON
    WLProxySSLPassThrough ON
</Location>
</VirtualHost>

The servers specified in the WebLogicCluster parameter are only important at startup time for the plug-in. The list needs to provide at least one running cluster member for the plug-in to discover other members of the cluster. Note that the listed cluster member must be running when Oracle HTTP Server is started.

Oracle WebLogic Server and the plug-in work together to update the server list automatically with new, failed, and recovered cluster members.

Some example scenarios:

  • Example 1: If you have a two-node cluster and then add a third member, you do not need to update the configuration to add the third member. The third member is discovered on the fly at runtime.

  • Example 2: You have a three-node cluster but only two nodes are listed in the configuration. However, if both listed nodes are down when you start Oracle HTTP Server, then the plug-in would fail to route to the cluster. You must ensure that at least one of the listed nodes is running when you start Oracle HTTP Server.

    If you list all members of the cluster, then you guarantee you can route to the cluster, assuming at least one member is running when Oracle HTTP Server is started.

For more information on configuring the WebLogic Server plug-in, see the Oracle Fusion Middleware Using Web Server Plug-Ins With Oracle WebLogic Server guide.

10.2.13 Validating Access Through Oracle HTTP Server

Verify that the server status is reported as Running. If the server is shown as Starting or Resuming, wait for the server status to change to Started. If another status is reported, such as Admin or Failed, check the server output log files for errors. See Section 16.13, "Troubleshooting the Topology in an Enterprise Deployment" for possible causes.

Verify that you can access these URLs, where 'webhostN' specifies the name of each Oracle HTTP Server host (for example, WEBHOST1, WEBHOST2):

  • http://WEBHOST1:7777/soa-infra

  • http://WEBHOST2:7777/soa-infra

  • http://WEBHOST1:7777/soa/composer

  • http://WEBHOST2:7777/soa/composer

  • http://WEBHOST1:7777/integration/worklistapp

  • http://WEBHOST2:7777/integration/worklistapp

  • http://WEBHOST1:7777/sdpmessaging/userprefs-ui

  • http://WEBHOST2:7777/sdpmessaging/userprefs-ui

  • http://WEBHOST1:7777/b2bconsole

  • http://WEBHOST2:7777/b2bconsole

  • http://WEBHOST1:7777/BPM/composer

  • http://WEBHOST2:7777/BPM/composer

  • http://WEBHOST1:7777/BPM/workspace

  • http://WEBHOST2:7777/BPM/workspace

You can also verify these URLs using your load balancer address:

  • http://soa.mycompany.com:80/soa-infra

  • http://soa.mycompany.com:80/soa/composer

  • http://soa.mycompany.com:80/integration/worklistapp

  • http://soa.mycompany.com:80/sdpmessaging/userprefs-ui

  • http://soa.mycompany.com:80/b2bconsole

  • http://soa.mycompany.com:80/BPM/composer

  • http://soa.mycompany.com:80/BPM/workspace

For information on configuring system access through the load balancer, see Section 3.3, "Configuring the Load Balancer."

10.2.14 Setting the Frontend HTTP Host and Port

You must set the frontend HTTP host and port for the Oracle WebLogic Server cluster:

  1. In the WebLogic Server Administration Console, in the Change Center section, click Lock & Edit.

  2. In the left pane, choose Environment in the Domain Structure window and then choose Clusters. The Summary of Clusters page appears.

  3. Select the SOA_Cluster cluster.

  4. Select HTTP.

  5. Set the values for the following:

    • Frontend Host: soa.mycompany.com

    • Frontend HTTPS Port: 443

    • Frontend HTTP Port: 80

    If you do not set the frontend HTTP host and port, you get the following message when trying to retrieve a document definition XSD from Oracle B2B:

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

  7. To activate the changes, click Activate Changes in the Change Center section of the Administration Console.

  8. Restart the servers to make the Frontend Host directive in the cluster effective.

Note:

When HTTPS is enabled in the load balancer and the load balancer terminates SSL (the SOA servers receive only HTTP requests, not HTTPS), as suggested in this guide, the endpoint protocol for webservices is set to http. Since the load balancer redirects HTTP to HTTPS this causes the following exception when testing webservices functionality in Oracle Enterprise Manger Fusion Middleware Control:

(javax.xml.soap.SOAPException: oracle.j2ee.ws.saaj.ContentTypeException)

To resolve this exception, update the URL endpoint:

In the Enterprise Manager Test Page, check Edit Endpoint URL.

Within the endpoint URL page:

  • Change http to https.

  • Change the default port number (say 80) to SSL port (say 443).

Note:

If you do not set the frontend HTTP host and port, you get the following message when trying to retrieve a document definition XSD from Oracle B2B:

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

Callback URL

The SOA system calculates the callback URL as follows:

  • If a request to SOA originates from an external or internal service, then SOA uses the callback URL specified by the client.

  • If a request to an external or internal asynchronous service originates from SOA, the callback URL is determined using the following method, in decreasing order of preference:

    • Use callbackServerURL specified as a binding property for the specific reference. (You can set this when modeling the composite or at runtime using the MBeans). This allows different service calls to have different callback URLs. That is, a callback URL from an external service can be set to be different than one to an internal service In the context of the Enterprise Deployment architecture, typically this will be soa.mycompany.com (443/https) for external services and soainternal.mycompany.com (7777/http) for internal services. At runtime, this property is set using the System MBean Browser, through the corresponding binding mbean. To add a specific URL, add a callbackServerURL property to its Properties attribute, then invoke the save operation.

    • Use the callback URL as specified in soa-infra-config.xml. In this case, only one address can be specified. When a mix of both external and internal services can be invoked, this should be set to soa.mycompany.com (443/https) in the Enterprise Deployment architecture. When only internal services are to be invoked, this can be set to soainternal.mycompany.com (7777/http).

    • Use the callback URL as the frontend host specified in WLS for the SOA_Cluster. In this case, too, only one address can be specified and the recommendation is same as the one for soa-infra-config.xml.

    • Use the local host name as provided by WLS MBean APIs. This is not recommended in HA environments such as Enterprise Deployment.

10.2.15 Configuring a Default Persistence Store for Transaction Recovery

Each server has a transaction log that stores information about committed transactions that are coordinated by the server that may not have been completed. The WebLogic Server uses this transaction log for recovery from system crashes or network failures. To leverage the migration capability of the Transaction Recovery Service for the servers within a cluster, store the transaction log in a location accessible to a server and its backup servers.

Note:

The recommended location is a dual-ported SCSI disk or on a Storage Area Network (SAN).

To set the location for the default persistence stores:

  1. Log into the Oracle WebLogic Server Administration Console.

  2. In the Domain Structure window, expand the Environment node and then click the Servers node. The Summary of Servers page appears.

  3. Click the name of the server (represented as a hyperlink) in Name column of the table. The settings page for the selected server appears and defaults to the Configuration tab.

  4. Click the Services tab.

  5. In the Default Store section of the page, enter the path to the folder where the default persistent stores will store its data files. The directory structure of the path is as follows:

    ORACLE_BASE/admin/domain_name/soa_cluster_name/tlogs
    
  6. Click Save.

Note:

To enable migration of the Transaction Recovery Service, specify a location on a persistent storage solution that is available to other servers in the cluster. Both WLS_SOA1 and WLS_SOA2 must be able to access this directory. This directory must also exist before you restart the server.

10.2.16 Enabling High Availability for Oracle File and FTP Adapters

The Oracle File and FTP Adapters enable a BPEL process or an Oracle Mediator to read and write files on local file systems and on remote file systems through FTP (File Transfer Protocol).These adapters support high availability for an active-active topology with Oracle BPEL Process Manager and Oracle Mediator service engines for both inbound and outbound operations. To make Oracle File and FTP Adapters highly available for outbound operations, use the database mutex locking operation as described in "High Availability in Outbound Operations" in Oracle Fusion Middleware User's Guide for Technology Adapters. The database mutex locking operation enables these adapters to ensure that multiple references do not overwrite one another if they write to the same directory.

Note:

The operations described in this section are necessary only if your application requires these adapters.

Note:

The File Adapter picks up a file from the inbound directory, processes it, and then outputs a file to the output directory. Because the File Adapter is non-transactional, files can be processed twice. As a result, it is possible to get duplicate files when there is failover in the Oracle RAC backend or in the SOA managed servers.

10.2.16.1 Using the Database Mutex Locking Operation

Use the following procedure to make an outbound Oracle File or FTP Adapter service highly available using database table as a coordinator:

Note:

The steps and configuration options for the FTP adapter are exactly the same as the options for the file adapter. The connection factory to be used for FTP HA configuration is eis/Ftp/HAFtpAdapter which appears under the Outbound Connection Pools for the FTPAdapter deployment.

Note:

You must increase global transaction timeouts if you use database as a coordinator.

  1. Create Database Tables

    You are not required to perform this step since the database schemas are pre-created as a part of soainfra.

  2. Modify Deployment Descriptor for Oracle File Adapter

    Modify Oracle File Adapter deployment descriptor for the connection-instance corresponding to eis/HAFileAdapter from the Oracle WebLogic Server console:

    1. Log into your Oracle WebLogic Server console. To access the console navigate to http://servername:portnumber/console.

    2. Click Deployments in the left pane for Domain Structure.

    3. Click FileAdapter under Summary of Deployments on the right pane.

    4. Click the Configuration tab.

    5. Click the Outbound Connection Pools tab, and expand javax.resource.cci.ConnectionFactory to see the configured connection factories.

    6. Click eis/HAFileAdapter. The Outbound Connection Properties for the connection factory corresponding to high availability is displayed.

    7. The connection factory properties appear as shown in Figure 10-3.

      Figure 10-3 Oracle WebLogic Server Console - Settings for javax.resource.cci.Connectionfactory Page

      Description of Figure 10-3 follows
      Description of "Figure 10-3 Oracle WebLogic Server Console - Settings for javax.resource.cci.Connectionfactory Page"

      Click on Lock & Edit. After this, the property value column becomes editable (you can click on any of the rows under "Property Value" and modify its value).

      The new parameters in connection factory for Oracle File and FTP Adapters are as follows:

      controlDir: Set it to the directory structure where you want the control files to be stored. You must set it to a shared location if multiple WebLogic Server instances run in a cluster. Structure the directory for shared storage as follows:

      ORACLE_BASE/admin/domain_name/cluster_name/fadapter
      

      inboundDataSource: Set the value to jdbc/SOADataSource. This is the data source, where the schemas corresponding to high availability are pre-created. The pre-created schemas can be found in the following directory:

      ORACLE_HOME/rcu/integration/soainfra/sql/adapter/createschema_adapter_oracle.sql
      

      If you want to create the schemas elsewhere, use this script. You must set the inboundDataSource property accordingly if you choose a different schema.

      outboundDataSource: Set the value to jdbc/SOADataSource. This is the data source where the schemas corresponding to high availability are pre-created. The pre-created schemas can be found under ORACLE_HOME/ rcu/integration/soainfra/sql/adapter/createschema_adapter_oracle.sql. If you want to create the schemas elsewhere, use this script. You must set the outboundDataSource property if you choose to do so.

      outboundDataSourceLocal: Set the value to jdbc/SOADataSource. This is the data source where the schemas corresponding to high availability are pre-created.

      outboundLockTypeForWrite: Set the value to oracle if you are using Oracle Database. By default the Oracle File and FTP Adapters use an in-memory mutex to lock outbound write operations. You must choose from the following values for synchronizing write operations:

      memory: The Oracle File and FTP Adapters use an in-memory mutex to synchronize access to the file system.

      oracle: The adapter uses Oracle Database sequence.

      db: The adapter uses a pre-created database table (FILEADAPTER_MUTEX) as the locking mechanism. You must use this option only if you are using a schema other than the Oracle Database schema.

      user-defined: The adapter uses a user-defined mutex. To configure the user-defined mutex, you must implement the mutex interface: "oracle.tip.adapter.file.Mutex" and then configure a new binding-property with the name "oracle.tip.adapter.file.mutex" and value as the fully qualified class name for the mutex for the outbound reference.

    8. Click Save after you update the properties. The Save Deployment Plan page appears.

    9. Enter a shared storage location for the deployment plan. The directory structure is as follows:

      ORACLE_BASE/admin/domain_name/cluster_name/dd/Plan.xml
      
    10. Click Save and Activate.

    11. Configure BPEL Process or Mediator Scenario to use the connection factory as shown in the following example:

      <adapter-config name="FlatStructureOut" adapter="File Adapter" xmlns="http://platform.integration.oracle/blocks/adapter/fw/metadata">
        <connection-factory location="eis/HAFileAdapter" adapterRef=""/>
        <endpoint-interaction portType="Write_ptt" operation="Write">
      <interaction-spec className="oracle.tip.adapter.file.outbound.FileInteractionSpec">
            <property../>
            <property../>
          </interaction-spec>
        </endpoint-interaction>
      </adapter-config>
      

      Note:

      The location attribute is set to eis/HAFileAdapter for the connection factory.

10.2.17 Scaling the Oracle Database Adapter

The introduction of skip locking has superseded the previous best practice of using LogicalDeletePollingStrategy or DeletePollingStrategy with a unique MarkReservedValue on each polling node, and setting MaxTransactionSize. If you were using this approach previously, you can simply remove (in db.jca) or clear (Logical Delete Page of wizard) the MarkReservedValue, and you automatically get skip locking.

The benefits of using skip locking over a reserved value include:

  • Skip locking scales better in a cluster and under load.

  • All work is in one transaction (as opposed to update/reserve, then commit, then select in a new transaction), so the risk of facing a non-recoverable situation in a high availability environment is minimized.

  • No unique MarkReservedValue must be specified. Previously, for this to work you would have to configure a complex variable, such as R${weblogic.Name-2}-${IP-2}-${instance}.

If you are using Logical Delete polling, and you set MarkReservedValue, skip locking is not used.

Formerly, the best practice for multiple Oracle Database Adapter process instances deployed to multiple Oracle BPEL Process Manager, or Oracle Mediator nodes was essentially using LogicalDeletePollingStrategy or DeletePollingStrategy with a unique MarkReservedValue on each polling node, and setting MaxTransactionSize.

For more information, see "Scalability" and "Polling Strategies" in the Oracle Fusion Middleware User's Guide for Technology Adapters.

10.3 Option 2: Extending a SOA Domain to Include Oracle BPM

In this step, you extend the domain created in Section 9, "Extending the Domain for SOA Components" to include Oracle BPM.

Prerequisites for Extending the SOA Domain to Include Oracle BPM

Before extending the current domain, ensure that your existing deployment meets the following prerequisites:

This section contains the following topics:

10.3.1 Running the Configuration Wizard on SOAHOST1 to Extend a SOA Domain to Include BPM

Run the Configuration Wizard from the SOA home directory to extend a domain containing an Administration Server and Oracle Web Services Manager to support SOA and BPM components.

  1. Change the directory to the location of the Configuration Wizard. This is within the SOA home directory. Domain extensions are run from the node where the Administration Server resides.

    cd ORACLE_COMMON_HOME/common/bin
    
  2. Start the Oracle Fusion Middleware Configuration Wizard:

    ./config.sh
    
  3. In the Welcome screen, select Extend an Existing WebLogic Domain, and click Next.

  4. In the WebLogic Domain Directory screen, select the WebLogic domain directory ORACLE_BASE/admin/domain_name/aserver/domain_name, and click Next.

  5. In the Select Extension Source screen, do the following:

    • Select Extend my domain automatically to support the following added products. Select the following products:

    • Select the following product:

      • Oracle BPM Suite - 11.1.1.0 [soa]

  6. In the Configure JDBC Component Schema screen, accept existing values (schemas created in the existing SOA system) and click Next.

    Oracle BPM uses the same Data Sources as the existing soa-infra system.

  7. In the Optional Configuration screen, select the following:

    • JMS Distributed Destinations

    • Deployments and Services

    Click Next.

  8. In the Select JMS Distributed Destination Type screen, select UDD from the drop down list for BPMJMSModule. Leave existing modules as they are.

  9. In the Target Deployments to Clusters or Servers screen, ensure the following targets:

    • Target WSM-PM only to WSM-PM_Cluster.

    • Target usermessagingserver and usermessagingdriver-email only to SOA_Cluster. (The usermessaging-xmpp, usermessaging-smpp, and usermessaging-voicexml applications are optional.)

    • Target the oracle.sdp.*, oracle.BPM.*, and oracle.soa.* libraries only to SOA_Cluster.

    • Target the oracle.rules.* library to SOA_Cluster and Admin Server.

    Click Next.

  10. In the Target Services to Clusters or Servers screen, target the mds-owsm datasource to the WSM-PM_Cluster and the AdminServer and click Next.

  11. In the Configure JMS File Stores screen, enter the shared directory location specified for your JMS stores as recommended in Section 4.3, "About Recommended Locations for the Different Directories." For example:

    ORACLE_BASE/admin/domain_name/soa_cluster_name/jms
    

    Select Direct-write policy for all stores.

    Click Next.

  12. In the Configuration Summary screen click Extend.

  13. In the Creating Domain screen, click Done.

    You must restart the Administration Server for this configuration to take effect. To restart the Administration Server, use the procedure in Section 8.4.3, "Starting the Administration Server on SOAHOST1."

10.3.2 Propagating the Domain Configuration to the managed server directory in SOAHOST1 and to SOAHOST2

Oracle BPM Suite requires some updates to the WebLogic Server start scripts. Propagate these changes using the pack and unpack commands.

To propagate the start scripts and classpath configuration from the Administration Server's domain directory to the managed server domain directory:

  1. Create a backup copy of the managed server domain directory and the managed server applications directory.

  2. Run the pack command on SOAHOST1 to create a template pack:

    cd ORACLE_COMMON_HOME/common/bin
    
    ./pack.sh -managed=true -domain=ORACLE_BASE/admin/
    domain_name/aserver/domain_name -template=soadomaintemplateExtSOABPM.jar
     -template_name=soa_domain_templateExtSOABPM
    
  3. Run the unpack command on SOAHOST1 to unpack the propagated template to the domain directory of the managed server:

    ./unpack.sh -domain=ORACLE_BASE/admin/domain_name/mserver/domain_name
    -overwrite_domain=true -template=soadomaintemplateExtSOABPM.jar 
    -app_dir=ORACLE_BASE/admin/domain_name/mserver/applications
    

    Note:

    The -overwrite_domain option in the unpack command, allows unpacking a managed server template into an existing domain and existing applications directories. For any file that is overwritten, a backup copy of the original is created. If any modifications had been applied to the start scripts and ear files in the managed server domain directory they must be restored after this unpack operation.

  4. Copy the template to SOAHOST2:

    cd ORACLE_COMMON_HOME/common/bin
    
    scp soadomaintemplateExtBPM.jar oracle@SOAHOST2:/ORACLE_HOME/common/bin
    
  5. Run the unpack command on SOAHOST2 to unpack the propagated template:

    cd ORACLE_COMMON_HOME/common/bin
    
    ./unpack.sh -domain=ORACLE_BASE/admin/domain_name/mserver/domain_name/ -overwrite_domain=true
    -template=soadomaintemplateExtBPM.jar -app_dir=ORACLE_BASE/admin/
    domain_name/mserver/applications
    

Note:

The configuration steps provided in this enterprise deployment topology are documented with the assumption that a local (per node) domain directory is used for each managed server.

10.3.3 Starting the BPM Suite Components

For configuration changes and start scripts to be effective, you must restart the WLS_SOAn server to which BPM has been added. Since BPM extends an already existing SOA system, the Administration Server and respective Node Managers are already running in SOAHOST1 and SOAHOST2.

To start the added BPM components:

  1. Restart the WLS_SOA1 managed server:

    1. Log into the Oracle WebLogic Server Administration Console at:

      http://ADMINVHN:7001/console.

    2. In the Domain Structure window, expand the Environment node, then select Servers.

      The Summary of Servers page appears.

    3. Click the Control tab.

    4. Select WLS_SOA1 from the Servers column of the table.

    5. Click Shutdown. Wait for the shutdown to complete (refresh the WebLogic Server Console page to verify shutdown status).

    6. Click Start.

  2. Repeat steps a-f for WLS_SOA2.

10.3.4 Configuring Oracle HTTP Server for the WLS_SOAn Managed Servers

To enable Oracle HTTP Server to route to the SOA_Cluster, which contains the WLS_SOAn managed servers, set the WebLogicCluster parameter to the list of nodes in the cluster.

To enable Oracle HTTP Server to route to the SOA_Cluster:

  1. On WEBHOST1 and WEBHOST2, add directives to the soa.vh.conf file located in the following directory:

    ORACLE_BASE/admin/instance_name/config/OHS/component_name/moduleconf
    

    Add the following directives inside the <VirtualHost> tags:

    # BPM
    <Location /BPM/composer>
        SetHandler weblogic-handler
        WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
        WLProxySSL ON
        WLProxySSLPassThrough ON
    </Location>
    
    # BPM
    <Location /BPM/workspace>
        SetHandler weblogic-handler
        WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
        WLProxySSL ON
        WLProxySSLPassThrough ON
    </Location>
    

    The soa_vh.conf file will appear as it does in Example 10-1.

  2. Restart Oracle HTTP Server on WEBHOST1 and WEBHOST2:

    WEBHOST1> ORACLE_BASE/admin/instance_name/bin/opmnctl restartproc ias-component=ohs1
    WEBHOST2> ORACLE_BASE/admin/instance_name/bin/opmnctl restartproc ias-component=ohs2
    

10.3.5 Validating Access Through Oracle HTTP Server

Since the cluster address for the SOA_Cluster has already been set in the previous chapter, the BPM system can only be verified once Oracle HTTP Server has been configured to route the BPM context URLs to the WebLogic Servers. Verify URLs to ensure that appropriate routing and failover is working from the HTTP Server to the BPM Suite Components.

For information on configuring system access through the load balancer, see Section 3.3, "Configuring the Load Balancer."

To verify the URLs:

  1. While WLS_SOA is running, stop WLS_SOA1 using the Oracle WebLogic Server Administration Console.

  2. Access WebHost1:7777/BPM/composer and WebHost1:7777/BPM/workspace to verify the appropriate functionality for BPM project Composer.

  3. Start WLS_SOA1 from the Oracle WebLogic Server Administration Console.

  4. Stop WLS_SOA2 from the Oracle WebLogic Server Administration Console.

  5. Access WebHost1:7777/BPM/composer and WebHost1:7777/BPM/workspace to verify the appropriate functionality for BPM Workspace.

You can also verify these URLs using your load balancer address:

  • http://soa.mycompany.com:80/BPM/composer

  • http://soa.mycompany.com:80/BPM/workspace

10.4 Backing Up the Oracle BPM Configuration

After you have verified that the extended domain is working, back up the domain configuration. This is a quick backup for the express purpose of immediate restore in case of failures in future procedures. Back up the configuration to the local disk. This backup can be discarded once you have completed the enterprise deployment. Once you have completed the enterprise deployment, you can initiate the regular deployment-specific backup and recovery process.

For information about backing up the environment, see "Backing Up Your Environment" in the Oracle Fusion Middleware Administrator's Guide. For information about recovering your information, see "Recovering Your Environment" in the Oracle Fusion Middleware Administrator's Guide.

To back up the domain configuration:

  1. Back up the Web tier:

    1. Shut down the instance using opmnctl.

      ORACLE_BASE/admin/instance_name/bin/opmnctl stopall
      
    2. Back up the Middleware Home on the web tier using the following command (as root):

      tar -cvpf BACKUP_LOCATION/web.tar MW_HOME
      
    3. Back up the Instance Home on the web tier using the following command (as root):

      tar -cvpf BACKUP_LOCATION/web_instance.tar ORACLE_INSTANCE
      
    4. Start the instance using opmnctl:

      ORACLE_BASE/admin/instance_name/bin/opmnctl startall
      
  2. Back up the database. This is a full database backup (either hot or cold) using Oracle Recovery Manager (recommended) or OS tools such as tar for cold backups if possible.

  3. Back up the Administration Server domain directory to save your domain configuration. The configuration files are located in the following directory:

    ORACLE_BASE/ admin/domain_name
    

    To back up the Administration Server run the following command on SOAHOST1:

    tar -cvpf edgdomainback.tar ORACLE_BASE/admin/domain_name
    

Note:

Back up ORACLE_HOME if any changes are made to the XEngine configuration that is part of your B2B setup. These files are located in the following directory:

ORACLE_HOME/soa/thirdparty/edifecs/XEngine

To back up ORACLE_HOME:

tar -cvpf fmwhomeback.tar MW_HOME