Building clustered topologies in WebSphere Process Server V6.1

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

Learn to use WebSphere Process Server V6.1 to create a clustered "Gold" topology using a template-driven approach. This article shows you how to create the cell and federate two empty nodes to it, create a deployment environment, which is a template for the clustered topology, and test the topology.

Michele Chilanti (chilanti@us.ibm.com), Senior Managing Consultant, IBM

Author photoMichele Chilanti is a Senior Managing Consultant 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.



19 March 2008

Introduction

Building clustered topologies in IBM® WebSphere® Process Server V6.1 has become a much simpler process. From a conceptual standpoint, the considerations related to planning and setting up a clustered topology for WebSphere Process Server V6.0.2 are still applicable to V6.1. See the article, Clustering WebSphere Process Server V6.0.2, Part 1: Understanding the topology. However, from a practical standpoint, WebSphere Process Server V6.1 offers a much simpler and more intuitive approach at defining and configuring the entire topology.

In WebSphere Process Server V6.1, you no longer need to run the cluster configuration wizards multiple times. Also, the configuration of the Common Event Infrastructure (CEI) is well integrated with the definition of your clustered topology. In fact, WebSphere Process Server V6.1 allows you to describe the entire topology that you want to set up by defining a new type of configuration object called a Deployment Environment.

In this article, you create a clustered "Gold" topology for WebSphere Process Server using a template-driven approach. After you create the cell and federate two empty nodes to it, you'll create a deployment environment that serves as a template for the clustered topology. You will then generate the deployment environment and test the topology.

Prerequisites

You will need to install the following software to build the topology:

  • Install WebSphere Process Server V6.1.0
  • Install a supported version of DB2® (V8.2 FP 6 or V9.1)

The list of prerequisites is on the Software support site.


Defining the deployment environment

A deployment environment contains the definition of the entire topology. You will be able to define the entire topology in a single place:

  • Topology type. The type of topology that you want to create (whether you want the "gold", "silver", or "bronze" topology).
  • Nodes. The nodes you need to participate with the topology.
  • Clusters. How you need to distribute the clusters in the topology.
  • Characteristics of databases and schemas. The characteristics of the databases and schemas that are required by the topology, and the credentials that are needed to connect to the databases.
  • Installation definitions. The definitions that are necessary for the installation of the Business Process Container and of the Human Task Manager.

Once you have defined the deployment environment, you can generate the resources associated to the topology in a single step. The generation will also fully configure the CEI resources and applications.


Selecting the type of topology

To create a deployment environment, you need to begin by selecting the type of topology.

The Deployment Environment creation wizard allows you to select among four different topologies:

  1. Single Cluster: Topology also known as the "Bronze" topology. In this topology, all the functional pieces (user applications, messaging infrastructure, CEI, support applications) run in the same cluster. We discourage adopting this approach if you have asynchronous interactions or long-running BPEL processes, because of scalability issues.
  2. Remote Messaging: Topology equivalent to the "Silver" topology. Here, the Messaging Engines are configured on their own cluster. User applications, CEI, and support application coexist in the same cluster. In total, you will be creating two clusters. This topology is adequate when you do not plan to make very intensive use of the CEI.
  3. Remote Messaging and Remote Support: Topology that corresponds to the "Gold" topology. In this topology, there are three clusters:
    1. Application: Cluster where you can run the user applications.
    2. Messaging: Cluster where the messaging infrastructure is configured.
    3. Support: Cluster primarily runs the CEI, and also other support applications, such as the Business Rule Manager.

The Remote Messaging and Remote Support topology is perhaps the most frequently adopted topology because of the flexibility it offers in terms of its potential for scalability.

You can create a deployment environment in any of the following phases; however, for production implementations, we recommend the third approach, because it is the only approach that provides full control over the whole definition of the deployment environment.

  • Profile creation time: Powerful for demonstrations or prototyping.
  • Installation time: Use if you choose to also create a profile while installing the product. Powerful for demonstrations or prototyping.
  • After you have federated the nodes to the cell (using the administrative console or a script). Recommended for production implementations because this is the only approach that provides full control over the entire definition of the deployment environment.

Before you begin building the deployment environment, you need to focus on a very important aspect of Deployment Environments. A deployment environment is just a description of the topology. It doesn't really contain or refer to the actual resources (such as servers, data sources, SI Buses, and so forth.) that constitute the topology itself.

The deployment environment definition provides you with a one-click generation button that allows you to create the entire clustered topology at once, rather than going through a large number of separate and unrelated steps.

However, once you have generated the deployment environment, WebSphere Process Server maintains no direct relationship between the deployment environment definition and the resources that are generated. The practical implications of this fact are:

  1. After generation, you are not allowed to make a change to the deployment environment definition and re-generate the Deployment Environment. You need to "start from scratch" if you need to do so.
  2. After generation, if you make a change to a specific resource that was generated (say, a data source), that change will not be reflected into the deployment environment.

It's a good practice, therefore, to save your configuration after creating the deployment environment and before you generate it. This practice allows you to easily restore the initial configuration in case you need to make a change and start over.

Now that you understand the benefits and the limitations of using a deployment environment for configuring a clustered topology, let's walk through the steps that are required to create a simple "gold" topology. For the sake of simplicity, we have concentrated our clustered topology on a single system; however, the steps would be pretty much the same if you have multiple, separate boxes.

Figure 1. Figure 1. The target topology we intend to build
The target topology we intend to build

The topology shown in figure 1 consists of two nodes and a Deployment Manager process. Across the two nodes, we create three clusters:

  1. One for the messaging infrastructure.
  2. One for the WebSphere Process Server applications.
  3. One for the CEI, and other support applications.

Each cluster has a member on each of the two nodes, for a total of six cluster members.

Notice that the figure depicts the entire cell as being hosted on a single physical system. However, the procedure for setting up a truly distributed cell, comprised of multiple boxes, would not differ significantly from the one exposed here.


Creating the profiles and federate the nodes

In this section, you will create the Deployment Manager and Custom profiles necessary for our topology, and you will federate them to the cell. We chose to follow the approach where the deployment environment gets created after federation, because that way you have better control over the configuration of the resources being created.

Important: This article assumes the usage of DB2 UDB for all the databases. It also assumes the following authentication credentials:

  • The DB2 administrator user and password (db2admin/xxxxxx in the text).
  • The WebSphere Process Server administrator user and password (admin/admin in the text).

The article also assumes that the WebSphere Process Server product binaries have already been installed, along with the appropriate version of DB2, and that no existing profiles have been created yet.

Let's start with the creation of the Deployment Manager profile. You are going to be using the new Profile Management Tool to create the various profiles.

  1. Open a command prompt and change directories to <WPS_INSTALL>\bin\ProfileManagement.
  2. Launch the Profile Management tool by typing pmt and pressing Enter.
  3. When the Profile Management Tool comes up, click the Create.
  4. On the Welcome to the Profile Management Tool dialog, click Next.
  5. On the subsequent dialog, you need to make sure you select the WebSphere Process Server entry from the list, as indicated in Figure 2:
    Figure 2. Figure 2. Selecting WebSphere Process Server for Profile Creation
    Selecting WebSphere Process Server for Profile Creation

    Important: The Profile Management Tool is not available on the supported 64-bit platforms. On those platforms, you should rather use the manageprofile command line tool, in order to perform these tasks.

    1. Click Next.
    2. Select the Deployment Manager profile, as indicated in figure 3:
      Figure 3. Figure 3. Selecting a Deployment Manager Profile
      Selecting a Deployment Manager Profile
    3. Click Next.
    4. Now, select Advanced profile creation, as shown in figure 4. You don't want to create a deployment environment at this time:
      Figure 4. Figure 4. Selecting Advanced Creation
      Selecting Advanced Creation
    5. Click Next.
    6. On the subsequent screen, leave the checkbox checked for Deploy the administrative console. Click Next.
    7. Leave the defaults for the name of the profile and the directory. You are going to create a profile called Dmgr01 as illustrated in figure 5:
      Figure 5. Figure 5. Specifying the profile name and location
      Specifying the profile name and location
    8. Click Next. Leave the defaults for the cell name, host name, and node name. Take a mental note of those names and notice that the node name is called <system name>CellManager01. This node is a "fictitious" node which is created to encompass the deployment manager process.
    9. Click Next, and uncheck Enable Administrative Security. You do not want to enable security at this time.
    10. Click Next. The dialog that ensues allows you to customize the ports for the deployment manager. Leave the defaults. By default, the console should be available on port 9060 and the SOAP connector on port 8879. If you have other versions of WebSphere Application Server installed on your system, the proposed ports may vary.
    11. Click Next. Uncheck Run the deployment manager as a Windows service. You are going to stop and start the deployment manager manually from the command line.
    12. Click Next. On the Database Configuration panel, select DB2 Universal Database for the database product. Leave the rest to the default, as shown in figure 6. However, notice that you could delay the creation of the common database, and that you could change the directory where the DB creation scripts are going to be saved. The database name is, by default, WPRCSDB. However, you can change that too. It's important that you understand that a cell will rely on a single common database.
      Figure 6. Figure 6. Defining the database product to use
      Defining the database product to use
    13. Click Next. The format of this screen varies with the database product you chose on the previous step. For DB2 UDB, you'll need to provide the authentication credentials, the location of the JDBC driver, the driver type, and the host name and port number of the database server process. Specify db2admin for the user and the password provided to you by the instructor and leave the rest as it is, as shown in figure 7:
      Figure 7. Figure 7. Specifying the database configuration parameters
      Specifying the database configuration parameters
    14. Click Next. Review the settings and click Create, as shown in figure 8:
      Figure 8. Figure 8. The Profile Creation Summary
      The Profile Creation Summary
    15. After a minute or so, you should receive confirmation that the profile was successfully created, as shown in figure 9:
      Figure 9. Figure 9. Profile Creation Completion Screen
      Profile Creation Completion Screen
    16. Uncheck Launch the First steps console. Check Create another profile. Click Finish.
  6. Let's create the first custom profile.
    1. On the welcome screen of the Profile Management Tool, click Next.
    2. Select WebSphere Process Server again. Click Next.
    3. This time, select the Custom profile, as shown in figure 10:
      Figure 10. Figure 10. Selecting a custom profile
      Selecting a custom profile
    4. Click Next. Select Advanced Profile Creation. Click Next again.
    5. Leave the defaults for the profile name and directory. You are going to create a profile called Custom01 at this time. Click Next.
    6. Leave the defaults for the node name and host name. Take note of the node name; you will add this node to the cell at a later time. The node name should be called <system name>Node01.
    7. Click Next. On the Federation screen, check the Federate this node later checkbox. All the fields should become grayed out, as shown in figure 11:
      Figure 11. Figure 11. Deferring the federation of the node
      Deferring the federation of the node
    8. On the Database Configuration dialog, select DB2 Universal Database and leave the driver location to the default, as in figure 12:
      Figure 12. Figure 12. Specifying the datatabase information for the custom profile
      Specifying the datatabase information for the custom profile
    9. Click Next.
    10. Review the summary and if everything looks fine, click Create.
    11. After a minute or so, you should receive notification that the profile was successfully created.
    12. Uncheck the Launch first steps console and check Create another profile, as in figure 13:
      Figure 13. Figure 13. Completion screen for the custom profile creation
      Completion screen for the custom profile creation
    13. Click Finish.
  7. Repeat all of the steps necessary to create the Custom profile and create profile Custom02.
    1. On the welcome screen of the Profile Management Tool, click Next.
    2. Select WebSphere Process Server again. Click Next.
    3. Select Custom profile.
    4. Click Next. Select Advanced Profile Creation. Click Next again.
    5. Leave the defaults for the profile name and directory. We are going to create a profile called Custom02 at this time. Click Next.
    6. Leave the defaults for the node name and host name. Remember the node name; you will add this node to the cell at a later time. The node name should be called <system name>Node02.
    7. Click Next. On the Federation screen, check the Federate this node later checkbox. All the fields should become grayed out.
    8. On the Database configuration dialog, select DB2 Universal Database and leave the driver location to the default.
    9. Click Next. Review the summary and if everything looks fine, click Create.
    10. After a minute or so, you should receive notification that the profile was successfully created.
    11. Uncheck the Launch first step console checkbox and click Finish to exit the Profile Management Tool.
  8. Now, verify what you have done so far. You can start by verifying that the common database was created successfully.
    1. Open a command prompt, and issue:
      db2cmd
    2. On the command prompt that opens up, issue the following command:
      db2 connect to WPRCSDB user db2admin using xxxxxxx
    3. You should successfully connect to the database. Now issue: db2 list tables

      Table 1. Table/View list

      Table/ViewSchemaTypeCreation time
      APPTIMESTAMPDB2ADMINT2007-12-03-17.26.31.265001
      BYTESTOREDB2ADMINT2007-12-03-17.26.31.125001
      BYTESTOREOVERFLOWDB2ADMINT2007-12-03-17.26.31.234003
      CUSTPROPERTIESDB2ADMINT2007-12-03-17.26.31.281001
      FAILEDEVENTBOTYPESDB2ADMINT2007-12-03-17.26.32.703003
      FAILEDEVENTDETAILDB2ADMINT2007-12-03-17.26.32.796005
      FAILEDEVENTMESSAGEDB2ADMINT2007-12-03-17.26.32.765001
      FAILEDEVENTSDB2ADMINT2007-12-03-17.26.32.625002
      MEDIATION_TICKETSDB2ADMINT2007-12-03-17.26.35.156002
      PERSISTENTLOCKDB2ADMINT2007-12-03-17.26.33.984002
      RELN_METADATA_T DB2ADMINT2007-12-03-17.26.36.625002
      SCHEMAVERSIONINFODB2ADMINT2007-12-03-17.25.24.906001
      WSCH_LMGRDB2ADMINT2007-12-03-17.26.37.921002
      WSCH_LMPRwDB2ADMINT2007-12-03-17.26.37.953002
      WSCH_TASKDB2ADMINT2007-12-03-17.26.37.843002
      WSCH_TREGDB2ADMINT2007-12-03-17.26.37.890005
    4. In addition to the tables listed above, there is an additional table in the schema ESBLOG, which is not shown. If you want to see a complete list of all the tables in the database, issue:

      db2 list tables for all > out.txt

      And then edit the out.txt file. You'll see the table in the ESBLOG schema, and the usual catalog tables.

    5. Disconnect from the database, by issuing:

      db2 connect reset

  9. Let's check whether the profiles were created correctly.
    1. In a command prompt, change the current directory to: <WPS_INSTALL>\bin.
    2. Issue the following command:
      manageprofiles –listProfiles
    3. You should obtain a list of the three profiles that we just created, as shown below:
      [DMgr01, Custom01, Custom02]
  10. Let's now federate the nodes to the cell.
    1. Start the Deployment Manager process: on a command prompt, change the current directory to: <WPS_INSTALL>\profiles\DMgr01\binand issue this command:

      startManager

    2. Once the process completes start up, change the current directory to <WPS_INSTALL>\profiles\Custom01\bin and federate this node to the cell by issuing:

      addNode localhost 8879

      Important: The port number is really unnecessary in the previous command, because we chose the default ports for the Deployment Manager, in case you did change the port, you would need to specify the actual host name and SOAP connector port number of the Deployment Manager process in the addNode command.

    3. The process should complete with a successful completion message, similar to the following: ADMU0003I: Node t60mcNode01 has been successfully federated.
    4. Repeat federation for the Custom02 profile, by changing directories to <WPS_INSTALL>\profiles\Custom02\bin and issuing again:

      addNode localhost 8879

      You have now federated the profiles to the cell and are ready to create the deployment environment to represent our clustered topology.


Creating a deployment environment

In this section, you are going to create the deployment environment that corresponds to the clustered topology we want to set up.

Keep in mind that the Deployment Environment object is just a description of the topology. When you create one, you do not implicitly create all the resources that are necessary to physically implement the topology.

The generation of those resources is a separate step, which we are going to illustrate in the appropriate section of the lab.

To create a new deployment environment using the console:

  1. Open a Web browser, and direct it to the administrative console (if you followed the steps to the letter, the URL should be http://localhost:9060/admin)
  2. There should be no active security, just click Log in to get into the console.
  3. Expand Servers and click Deployment Environments.
  4. On the Deployment Environments panel, click New.
  5. Leave the radio button Create a new deployment environment selected, and type MyTopology for the Deployment environment name field. Make sure that WPS is also selected, as in figure 14:
    Figure 14. Figure 14. Creation of a new deployment environment (initial screen)
    Creation of a new deployment environment (initial screen)
  6. Click Next. Leave Remote Messaging and Remote Support checked, as in figure 15:
    Figure 15. Figure 15. Selecting the "Gold" Topology
    Selecting the
  7. Click Next. You are presented with a series of steps. The first step is about adding the nodes to the topology we want to create. We have two separate nodes in the cell. Let's add them both to the deployment environment, by checking their checkboxes, as shown in figure 16:
    Figure 16. Figure 16. Adding the nodes to the topology
    Adding the nodes to the topology
  8. Click Next. The second step is about defining the distribution of the members of the three clusters we want to create. This screen allows you to specify how many cluster members of a certain type you want to create on each node. In a Gold topology there are three clusters:
    1. The Application Deployment Target cluster. This is where you will install the WPS modules you develop.
    2. The Messaging Infrastructure cluster. For the messaging engines.
    3. The Support Infrastructure cluster. For CEI and the Business Rules Manager.
    Since we only have two nodes, we'll assign a member of each cluster to each node, in order to ensure failover. Each node will run three cluster members, as shown in figure 17:
    Figure 17. Figure 17. Defining the location of the three clusters
    Defining the location of the three clusters
  9. Click Next. This leads you to the database settings screen, arguably the most complex of all the steps. To complete this step, you need to have a very clear idea of how many databases you are going to need, which schemas go into the various databases, and of the credentials to use for the authentication to those databases. Our database configuration includes the following DBs:
    1. The common database (WPRCSDB) was created at the time that you created the Deployment Manager. Notice that the deployment environment makes no reference to the WPRCSDB.
    2. The Messaging Engine DB (MEDB). You want a single database for the four Messaging Engines (a common configuration). Each messaging engine will have its schema in the database:
      1. The CEIME schema for the CEI messaging engine.
      2. The BPCME schema for the process choreographer messaging engine.
      3. The SCAAPP and SCASYS schemas for the SCA application and system messaging engines, respectively.
    3. The EVENT database for CEI events and for the event catalog.
    4. A database for the Business Process Choreographer Observer (OBSVRDB).
    5. A database for the Business Process Choreographer (BPEDB). For this database, there is no "schema support". The BPC will always use a schema that matches the user specified for authentication.

      To reflect the settings discussed above, we've made the following changes to the database and schemas parameters, shown in figure 18:

      Figure 18. Figure 18. Defining the databases and schemas
      Defining the databases and schemas

      Also, ensure that the credentials specified for authentication match the db2admin user and password, as in figure 19:

      Figure 19. Figure 19. Database authentication credentials
      Database authentication credentials
      Finally, make sure that the Create Tables checkbox is checked everywhere. At the end of this article, we are going to elaborate on how you can manually create the database objects, in case it is required by your environment.
  10. Ensure that all the parameters are correct and match the figures of the previous step. Click Next. On the Security screen, use the WPS admin user and password provided to you by the instructor. These settings are relevant only if security is turned on, but we'll specify them anyway here, as in figure 20:
    Figure 20. Figure 20. Additional security settings
    Additional security settings

    Important: This admin user is typically different from the database administrator's user ID. The user that needs to be specified here must be a valid user in the user registry used to authenticate users to the application server.

  11. Click Next. On the Business Process Choreographer screen, you need to specify some authorization settings. In particular, set the Administrator and Monitor groups to Administrators (which in our case corresponds to the Windows group). Set the JMS API Authentication and Escalation User Authentication to the admin user and password. These settings are shown in figure 21:
    Figure 21. Figure 21. Defining the Business Process Choreographer settings
    Defining the Business Process Choreographer settings
    Uncheck the Enable e-mail service checkbox (in this scenario, we are not interested in hooking up to a mail server).
  12. Click Next. The Business Rules Manager screen allows you to set the context root of the Business Rules Manager Web application. Leave the default, shown in figure 22:
    Figure 22. Figure 22. Business Rules Manager settings
    Business Rules Manager settings
  13. Click Next. Review the summary and if everything is as expected, click Finish.
    Important: Do not click Finish and Generate at this time. We need to complete some database configuration before we can generate the environment.
  14. Save your work.

To review what we have created so far:

  1. The console should now show MyTopology in the list of deployment environments. If you hover with your mouse over the Status icon, you will see that the status is now Not configured (as in figure 23). This means that the deployment environment exists, but the actual resources have not be generated yet.
    Figure 23. Figure 23. The Deployment Environment is Not Yet Configured
    The Deployment Environment is Not Yet Configured
  2. Click MyTopology. The screen that you obtain shows you a summary of the deployment environment, in particular, it shows the status of each of the clusters that belong to it. Since we haven't generated any resources yet, the status will be Not configured for every element. Notice, at the bottom of figure 24, the button that allows you to generate the resources:
    Figure 24. Figure 24. Details of the deployment environment prior to generating the resources
    Details of the deployment environment prior to generating the resources
  3. Click on Deployment Topology on the right hand side. You'll be shown a screen that describes the topology, as in figure 26. At this time, you should see the green arrows for the nodes (the node agents are up and running), but you should still see that the status of the clusters is Not configured:
    Figure 25. Figure 25. Deployment environment nodes and clusters
    Deployment environment nodes and clusters
  4. Click Cancel and then click Data sources. The database configuration screen appears again, showing not only the database names and schema names we defined in the previous step, but also the JNDI name for a number of data sources. At this point, you can still make changes and save those changes in the deployment environment. Any change that you make now will be reflected on the actual resources.
  5. Click Cancel and Log off.

Completing the database configuration

In order for the deployment environment generation to succeed, you need to make sure that the database instances exist. In particular, the EVENT database must exist, or the generation will abort with an error that indicates that the database could not be found.

Here we are going to create the instances of all the necessary databases and rely as much as possible on the automatic creation of tables. However, if you are interested in creating the database objects in an entirely manual way, please refer to the Appendix at the end of this document.

  1. Create the EVENT database for the CEI:
    1. Open a command prompt and issue the following command:
      db2cmd
    2. On the resulting command prompt, issue:
      db2 create db EVENT

      Important: The EVENT schema and tables will be automatically created when the deployment environment gets generated. However, if you need to have those objects manually created, please refer to the Appendix.

  2. Create the BPEDB database.
    1. On the database command prompt, issue:
      db2 create db BPEDB
  3. Create the Observer's database.
    1. On the database command prompt, issue:
      db2 create db OBSVRDB
  4. Create the Messaging Engine database:
    1. On the same command prompt as above, issue:
      db2 create db MEDB

Important: The Messaging Engines, BPEDB, and Observer's schemas and tables will be automatically created when the clusters start up. However, if you need to have those objects manually created, please refer to the Appendix.


Generating the deployment environment and testing

Now that we have the databases created, let's go back to the console and generate the deployment environment.

  1. Let's generate the resources for the deployment environment.
    1. Go back to the administrative console. Expand Servers and then click Deployment Environments.
    2. Click MyTopology. On the subsequent screen, click Generate Environment.
    3. When the generation is complete (it may take a minute or so), save your work.
    4. Notice that the topology is now configured, and the status is Stopped, as indicated in figure 26:
      Figure 26. Figure 26. Deployment Environment in the Stopped Status
      Deployment Environment in the Stopped Status
    5. Click MyTopology. Now, the status of each of the clusters is Stopped, as shown in the following figure:
      Figure 27. Figure 27. Stopped Clusters in the Deployment Environment
      Stopped Clusters in the Deployment Environment
      Notice that you can still click on Deployment Topology and Data sources, but if you make any changes there, those changes won't be reflected on the actual resources that we have already generated.
    6. Let's take a quick look at some of the resources that we have generated. Expand Servers and click Clusters. You should see the three clusters that we have generated, as shown below:
      Figure 28. Figure 28. Clusters viewed through the Usual Panel for Cluster Management
      Clusters viewed through the Usual Panel for Cluster Management
    7. Each cluster has two cluster members. Click Servers => Application Servers. You should see the six servers that were generated, as shown below:
      Figure 29. Figure 29. Cluster Members in the Topology
      Cluster Members in the Topology
    8. Make sure the data sources were created. Navigate to Resources => JDBC => Data sources. You should see a list of 10 data sources.
    9. Check out the SI Buses. Navigate to Service Integration => Buses and make sure that you see the four buses shown below:
      Figure 30. Figure 30. SI Buses in the Topology
      SI Buses in the Topology
    10. Click on one of the buses (for example the BPC bus). Navigate to Messaging Engines and then click the messaging engine.
    11. Click Message Store. You should see the schema name we defined for it (BPCME), the JNDI name of the data source that was generated, and the Create tables checkbox should be checked (see below):
      Figure 31. Figure 31. Data Store Settings for SI Buses in the Topology
      Data Store Settings for SI Buses in the Topology
    12. Finally, let's review the applications that were installed. Navigate to Applications => Enterprise Applications. You should see the following applications; notice that their name bears an indication of where they have been installed:
      Figure 32. Figure 32. Enterprise Applications Installed as Part of the Topology
      Enterprise Applications Installed as Part of the Topology
  2. Now you are ready to start the deployment environment and test some of the functions. Keep in mind that the node agent processes must be up and running for this step to be successful.
    Important: This step may be difficult to carry out on a single system because of memory constraints (keep in mind that we have the Deployment Manager, two Node Agents, and six application servers running on the same box). We mention these steps for illustration purposes. We suggest that you read through step 2 and then skip to step 3 for an alternative way to test the topology.
    1. Navigate to Servers => Deployment Environments. Check the checkbox close to MyTopology and click Start.
    2. Very quickly, the status of the Deployment Environment changes to Started, as shown below:
      Figure 33. Figure 33. The Deployment Environment in the Started Status
      The Deployment Environment in the Started Status
    3. Click MyTopology. You will also see that the status of the individual clusters is Started. However, the actual servers take quite a while to start up.
    4. Navigate to Servers => Clusters. Notice that (in all likelihood) the clusters are still in the process of starting (partial start), as shown below:
      Figure 34. Figure 34. Clusters during startup
      Clusters during startup
    5. Wait a couple of minutes, and then refresh the status of the clusters. Wait until all the three clusters are up and running.
  3. Here is an alternative way to test the topology considering the memory constraints.
    1. Navigate to Servers => Application Servers. All the servers should be stopped now.
    2. Select all the servers that are configured to run on Node 1 and click Start (as shown below):
      Figure 35. Figure 35. Starting Only Some Members to Cope with Memory Constraints
      Starting Only Some Members to Cope with Memory Constraints
    3. Wait a couple of minutes, and then refresh the status of the clusters. Wait until all the three clusters are up and running.
  4. Let's now make sure that the topology is functional. First ensure that the tables for the Messaging Engines have been created.
    1. In a command prompt window, type the following command:

      db2cmd

    2. In the resulting command prompt window, issue the following commands:

      db2 connect to MEDB user db2admin using xxxxxxx

      db2 list tables for all > out.txt

    3. Edit the file out.txt using a text editor. You should notice that there are a number of tables in the schemas CEIME, BPCME, SCAAPP, SCASYS (as shown below):

      Table 2. Table/View list

      Table/ViewSchemaTypeCreation time
      SIB000BPCMET2007-12-05-10.29.32.015002
      SIB001BPCMET2007-12-05-10.29.32.921002
      SIB002BPCMET2007-12-05-10.29.34.078002
      SIBCLASSMAPBPCMET2007-12-05-10.29.30.875005
      SIBKEYSBPCMET2007-12-05-10.29.35.703003
      SIBLISTINGBPCMET2007-12-05-10.29.31.406002
      SIBOWNERBPCMET2007-12-05-10.29.25.640001
      SIBXACTSBPCMET2007-12-05-10.29.36.750002
      SIB000SCAAPPT2007-12-05-10.29.31.218001
      SIB001SCAAPPT2007-12-05-10.29.32.296002
      SIB002SCAAPPT2007-12-05-10.29.32.859001
      SIBCLASSMAPSCAAPPT2007-12-05-10.29.29.390001
      SIBKEYSSCAAPPT2007-12-05-10.29.33.828003
      SIBLISTINGSCAAPPT2007-12-05-10.29.30.343001
      SIBOWNERSCAAPPT2007-12-05-10.29.25.640000
      SIBXACTSSCAAPPT2007-12-05-10.29.34.328002
      SIB000SCASYST2007-12-05-10.29.32.828001
      SIB001SCASYST2007-12-05-10.29.33.671004
      SIB002SCASYST2007-12-05-10.29.34.406002
      SIBCLASSMAPSCASYST2007-12-05-10.29.31.796002
      SIBKEYSSCASYST2007-12-05-10.29.35.484001
      SIBLISTINGSCASYST2007-12-05-10.29.30.343001
      SIBLISTINGSCASYST2007-12-05-10.29.32.359001
      SIBOWNERSCASYST2007-12-05-10.29.25.640002
      SIBXACTSSCASYST2007-12-05-10.29.36.062004
    4. Verify that the Messaging Engines are up and running. In the administrative console, navigate to Service Integration => Buses. Click on one of the SI Buses (for example the BPC SI Bus).
    5. Click Messaging Engines. The status should be active, as shown in the figure below:
      Figure 36. Figure 36. Messaging Engine in the Started State
      Messaging Engine in the Started State
  5. Let's now try out the Business Process Choreographer Explorer. This application runs on the Support cluster.
    1. Open a Web browser and direct it to the URL: http://localhost:9082/bpc. (You may need to find out what port your Support cluster uses for inbound HTTP traffic. Generally, if you kept all the defaults, the Application Target server on Node 1 uses port 9080, and the Support cluster uses port 9082).
    2. The Business Process Choreographer Explorer window should open up (shown below):
      Figure 37. Figure 37. Business Process Choreographer Explorer Web Application
      Business Process Choreographer Explorer Web Application
    3. Obviously, there are no To-dos, since we don't have any process or human task installed.
  6. Okay, now let's make sure that the Observer is available. This application runs on the Support cluster.
    1. Direct the browser to the following URL: http://localhost:9082/bpcobserver (the port 9082 is generally the default HTTP transport port for the Support cluster member on Node 1. You may need, however, to verify which port is in use).
    2. You should get the front page of the BPC Observer, shown below:
      Figure 38. Figure 38. Business Process Choreographer Observer Web Front-end
      Business Process Choreographer Observer Web Front-end
  7. Let's make sure the Business Rules Manager is also available.
    1. Direct the browser to the following URL: http://localhost:9082/br (the same considerations about the 9082 apply here as explained in the previous step).
    2. The Business Rules Manager main page should appear (shown below):
      Figure 39. Figure 39. Business Rules Management Web Application
      Business Rules Management Web Application

Congratulations, you have now generated and tested the deployment environment


Conclusion

In this article, you have experienced how to create a clustered "Gold" topology for WebSphere Process Server using a template-driven approach. First, you created the cell and federated two empty nodes to it. You then created a deployment environment, which is a template for the clustered topology. Finally, after making some adjustments to the databases, you generated the deployment environment and tested the topology.


Appendix: Manual creation of database objects

The article mentions several times that we relied on automatic table creation as much as possible during the lab.

However, in most customer environments, automatic creation is not an option. For automatic table creation to work, several conditions must be met, in particular the following:

  • The "common" database can only be created automatically if it is local. Remote creation is not supported.
  • The user that is specified for database authentication has to have the right level of permissions to create tables, indices, and so on. It hardly ever happens that a database administrator hands out the credentials of a user with those authorities. Typically, the user that is specified for database access has the permissions that are necessary to manipulate data, not to create database objects.

For these reasons, in most cases you will want to provide the DB administrator with scripts to create the database objects. This section summarizes how to find or produce those scripts for each one of the databases that are involved.

Creating the "Common" (WPRCSDB) database using scripts

  1. Manual creation of the common database is easy to accomplish. Refer to Figure 6 in this same document: you notice that on that panel, which appears during the creation of the Deployment Manager profile, you can check the checkbox, Delay execution of database scripts for new or existing database.
  2. Check the checkbox, and you will be able to retrieve the script in the directory indicated on the same screen in the field Database script output directory.
  3. Use (after possibly modifying them) the script that were generated.

Creating the Business Process Choreographer database.

The scripts for creating this database objects are located in: <WPS_INSTALL>/dbscripts/ProcessChoreographer.

  1. Open a command prompt and issue: db2cmd.
  2. Change the current directory to <WPS_INSTALL>\dbscripts\ProcessChoreographer\DB2.
  3. Open the file createDatabase.sql using a text editor (wordpad).
  4. Locate the line where a connection to the database is made (CONNECT TO BPEDB;). Change it to the following:

    CONNECT TO BPEDB USER db2admin USING xxxxxxx;

  5. Save and close the file.
  6. Now issue the following command:

    db2 –tf createDatabase.sql

Creating the Business Process Observer database

The scripts are located in <WPS_INSTALL>/dbscripts/ProcessChoreographer.

  1. On the same command prompt as above, open the file createDatabase_Observer.sql with a text editor.
  2. Locate the line used to connect to the database (CONNECT TO OBSVRDB;)
  3. Change that line to:

    CONNECT TO OBSVRDB USER db2admin USING xxxxxxx;

  4. Save and close the file. Issue the following command:

    db2 –tf createDatabase_Observer.sql

Creating the Messaging Engine database and schemas using scripts

In order to perform this task, you need to take three steps:

  1. Create the database first. In this document (Creating a Deployment Environment section), we took the approach of creating a single database for the four Messaging Engine schemas, but you could take a different approach as well.
  2. Generate the script, using the sibDDLGenerator utility located in >WPS_INSTALL</bin. For example, consider the following command:

    sibDDLGenerator.bat -system db2 -schema ISSWME –user DB2ADMIN -create –statementend ; > ME.ddl

    This command creates a file (ME.ddl) that can be used to generate a messaging engine store schema for DB2, using the user db2admin to connect.

    The schema is called ISSWME, but you can make copies of the ME.ddl file and edit it to set the desired schema name.

  3. After making any changes to the generated script, connect to the database and run it.

Creating the CEI database using scripts

The CEI script can be found after the generation of the Deployment Environment in the directory <WPS_INSTALL>/profiles/<deployment manager profile directory>/databases/event/dbscripts.

Unfortunately, this script cannot be run until after the generation of the Deployment Environment, discussed in the Generating the Deployment Environment and testing section of this document.

Important: In order to prevent the system to attempt running the script during the generation of the deployment environment, you need to make sure you uncheck the "Create Tables" checkbox for the data sources of the deployment environment, as seen in figure 40.

Figure 40. Figure 40. Disabling Automatic Creation of Tables
Disabling Automatic Creation of Tables

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
ArticleID=294076
ArticleTitle=Building clustered topologies in WebSphere Process Server V6.1
publish-date=03192008