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

Part Number E12036-06
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
View PDF

6 Extending the Domain to Include Oracle BPM

The Oracle BPM system is created using the WL_HOME and ORACLE_HOME installed in previous chapters on a shared storage. Oracle BPM requires these WL_HOME and ORACLE_HOME homes to be patched to the Oracle FMW 11.1.1.4 (PS3) patchset level before the WebLogic Configuration Wizard steps are performed to extend a domain.

You can enable BPM in a Fusion Middleware installation in the following two ways:

6.1 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 BAM. 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.

Important:

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:

6.1.1 Backing Up the Existing Installation

Before beginning the procedures in this chapter, Oracle recommends backing up the existing Fusion Middleware Home and domain.

SOAHOST1> tar -cvpf fmwhomeback.tar ORACLE_BASE/product/fmw
SOAHOST1> tar -cvpf domainhomeback.tar ORACLE_BASE/admin/domain_name/aserver/domain_name

These commands create a backup of the installation files for both Oracle WebLogic Server and Oracle Fusion Middleware, as well as the domain configuration.

6.1.2 Enabling VIP2 on SOAHOST1 and VIP3 on SOAHOST2

The procedures in this section are required for server migration of WLS_SOA1 and WLS_SOA2.

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 VIPs (VIP2 and VIP3).

To enable the virtual IP on Linux, 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

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

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

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

  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.

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

    SOAHOST1> ./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 Component Schema screen, do the following:

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

    • Select Configure selected component schemas as RAC multi data source schemas in the next panel.

    Figure 6-1 Configure JDBC Component Schema Screen

    Description of Figure 6-1 follows
    Description of "Figure 6-1 Configure JDBC Component Schema Screen"

    Click Next.

  8. The Configure RAC Multi Data Source Component Schema screen is displayed. In this screen, enter values for the fields below, specifying the connect information for the Oracle RAC database that was seeded with RCU. Enter this information for each schema (you can select multiple schemas and specify values that are common to all):

    Figure 6-2 Configure RAC Multi Data Source Component Schema Screen

    Description of Figure 6-2 follows
    Description of "Figure 6-2 Configure RAC Multi Data Source Component Schema Screen"

    In this screen, do the following:

    You can select all schemas and enter values that are common to all. Leave the OWSM MDS Schema information as it is, since it was already configured in Chapter 4.

    Enter values for the following fields, specifying the connect information for the Oracle RAC database that was seeded with RCU. Enter this information for each schema:

    1. Enter the host name, instance name, and port for the first Oracle RAC DB instance.

    2. Click Add.

    3. Repeat for each Oracle RAC instance.

    4. Driver: Select Oracle driver (Thin) for RAC Service-Instance connections, Versions:10, 11.

    5. Service Name: Enter the service name of the database, for example, soaedg.mycompany.com

    6. Username: Enter the complete user name (including the prefix) for the schemas. You can enter a value with all schemas selected (like the prefix) and then select each schema individually to change the rest of the schema name

    7. Password: Enter the password to use to access the schemas.

    Click Next.

  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 6-1. Do not modify the other servers that appear in this screen; leave them as they are.

    Table 6-1 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 6-2. Do not modify the other clusters that display in this screen; leave them as they are.

    Table 6-2 Cluster

    Name Cluster Messaging Mode Multicast Address Multicast Port Cluster Address

    SOA_Cluster

    unicast

    n/a

    n/a

    Leave it empty.


    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 6-3):

      Table 6-3 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, do the following:

    • Assign AdminServer to ADMINHOST.

    • Assign WLS_SOA1 to SOAHOST1.

    • Assign WLS_SOA2 to SOAHOST2.

    • Assign WLS_WSM1 to SOAHOST1.

    • Assign WLS_WSM2 to 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.

    • Target the oracle.wsm.seedpolicies library only to WSM-PM_Cluster and SOA_Cluster (if the SOA_Cluster is going to contain any webservices itself).

    Click Next.

  18. In the Target Services to Clusters or Servers screen, ensure the following targets:

    • Target JOC Startup Class and JOC Shutdown Class only to WSM-PM_Cluster.

    • Target the mds-owsm, mdw-owsm-rac0 and mds-owsm-rac1 datasources to the WSM-PM_Cluster and the AdminServer

    Click Next.

  19. In the Configuration Summary screen click Extend.

  20. 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 4.7, "Starting the Administration Server on SOAHOST1."

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

Note:

An incorrect configuration of the Oracle Coherence framework that is 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 following configuration described in this section.

Enabling Communication for Deployment Using Unicast Communication

Multicast communication enables Oracle Fusion Middleware SOA to discover all of the members of a cluster to which to it deploys composites dynamically. However, 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 box, you must configure Oracle Coherence to use a specific host name to create the Oracle Coherence cluster.

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.

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 6-3).

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 6-3 Setting the Host Name Using the Start Server Tab of Oracle WebLogic Server Administration Console

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

Specifying the host name

To add the host name used by Oracle Coherence, complete these steps:

  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 and Edit.

  6. Click the Configuration tab, and then the Server Start tab.

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

    For WLS_SOA1, enter the following:

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

    For WLS_SOA2, enter the following:

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

    Note:

    There should be no breaks in lines between the different -D parameters. Do not copy or paste the text from above to your Administration Console's arguments text field. This 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.
  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.

6.1.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 and 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.

6.1.6 Disabling Host Name Verification for the WLS_SOA1, WLS_SOA2, Managed Servers

This step is required if you have not set up the appropriate certificates to authenticate the different nodes with the Administration Server (see Chapter 8, "Setting Up Node Manager"). If you have not configured the server certificates, you will receive errors when managing the different WebLogic Servers. To avoid these errors, disable host name verification while setting up and validating the topology, and enable it again once the EDG topology configuration is complete as described in Chapter 8, "Setting Up Node Manager."

To disable host name verification:

  1. Log in to Oracle WebLogic Server Administration Console.

  2. Click Lock and 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. To restart the Admin Server, follow the steps provided in section Section 4.7, "Starting the Administration Server on SOAHOST1."

    1. To restart the Admin Server follow the steps provided in Section 5.3, "Restarting the Administration Server.".

    2. To restart Node Manager on SOAHOST1, use the procedure described in Section 5.7, "Restarting the Node Manager on SOAHOST1."

      Repeat for Node Manager in SOAHOST2

6.1.7 Propagating the Domain Changes to the Managed Server Domain Directory

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

  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:

    SOAHOST1> cd ORACLE_COMMON_HOME/common/bin
    
    SOAHOST1> ./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:

    SOAHOST1> ./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.

6.1.8 Starting and Validating the WLS_SOA1 Managed Server

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 10, "Troubleshooting" 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.

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

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

    SOAHOST2> cd ORACLE_COMMON_HOME/common/bin
    
    SOAHOST2> ./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.

6.1.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:

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

6.1.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 10, "Troubleshooting" 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.

6.1.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, you must set the WebLogicCluster parameter to the list of nodes in the cluster:

  1. On WEBHOST1 and WEBHOST2, add the following lines to the ORACLE_BASE/ admin/instance_name/config/OHS/component_name/mod_wl_ohs.conf file:

    # SOA soa-infra app
    <Location /soa-infra>
        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>
    

    Make sure the httpd.conf file located in the same directory as the mod_wl_ohs file contains the following lines:

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

    Note:

    Values such as soa.mycompany.com:443, 7777, admin.mycompany:80, and you@youraddress that are noted in this document serve as examples only. Enter values based on the actual environment.
  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
    

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 will be 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.

6.1.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 10.7, "Troubleshooting" 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 2.2.2, "Load Balancers."

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

  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:

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:

    1. 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 EDG 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.

    2. 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 EDG architecture. When only internal services are to be invoked, this can be set to soainternal.mycompany.com (7777/http).

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

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

6.1.15 Setting the WLS Cluster address for Direct Binding/RMI invocations to composites

When using direct binding composites, you must set the WLS Cluster address for the SOA_Cluster. To set the WLS Cluster address:

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

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

  3. Select the SOA_Cluster cluster.

  4. In the Configuration, General tab, enter the following in the Cluster Address field:

    SOAHOST1VHN1:8001,SOAHOST2VHN1:8001

  5. Click Save.

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

  7. Restart the servers for the Frontend Host directive to take effect in the cluster.

    Note:

    For asynch request/response interactions over direct binding, the SOA composites must provide their jndi provider URL for the invoked service to look up the beans for callback.

    If soa-infra config properties are not specified, but the WLS Cluster address is specified, the cluster address from the JNDI provider URL is used. This cluster address can be a single DNS name which maps to the clustered servers' IP addresses or a comma separated list of server ip:port. Alternatively, the soa-infra config property JndiProviderURL/SecureJndiProviderURL can be used for the same purpose if explicitly set by users.

6.1.16 Configuring a Shared JMS Persistence Store

Configure the location for all of the persistence stores as a directory that is visible from both nodes. For more information see Section 4.1, "Installing Oracle Fusion Middleware Home." You must then change all of the persistent stores to use this shared base directory as follows:

  1. Log into the Oracle WebLogic Server Administration Console.

  2. In the Domain Structure window, expand the Services node and then click the Persistence Stores node.

    The Summary of Persistence Stores page appears.

  3. Select the persistence store (represented as a hyperlink) from the Name column of the table.

    The Settings page for the persistence store appear.

  4. In the Configuration tab, enter the location on a persistent storage solution (such as NAS or SAN) that is available to other servers in the cluster in the Directory field.

    Specifying this location enables pending JMS messages to be sent. The location should follow the following directory structure:

    ORACLE_BASE/admin/domain_name/soa_cluster_name/jms
    

    Note:

    Both WLS_SOA1 and WLS_SOA2 must be able to access this directory. This directory must also exist before you restart the server.
  5. Click Save and activate changes.

  6. Restart the servers to make the change in the persistent stores effective.

6.1.17 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:

Preferably, this location should be a dual-ported SCSI disk or on a Storage Area Network (SAN).

To set the location for the default persistence store, complete these steps:

  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.

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

6.1.18.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 6-4.

      Figure 6-4 Oracle WebLogic Server Console - Settings for javax.resource.cci.Connectionfactory Page

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

      Click on Lock and 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 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 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 datasource 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>/dp/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.

6.1.19 Scaling the Oracle Database Adapter

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.

However, with the introduction of skip locking in this release that approach has now been superseded. 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}.

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

6.1.20 Backing Up the Installation

After you have verified that the extended domain is working, back up the installation. This is a quick backup for the express purpose of immediate restore in case of problems in the further steps. The backup destination is the local disk. This backup can be discarded once the enterprise deployment setup is complete. At this point, the regular deployment-specific backup and recovery process can be initiated. The Oracle Fusion Middleware Administrator's Guide provides further details. For recommendations specific to recovering from the loss of a host, see the "Recovering Oracle HTTP Server to a Different Host" in the guide. Also refer to the Oracle Database Backup and Recovery Guide for information on database backup.

To back up the installation a this point, complete these steps:

  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 all exist under the ORACLE_BASE/admin/<domain_name> directory.

    SOAHOST1> tar -cvpf edgdomainback.tar ORACLE_BASE/admin/domain_name
    

Note:

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

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

In this step, you extend the domain created in Section 5, "Extending the Domain for SOA Components" to contain BPM. You can also extend the resulting domain to add BAM. It is assumed that SOA ORACLE_HOME (binaries) has already been installed, patched to the Oracle FMW 11.1.1.4 (PS3) patchset level, and is available from SOAHOST1 and SOAHOST2 (this is required before the WebLogic Configuration Wizard steps are performed to extend the domain).

The instructions in this section assume that Node Manager, Admin Server, SOA Servers and WSM Servers exist and have been configured as described in previous chapters to run a SOA system. Server migration, transaction logs, coherence, and all other configuration steps for the SOA System have already been performed and will be used by BPM. BPM is added as a superset of the existing configuration.

This section contains the following topics:

6.2.1 Backing Up the Existing Installation

Before beginning the procedures in this section, Oracle recommends backing up the existing Fusion Middleware Home and domain. Be sure to stop the Administration Server first.

SOAHOST1> tar -cvpf fmwhomeback.tar ORACLE_BASE/product/fmw
SOAHOST1> tar -cvpf domainhomeback.tar ORACLE_BASE/admin/domain_name/aserver/domain_name

These commands create a backup of the installation files for both Oracle WebLogic Server and Oracle Fusion Middleware, as well as the domain configuration.

6.2.2 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).

    SOAHOST1> cd ORACLE_HOME/common/bin
    
  2. Start the Oracle Fusion Middleware Configuration Wizard:

    SOAHOST1> ./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.

    BPM uses the same DataSources 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.rules.*, oracle.sdp.*, oracle.bpm.*, and oracle.soa.* deployments only to SOA_Cluster.

    • Target the oracle.wsm.seedpolicies library only to WSM-PM_Cluster and SOA_Cluster.

    Click Next.

  10. In the Target Services to Clusters or Servers screen, ensure the following targets:

    • Target JOC Startup Class and JOC Shutdown Class only to WSM-PM_Cluster.

    • Target the mds-owsm, mdw-owsm-rac0 and mds-owsm-rac1 datasources to the WSM-PM_Cluster and the AdminServer

    Click Next.

  11. In the Configuration Summary screen click Extend.

  12. 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 4.7, "Starting the Administration Server on SOAHOST1."

6.2.3 Configuring a JMS Persistence Store for BPM JMS

Configure the location for the default persistence stores as a directory that is visible from both nodes. For more information see Section 4.1, "Installing Oracle Fusion Middleware Home." You must then change all of the persistent stores to use this shared base directory as follows:

  1. Log into the Oracle WebLogic Server Administration Console.

  2. In the Domain Structure window, expand the Services node and then click the Persistence Stores node.

    The Summary of Persistence Stores page appears.

  3. Select the BPMJMSFileStore_auto_1 persistence store (represented as a hyperlink) from the Name column of the table.

    The Settings page for the BPMJMSFileStore_auto_1 persistence store appears.

  4. In the Configuration tab, enter the location on a persistent storage solution (such as NAS or SAN) that is available to other servers in the cluster in the Directory field.

    Specifying this location enables pending JMS messages to be sent. The location should follow the following directory structure:

    ORACLE_BASE/admin/domain_name/soa_cluster_name/jms
    

    Note:

    Both WLS_SOA1 and WLS_SOA2 must be able to access this directory. This directory must also exist before you restart the server.
  5. Click Save and activate changes.

  6. Repeat these steps for the BPMJMSFileStore_auto_2 persistence store.

  7. Restart the servers to make the change in the persistent stores effective.

6.2.4 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:

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

    SOAHOST1> ./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
    
  4. Copy the template to SOAHOST2:

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

    SOAHOST2> cd ORACLE_COMMON_HOME/common/bin
    
    SOAHOST2> ./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 -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.

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

Note:

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.

6.2.6 Validating the BPM Suite Components in WLS_SOA1 and WLS_SOA2

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. To verify the BPM system using Oracle HTTP Server, follow the steps in the sections Section 6.2.7, "Configuring Oracle HTTP Server for the WLS_SOAn Managed Servers," and Section 6.2.8, "Validating Access Through Oracle HTTP Server."

6.2.7 Configuring Oracle HTTP Server for the WLS_SOAn Managed Servers

To enable Oracle HTTP Server to route to BPM web applications, you must set the WebLogicCluster parameter to the list of nodes in the cluster:

  1. Add the following lines to the ORACLE_BASE/ admin/instance_name/config/OHS/component_name/mod_wl_ohs.conf file:

    # BPM
    <Location /bpm/composer >
        SetHandler weblogic-handler
        WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2:VHN1:8001
        WLProxySSL ON
        WLProxySSLPassThrough ON
    </Location>
    
    # BPM
    <Location /bpm/workspace >
        SetHandler weblogic-handler
        WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2:VHN1:8001
        WLProxySSL ON
        WLProxySSLPassThrough ON
    </Location>
    
  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
    

6.2.8 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. To verify 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

6.2.9 Backing Up the Installation

After you have verified that the extended domain is working, back up the installation. This is a quick backup for the express purpose of immediate restore in case of problems in the further steps. The backup destination is the local disk. This backup can be discarded once the enterprise deployment setup is complete. At this point, the regular deployment-specific backup and recovery process can be initiated. The Oracle Fusion Middleware Administrator's Guide provides further details. For information on describing the Oracle HTTP Server data that must be backed up and restored, refer to the "Backup and Recovery Recommendations for Oracle HTTP Server" section in this guide. For information on how to recover components, see "Recovery of Components" and "Recovery After Loss of Component" sections in the guide. For recommendations specific to recovering from the loss of a host, see the "Recovering Oracle HTTP Server to a Different Host" in the guide. Also refer to the Oracle Database Backup and Recovery Guide for information on database backup.

To back up the installation at this point, complete these steps:

  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 all exist under the ORACLE_BASE/admin/<domain_name> directory.

    SOAHOST1> tar -cvpf edgdomainback.tar ORACLE_BASE/admin/domain_name