Understand configuration options for process integration

 

+

Search Tips   |   Advanced Search

 

 

WebSphere Portal and WebSphere Process Server managed in different WAS cells

• A stand-alone portal server configured to use a stand-alone process server
• A stand-alone portal server configured to use a process server cluster
• A portal server cluster configured to use a stand-alone process server
• A portal server cluster configured to use a process server cluster

 

WebSphere Portal and WebSphere Process Server managed in the same WAS cell

• A single, federated portal server configured to use a single, federated process server
• A single, federated portal server configured to use a process server cluster
• A portal server cluster configured to use a single, federated process server
• A portal server cluster configured to use a process server cluster

Restrictions

You can only install WebSphere Portal into a Base Application Server profile.

Installing WPS on top of WebSphere Portal supports only the WPS Client functionality.

The WPS Client functionality and the complete WPS server are mutually exclusive. Therefore, you enable business process integration by installing the WPS Client and connecting to a remote WPS server.

 

Deployment choices

Determine how you want to deploy the integrated servers by answering the following questions:

• Should the integrated products, WebSphere Portal and WPS, run as stand-alone servers or in a cluster?The decision to use a cluster is driven mainly by the following factors:
  • The need to support advanced availability
  • The planned load of the portal, which may exceed the capabilities of a single server.

• Should these products run in the same WAS management cell or in different management cells?

  A single-cell deployment is simpler than a cross-cell deployment because the portal and process server cooperate through the common name space (JNDI) of the single-cell. A cross-cell deployment requires that LTPA single sign-on be enabled in WAS for the processing of CSIv2. However, single-cell deployment increases the dependencies between the products. For example, if one of the products requires a maintenance upgrade, the other product is likely to require an upgrade as well. It is important to consider the deployment manager server (DMGR) because it coordinates both products.

  In additions to these technical factors, various non-technical factors, such as the availability of skilled administrators, will influence your decision.

  Consider the following factors when choosing a single-cell setup or a cross-cell setup for business process integration:

  • The need for manual remote artifact loading

    The remote artifact loader allows the generic portlets to retrieve the process artifacts from the process definition, namely, the XML definitions of the input and output messages required for task processing. In a cross-cell setup, manually deploy the process artifacts to the WebSphere Portal cell.

    If you intend to use the generic portlets and want to manage a simple deployment, choose single-cell setup.

  • One type of server is already in operation

    If either WebSphere Portal or WPS is already in operation when the complementary servers are added, it is normally a good practice to use two cells because this will minimize the influence of building up the new servers in the existing environment.

  • Availability and skills of the required staff

    A cross-cell setup requires an additional management console and creates slightly more complexity for the administrator. If your enterprise is small, the availability of a skilled administrator to manage the integrated deployment might be a factor in choosing a single-cell setup over a cross-cell setup.

The illustration shows the various ways in which business process integration can be configured in combination with clustering. The orange arrows indicate the process of scaling an existing portal installation from a single server into a cluster, while the green arrows indicate the configuration step for business process integration. These two actions can be performed in any order. To build up a clustered portal server that is connected to a process server, choose the sequence that meets your needs:

• Cluster first.

  This sequence is most often used when WebSphere Portal is already installed and running, before the decision to use WPS is made, because availability or the system load required clustering while process server was not available at that time. Once the new process server is available, install the WPS Client on top of the portal to enable portal-to-process server communication:

  1. Install WebSphere Portal as a stand-alone server.

  2. Cluster the portal.

  3. Add the WPS Client on top of each portal node.

• Connect first.

  This sequence is preferred when WPS is already installed and running, before WebSphere Portal is installed. This approach allows for early prototypes and testing. After prototyping and testing has been successfully completed, the portal will be clustered to carry the load of a production environment.

  1. Install WebSphere Portal as a stand-alone server.
  2. Add the WPS Client on top of each portal node.
  3. Cluster the portal.

 

Parent topic

Planning integration with WPS

 

Previous topic:

Prerequisites for setting up process portals

Next topic:

Planning to use process portals

 

Related concepts

Planning for multiple clusters