Clustering WebSphere Process Server V6.0.2, Part 2: Install and configure WebSphere Process Server clusters

Basic steps guide: Install, configure, and set up WebSphere Process Server V6.0.2 clusters and the golden topology

The first article of this series discussed some of the topological options and trade-offs that you need to deal with when planning to cluster IBM® WebSphere® Process Server V6.0.2. You were also introduced to the "golden topology" and the steps needed to implement it. This article walks you through the steps to install the product and configure the clusters and the related resources. This two-part article series provides information for WebSphere Process Server V6.0.2 and is considered an update to IBM WebSphere Developer Technical Journal article: Basic steps for clustering WebSphere Process Server V6.0 (see Resources).

Michele Chilanti (chilanti@us.ibm.com), Consulting IT Specialist, IBM

Author photoMichele Chilanti is a Consulting IT Specialist with the IBM Software Services organization. He has over 15 years of experience working with a variety of products of the IBM software portfolio. Currently, he consults on a daily basis with IBM customers in the areas of business process modeling, implementation, and deployment. Michele regularly presents at conferences worldwide, and has authored a number of IBM and external technical publications.


developerWorks Contributing author
        level

Sriram Madapura, Senior IT Specialist, IBM

Sriram Madapura is a Managing Consultant with the IBM Software Services organization. Currently he consults in the area of process integration, implementation and deployment using IBM Websphere products.



18 April 2007

Also available in Chinese

Introduction

The first article of this two-part series debates, at a more theoretical level, the key options and the trade-offs that you need to keep in mind when clustering IBM®WebSphere® Process Server V6.0.2. This article takes a more practical approach and describes the step-by-step process to install, configure and set up the "golden topology" for WebSphere Process Server clustering.


Install WebSphere Process Server Version 6.0.2

For this project, we installed WebSphere Process Server Version 6.0.2.0 on both the ISSW1 and the ISSW2 systems. Version 6.0.2 is a refresh of the WebSphere Process Server 6.0.1 product and it is packaged also as a fully installable image. The installation procedure of WebSphere Process Server V6.0.2 also installs the prerequisite (WebSphere Application Server Network Deployment, V6.0.2.17).

Important: On the Windows® operating system, we recommend modifying the installation directory from its default value: (C:\Program Files\IBM\WebSphere\ProcServer) to a shorter value like: \WebSphere\ProcServer. Due to the limitation on the number of characters in Windows path names, you may incur problems if you accept the default.

We chose the Custom Install path and selected not to install the samples:

Figure 1. Installing WebSphere Process Server
Installing WebSphere Process Server

When the installation completed, we selected not to run the profile creation wizard that we ran manually in a subsequent step.

Important: Make sure you install the mandatory fixes as indicated by the IBM Software Support Web site.

You should realize that installing WebSphere Process Server is not the only way to achieve the target topology; you could use a different set of product combinations. In fact, it is important to note that WebSphere Process Server code is not needed to run the messaging infrastructure. You could install WebSphere Application Server Network Deployment V6.0.2.17 for messaging, and then federate any such node to the WebSphere Process Server cell.

You could also proceed by augmenting an existing installation of WebSphere Application Server to WebSphere Process Server. If you choose to proceed this way, you need to create the WebSphere Application Server profiles, augmenting them prior to federating them to the Deployment Manager cell, because augmentation of already federated profiles is not supported.


Create the databases for WebSphere Process Server

A number of database tables are needed for WebSphere Process Server. You have the freedom to create one or more databases to host the various schemas that contain the tables.

You need to find the right balance between creating many separate databases and creating all the schemas and tables in a single database. The latter practice is discouraged, because you will not be able to individually tune each database. However in a large installation, you may have multiple independent environments (with multiple Business Process containers and so on). You may end up with an extremely large number of databases if you choose to create a separate database for each component that needs it. However, if you wanted to configure multiple instance of BPC in separate clusters, each instance would need its own database.

A common practice is to create separate databases for the Messaging Engines, for the other WebSphere Process Server components (the WebSphere Process Server tables and BPC), and for the Common Event Infrastructure (CEI).

Within the Messaging Engine database, you can then create different schemas to support the different Messaging Engines.

The BPC does not provide explicit schema support. The schema is implied and coincides with the user ID specified in the authentication alias, at the time the BPC is configured.

Typically, you will need to manually create the databases ahead of installing and configuring WebSphere Process Server.

For the objects within the databases, such as schemas and tables, you have two options:

  1. You can let the WebSphere Process Server administrative functions create the objects automatically for you. The only exception is represented by the BPC database, which needs to be created using separate steps (discussed later). This implies that your database administrator agrees that the people who are responsible for configure WebSphere Process Server are going to be creating database objects. In a real-life production environment, this is hardly ever the case.
  2. You can have the database administrator create databases, schemas, tables, and other objects for you. WebSphere Process Server provides a set of scripts, or allows you to generate scripts, that can then be given to the database administrator. In this article, we followed a mixed approach. We created some of the schemas manually and we let the system create others. However, this paper indicates how to get hold of the scripts that perform the creation, if you want to follow a completely manual approach.

This article follows a mixed approach. We created some of the schemas manually and let the system create others. However, if you want to follow a completely manual approach, this paper indicates how to get hold of the scripts that perform the creation.

WebSphere Process Server needs the following schemas:

  1. A schema for the WebSphere Process Server repository. The default name for this database is WPRCSDB. Here we created a new and empty DB2® database (ISSWWPS) and then let the profile wizard create the schema and the tables for us in it. The tables will be created when you create the Deployment Manager profile (explained later).

    The ESB Mediation Log database table can also be created at this time. The scripts are located in:

    <WPS INSTALL DIRECTORY>\util\EsbLoggerMediation
  2. A schema for the Business Process Container and Human Task Container. This schema must be created manually, either by executing the database scripts, or by using the bpeconfig.jacl command. The scripts for creating the BPC database are located in:

    \WebSphere\ProcServer\dbscripts\ProcessChoreographer

    In our example, we created a new database called BPEDB and used the script createDatabseDb2.sql to create the tables. For production-grade configurations, we recommend using the two scripts createTablespaces.sql and createSchema.sql, as indicated by the Information Center. These two scripts also take care of creating a set of tablespaces, in addition to the schema and tables.

    We edited the SQL script file and changed the first two SQL statements to indicate the desired database name:

    -- create the database
    CREATE DATABASE BPEDB USING CODESET UTF-8 TERRITORY en-us;
    -- Use CONNECT TO BPEDB USER xxx when another user should become owner of the schema
    CONNECT TO BPEDB USER MICHELE USING PASSWORD;
  3. Each Messaging Engine needs a schema. These schemas can be configured for automatic creation at the time you configure the Messaging Engine. However, you can also create them manually. In that case, you need to generate the scripts using the sibDDLGenerator command in the WebSphere\ProcServer\bin directory. For example, to generate a script that will create a schema called SCAAPP, within the database MEDB to which the user MICHELE is fully authorized, you can use the following command:
    sibDDLGenerator.bat -system db2 -schema SCAAPP –user MICHELE
     	-create  –statementend ; > ME.ddl

    This command creates a script called ME.ddl which can be provided to the database administrator.

    In our scenario, we created a single database and four schemas (one per messaging engine). To change the schema names manually one can edit the ME.ddl file obtained in the previous step.

  4. WebSphere Process Server may also need a Common Event Infrastructure database. However, the scripts for this database aren't available until you have created a profile. We will delay the creation of this database to the section where we talk about configuring CEI.

    Summarizing, these are the databases and schemas we created ahead of starting the creation of the profiles (see Table 2):

Table 2. Databases, schemas, and functions created ahead of starting the creation of the profiles
DatabasesSchemasFunctions
ISSWWPSNone at this point. The profile creation wizard creates the schemas and tables. In addition, you can manually create the table for the ESB Log Mediation database.This is the WebSphere Process Server repository.
BPEDBSame as the user id utilized to connect to the database.Holds the Business Flow Manager and Human Task Manager information.
MEDBOne per Messaging Engine:
  1. BPEME for the choreographer
  2. CEIME for the Common Event Infrastructure
  3. SCAAPP for the SCA application messaging engine
  4. SCASYS for the SCA system messaging engine

Holds the persistent information for the messaging engines.
EVENTSame as the user ID utilized to connect to the database.CEI Application Database that is created using scripts.

Create the Deployment Manager profile

The first profile you should create is the WebSphere Process Server Deployment Manager profile.

  1. Launch the profile creation wizard from the directory:
    C:\WebSphere\ProcServer\bin\ProfileCreator_wbi.
    Make sure that you select this directory, and not the ProfileCreator directory, or you'll create a base WebSphere Application Server Deployment Manager profile.
  2. Select Deployment Manager profile in the profile type selection:
    Figure 2. Creating a Deployment Manager profile
    Creating a Deployment Manager profile
  3. Click Next. Name your profile (for example, ISSWDmgr), see Figure 3:
    Figure 3. Naming the Deployment Manager profile
    Naming the Deployment Manager profile
  4. Click Next. Select the profile directory (we left the default):
    Figure 4. Specifying the Deployment Manager directory
    Naming the Deployment Manager profile
  5. Click Next. Specify the host, node, and cell name (we left the defaults), see Figure 5:
    Figure 5. Specifying node, host, and cell name
    Specifying node, host, and cell name
  6. Click Next. The subsequent step is important: it will ask you for the user and password that the SCA infrastructure is going to use to connect to the system and application SI Buses (keep in mind that the SI Buses will not be created at this time. We will discuss them later when we create them.), see Figure 6:

    Figure 6. Specifying security credential for the SCA SI buses
    Specifying security credential for the SCA SI buses

    Important: The user and password specified in the dialog above needs to be a valid WebSphere Application Server user and password. These credentials are typically totally independent of the credentials you will need to specify to connect to the various databases. In this article, we assumed that the same credentials are used for the SI Bus and for the relational databases.

  7. Click Next. Now, you are asked whether you want to create a new database, or use an existing database. We have already created an empty database, so we selected Use an existing database. It's also important to notice that the automatic creation of the database is only allowed if the database is local.

    The wizard is smart enough to recognize that the database is empty, and will create the schema if necessary. If the database already contains the schema, the wizard will skip the creation, see Figure 7.

    Figure 7. Selecting a database for WebSphere Process Server
    Selecting a Database for WebSphere Process Server
  8. Click Next. Review the summary and click Finish:

    Figure 8. Reviewing the Deployment Manager creation options
    Reviewing the Deployment Manager creation options
  9. Once the profile has been created, you might want to check that the schemas and tables were created too. We did so by connecting to our database server and verifying the presence of the following tables in the ISSWWPS database, see Figure 9:

    Figure 9. Tables created for the Deployment Manager
    Tables created for the Deployment Manager

    You can also do that by issuing this script:

    db2cmd
    db2 connect to ISSWWPS user <...> using <...>
    db2 list tables for schema <user name>

    Tip: There are also scripts available to populate the database. Those scripts are available in the directory: \WebSphere\ProcServer\dbscripts\commonDB

  10. Verify that the J2C Authentication Aliases are in place. These are used in data sources and connection factories.
    1. Navigate to Security => Global security => JAAS Configuration => J2C authentication data entries.
    2. You should have an SCA_Auth_Alias (to be used when connecting to the messaging engines) and a WPSDBAlias (for the WebSphere Process Server database).
      Figure 10. Authentication aliases created for the Deployment Manager profile
      Authentication aliases created for the Deployment Manager profile

Create a WebSphere Process Server custom profile

We have a Deployment Manager profile; so we can now create the profiles for the managed nodes.

Let's start with the WebSphere Process Server node. In your topology, you may have multiple nodes residing on separate machines. In our scenario, there is just a single node for WebSphere Process Server and one for the messaging engine, but conceptually the same steps apply to larger configurations.

  1. Run the WebSphere Process Server profile creation wizard, see Figure 11:
    1. As you did for the Deployment Manager, launch the profile creation wizard pcatWindows.exe from the directory C:\WebSphere\ProcServer\bin\ProfileCreator_wbi.
    2. This time, select Custom Profile, see Figure 11:

      Figure 11. Creating a custom WebSphere Process Server profile
      Creating a custom WebSphere Process Server profile
    3. Click Next. Select the option to federate this profile to the cell at a later time:

      Figure 12: Options for the Custom WebSphere Process Server profile
      Options for the Custom WPS profile
    4. Important: If you choose to federate the node immediately, the Deployment Manager process has to be up and running.
    5. Click Next. Give a name to this profile and make it the default:

      Figure 13: Naming the Custom WebSphere Process Server profile
      Naming the Custom WPS Profile
    6. Click Next. Choose a directory for installation.
    7. Click Next. Choose node name and type in the system name (most of the times the defaults are fine). We used ISSW1Node for the node name.
    8. Click Next. Select the database type and driver location. For DB2, the driver is shipped with the product and no changes are normally needed.
      Figure 14: Selecting the database options for the custom WebSphere Process Server profile
      Selecting the database options for the custom WebSphere Process Server profile
    9. Review the summary and click Finish to complete the creation of the profile.
    10. Exit the wizard without further actions.

Create a WebSphere Application Server custom profile

In our topology, there is a single WebSphere Application Server node for messaging (the system ISSW2).

On that node, we need to create a base WebSphere Application Server profile. There is no use in creating a WebSphere Process Server profile to run just the messaging infrastructure.

  1. Run the WebSphere Application Server profile creator (not WebSphere Process Server), see Figure 15:
    1. Launch the profile creation wizard located in:
      C:\WebSphere\ProcServer\bin\ProfileCreator. Notice that this is a different location than the one we used to create a WebSphere Process Server profile.
    2. Choose Custom Profile: (the profile types are presented in a different order when you compare this screen to the one we see for WebSphere Process Server) Figure 26: Creating a plain WebSphere Application Server Profile
      Figure 15. Creating a plain WebSphere Application Server profile
      Creating a plain WebSphere Application Server profile
    3. Click Next and choose the option to federate the profile at a later time (if you want to federate the profile right away, you need to have the Deployment Manager running):
      Figure 16. Options for the WebSphere Application Server profile
      Options for the WebSphere Application Server profile
    4. Click Next and give your profile a name. We used ISSWWAS.
    5. Click Next and verify (or change) the host name and node name. In our scenario the node name was set to ISSW2Node.
    6. Click Next, verify the summary, and click Finish to complete the creation.
    7. Exit the wizard without further actions.

Adding the nodes to the Deployment Manager

We are now going to federate the nodes to the cell using the addNode command.

  1. Start the Deployment Manager.
    1. On the system where the Deployment Manager profile was created (ISSW1), run the startManager command out of \WebSphere\ProcServer\profles\ISSWDmgr\bin.
  2. When the Deployment Manager is up and running, on the same Deployment Manager system (ISSW1), add the WebSphere Process Server node to the cell:
    1. Change directories to:
      \WebSphere\ProcServer\profiles\ISSW01\bin
    2. Use the addNode command to federate the node to the Deployment Manager. This command takes the host name (or IP address) of the Deployment Manager system, and optionally the port number of the SOAP connector of the Deployment Manager, if you modified the default (which is 8879) or created more than one Deployment Manager profile on the same physical system. In our case, we executed the following command:

      addNode issw.rchland.ibm.com
    3. Wait for completion. The node agent is also started at this time.

      Important: When you need to add multiple nodes, make sure that you add one node at a time. Wait until each addNode command has completed before issuing the subsequent addNode command.

  3. Now switch to the system where the WebSphere Application Server profile was created (ISSW2) and federate that node:
    1. Change directories to: \WebSphere\ProcServer\profiles\ISSWWAS\bin
    2. Run: addNode issw.rchland.ibm.com
    3. Wait for completion. The node agent is also started at this time.
  4. Start the administrative console and verify that the two nodes have been federated.
    1. Navigate to System administration => Nodes. You should see the two nodes as shown in the picture below. Figure 17: List of Nodes.

      Figure 17. List of nodes
      List of Nodes

Create the cluster for the messaging engines

  1. Create a WebSphere Application Server cluster for the Messaging Engines. This cluster doesn't need WebSphere Process Server capability, because it only runs the messaging infrastructure.
    1. Navigate to Servers => Clusters. Click New. Give your cluster a name (MECluster), see Figure 18:
      Figure 18: Configuring the cluster for messaging
      Configuring the cluster for messaging
    2. Click Next. Create an initial cluster member. Give it a name (MEMbr01) and select the node where you want the member to reside. Leave the server template to default. By using a default template you create a "plain" WebSphere Application Server server, rather than a WPS-capable server:
      Figure 19. Selecting the correct server template
      Selecting the Correct Server Template
    3. You can create more members now or later. We suggest you create just one member to start with, and then grow the cluster as appropriate by adding members later on.
    4. Click Next. Review the summary and finish the creation process.
  2. For DB2, update the DB2 driver environment variables. In general, it is best to create these variables at the node level, because that gives you the freedom to customize each node independently. In our scenario, the systems we are using are identical in terms of disk drives, directory structure, database driver location, and so on. Therefore, we can define those variables at the cell level, so that every box in the cell will inherit those definitions:
    Figure 20. Defining WebSphere variables for the data source
    Defining WebSphere variables for the data sourceImportant: If you define variables at the cell level, make sure that you don't also have the same variables defined at the node or server level. Lower level definitions override the cell level definitions.
  3. Business Integration Configuration for the ME Cluster. We are going to use the Business Integration Configuration wizard, which is new in WebSphere Process Server V6.0.2. This simplifies the configuration of the clusters.
    1. Select the ME Cluster under the Server => Cluster menu.
    2. Click on the Business Integration Configuration link, which is located within the list on the right as shown in Figure 29.
      Figure 21. Business Integration Wizard (new in version 6.0.2)
      Business Integration Wizard (new in version 6.0.2)
    3. You'll get to the dialog shown in Figure 22:
      Figure 22. Business Integration Wizard for ME cluster, screen1
      Business Integration Wizard for ME cluster, screen1
    4. On this dialog, select Local under Setup SCA Destination. This step will set up the SCA buses on the ME Cluster. Installation of other applications (Business Rules Manager, Business Processes and Human Task should not be selectable, since this is a pure WebSphere Application Server cluster.
    5. Click Next. You'll get to the following screen (see Figure 23).
      Figure 23. Business Integration Wizard for ME cluster, screen 2
      Business Integration Wizard for ME Cluster, Screen 2
    6. Select the XA JDBC Driver provider and input the appropriate user name and password. Click Next.
    7. The dialog in Figure 22 appears. Here you can specify the data source and database information for the Messaging Engine data store. Notice that we have "Create Tables" selected, if you are using a database which was created as indicated in a previous section in this document, leave these checkbox unchecked.
      Figure 24. Business Integration Wizard for ME cluster, screen 3
      Business Integration Wizard for ME Cluster, Screen 3
    8. Notice that we set the database name (MEDB) and schemas (SCASYS and SCAAPP). Click Finish and save your work.

Artifacts created using the Business Integration Wizard for the ME cluster

We want to review the artifacts created during the execution of the Business Integration wizard for the ME cluster.

  1. Navigate to Service Integration => Buses. You should see the buses as shown below in Figure 25.
    Figure 25. SCA SI buses
    Business Integration Wizard for ME Cluster, Screen 3
  2. Unlike in WebSphere Process Server V6.0.1, the SCA SI buses (System and application buses) are only created after the Business Integration wizard is executed.
  3. Verify that for each of the buses there is one and only one Bus member as shown below.
    Figure 26. SCA SI bus members
    SCA SI Bus Members
  4. Navigate to Service Integration => Buses => SCA.APPLICATION.isswCell01.Bus. => Messaging Engines => MECluster.000-SCA.APPLICATION.isswCell01.Bus => Data Store. You should see the screen below.
    Figure 27. SCA SI bus data store
    CA SI Bus Members
    The screen shot above shows the JNDI name for the data source.
  5. Verify that the data source is created and that you can test it. To verify the data source navigate to Resources => JDBC Providers => Apply ME Cluster Scope. You should see the data sources created using the Business Integration wizard. To Test the data source the corresponding node agent needs to be up and running. The data sources created using the wizard are shown below.
    Figure 28. SCI bus data sources
    SI Bus data sources

Start the Cluster to make sure that the Messaging Engines work (they should be in the "started" state, Also check the SystemOut.log for the servers in the cluster).

Tip: Should you ever need to re-create a bus, make sure that you drop and re-create the schema, or you will have trouble when the messaging engine starts up, because of existing data in the database schema itself.


Create the WebSphere Process Server cluster

Now that we have the messaging infrastructure in place, we can create the WebSphere Process Server cluster where the WebSphere Process Server applications can be installed.

  1. Create the cluster.
    1. Navigate to Servers => Clusters and click New.
      Figure 29. Creating the WebSphere Process Server cluster
      Creating the WebSphere Process Server cluster
    2. Create one member (WPSMbr01) of type defaultProcessServer (make sure that you change the default, or you will create a cluster that doesn't support WebSphere Process Server applications). Also, make sure that you select a node where WebSphere Process Server is installed. In our scenario, we did create a profile for WebSphere Process Server only on the node ISSW1Node.
      Figure 30. Creating the WebSphere Process Server cluster
      Creating the WebSphere Process Server clusters
    3. Click Apply to confirm the creation of the WebSphere Process Server cluster member.
    4. Click Next.
    5. Review the summary and complete the creation of the cluster by clicking Finish.
  2. Business Integration Configuration for the WPS cluster. Again, we want to use the new Business Integration Configuration wizard of WebSphere Process Server 6.0.2, which simplifies the creation and configuration of BPC and Human Task applications.
    1. To execute the wizard select the WPS Cluster under the Server => Cluster menu.
    2. Click on the Business Integration Configuration link, which appears on the list of links under Additional Properties. You'll get to the dialog in Figure 29.
      Figure 31. Business Integration Wizard for WPS cluster, screen 1
      Business Integration Wizard for WPS cluster - Screen 1
    3. As the previous diagram indicates, you should select Remote for the SCA Destination, because the WPS Cluster uses the SCA SI Buses we have created on the ME Cluster. We have selected to configure the Business Rules Manager, Business Process Container and the Human Task Container here.
    4. Click Next. You'll get to the second dialog, as shown in Figure 30.
    5. Select the database driver you want to use and specify user and password for the database.
      Figure 32. Business Integration Wizard for WPS cluster, screen 2
      Business Integration Wizard for WPS Cluster, Screen 2
    6. Click Next. You'll get to the dialog shown in Figure 33.
    7. Select Use a remote destination location, as the screen shot indicates. The applications as part of the WebSphere Process Server cluster are configured to use the remote SCA destination that is part of the already installed ME Cluster.
    8. Figure 33. Business Integration Wizard for WPS cluster, screen 3
      Business Integration Wizard for WPS Cluster - Screen 3
    9. Click Next. The subsequent screen (Figure 32 ) allows you to select the CEI Emitter Factory JNDI name. Keep in mind that this step does not configure the CEI Event Server. It just tells the WPS Cluster the name of the emitter factory. We leave the default here.
      Figure 34. Business Integration Wizard for WPS cluster, Screen 3
      Business Integration Wizard for WPS Cluster, Screen 3
    10. Click Next. Leave the Install business rules manager checkbox checked, as in Figure 35.
      Figure 35. Business Integration Wizard for WPS cluster, screen 5
      Business Integration Wizard for WPS Cluster, Screen 5
    11. Click Next. You get to the dialog in Figure 36. This dialog allows you to configure the BPC Explorer. Notice that you may skip this dialog by checking the Config with the business process container installation wizard (which is the "traditional wizard" we had in V6.0.1, and which is still fully available). We decided to use the new dialog.
      Figure 36. Integration Wizard for WPS Cluster - Screen 6
      Integration Wizard for WPS Cluster - Screen 6
    12. In the previous screen, we selected the DB driver and specified the Data Source user and password. These parameters will configure the BPE DB data source.
    13. We also specified the JMS User Id and password, which configure the JMS Connection Factories associated with the Business Process Choreographer (BPECF, BPECFC, and HTMCF).
    14. We also specified the JMS API User Id and password, which are used to configure the RunAs parameter of the MDB associated with the Business Process Container (a good value here is a valid WebSphere Process Server user, possibly with administrator privileges).
    15. We selected to install the BPC Explorer (web client) and enabling CEI logging for the processes.
    16. We also set the Administrator and Monitor user group mapping (it has to be mapped to a valid WebSphere Process Server user group, which must be present in the user registry to be utilized for security).
    17. Notice that nowhere does this dialog ask for the BPE DB name we'll have to set that value later.
    18. Click Next. You get to the dialog that allows you to set up the Human Task Container (Figure 37).
      Figure 37. Business Integration Wizard for WPS Cluster - Screen 7
      Business Integration Wizard for WPS Cluster - Screen 7
    19. Again, notice that the traditional wizard is still an option. We used the new wizard and specified the JMS user id/password, escalation user id/password and Administrator/Monitor role mapping (to a valid WebSphere Process Server user group, which must be present in the user registry to be utilized for security).
    20. Click Next.
    21. On the summary screen (Figure 38), review and click Finish.
      Figure 38. Business Integration Wizard for WPS cluster, screen 8
      Business Integration Wizard for WPS cluster, screen 8
    22. You should get a message in the console indicating successful completion.

Applications installed after a successful completion of the Business Integration Wizard for the WPS cluster

This section discusses artifacts created during the execution of Business Integration wizard for the WebSphere Process Server Server. Selecting Applications => Enterprise Applications indicates that the BPC Explorer, Business Process Container, BR Manager, and Human Task container should all be installed.

Figure 39. Installed Apps post Business Integration wizard completion
Installed Apps post Business Integration wizard completion

Manual changes required for WebSphere Process Server cluster

The current version of the Business Integration wizard does not prompt for database names or schemas in various places. Three resources need manual changes, the changes are discussed below.

  1. Changing the BPE DB Data source. The first data source that may need modification is the data source for the Business Process Choreographer.
    1. Navigate to Resources => JDBC Providers. Set the scope to the WPS Cluster.
    2. Navigate to DB2 Universal JDBC Driver Provider (XA) => Data sources.
    3. You should see Data source for the process choreographer as shown below.
      Figure 40. BPE Data source
      BPE Data source
    4. Click on the data source. The following screen shows you the details:
      Figure 41. Configuring BPE Data Source
      Configuring BPE Data Source
    5. Scroll down to the section where you can see the database name:
      Figure 42. Examining the Database Name for the BPE Data Source
      Examining the Database Name for the BPE Data Source

      If the database name you used is different from BPEDB, then appropriate changes need to be made.

    6. After making changes, make sure you save your work.
  2. BPC SI Bus Data Source Configuration
    1. Navigate to Resources => JDBC Providers. Set the scope to the cell level.
    2. Navigate to DB2 Universal JDBC Driver Provider (XA) => Data Sources.
    3. You should see the BPC SI Bus Data Source as shown below.
      Figure 43. BPC SI bus JDBC resource
      BPC SI bus JDBC resource
    4. Click on the BPC SI bus Data source to edit it as shown below.
      Figure 44. Editing the BPC SI Bus Data Source
      Editing the BPC SI Bus Data Source
    5. On this page, scroll down to highlight the DB2 Universal database properties (Figure 45). Notice that the wizard assumes that the Messaging Engine schema is located in the same database as the Business Process Choreographer schema -- the BPEDB database.
      Figure 45. Default Database Settings for the BPC Messaging Engine Data Source
      Default Database Settings for the BPC Messaging Engine Data Source
    6. Change the Database name for the BPC Messaging Engine Data Source to match the location of the messaging engine schema. In our case, as indicated in Figure 46, we changed it to MEDB.
      Figure 46. Updated Database Settings for the BPC Messaging Engine Data Source
      Updated Database Settings for the BPC Messaging Engine Data Source
    7. Save your changes. This completes the manual modifications.
  3. BPC SI Bus Data Store Configuration

    The last manual change required is configuring the Data store associated with BPC SI Bus.

    1. Navigate to Service Integration => Buses => BPC.isswCell01.Bus. You should see the screen below.
      Figure 47. BPC SI Bus Data Store
      BPC SI Bus Data Store
    2. Click on the Bus to highlight the details. Click on Messaging Engines and then click the messaging engine name (typically, the name is <Cluster Name>.000-<Bus Name>).
    3. Click the Data Store link (figure 48).
      Figure 48. Configuring BPC SI Bus Data Source
      Configuring BPC SI Bus Data Source
    4. Notice that the schema name corresponds to the the default Scheme Name (IBMWSSIB). Change it to the desired schema name (BPCME in our example) and assign the appropriate Authentication Alias for database authentication
    5. Save your work. This step completes making the manual changes.

Create the CEI cluster

We can now configure and install the Common Event Infrastructure on the CEI cluster. In the Golden Topology CEI is configured in a separate cluster. In the Silver Topology, the CEI is configured as part of the WPS cluster.

  1. Create the cluster.
    1. Navigate to Servers => Clusters and click New. Create the CEI cluster as suggested below
      Figure 49. Create CEI cluster
      Create CEI cluster
    2. Create one member of type defaultProcessServer (make sure that you change the default -- or you will create a cluster that doesn't support WebSphere Process Server applications). Also, make sure that you select a node where WebSphere Process Server is installed. In our scenario, we did create a profile for WebSphere Process Server only on the node issw2Node01.
      Figure 50. Adding members to the CEI Cluster
      Adding members to the CEI cluster

Installing the CEI application

  1. Create the Common Event Infrastructure database. In order to do so, we need to generate some scripts and execute them.
    1. a. Open a command prompt and change you current directory to be <WPS_INSTALL_ROOT>\profiles\<CEI Profile directory>\event\dbconfig
    2. There are a number of scripts here -- since we are using DB2, we are going to use the corresponding script. Make a copy of the DB2ResponseFile.txt file. Open the file with a text editor to make some changes as indicated next.
    3. Make the following changes (you may have different values for the driver location, type, and DB Instance Port depending on how DB2 is configured):
      CLUSTER_NAME=CEICluster
      SCOPE=cluster
      DB_NAME=EVENT
      DB_NODE_NAME=<your remote DB node name>
      JDBC_CLASSPATH="<WPS_INSTALL_ROOT>\universalDriver_wbi\lib"
      UNIVERSAL_JDBC_CLASSPATH="<WPS_INSTALL_ROOT>\\universalDriver_wbi\lib"
      JDBC_DRIVER_TYPE=4
      DB_HOST_NAME=<your DB host name>
      DB_INSTANCE_PORT=50000
      EXECUTE_SCRIPTS=NO
    4. Save the changes.
    5. Run the following command: config_event_database.bat DB2ResponseFile.txt
    6. The previous command creates a set of scripts to create the CEI database in <WPS_INSTALL_ROOT>\profiles\<WPS profile directory>\event\dbscripts\db2. Make that directory your current directory.
    7. In order to create the CEI database on a remote system, run the following command: cr_event_db2.bat client <user> <password>
    8. Once you have successfully created the database, change directories to WPS_INSTALL_ROOT>\profiles\<WPS profile directory>\event\dsscripts\db2. Here you will find the script to configure the data sources that are needed for CEI.
    9. Run the following command to create the datasources on the cluster (make sure that the Deployment Manager is up and running first): cr_db2_jdbc_provider cluster CEICluster
    10. Provide the database user ID and password when prompted to do so and let the script complete.
  2. Verify that the command created the JDBC provider and the data sources.
    1. Open the administrative console.
    2. Navigate to Resources => JDBC Providers and set the scope to the cluster level. You should see a JDBC provider called Event DB2 JDBC Provider:
      Figure 51. The JDBC provider defined for CEI
      The JDBC provider defined for CEI
    3. Click on the provider and then click Data Sources.
    4. You should see two data sources:
      Figure 52. Data sources created for CEI
      Data sources created for CEI
  3. We are now ready to install the CEI applications. There are two of them one that implements the CEI engine and another that allows asynchronous emission of CEI events.
    1. Let's start by installing the CEI engine. Make <WPS_INSTALL_ROOT>\profiles\<WPS Profile>\event\application your current directory.
    2. Issue the following command, on a single line (this command works for DB2 V8.2 and assuming your WPS cluster is called WPSCluster):
      ..\..\bin\wsadmin -profile event-profile.jacl -f 
      event-application.jacl -action install 
      -earfile event-application.ear 
      -backendid DB2UDBNT_V82_1 -cluster CEICluster
    3. Now, let's install the CEI message application for asynchronous publishing. In the same directory, issue the following command (on a single line):
      ..\..\bin\wsadmin -profile event-profile.jacl -f 
      default-event-message.jacl -action install 
      -earfile event-message.ear  -cluster CEICluster
  4. The two commands that we issued did not only install the applications, but they also created some SI Bus resource definitions for CEI. In a clustered environment, you need to modify some of those definitions. The issue with the SI Bus that gets created is that it has the incorrect bus member (in other words, the wrong cluster). Also, the default configuration for the CEI SI Bus uses Cloudscape. We need to create a DB2 data source for the CEI SI Bus.
    1. Open the console and navigate to Service Integration => Buses. Notice that a new bus has been created, called CommonEventInfrastructure_Bus:
      Figure 53. The SI bus created for CEI
      The SI bus created for CEI
    2. This bus, as we mentioned, needs a couple of changes. Let's start by creating a suitable data source, so that the messaging engine will use DB2 instead of Cloudscape. In the console, navigate to Resources => JDBC Providers.
    3. Set the scope to the MECluster level. Navigate to DB2 Universal JDBC Driver Provider (XA) => Data sources. You will see the three data source already created for the SCA and BPC messaging engines. Click New to create a new data source for the CEI messaging engine.
    4. Call the data source CEIMEDS and set the JNDI name to jdbc/CEIMEDS. Scroll down and set the database name to be MEDB, as we did for the other SI Bus instances (see for example figure 46.)
    5. Save your changes. Let's now go back to the CEI SI Bus definition, by navigating to Service Integration => Buses and clicking on CommonEventInfrastructure_Bus.
    6. On the resulting screen, click Bus Members. You will see that the CEICluster has been added as a bus member -- which is not what we want, since we have defined a separate cluster to host the messaging engines.
    7. Select that bus member and click Remove.
    8. Subsequently, click Add and add the MECluster to the bus. Specify jdbc/CEIMEDS for the data source JNDI name:
      Figure 54. Setting the Correct Cluster as a Member of the CEI SI Bus
      Setting the Correct Cluster as a Member of the CEI SI Bus
    9. Click Next and then Finish.
    10. Click again CommonEventInfrastructure_Bus and click Messaging Engines.
    11. Click the MECluster.000-CommonEventInfrastructure_Bus and click Data Store.
    12. Specify CEIME for the schema, select the WPSDBAlias for the authentication alias, and uncheck Create Tables:
      Figure 55: Setting the Correct Database Schema for the CEI Messaging Engine
      Setting the correct database schema for the CEI messaging Engine
    13. Click OK and save your changes.
  5. You now need to create two physical destinations on the bus for CEI.
    1. Select Service Integration => Buses and click the CommonEventInfrastructure_Bus.
    2. Click Destinations.
    3. Click New and select Queue. Click Next.
    4. Type CommonEventInfrastructureQueueDestination for the Identifier. Click Next.
    5. Make sure that the bus member is set to be MECluster.
    6. Click Next and then Finish.
    7. Click New again, and this time select Topic space.
    8. Type CommonEventInfrastructure_AllEventsTopic for the Identifier. Click Next.
    9. Click Next and Finish.
    10. Save your configuration changes.
  6. The CEI application is now part of a separate cluster. Therefore the default CEI bus transmission profile must be modified to account for this change.
    1. Navigate to Resources => Common Event Infrastructure Provider => Apply Cell Scope.
    2. Click on the event bus transmission profile. Click on the Default Common Event Infrastructure event bus transmission.
      Figure 56. Event bus transmission profile
      Event bus transmission profile
    3. For the default event bus Transmission profiles, make sure that the event bus JNDI name is a fully qualified one, that is: cell/clusters/CEICluster/ejb/com/ibm/events/bus/EventBus.
      Figure 57. Modify the Event bus transmission profile
      Modify the Event bus transmission profile
  7. Recycle the clusters to allow them to pick up the new changes.
    1. Stop WPSCluster, CEICluster, and the MECluster.
    2. Start MECluster.
    3. Start WPSCluster.
    4. Start CEICluster.
    5. Ensure that the application servers start cleanly by checking the SystemOut.log files of all the Cluster members.

Verifying the clusters functionality and growing the clusters

Initially, we recommend you create clusters with a single cluster member. By doing so, you will be able to more easily test the configuration while you are building the clusters.

Once you are comfortable with your configuration, you will be able to add new members to the clusters.

In order to test the configuration, you may need a simple test application that includes some SCA functionality, and a long running business processes with staff so that you can test most of the components that we configured and installed.

Before you proceed with application installation and testing, follow these steps:

  1. Verify the creation of the data source for the Business Process Choreographer:
    1. Go to Resources => JMS Providers.
    2. Set the scope to the cluster level for the WPSCluster.
    3. Click the DB2 Universal JDBC Driver Provider (XA).
    4. Click Data sources.
  2. Verify the creation of the JMS resources for the Business Process Choreographer:
    1. Go to Resources => JMS Provider and select Default Messaging.
    2. Set the scope to the cluster level for the WPSCluster.
    3. Click JMS Connection Factory. Verify that the following connection factories have been configured:
      1. BPECF
      2. BPECFC
      3. HTMCF
    4. Click Cancel. Now click JMS Queue Destinations. You should see the following queues:
    1. BPEApiQueue_WPSCluster (JNDI name: jms/BPEApiQueue)
    2. BPEHldQueue_WPSCluster (JNDI name: jms/BPEHldQueue)
    3. BPEIntQueue_WPSCluster (JNDI name: jms/BPEIntQueue)
    4. BPERetQueue_WPSCluster (JNDI name: jms/BPERetQueue)
    5. HTMHldQueue_WPSCluster (JNDI name: jms/HTMHldQueue)
    6. HTMIntQueue_WPSCluster (JNDI name: jms/HTMIntQueue)
  3. Start the Messaging engine cluster and subsequently the WPS cluster.
    1. Verify that each cluster starts correctly by checking the SystemOut.log of each member.
  4. Verify that the Business Process Explorer application works correctly.
    1. The application can be reached at the following URL:

      http://<WPS Cluster hostname>:<port number>/bpc

      For instance, if you are testing on your local machine, and you have the default HTTP transports for your WPS cluster member, you can try:

      http://localhost:9080/bpc
    2. If the transport is not the default transport (for example, the WPS cluster member's Web container works on port 9081), you need to add a virtual host to your cell for that port.
      1. Open the console, and navigate to Environment => Virtual Hosts.
      2. Click default_host and then Host Aliases.
      3. Verify an entry exists for Port 9081
  5. Install and test your application.

    Once you have verified that the BPC explorer works correctly, you are in a good position to install and run the test applications you may have prepared. You can use the BPC explorer to kick off any business processes or human tasks in those applications.

  6. Grow the clusters. In order to grow the clusters, proceed as follows:
    1. Using the console, navigate to Servers => Clusters and then click the name of the cluster you want to grow (for example, MECluster).
    2. Click Cluster Members and then New.
    3. Specify a member name, and select a node to host the new cluster member.
    4. Click Apply if you want to add more members. At the end, click Next.
    5. Check the summary and click Finish.
    6. Repeat these steps for the WPS cluster.
    7. Add the virtual hosts corresponding to the additional cluster members (each cluster member will listen on its own port for HTTP and HTTPs. You need to add virtual hosts definitions to match those ports.)
    8. Restart the clusters.
    9. Ensure that each cluster member starts correctly, by checking the SystemOut.log of each server.
  7. Test the applications on the final configuration.

    Now that the final configuration is up and running, you may want to perform a series of tests to ensure that the applications are running on each cluster member.

    A first, very simple test is to ensure that the BPC explorer is running on each member.

    Subsequently you may want to run a long running BPEL process, and verify that is executed correctly. If the process is made of a large number of activities, you should verify that those activities are executed on different cluster members.

    Testing failover is also important. You may want to make sure that long running processes can continue to run if the server where they were initiated is stopped abruptly, and you may want to verify the failover behavior of short-running processes.


More complex topologies

The topology we built in this paper is a significant example of a clustered topology for WebSphere Process Server.

However, there are many variations that you need to keep in mind, which may be used to address larger environments.

For a general discussion of these advanced topologies we suggest you refer to the following papers:

  1. WebSphere Process Server and WebSphere Enterprise Service Bus deployment patterns, Part 1: Selecting your deployment pattern.
  2. WebSphere Process Server and WebSphere Enterprise Service Bus deployment patterns, Part 2: My first WebSphere Process Server cluster.

Partitioned destinations

We have already discussed this option in the section Key Topologies for WebSphere Process Server Clustering.

Partitioning the destinations provides the advantage of having multiple instances of the Messaging Engines for SCA, BPC, and CEI active at the same time. As we mentioned, this options is a way to increase the scalability of the Messaging Engine.

In general, we recommend you avoid this approach, since it carries significant limitations. Charlie Redlin's article, WebSphere Process Server and WebSphere Enterprise Service Bus deployment patterns, Part 1: Selecting your deployment pattern, discusses these limitations in detail (see Resources). Here we mention them in summary:

  1. There is no guarantee of true balancing across partitions. For this reason, you may end up with significantly under-utilized or over-utilized partitions.
  2. Stateful applications rely on connecting to a specific partition. For example, an SCA application that uses JMS to perform a synchronous request/response operation expects the response on a specific partition. If the response is delivered to a different partition, it won't be processed correctly.
  3. Stranded (or orphan) messages are also an issue with certain configurations that include partitioned destinations. This problem occurs when a cluster member fails, and the messaging engine fails over to another cluster member. In some circumstances, there are no Message-driven Beans that are ready to process messages from the failed over messaging engine, and any message on the affected partition will be unprocessed.
  4. Ordering is also a known issue with partitioned destinations. There is no guarantee that messages will be processed in the order they were sent to the destination. For some applications, this may be a major problem.

Separating the "administrative applications" from the SCA. BPEL, and HTM applications

WebSphere Process Server includes a number of "ancillary" applications to help with administration and troubleshooting of WebSphere Process Server applications.

Those applications are (in addition to the administrative console, which is not specific to WebSphere Process Server):

  • Failed Event Manager
  • Relationship Manager
  • Common Base Event Browser
  • Business Rules Manager
  • Business Process Observer
  • Business Process Choreographer Explorer

The first three applications in this list are hosted by the Deployment Manager. Making them highly available implies making the Deployment Manager highly available. This can be done using known techniques, such as placing the Deployment Manager on its own system, and protecting that system with an Operating System failover mechanism (for example, HACMP for AIX).

It is possible to install the Business Rule Manager, the Business Process Observer, and the Business Process Choreographer Explorer in different servers or clusters, in order to increase the scalability of the overall solution.


Conclusion

WebSphere Process Server offers a solid basis for customers to build a scalable and highly available application environment. This article provides a starting point for those customers and practitioners who need to set up a basic clustered WebSphere Process Server installation.

The article illustrates detailed steps for how to set up a reasonably simple and yet robust clustered topology. However, you must keep in mind that there are a wide variety of possible topological solutions for WebSphere Process Server, which ensure different levels of scalability and availability.

Resources

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into WebSphere on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=WebSphere, Business process management
ArticleID=208958
ArticleTitle=Clustering WebSphere Process Server V6.0.2, Part 2: Install and configure WebSphere Process Server clusters
publish-date=04182007