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):
- 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.
- 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:
- 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.
- 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.
- 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!
