The convedo Tech Talk Blog

The OpenText Process Suite ABC Glossary - High Availability part 2

Written by Sascha Cutura | 25 November 2015

HIGH AVAILABILITY

The OpenText Process Suite platform web gateway

As described before, when installing and configuring the OTPS platform for high availability, you install the OTPS platform baseline to run in primary distributed mode. Each of the OTPS platform instances will be running its own web server and OTPS web gateway. Typically in these scenarios, you will use an IP (Internet Protocol) Load Balancer to distribute the workload across the multiple nodes of the cluster. Although both hardware and software based IP load balancers can be applied, it is recommended to use a hardware based for better performance and their built-in high availability features.

CARS – Cordys Admin Repository Server

The OTPS clusters consists of at least two or more instances (nodes) that are installed in primary distributed mode and are used to distribute the load of web service requests between the different nodes of the cluster. Each instance has its own CARS repository while these repositories are configured to run in Multi‑Master replication mode. This ensures that the contents of the different master CARS repositories are synchronized over time, and whenever one of the masters fails, the requests can be handled through any of the other master repositories.

Alternatively, multiple OTPS instances can share one and the same CARS repository, but notice that this creates a single point of failure you have to ensure that the CARS repository is running on a highly available LDAP server. This should make sure that the contents of the CARS repository is replicated to prevent data loss for any reason. Documentation is available in a separate CARS administrators guide.

SOA - Services Oriented Architecture grid

The SOA grid of the OTPS platform is created by defining any number of service containers. Web service requests are handled by service containers, these are JVMs (Java Virtual Machine) that are handling the requests. Service containers are grouped in a service group. The service container reads the associated native implementation of the web service operation from the CARS repository and forwards the implementation to the associated application connector. The application connector executes the native (source) code and any result is passed back to the service container which passes it back to the client requesting the web service execution.

When you define a service container, you start by creating a service group to group similar service containers. At the level of the service group, you associate the web service interfaces (library of web service operations). This information is stored in the CARS repository, service group with web services interfaces, the web service operations and their implementation. After you defined a service container, you can quickly clone another service container with the same group and run the service container on another node of the cluster. By cloning service containers, you create multiple service containers that run the same type of web services across the different nodes of the cluster. The load between the different service containers is divided by the load balancing algorithm specified at the service group level.

When starting any of the node(s), each node will start the OTPS monitor service that will next start the other service containers within the node that are defined to be started automatically. While running, the OTPS monitor service keeps track of the state of the available services containers of that node. This state information together with registered problems if any, are shared and maintained by means of a SSU (State Sync-Up) based framework. You can run the CMC (Cordys Management Console) from any node and use the option “State SyncUp” to explore the current overview of the registered state of all of the service containers across the different nodes of the cluster. Whenever the monitor service discovers that the service container has failed for what reason, if the service container is defined to start automatically with cluster node start-up, the monitor will try to restart the service container again.

The OTPS platform instance database(s)

With any OTPS platform instance, one or more databases are used to store the relevant data of the running instance. Typically, these databases should be running in high availability mode as well. For configuration, you are referred to the documentation of the RDBMS (Relational Database Management System) used, MS-SQLServer, Oracle or MySQL. Notice that depending on the purpose of the cluster, running for production, development, test or acceptance, the OTPS platform instance may use different databases for storing details on the whole system (system DB), separate BAM repository for monitoring the running process instances. In case of a development cluster, the CWS contents can be saved in a separate database to enable backup and recovery of only the development efforts.

The OTPS platform instance local file system

The local file system of the OTPS platform instance is used for installation of all the platform files of the OTPS instance.  When deploying applications on the nodes of the cluster, some of the component contents of the application will be deployed on the local file system as well. Ensure that the local file system is scalable, and that is included in any backup and recovery scenario. In addition to the local file system, you can also use a shared file system for storing and retrieving any contents that is used by the applications.

When configuring the OpenText Process Suite platform for scalability and/or high availability, you have two areas to consider:

  1. The OTPS platform constituents

The different constituents we have discussed before, such as the OTPS web server gateway, the CARS repository, the OTPS system database and other configured databases for data storage of BAM data, or CWS workspaces, etc.

  1. The non OTPS platform parts

Non OTPS platform parts are the file system of the OTPS platform server(s), the database management system involved for managing the different data stores used by the OTPS platform.

Make sure that in the explanation of your high availability configuration, you are including any backup and recovery strategies as well for both the OTPS platform constituents as well as the above mentioned non OTPS platform parts.

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!