Installing and clustering WebSphere Process Server V7 in non-GUI mode, Part 2: Using the command line to create a cluster

Part 2 of this 2-part tutorial series describes installing and clustering WebSphere® Process Server V7.0.0.3 in non-GUI or silent mode. Part 2 describes clustering the Process Server environment using the deployment environment pattern. The tutorial explains how to use the command line mode, instead of the GUI mode, to create profiles and then set up the deployment environment using the Golden topology reference pattern.

Rajiv Madassery (rajiv.madassery@in.ibm.com), Principal Software Engineer, IBM

Author photo of Rajiv MadasseryRajiv Madassery is a Principal Software Engineer at IBM and works for the WebSphere Process Server Level 2 Support Team. Rajiv came to IBM in 2003 and has worked with the WebSphere Business Integration Adapters Functional Verification Test team and WebSphere Application Server Level 2 Support team. Rajiv is a developerWorks Contributing Author in the WebSphere Process Server space.


developerWorks Contributing author
        level

Vamsee Movva (vmovva@us.ibm.com), Software Engineer, IBM

Vamsee Movva is a Software Engineer on the IBM WebSphere Process Server Technical Support team. Vamsee joined IBM in 2008 and specializes in the area of WebSphere Process Server topologies and their extensions.



08 June 2011

Also available in Chinese Portuguese

Introduction

This 2-part tutorial series describes installing and clustering of WebSphere Process Server V7 (hereafter called Process Server). Part 1 deals with the installation and setup of Process Server. Part 2 will deal with clustering using a Golden topology deployment environment pattern. Throughout the tutorial, the tasks will be performed in a non-GUI or silent mode. The tutorial is developed based on field experiences working with installation and clustering problems and is a valuable reference to users adopting Process Server V7.

In this tutorial

You can achieve clustering in non-GUI mode by using commands provided in the Process Server installation. The most optimal and quickest method is explained to create the Process Server clustered environment using deployment environments. This is done by commands provided with Process Server to create, configure, and generate the deployment environment. We will also use the DBDesignGenerator tool available with Process Server to configure the database design for the profiles and the deployment environment generation.

The tutorial is divided into the following sections:

Prerequisites

  • Knowledge of basic administration of WebSphere Process Server
  • Knowledge of network deployment concepts of WebSphere Application Server
  • Familiarity with WebSphere Application Server scripting

System requirements

  • A Linux machine with 8 GB of RAM was used for this exercise.
  • WebSphere Process Server V7.0.0.3

Duration

Approximately 2 hours


Introduction to the commands

To create a Process Server deployment environment using the command line, there are several tools and commands provided within the installation. This section introduces these tools and commands. This section also explains how to use the DBDesignGenerator tool.

Database design

Typical production environments for Process Server will have several databases configured. These are:

  • Process Server Common database holding the tables for Failed Event Manager
  • Business rules, relationships, and so on
  • Business Process Choreographer database for Business Process Choreographer and Human Task container
  • Common Event Infrastructure database
  • Messaging engine database that hosts the database schema for the standard messaging engines in Process Server

You can configure the databases along with the profile creation provided that the user has sufficient rights and privileges to perform the various database operations. Typically, this is restricted to the database administrators (DBAs). Therefore, you have the option to defer the database creation, and only generate the database scripts during profile creation. The database scripts can then be executed by the DBA to complete the requirements before the deployment manager is started.

The DBDesignGenerator tool shipped in Process Server V7.0. It is an interactive command line tool used to configure the database according to the design requirements for your environment. For the output of the tool, you get a database design file, which is used as an input file for the deployment manager profile creation, or alternatively during the deployment environment creation. The database scripts are generated at the end of the tasks, which are required to be executed to complete the database configuration. A detailed tutorial for the DBDesignGenerator tool is available in WebSphere Process Server database configuration made easy. The rest of the tutorial assumes that you have a valid design file and scripts ready.

Profile creation commands

A clustered environment requires a deployment manager profile and at least one custom profile. Ensure that these profiles use the Process Server template. Therefore, the next stage is to create these profiles on the Process Server installation. A command is available in the installation, namely “manageprofiles”.

This command is not only used for profile creation, but also for verifying, deleting, backing up, and restoring profiles. Therefore, it is important to note the various parameters that this command takes as input. A detailed overview of the command is described in this Information Center topic, manageprofiles parameters. Table 1 shows the frequently used parameters.

Table 1. Parameters for the manageprofiles command
create Creates the profile.
delete Deletes a profile. Automatically unaugments the profile, and deletes the servers within this profile.
deleteAll Unaugments and deletes all the profiles and servers within the profile.
listProfiles Lists all existing and valid profiles.
validateAndUpdateRegistry Validates and updates newly added or removed profiles to the profile registry.

You can use the manageprofiles command along with a response file for a silent mode operation. The response file will have the parameters for the manageprofiles command typically in key and value format as shown in Listing 1.

Listing 1. Command syntax
manageprofiles –response <response file name>

For manageprofiles command examples for various database providers and various profile types, see this Information Center topic, Creating profiles using the manageprofiles command-line utility.

Deployment environment commands

The deployment environment is a collection of servers or clusters based on reference patterns that helps in quickly setting up clustered topologies for Process Server. It eliminates the need for creating nodes, clusters, servers (one followed by the other), and then manually configuring Service Runtime Architecture (SCA), messaging engines, Common Event Infrastructure (CEI), and associated resources. By choosing one of the reference patterns, a clustered topology is configured on the fly. Apart from the ease in setup, deployment environments also provide an option to import or export if you want to quickly set up a topology based on an existing pattern. To learn more about deployment environments, see this Information Center topic, Deployment environments.

Commands are available to create and configure a deployment environment of any of the reference pattern types – single cluster, remote messaging, and remote messaging and remote support. There are other topologies that are possible using the deployment environment pattern, such as the double remote messaging and remote support and custom patterns. More information is available in the Resources section of the tutorial. These commands help to create the deployment environment in silent mode. The other option is using the administrative console to generate one interactively. The frequently used commands are shown in Table 2.

Table 2. Deployment environment commands
createDeploymentEnvDef Defines a new deployment environment based on a reference pattern. Click here to learn more.
addNodeToDeploymentEnvDef Adds an application target or messaging or support nodes to a deployment environment. Click here to learn more.
validateDeploymentEnvDef Validates a deployment environment whether all the required constraints are met. Click here to learn more.
generateDeploymentEnv Configures the deployment environment on the deployment manager. Click here to learn more.
exportDeploymentEnvDef Exports topologies from a deployment manager. Click here to learn more.
importDeploymentEnvDef Imports topologies to a deployment manager. Click here to learn more.
startDeploymentEnv Starts the deployment environment. Click here to learn more.
showDeploymentEnvStatus Displays the current status of the deployment environment as to whether it is generated or started. Click here to know more.
stopDeploymentEnv Stops the deployment environment by stopping all the clusters. Click here to know more.
deleteDeploymentEnvDef Deletes a deployment environment from a deployment manager without removing the configured servers or clusters. Click here to know more.

Introduction to the topology

The topology discussed in the tutorial is shown in Figure 1. dWDepEnv is the name of the deployment environment. It hosts three clusters in the dWCustom01 node, namely dWDepEnv.AppTarget, dWDepEnv.Messaging, and dWDepEnv.Support. dWDmgr is the deployment manager profile. Each cluster has a single member for the purpose of this tutorial. This topology pattern is known as the Golden topology or Remote Messaging Remote Support topology pattern. For detailed information, see this Information Center topic, Remote messaging and remote support topology.

Figure 1. Topology diagram
Topology diagram

Creating profiles using the manageprofiles command

You can use the manageprofiles command to create profiles in silent mode. According to the topology diagram in Figure 1, a Process Server deployment manager and a custom profile are required. Therefore, you need to create two response files. You will create the databases right after the deployment manager profile is created. The database design file name along with the directory location is to be provided in the deployment manager response file.

Note: For your reference, the response files and design files used in the following sections of the tutorial are available in the Download section.

Creating the database design file

For the purpose of this tutorial, we will use the Derby network server as the database provider. The Derby network server is embedded within the Process Server installation. Using DbDesignGenerator will be similar for other database providers, except that you might be asked for provider-specific property input. The steps to create the design file are:

  1. Launch the DbDesignGenerator interactive tool using the command below from opt/IBM/WebSphere/ProcServer7/util/dbUtils:
    ./DbDesignGenerator.sh
  2. The tool starts and prompts you for the database configuration properties:
    [info] running DbDesignGenerator in interactive mode...
    
    [info] Enter 'q' to quit without saving; '-' for back to previous   menu; '?' for 
    help at any time.
    
    [info] To accept the given default values, simply press the 'Enter' key.

    Note: We do not recommend multiple deployment environments in a single cell. Deployment environments, though very easy to configure, are complex entities and create numerous resources required for a clustered Process Server environment. Multiple deployment environments managed by a single deployment manager can result in administrative challenges in the long run. In such a configuration, the Common Database will be common for deployment environments. All other resources are scoped at the deployment environment level. This creates the additional overhead of ensuring that there are no database or schema conflicts between the environments. Another cause of concern is that there will be multiple CEI server and Business Space server configurations in the same cell. To keep the environment simple and for ease of maintenance, you need to restrict to one deployment environment per cell. You can always configure another deployment environment in a new cell.

  3. Choose the Create a database design for Standalone profile or Deployment Environment option in the next prompt:
    [info] Please pick one of the following [design option(s)] :
    
    (1)Create a database design for Standalone profile or Deployment Environment
    (2)Create a database design for a single component (e.g. BPC, CEI etc)
    (3)Edit an existing database design
    (4)Generate database scripts from a database design
    (5)exit [q]
    
    Please enter the number for the design option :1
  4. Choose wps.nd.topology as the database pattern:
    (1)wesb.nd.topology
    (2)wesb.standalone
    (3)wps.nd.topology
    (4)wps.standalone
    
    Please enter the number for the database pattern :3
  5. Pick the CommonDB database component to be designed first:
    [info] Please edit any database component with status of 'not complete' for required 
    properties.
    [info] Completed database components can be edited to change existing or defaulted 
    property values.
    [info] Design the 'master' component first, and then any parent components, since 
    other components may inherit values from them.
    
    [info] Please pick one of the following [database component(s)] :
    
    (1)[CommonDB]   WBI_CommonDB : [master] [status = not complete]
    (2)[BPCReporting]   WBI_BPCEventCollector :  [status = not complete]
    (3)[BPC]        WBI_BPC :     [status = not complete]
    (4)[BSpace]     WBI_BSPACE :  [status = not complete]
    (5)[CEI]        WBI_CEI_EVENT :  [status = not complete]
    (6)[SibME]      WBI_BPC_ME :  [status = not complete]
    (7)[SibME]      WBI_CEI_ME :  [status = not complete]
    (8)[SibME]      WBI_SCA_APP_ME :  [status = not complete]
    (9)[SibME]      WBI_SCA_SYS_ME :  [status = not complete]
    (10)[save and exit]
    
    Please enter the number for the database component :1
  6. The next steps prompt you for details for the CommonDB data source configuration:
    [status] WBI_CommonDB is not complete with 1 remaining item(s):
    [ 1 ] CommonDB.WBI_CommonDB :  : DbType key is not set.
    
    Edit this database component? (y/n) [default=y] :
  7. Choose the database type as Derby-networkServer:
    [info] Please pick one of the following [database type(s)] :
    
    (1)DB2-distributed
    (2)DB2-iSeries
    (3)DB2-zOS-8
    (4)DB2-zOS-9
    (5)Derby-embedded
    (6)Derby-networkServer
    (7)Informix
    (8)Oracle
    (9)SQL Server
    
    Please enter the number for the database type :6
  8. Enter the database specific properties in the next prompt. All the default values are chosen in this case.
    [info] Please enter the values for the properties in the database objects section.
    Database name[default=WPRCSDB] :
    Database User name[default=TEST] :
    Database server host[default=localhost] :
    Database server port[default=1527] :
    Schema name[default=] :
    
    [info] You have completed database objects section properties needed for database 
    scripts generation.
  9. Enter the data source properties in the next prompt:
    To skip data source properties, enter 's'; or enter anything else to continue :
    
    [info] Please pick one of the following [database provider(s)] :
    
    (1)Derby Network Server Using Derby Client # XA data source # Derby Network Server 
     Using Derby Client (XA)
    (2)Derby Network Server Using Derby Client 40 # XA data source # Derby Network 
     Server Using Derby Client 40 (XA)
    
    Please enter the number for the database provider :1
    
    [info] Please enter the values for the properties in the data source properties 
    section.
    Data source user name[default=TEST] :
    Data source password[default=] :TEST
    Derby JDBC driver path[default=${WAS_INSTALL_ROOT}/derby/lib] :
    
    [status] WBI_CommonDB is complete with 0 remaining item(s):
  10. This completes the CommonDB configuration and you are returned to the prompt in Step 5. You can specify separate databases for the BPC, CEI, and messaging databases. The overall steps are similar to what is explained above for CommonDB.
  11. Once the configuration is complete, exit the design.
    [info] Please pick one of the following [database component(s)] :
    
    (1)[CommonDB]   WBI_CommonDB : [master] [status = complete]
    (2)[BPCReporting]       WBI_BPCEventCollector :  [status = not complete]
    (3)[BPC]        WBI_BPC :  [status = not complete]
    (4)[BSpace]     WBI_BSPACE :  [status = not complete]
    (5)[CEI]        WBI_CEI_EVENT :  [status = not complete]
    (6)[SibME]      WBI_BPC_ME :  [status = not complete]
    (7)[SibME]      WBI_CEI_ME :  [status = not complete]
    (8)[SibME]      WBI_SCA_APP_ME :  [status = not complete]
    (9)[SibME]      WBI_SCA_SYS_ME :  [status = not complete]
    (10)[save and exit]
    
    Please enter the number for the database component : 10
  12. You are prompted for the output directory and the name of the output file name. The default values are chosen here.
    Please enter the output directory [default=/opt/IBM/WebSphere/ProcServer7/util/
    dbUtils] :
    
    Please enter the output filename [default=wps.nd.topology.dbDesign] :
  13. The tool generates the database scripts after this prompt. The default option is to generate the scripts.
    generate database scripts? (y/n) [default=y] :
  14. You are prompted for the locations to save the scripts for various databases. Provide the directory paths as appropriate. All default paths are chosen in this tutorial.
    Please enter the output directory for WBI_CEI_ME [default=Derby-SibME/WBI_CEI_ME]:
    
    [info] The script(s) have been generated in /opt/IBM/WebSphere/ProcServer7/util/
     dbUtils/Derby-SibME/WBI_CEI_ME
    
    [warning] database scripts generation failed for [WBI_CEI_EVENT] due to DDL provider 
     is not available. You will not be able to generate SQL scripts for the component : 
     CEI
    
    Please enter the output directory for WBI_BPC_ME [default=Derby-SibME/WBI_BPC_ME]:
    
    [info] The script(s) have been generated in /opt/IBM/WebSphere/ProcServer7/util/
     dbUtils/Derby-SibME/WBI_BPC_ME
    
    Please enter the output directory for WBI_BPC [default=Derby-BPC] :
    
    [info] The script(s) have been generated in /opt/IBM/WebSphere/ProcServer7/util/
     dbUtils/Derby-BPC
    
    Please enter the output directory for WBI_SCA_APP_ME [default=Derby-SibME/
    WBI_SCA_APP_ME]:
    
    [info] The script(s) have been generated in /opt/IBM/WebSphere/ProcServer7/util/
     dbUtils/Derby-SibME/WBI_SCA_APP_ME
    
    Please enter the output directory for WBI_BSPACE 
     [default=Derby-networkServer-BSpace]:
    
    [info] The script(s) have been generated in /opt/IBM/WebSphere/ProcServer7/util/
     dbUtils/Derby-networkServer-BSpace
    
    Please enter the output directory for WBI_BPCEventCollector 
     [default=Derby-BPCReporting] :
    
    [info] The script(s) have been generated in /opt/IBM/WebSphere/ProcServer7/util/
     dbUtils/Derby-BPCReporting
    
    Please enter the output directory for WBI_SCA_SYS_ME [default=Derby-SibME/
     WBI_SCA_SYS_ME] :
    
    [info] The script(s) have been generated in /opt/IBM/WebSphere/ProcServer7/util/
     dbUtils/Derby-SibME/WBI_SCA_SYS_ME
    
    Please enter the output directory for WBI_CommonDB 
     [default=Derby-networkServer-CommonDB] :
    
    [info] The script(s) have been generated in /opt/IBM/WebSphere/ProcServer7/util/
     dbUtils/Derby-networkServer-CommonDB
  15. When completed, the tool ends with the following messages. The scripts are now available for execution in the locations mentioned in Step 5.
    [info] thanks, quitting now ...
  16. Execute the scripts in the database to complete the database requirements for Process Server.

Creating the profiles

To create the profiles:

  1. Create the deployment manager profile using the following command:
    manageprofiles –response dWDmgr_responsefile.txt
  2. Ensure that the command completes without errors. Open [Installation root]/logs/manageprofiles/dWDmgr_create.log. The following messages indicate that the profile creation is successful:
    <record>
        <date>Mar 29, 2011 11:27:27 PM</date>
        <millis>1301421447906</millis>
        <sequence>19928</sequence>
        <logger>com.ibm.wsspi.profile.WSProfileCLI</logger>
        <level>INFO</level>
        <class>com.ibm.wsspi.profile.WSProfileCLI</class>
        <method>invokeWSProfile</method>
        <thread>0</thread>
        <message>Returning with return code: INSTCONFSUCCESS</message>
    </record>
  3. Do not start the deployment manager at this stage. dbDelayConfig=true requires the database scripts to be manually run by the user to create the databases and required DDL for the databases. You have already executed the database scripts and, therefore, you do not need the value to be false.
  4. Start the deployment manager server and look for a clean startup.
    ../profiles/dWDmgr/bin>./startManager.sh
  5. Ensure that [Installation root]/profiles/dWDmgr/logs/dmgr/SystemOut.log does not report any fatal error messages.
  6. Create the custom profile using the following command:
    manageprofiles –response dWCustom_responsefile.txt
  7. Ensure that the command completes without errors. Open [Installation root]/logs/manageprofiles/dWCustom01_create.log. The following messages indicate that profile creation is successful:
    <record>
        <date>Mar 30, 2011 12:05:19 AM</date>
        <millis>1301423719328</millis>
        <sequence>11307</sequence>
        <logger>com.ibm.wsspi.profile.WSProfileCLI</logger>
        <level>INFO</level>
        <class>com.ibm.wsspi.profile.WSProfileCLI</class>
        <method>invokeWSProfile</method>
        <thread>0</thread>
        <message>Returning with return code: INSTCONFSUCCESS</message>
    </record>
  8. You need to federate the node dWNode02 to the deployment manager. Use the following command from [Installation root]/profiles/dWCustom01/bin. The SOAP port for the deployment manager is located in [Installation root]/profiles/dWDmgr/logs/AboutThisProfile.txt. The default port value is 8879.
    addNode <dmgr hostname> <dmgr SOAP port> -username <administrative username> 
     -password <administrative user password>
  9. Verify that the command completes successfully. You can also verify [Installation root]/profiles/dWCustom01/logs/addNode.log to ensure that the node federation is complete. Note that the nodeagent server will be started after this command. Verify [Installation root]/profiles/dWCustom01/logs/nodeagent/SystemOut.log to ensure that there are no errors.
  10. Verify the profiles using the following command. Both the profiles should be listed in the command output from [Installation root]/bin/:
    manageprofiles.sh –listProfiles
    [dWDmgr, dWCustom01]

This completes the profile creation tasks. You can take a backup of the profile directories at this stage for disaster recovery purposes.


Creating the Golden topology

This section details the steps to set up a Golden topology using the deployment environment commands.

Preparing the environment

The administration tasks will require considerable time using the wsadmin scripts. Therefore, the SOAP timeout has to be adjusted accordingly for the deployment manager to avoid SOAP timeout errors. To adjust the timeout, set com.ibm.SOAP.requestTimeout to 2700 from the default value in the file <dmgr_profile_path>/properties/soap.client.props.

Note: It is a good practice to back up the system configuration before and after a deployment environment is generated.

Running the commands

  1. Start the deployment manager and the nodeagent in the dWCustom01profile:
    ../profiles/dWDmgr/bin>./startManager.sh
    
    ../profiles/dWCustom01/bin>./startNode.sh
  2. Connect to the wsadmin scripting environment from the dWDmgr/bin directory:
    ./wsadmin.sh –lang jython –user <administrative user> -password 
     <administrative user password> -connType SOAP
  3. The following is the command to create a new deployment environment definition. This command creates a deployment environment with a name of dWDepEnv. The topology pattern is specified here as well as the runtime type, which is either WPS or WESB.
    AdminTask.createDeploymentEnvDef (‘[ -topologyName dWDepEnv  
    -topologyPattern RemoteMessagingAndSupport –topologyRuntime  
    WPS ]’)
  4. Add the dWCustom01 node to dWDepEnv. Also configure the clusters and add a single member in each of the clusters.
    AdminTask.addNodeToDeploymentEnvDef (‘[ -topologyName dwDepEnv      
     -topologyRole ADT,Messaging,Support -nodeRuntime WPS –nodeName dWNode02 
     -serverCount 1 ]’)
  5. Validate the deployment environment. Show the current status. Save the changes. To learn more about the status of the deployment environment, refer to this Information Center topic, Displaying deployment environment status using the command line.
    AdminTask.validateDeploymentEnvDef (‘[ -topologyName dWDepEnv ]’)
    AdminTask.showDeploymentEnvStatus (‘[ '-topologyName dWDepEnv ]’)
    AdminConfig.save()
  6. Generate the deployment environment. Ensure that the nodeagent is running before this command is issued.

    This task configures the clusters and servers for the deployment environment first. It then proceeds to create the data sources, authentication aliases, and JMS resources. As part of this task, the SCA and BPC containers are configured in the application clusters, messaging engines are configured in the messaging cluster, CEI, Business Space, business rules, and other support applications are configured in the Support cluster.

    Depending on the size of the topology, the command may take a while to complete the execution. The command took around ten minutes to complete on the Linux server.

    AdminTask.generateDeploymentEnv (‘[ -topologyName dWDepEnv ]’)
    AdminTask.showDeploymentEnvStatus (‘[ '-topologyName dWDepEnv ]’)
    AdminConfig.save()
  7. Ensure that the deferred tasks are completed before you issue the next command.

    Navigate to Servers > Deployment Environments > dWDepEnv > Configuration tab > Additional properties > Deferred Configurations. You will see instructions to complete the deferred tasks as shown in Figure 2. Complete the deferred configuration tasks for the Business Space component. Open the administrative console.

    Figure 2. Deferred configuration steps page in the Administrative console
    Deferred configuration steps page in the Administrative console
    1. Business Space database: The page also displays the location where the database scripts for Business Space are created. Note the location details and execute the database scripts. Failure to complete this task results in error while the application cluster is launched.
    2. CEI database: Complete the CEI database configuration. The CEI database is created after the generation of the deployment environment and the script locations will be indicated. Note the location and execute the scripts to complete the CEI database configuration.
  8. Upon successful configuration, return to this page and click the Configuration Done button as shown in Figure 3.
    Figure 3. Completed deferred configuration steps
    Completed deferred configuration steps
  9. Start the deployment environment. This command starts all the clusters in the environment. Verify that all the servers or clusters have started successfully.
    AdminTask.startDeploymentEnv (‘[ -topologyName dWDepEnv ]’)
    AdminTask.showDeploymentEnvStatus (‘[ '-topologyName dWDepEnv ]’)
  10. Stop the deployment environment.
    AdminTask.stopDeploymentEnv (‘[ -topologyName dWDepEnv ]’)
    AdminTask.showDeploymentEnvStatus (‘[ '-topologyName dWDepEnv ]’)

    The deployment environment is now complete. Figure 4 shows the cluster topology screen from the administrative console.

    Figure 4. Cluster topology view from the administrative console
    Cluster topology view from the administrative console

Verifying the environment

The deployment environment approach hides considerable configuration data from the administrator, performing these tasks in the background. Now that the environment is generated, it is worthwhile to check to see if the configured resources are functioning as designed before using the deployment environment.

Figure 5 shows the various resources configured as part of the deployment environment creation task.

Figure 5. Resources configured in the Golden topology
Resources configured in the Golden topology

A detailed checklist for verification is available in IBM Redbook: WebSphere Business Process Management V7 Production Topologies (Section 5.5: Post-creation configuration and verification). Table 3 shows the verification list.

Table 3. Verification list for the deployment environment
Authentication aliases are created and configured for Service Component Architecture (SCA), Business Process Choreographer (BPC), and their Java Messaging Service.
Data sources are configured and the test connection is successful.
REST service endpoints and the BPC Explorer context root are configured.
Host and ports of all cluster members are updated or added in the virtual hosts.
Messaging engines are enabled and started for SCA (System.Bus and Application.Bus, BPC, CEI). Hosted in dWDepEnv.Messaging.
All standard applications are started and running. BPC, Human Task containers, and Failed Event Manager are hosted in dWDepEnv.AppTarget. CEI service is hosted in dWDepEnv.Support. The BPC Observer and BPC Explorer are hosted in dWDepEnv.Support.
Verify the consoles. Consoles are available for the Failed Event Manager, Common Base Event browser, BPC Explorer, Business Space, and relationships. Verify that the consoles are coming up fine.
Verify the BPC Container using the BPCIVT application.

Modifying the environment

Certain commands are available for modifying the already configured deployment environments. Documentation on these commands is available in the Information Center topic, Administering deployment environments. Note that these commands will not be effective over an already generated deployment environment.

No other modifications are possible via the deployment environment scripts. You will need to manually make the required configuration changes to the environment if the need arises.

Note: If you need to expand the deployment environment to add additional clusters, there are no commands provided in the pre-defined reference patterns. This option is available only on a Custom topology pattern. For expanding deployment environments created using pre-defined patterns, manual configuration is required. For best practices and patterns on expanding clustered topologies, see Expanding clustered topologies for WebSphere Process Server and WebSphere Enterprise Service Bus.

Recovering from failures

If you encounter failure while generating a deployment environment, it is not necessary to remove the deployment environment configuration. You can correct the error, clean up the resources, and reattempt the deployment environment generation. In case you accidentally saved an incorrect configuration, use the deleteDeploymentEnvDef command to remove the configuration:

AdminTask. deleteDeploymentEnvDef (‘[ -topologyName dWDepEnv]’)

This command deletes the deployment environment definition from a deployment manager.

Note: This command does not remove the node, cluster, or server configurations created for the deployment environment. Regenerating the deployment environment after using the above command may not work. We strongly recommend that you manually delete the node, cluster, or server configurations and start the task from scratch. If you are using a topology pattern with webserver, ensure that the corresponding profile or servers and the webserver plug-in configuration are also deleted before the re-attempt. We recommend that you restart the deployment manager after the cleanup. Ensure that the managed nodes are resynchronized with the deployment manager before the deployment environment is rerun.

For a comprehensive list of known issues and defect fixes in this area, see the Support Portal.

For debug information, you can enable wsadmin trace by navigating to the file <dmgr_profile_path>/properties/wsadmin.properties. Uncomment the line #com.ibm.ws.scripting.traceString=com.ibm.*=all=enabled. <dmgr_profile_path>/logs/dmgr/wsadmin.traceout will generate trace information as the commands execute. You can use this trace to troubleshoot any errors you may face while running the commands.

Refer to <dmgr_profile_path>/logs/dmgr/SystemOut.log when you encounter errors while the Process Servicer components are being configured by the commands. For debug information, you can use additional trace specifications for the deployment manager.


Reusing the deployment environment design

The ability to reuse existing configuration to build new environments is another important advantage of the deployment environment, next to the simplicity of building a clustered topology. The commands exportDeploymentEnvDef and importDeploymentEnvDef serve this purpose.

Considerations for importing the design

There are some important points to note before importing a deployment environment definition to a new cell or machine. These are documented in the Information Center topic, Importing deployment environment definitions using the command line.

The import facility helps you to easily import a deployment environment pattern to another environment. For instance, you can create a production environment using the deployment environment commands, use the definition for production environment replica, and test the environment of the same reference topology pattern using the import facility.

You can edit the definition to modify the host or port information, but be careful while changing any other configuration. Any inconsistency in the component ID or component names will cause the environment to throw errors while starting up. Note that the profiles and nodes defined in the definition exist prior to the import task. These have to be created manually using the manageprofiles command.

Also note that you should not alter the CEI data source JNDI name from the default value jdbc/cei. Changing this value will cause the new deployment environment generation to fail.

Since you will import this configuration to a new cell, ensure that the cell name and profile name references are consistent with the new cell. Any mismatch will cause the generation to fail.

Steps to import a deployment environment

  1. A deployment environment is exported using the following command:
    AdminTask.exportDeploymentEnvDef('[-filePath /tmp/dWDepEnvtemplate.xml -topologyName 
     dWDepEnv]')
    AdminConfig.save()

    The configuration is saved to dWDepEnvTemplate.xml. The file stored the deployment environment information such as the clusters, cluster members involved in the topology, the resource configuration required to configure SCA, BPC, CEI, messaging engines for the topology, authentication aliases for the topology, and so on.

  2. On the target cell or target machine, create a new deployment manager profile dWTestEnv and a new custom profile dWCustom02 to host a new deployment environment. Start the deployment manager and nodeagent.
  3. Modify dWDepEnvTemplate.xml to modify the values for the cell, profile, authentication aliases, database users and passwords, cluster names if required, and name of the deployment environment. We will use dWTestEnv.
  4. You can import the deployment environment in another cell or machine using the following command. The command has to be run from the new deployment manager:
    AdminTask.importDeploymentEnvDef('[-filePath /tmp/dWDepEnvtemplate.xml 
     -topologyName dWTestEnv]')
    AdminConfig.save()
  5. Validate the deployment environment using the validateDeploymentEnvDef command. Ensure that there are no errors.
  6. Now that the design is imported. Use generateDeploymentEnv to generate the deployment environment. Ensure that there are no errors during the generation.
  7. If you encounter errors during the generation, refer to the troubleshooting steps discussed earlier for the deployment environment tasks. Save the configuration if the generation is successful. Otherwise, do not save the configuration. If this is done, delete the deployment environment definition using deleteDeploymentEnvDef to remove the saved configuration. Rectify the errors by performing the clean up actions and rerunning the commands.
  8. If the generation is completed and saved, complete the deferred configuration tasks for the deployment environment. Once this is complete, you can start the new deployment environment.

You have successfully reused your original deployment environment design to create an identical topology on another cell or machine in just a few simple steps.


Conclusion

This tutorial discussed the commands and scripts required to create a clustered environment based on a deployment environment reference pattern. You can quickly set up clustered environments using the deployment environment commands and save considerable time and effort setting up the resources individually. Use the commands in conjunction with Part 1 of this tutorial series to automate the installation and clustering tasks of WebSphere Process Server V7.

Acknowledgements

The authors would like to thank Shashi Mara from Technical Support for his valuable advice in authoring this 2-part tutorial series.


Download

DescriptionNameSize
Code samplesdownloads.zip4KB

Resources

Learn

Discuss

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 Business process management on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Business process management, WebSphere
ArticleID=678409
ArticleTitle=Installing and clustering WebSphere Process Server V7 in non-GUI mode, Part 2: Using the command line to create a cluster
publish-date=06082011