10 Extending the Domain to Include Oracle BPM

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, see Section 3.5, "Enabling Virtual IP Addresses for Administration Servers."

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

   
   

   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

    • JMS File Stores

    • Managed Servers, Clusters, and Machines

    • Deployments and Services

    Click Next.

11. Once the new deployment plan has been saved and activated, activate the FileAdapter deployment (the deployment remains in Prepared state if not started).

    To activate the FileAdapter deployment plan:

    1. In the Administration Console, click Deployments in the left pane for Domain Structure.

    2. Select the FileAdapter under Summary of Deployments on the right pane.

    3. Select Start, and then Servicing All Requests.

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

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

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

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

    • SOA_Cluster:

      • WLS_SOA1

      • WLS_SOA2

    Click Next.

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

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

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

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

    Click Next.

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

    For information on targeting applications and resources, see Appendix B, "Targeting Applications and Resources to Servers."

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

    ASERVER_HOME/soa_cluster_name/jms
    

    Select Direct-write policy for all stores.

    Click Next.

21. In the Configuration Summary screen click Extend.

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

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

10.2.4 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 SOA Suite. You must disable the host name verification for the WLS_SOA1 and WLS_SOA2 managed servers to avoid errors when managing the different WebLogic Server instances. For more information, see Section 8.4.8, "Disabling Host Name Verification."

You enable host name verification again once the enterprise deployment topology configuration is complete. For more information, see Section 13.3, "Enabling Host Name Verification Certificates for Node Manager in SOAHOST1."

10.2.5 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=ASERVER_HOME
    -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=MSERVER_HOME
   -overwrite_domain=true
   -template=soadomaintemplateExtSOABPM.jar 
   -app_dir=MSERVER_HOME/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.

10.2.6 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.7 Propagating the Domain Configuration to SOAHOST2 Using the Unpack Utility

Propagate 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=MSERVER_HOME
   -overwrite_domain=true -template=soadomaintemplateExtSOABPM.jar 
   -app_dir=MSERVER_HOME/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 Extracting the XEngine Files in SOAHOST2

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

1. Run the following command from SOAHOST2:

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

2. Restart Node manager on SOAHOST2 using the procedure Section 9.5.2, "Restarting the Node Manager on SOAHOST1."

3. Verify the following directory structure after the extraction:

   ORACLE_HOME/soa/soa/thirdparty/edifecs/
   

   In this directory the following directories should appear:

   • Common

   • XEngine

   In the XEngine directory the following directories and files should appear:

   • bin

   • config

   • Readme.htm

   • EULA.pdf

10.2.9 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.10 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.11 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_INSTANCE/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_INSTANCE/bin/opmnctl restartproc ias-component=ohs1
   WEBHOST2> ORACLE_INSTANCE/bin/opmnctl restartproc ias-component=ohs2
   

<VirtualHost *:7777>
    ServerName https://soa.mycompany.com:443
    ServerAdmin [email protected]
    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.12 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.14, "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 Balancers."

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

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

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

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

   ASERVER_HOME/soa_cluster_name/tlogs
   

6. Click Save.

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

10.2.16 Enabling High Availability for Oracle JMS Adapters

When the Oracle JMS adapter communicates with multiple servers in a cluster, the adapter's connection factory property FactoryProperties must list available servers. If it does not list servers, the connection establishes to only one random server. If that particular server goes down, no further messages are processed.

To verify that the adapter's JCA connection factory:

1. Log into your Oracle WebLogic Server Administration Console using the following URL:

   http://servername:portnumber/console

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

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

4. Click the Configuration tab.

5. Click the Outbound Connection Pools tab and expand oracle.tip.adapter.jms.IJmsConnectionFactory to see the configured connection factories.

6. Click the specific instance you are using (for example, eis/wls/Queue). The Outbound Connection Properties for the connection factory opens.

7. Click Lock & Edit.

8. In the FactoryProperties field (click on the corresponding cell under Property value), enter the following:

   java.naming.factory.initial=weblogic.jndi.WLInitialContextFactory;
   java.naming.provider.url=t3://soahostvhn1:8001,soahost2vhn1:8001;java.naming.se
   curity.principal=weblogic;java.naming.security.credentials=mypassword
   

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

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

    ASERVER_HOME/cluster_name/dp/Plan.xml
    

11. Click Save and Activate.

Update the deployment in the console:

1. Click Deployments and select the JMS Adapter.

2. Click Lock & Edit then Update.

3. Select Update this application in place with new deployment plan changes (A deployment plan must be specified for this option.) and select the deployment plan saved in a shared storage location; all servers in the cluster must be able to access the plan).

4. Click Finish.

5. Activate the changes.

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.2.18 Updating the B2B Configuration for High Availability

To set up File, FTP, or Email transports in a high availability environment, specify a unique name for each instance by using b2b.HAInstanceName unique_instance_name. If you use ServerName for the value, Oracle B2B retrieves the WebLogic Server name as the HAInstanceName.

To specify a unique name:

1. Log in to Oracle Enterprise Manager Fusion Middleware Control with the username and password specified in Section 8.4.1, "Creating boot.properties for the Administration Server on SOAHOST1."

2. On the navigation tree on the left, expand Farm_<domain_name>, SOA, and then right click on the soa-infra<server_name>, and select the SOA Administration, and then B2B Server Properties.

3. Click on More B2B Configuration Properties... on the right.

4. Click the b2b MBean.

5. Click the Operations tab.

6. Click addProperty in the list on the right.

7. In the Key field enter b2b.HAInstanceName.

8. In the value field enter #ServerName#.

   Enter this value in only one of the two servers.

9. Click Invoke.

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.

   For information on targeting applications and resources, see Appendix B, "Targeting Applications and Resources to Servers."

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:

    ASERVER_HOME/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=ASERVER_HOME
    -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=MSERVER_HOME
   -overwrite_domain=true -template=soadomaintemplateExtSOABPM.jar 
   -app_dir=MSERVER_HOME/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 soadomaintemplateExtSOABPM.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=MSERVER_HOME/DOMAIN_NAME -overwrite_domain=true
   -template=soadomaintemplateExtSOABPM.jar -app_dir=MSERVER_HOME/applications
   

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_INSTANCE/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_INSTANCE/bin/opmnctl restartproc ias-component=ohs1
   WEBHOST2> ORACLE_INSTANCE/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 Balancers."

To verify the URLs:

1. While WLS_SOA2 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