General steps for implementing a deployment environment
After designing a deployment environment, you will perform specific tasks to make that design a reality. Regardless which method you use to implement the deployment environment, you will perform the same general steps.
- Plan your topology and record the decisions you make about:
- The servers and clusters involved.
- The number of databases required.
- Which database tables belong in which databases
- Any required userids and authentication roles
- What function each cluster involved in the deployment environment provides
- Which method you are using to implement the deployment environment
- Make sure the systems on which you are installing the product meet the hardware and software requirements.
- Prepare the operating system for installation.
- Make sure all servers involved in the topology can be located by both IP address and Domain Name Server (DNS) name.
- Make sure you have a user ID that has the appropriate authority to create directories and files on all systems.
- Make sure you perform any other preparation that might be needed to coexist with other products and provide any needed redundancy.
Now that you have completed planning your deployment environment and performed all the prerequisite tasks, install the servers and clusters involved in your design. Regardless of the method you choose to implement the deployment environment, the following steps outline creating a single cell of that design.
This procedure covers all of the steps required to implement a deployment environment and the order might differ slightly depending on your installation method.
Procedure
- Install the product binaries on all systems involved in the deployment environment and verify that the software is correctly installed.
- Optional: Design the database configuation
If you choose to, you can design the database configuration using the database design tool (DDT). Designing the database configuration before profile creation time can result in simplifying the profile creation process. If you design the database configuration early in the configuration process, you can import the database design document at profile creation time.
Whether or not you choose to use the DDT as a way to create your database configuration is a design decision that you need to work out with members of your solution implementation team.
- Create the dmgr.
IBM BPM provides you with multiple ways to create the dmgr, including using PMT or manageprofiles.sh. The method that you select for creating the dmgr profile is a matter of preference. Each method is documented in the section on Creating profiles.
- Start the dmgr.
- Create as many managed nodes as you need.
- Federate the nodes from step 5 to the dmgr created in step 3.
- Configure the cell.
You can use the Deployment Environment Configuration wizard to configure the cell. You can use the wizard to create a deployment environment based on patterns. Deployment environment patterns are rules-based configurations of the most commonly used business integration topologies. A pattern provides a template for an environment configuration. Because the deployment environment patterns represent well-known, tested and recommended topologies with component configurations that work together; using patterns ensures reliable deployment environment functionality.
If you are using a script to create the deployment environment, the configuration can take a long time depending on your deployment environment. To prevent the process from timing out, set the SOAP request timeout on the dmgr to a large value, for example 1800 seconds. See "Java™ Management Extensions connector properties" in the WebSphere Application Server information center for information on SOAP request timeout. To change the default timeout value, open the file $WAS_HOME/profiles/<profile name>/properties/soap.client.props in any ASCII text editor and find the following line (shown here with default value of 180 seconds):
com.ibm.SOAP.requestTimeout=180If you need to change the default you can edit this line to set the timeout to a value more appropriate for your situation. Setting the value to 0 will disable the timeout check altogether.
Configure the cell involves creating the clusters to perform the functions you defined to them in your design and then adding members to those clusters.
If your design implements a patterned deployment environment, the system creates all needed clusters and defines cluster members to provide all necessary functions. Depending on the pattern you selected, this includes clusters for application deployment, messaging support and infrastructure support.
If your design implements a custom deployment environment, create all the clusters needed to provide the necessary functions. These functions include messaging support for application deployment, application support and Common Event Infrastructure support.
- Configure the databases or database tables required for your topology, if you chose deferred table creation.
Configuration consists of running the scripts generated by the deferred option.
- Configure the common database tables. These tables are in the common database. See Create the databases and Ddl2Pds.sh script for more information.
- Configure the messaging engine database tables. These tables are in the common database.
- Optional: Configure the Business Process Choreographer database tables.
If your system is not using business processes or human tasks, bypass this step. This table resides in whichever database you configured for use by the Business Process Choreographer, which is named BPEDB by default.
If you are using the Business Process Choreographer Explorer reporting function, you also need to configure the Business Process Choreographer Explorer reporting database (OBSRVDB).
- Create the enterprise service bus logging mediation database table. These tables are in the common database.
- Configure the Common Event Infrastructure database.
- Create a proxy server in WebSphere Application Server. The proxy server routes HTTP requests to content servers that perform the work.
You can use other routing servers in place of, or in front of the proxy server, for example IBM HTTP Server. The benefit of using the proxy server is that it is integrated with WebSphere Application Server and therefore easy to use and maintain.
Attention: The proxy server (or an alternate routing server) is required when you are load balancing HTTP requests between two or more cluster members. This server allows clients to access the applications within this topology.
- Verify the installation by installing and running test applications.
What to do next
- Create another cell, if required.
- Deploy the applications that are to run in this deployment environment.
Related tasks:
Create the Process Server deployment environment using a pattern