The convedo Tech Talk Blog

The OpenText Process Suite ABC Glossary - GUID & High Availability #1

Written by Sascha Cutura | 17 November 2015

GUID

Globally Unique Identifier

In the OpenText Process Suite, this is a hexadecimal string consisting of 32 positions, e.g. 000c2990-6953-11e5-e141-1f639364d29b.

Every object or component, process and / or case instances is assigned a GUID to uniquely identify that object or instance of the object. With the process, this is called a Process Instance ID (PID).

HIGH AVAILABILITY

The OpenText Process Suite (OTPS) platform has a number of architectural features that make the OTPS platform highly scalable. In addition to the scalability, some of these features can also be used to configure the platform for high availability. These features enable you to create an IT infrastructure that is effectively resilient to various disruptions that can happen while running the application(s) on the platform, for example, one of the involved systems or applications crashes, network problems, power outage of one of the components, etc.

Note that for disaster recovery of the OTPS platform there is documentation available in a separate disaster recovery guide.

When you configure the OTPS platform for high availability, there are two functions for configuration of the OTPS platform cluster with any number of nodes (OTPS platform instances):

  1. Failover configuration of the cluster

When a node with a particular application crashes, configuring the cluster for failover ensures that this situation is remedied without immediate administrative intervention. In failover configuration, one of the nodes within the server is set with high priority or first preference for handling the services within the cluster, this node becomes the active node. All other nodes are defined as passive or standby nodes. Whenever the active nodes fails for any reason, the passive node or one of the passive nodes will automatically take over. This kind of configuration is also called active‑passive cluster configuration.

  1. Load balancing configuration of the cluster

This type of configuration makes a more efficient use of the different nodes of the cluster. All nodes in the cluster will handle the services with equal preference and thus any received requests can be handled simultaneously. If any of the nodes fails the remaining node(s) will automatically take over the load and handle the requests without any interruption. This is also called active‑active cluster configuration.

The latter option (active-active cluster configuration) is most economical and does not waste any of the HW (HardWare) and SW (SoftWare) resources used. High availability configuration with the OTPS platform is typically focussed on this active-active type of configuration providing a most optimized and performant OTPS platform cluster. Documentation is available in a separate high availability configuration guide.

While installing the OpenText Process Suite platform, you can choose between three different types of installation:

  1. Single server installation, one single OTPS platform instance with one associated CARS repository running on a single server, this is also referred to as standalone installation.
  2. Side-by-side installation, multiple instances of the OTPS platform with preferably their own CARS repository running on the same server. Note that multiple instances can share one single CARS repository. However, it is strongly recommended to install each OTPS instance with their own CARS repository. When you need to backup and restore the CARS repository, this only effects one of the instances to become temporarily unavailable rather than all OTPS instances.
  3. Primary distributed installation, you are following a similar installation procedure as of a single server installation. However, each instance will represent one of the nodes and these collectively form the OTPS cluster. Each instance has its own CARS repository while these repositories are configured to run in Multi‑Master replication mode. This ensures high availability both at the CARS repository level as well as at the OTPS instance level.

An OTPS platform application consists of a number of different components:

  • The business process(es) that constitute(s) the application;
  • The web services implementing the (system related) activities included the process(es);
  • The user interfaces for any kind of human interaction involved;
  • Other components like roles, rules, decision tables, work lists, etc.

Note that when deploying an application on the OTPS platform cluster, it must be deployed on every single node in order to ensure that each OTPS instance can run the application contents. When deploying an application from one node, the system administrator can immediately deploy the application across multiple nodes of the cluster.

To be able to run such an application in high availability mode, you need to configure a number of architectural constituents for high availability. The constituents involved are:

  • The OpenText Process Suite web gateway that passes the requests received by the web server (IIS, Apache or TomEE) to the OTPS cluster.
  • CARS (Cordys Admin Repository Server), the repository containing the essential data for managing the OTPS platform instance at system level as well as organisational level.
  • SOA (Services Oriented Architecture) grid, the service containers and the associated application connectors that form the so-called SOA grid that serves as the ESB (Enterprise Service Bus). The SOA grid is handling all the web service requests that are passed to the OTPS platform cluster.
  • The OTPS platform instance database(s) are used to save the details on the running process instances, and other databases configured as BAM or CWS repository (when development server or cluster is involved).
  • The OTPS platform instance local file system. The file system is used for different purposes when running the OTPS platform. Refer to the topic: File system for more details.

The following diagram depicts the most preferable scenario for the configuration of an OTPS cluster with multiple nodes:

List of abbreviations 

Abbreviation Description
 ANSI  American National Standards Institute
 BAM  Business Activity Monitoring
 BER  Business Event Response
 BPML  Business Process Modeling Language
 BPMN   Business Process Modeling Notation
 BPMS   Business Process Management Suite (or System)
 CAF  Composite Application Framework file extension
 CAL   Composite Application Logging (framework)
 CAP  Cordys / Composite Application Package (file extension)
 CARS  Cordys Admin Repository Server
 CMC   Cordys Management Console
 CRUD  Create, Read, Update and Delete, data manipulation operations with a    relational database
 CWS  Collaborative Work Space
 DTAP   Development, Testing, Acceptance and Production
 ESB   Enterprise Service Bus
 HW   HardWare
 IDE   Integrated Development Environment
 IP   Internet Protocol
 JAR  Java ARchive file extension
 JVM   Java Virtual Machine
 KPI   Key Performance Indicator
 LDAP   Lightweight Directory Access Protocol
 OMG   Object Management Group
 OTPS   OpenText Process Suite
 PIM   Process Instance Manager
 PMO   Process Monitoring Object
 RDBMS   Relational DataBase Management System
 SCM   Software Configuration Management
 SCXML   State Chart XML
 SOA   Services Oriented Architecture
 SOAP   Simple Object Access Protocol
 SQL  Structured Query Language
 SSU   State Sync-Up
 SVN   SubVersioN
 SW   SoftWare
 W3C  World Wide Web Consortium
 WfMC   Workflow Management Coalition
 WSDL   Web Service Definition Language
 WSI  Web Service Interface
 WSO  Web Service Operation
 XML   eXtensible Mark-up Language
 XPDL   XML Process Definition Language

Don't miss out on future blog posts! Subscribe to email updates today!