Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
5
topology by using multiple deployment environments
Yu Xiao Li (yuxiaoli@cn.ibm.com )
Advisory Software Engineer
IBM
30 June 2014
As your business requirement grows, you may want to expand the topology of IBM Business
Process Manager to run different processes independently. This article introduces how to
expand the IBM BPM V8.5 topology using multiple deployment environments.
Introduction
After you install and configure the runtime environment on IBM Business Process Manager
(BPM) and your business requirements continue to grow and change, you may want to run more
processes and isolate those processes. You can expand the environment by configuring multiple
deployment environments (DE) in this case. Each deployment environment can run different
processes and work independently.
This article introduces how to expand IBM BPM V8.5 topology by using multiple deployment
environments, including topology planning, configuration methods according to your requirements,
configuration and post verification steps, and troubleshooting tips. You can use this article to plan
your multiple deployment environments and configure them for your environment.
This article is intended for IBM BPM users and administrators who have growing business
requirements, need to run more processes independently in their IBM BPM environment, and need
to isolate different IBM BPM deployment environments in the same cell.
Trademarks
Page 1 of 22
developerWorks
ibm.com/developerWorks/
Adding cluster members may not be suitable for all situations. For example, you may want to
isolate different applications. If you deploy different applications to the same DE, it may introduce
dependencies between those applications, such as maintenance schedules and application
availability. Also, you may already have many applications running on the existing DE. Adding
more applications to the same DE may result in too many modules, or heavily using your database
tables.
Adding cells
To expand your topology, you can also create a new cell, and then create a new DE in this new
cell. This method is the most flexible, and it can isolate applications in different DEs. However,
it requires more administration work. You will need to use different admin consoles to manage
different cells and DEs.
Page 2 of 22
ibm.com/developerWorks/
developerWorks
applications on different DEs independently, and you can manage them in the same admin
console.
However, in an IBM BPM network deployment environment, you can configure a routing server,
such as an IBM HTTP (IHS) Server, a WebSphere Application Server proxy server, or others, as
a proxy server for workload balancing and failover purposes. Instead of incoming HTTP requests
going directly to an application server, they go to the proxy server, which then distributes the
requests across multiple application servers that perform the work.
After configure IHS, you can use the IHS host name or IP to access all IBM BPM web-based tools,
such as Portal, Process Admin, BPC Explorer, Process Center, Business Space, and so on. But
for example, if you use the URL of http://IHSHostName/bpc to access the BPC Explorer, you
cannot distinguish the BPC Explorer of the two DEs. The URL is the same for the BPC Explorer of
the two DEs, as they are using the same IHS and in the same cell.
Therefore, you have to do some configurations to distinguish between the two DEs. There are two
ways to do it: by virtual host or by context root.
Page 3 of 22
developerWorks
ibm.com/developerWorks/
You cannot install the same SCA applications to both DEs because both DEs are in the same
cell, and there is only one admin console to manage them.
Only Process Server supports multiple DEs. Process Center does not support multiple DEs.
Each DE must have their own application cluster, and if you select to use a three cluster
topology, each DE must have their corresponding messaging and support clusters.
Each DE must use different databases. For example, if you are using DB2, you can use the
same DB2 instance. However, you need to use different databases for different DEs.
If there is an issue with one application in the cell, it is not possible to apply an interim fix only
to the affected application. Interim fixes affect all servers and clusters in the cell.
Multiple DE configurations
In this section, we will introduce how to configure double DEs using IBM BPM Advanced Edition.
We will use the IHS as proxy server and configure different virtual hosts for each DE.
Environment topology
In our sample environment, there will be double IBM BPM Advanced PS DEs. Both of them will
use the same IHS. The topology diagram is shown in Figure 2.
Page 4 of 22
ibm.com/developerWorks/
developerWorks
Page 5 of 22
developerWorks
ibm.com/developerWorks/
Host alias
Used by
Golden1
Golden1
DE1
proxy_host
Golden2
DE2
admin_host
Dmgr
default_host
Page 6 of 22
ibm.com/developerWorks/
developerWorks
Page 7 of 22
developerWorks
ibm.com/developerWorks/
After running the commands, all applications deployed on DE1 will use the virtual host of
"Golden1" as shown in Figure 9.
Page 8 of 22
ibm.com/developerWorks/
developerWorks
After running the commands, all applications deployed on DE2 will use the virtual host of
"proxy_host", similar to Figure 9.
Update the rest service gateway applications and rest service providers
Be default, the REST Services Gateway application is deployed on both DEs and it is impossible
to distinguish it for the different DEs. Deploy another REST Services Gateway application with a
different name, and map a different REST Services Gateway application to each DE. Also, you
need to update the other service providers.
Page 9 of 22
developerWorks
ibm.com/developerWorks/
Second, map the application to the DE1 application cluster and web server. In the admin console,
select Applications > Application Types > WebSphere Enterprise Applications > REST
Services Gateway > Manage Modules and update the information as shown in Figure 11.
Third, change the context root to "restPS1". The rest service gateway applications of the different
DEs must use different context roots; otherwise, some applications that use the rest APIs cannot
distinguish the two applications. In the admin console, select Applications > Application Types
> WebSphere Enterprise Applications > REST Services Gateway > Context Root for Web
Modules and update the information as shown in Figure 12.
Figure 12. Context root of the DE1 rest service gateway application
Page 10 of 22
ibm.com/developerWorks/
developerWorks
To update the context root from default rest to "restPS1", besides updating in the admin console
as shown in Figure 12, you also need to run the following UpdateRESTServiceProvider wsadmin
command. Enter your user credentials when prompted.
wsadmin.bat -lang jython
wsadmin>AdminTask.updateRESTServiceProvider(['-clusterName', 'DE1.AppCluster', '-appName',
'REST Services Gateway', '-webModuleName', 'rest.gateway.war', '-contextRoot', '/restPS1'])
wsadmin>AdminConfig.save()
Deploy and update the rest service gateway application for DE2
To distinguish the rest service gateway applications of the different DEs, you must manually deploy
another rest service gateway application to DE2 and update the configurations:
1. First, deploy the rest service gateway application manually to DE2. The REST Services
Gateway application is found in the WebSphere Application Server installation as root/
installableApps/RESTServiceGateway.ear. Deploy it from the admin console by selecting
Applications > Application Types > WebSphere Enterprise Applications > Install. When
you deploy it (see Figure 13), you need to identify a different application name, such as
"REST Services Gateway PS2", to distinguish it from the existing REST Services Gateway
application of DE1.
2. Second, when you deploy the application, map the application to DE2 and web server as
shown in Figure 14.
Page 11 of 22
developerWorks
ibm.com/developerWorks/
Figure 14. Map modules of the DE2 rest service gateway application
3. Third, update it to use the virtual host of "proxy_host", which you used for the DE2
applications. Similar to DE1, update the virtual host as shown in Figure 15.
4. Fourth, change the context root to "restPS2". Similar to what you did for DE1, update the
information as shown in Figure 16.
5. To update the context root from default rest to "restPS2", besides updating in
the admin console as shown in Figure 16, you also need to run the following
Page 12 of 22
ibm.com/developerWorks/
developerWorks
Scope
Port
Cluster=DE2.SingleCluster
Golden2
443
IBM_BPM_Teamworks_DE2.SingleCluster
Cluster=DE2.SingleCluster
Golden2
443
BPEContainer_DE2.SingleCluster
Cluster=DE2.SingleCluster
Golden2
443
TaskContainer_DE2.SingleCluster
Cluster=DE2.SingleCluster
Golden2
443
No need to update
Cluster=DE1.AppCluster
Golden1
443
IBM_BPM_Teamworks_DE1.AppCluster
Cluster=DE1.AppCluster
Golden1
443
BPEContainer_DE1.AppCluster
Cluster=DE1.AppCluster
Golden1
443
TaskContainer_DE1.AppCluster
Cluster=DE1.AppCluster
Golden1
443
Page 13 of 22
developerWorks
ibm.com/developerWorks/
Similarly, update the context root for the DE2 TaskContainer application as shown in Figure 19.
Expanding the IBM Business Process Manager V8.5 topology by
using multiple deployment environments
Page 14 of 22
ibm.com/developerWorks/
developerWorks
Page 15 of 22
developerWorks
ibm.com/developerWorks/
Figure 20. Update the DE1 BPC Explorer REST API URLs
For DE2, update the REST URLs to use the virtual host of Golden2, and add the context
root of PS2. In the admin console, select Servers > Clusters > WebSphere application
server clusters > DE2.SingleCluster > Business Process Choreographer Explorer >
BPCExplorer_DE2.SingleCluster and update the information as shown in Figure 21.
Page 16 of 22
ibm.com/developerWorks/
developerWorks
Figure 21. Update the DE2 BPC Explorer REST API URLs
Page 17 of 22
developerWorks
ibm.com/developerWorks/
Figure 22. Business Space REST services endpoint registration for DE1
Figure 23. Business Space REST services endpoint registration for DE2
Page 18 of 22
ibm.com/developerWorks/
developerWorks
IP is "9.110.83.101" and the virtual hosts of DE1 and DE2 are "Golden1" and "Golden2". Add the
following two lines in the hosts file:
9.110.83.101 Golden1
9.110.83.101 Golden2
Page 19 of 22
developerWorks
ibm.com/developerWorks/
Troubleshooting tips
During your configurations, there are some things you need to notice. Here are some
troubleshooting suggestions:
After you create two DEs, and before all other configurations, verify if your environment
works. For example, start your DE and check the error logs.
After you configure IHS, and before other configurations, verify if you can access all webbased tools via IHS. For example, if you can access them by http://IHSHostname/bpc, then
IHS is working. If you cannot access it, you can try to access web-based tools directly, not via
IHS, for example, http://BPMHostname:port/bpc. If you cannot access it, then the IBM BPM
configuration has problems.
Similarly, it is better to verify your configurations after each step. And if possible, backup your
environment before important configuration steps.
In a double DE environment, there will be more IBM BPM servers running so you may need
more powerful CPUs and more memory. Otherwise, it may take a significant amount of time to
start and stop the environment.
Make sure you update the hosts file on all the machines as we described before. Otherwise,
you may have problems accessing some of the web-based tools.
Conclusion
This article described how to expand the IBM BPM V8.5 topology by using multiple deployment
environments. It provided topology planning, configuration methods according to your
requirements, configuration and post verification steps, and troubleshooting tips.
Page 20 of 22
ibm.com/developerWorks/
developerWorks
Resources
Page 21 of 22
developerWorks
ibm.com/developerWorks/
Page 22 of 22