The following types of systems are supported in CA Process Automation:
A simple CA Process Automation system includes the following components:
- The Domain Orchestrator
Orchestrators are CA Process Automation servers. Users connect to an Orchestrator to design and test processes, run processes, and configure the CA Process Automation system. Every CA Process Automation system has a Domain Orchestrator and can have one or more non-Domain Orchestrators. A simple deployment has a single Domain Orchestrator.
- A Database Server
During the Domain Orchestrator installation, you identify the database server in which to create the CA Process Automation databases:
- The Library database stores the automation content that you create (for example, processes, datasets, and forms).
- The Runtime database stores state information about process instances that have run or are in the process of running.
- The Reporting database stores information about process instances that have run in a format suitable for reporting against.
- CA EEM
- During the Domain Orchestrator installation, you register the CA Process Automation application with CA Embedded Entitlements Manager (CA EEM). A single CA EEM instance can be used with multiple CA Technologies products to provide a single place to manage user identities and their application permissions.
- CA EEM authenticates CA Process Automation users. CA EEM tries to match credentials that users enter at login with credentials of known CA Process Automation users. All valid credentials are either defined directly in CA EEM, or referenced by CA EEM from one or more LDAP-based repositories such as Microsoft Active Directory.
- CA EEM also manages the authorization levels for CA Process Automation users. In CA EEM, you assign permissions to each user account after CA Process Automation is installed to provide permissions in the CA Process Automation application.
Many deployments require the ability to distribute some workload to run on hosts other than the Domain Orchestrator. Some types of workload can be run on a remote host without an agent being installed on it. However, more functionality is available when CA Process Automation agent is installed on the target host.
Each process instance consists of one or more operators. Each operator is targeted to run on a specific host, either directly, or indirectly using touchpoints. Through system configuration, each touchpoint is mapped to a specific host.
The same touchpoint can map to different hosts in different CA Process Automation domains or environments. Thus, touchpoints allow the same process content to be deployed unaltered in different CA Process Automation domains or environments.
Touchpoints can map to CA Process Automation Orchestrator or CA Process Automation agent. A proxy touchpoint maps to a remote host that contains no CA Process Automation software. Orchestrators can distribute workload to a remote host by:
- Connecting to it directly over SSH.
- Connecting through an agent that in turn connects to the remote host over SSH.
Like a touchpoint, a proxy touchpoint is a logical entity. A proxy touchpoint is a name that can be used in the process designer to specify an operator execution target. While a touchpoint is defined and mapped to a specific agent through environment configuration, a proxy touchpoint is mapped to a specific agentless remote host. Each agentless remote host (mapped to a proxy touchpoint) is managed by an agent that is installed on a different host. When an Orchestrator distributes work that targets a proxy touchpoint, it sends the work to the agent that manages the remote host. That agent in turn establishes an SSH session to the remote host to complete the work.
Therefore, the primary task of CA Process Automation agent is to execute workload on the host on which it is installed. Agents can act as gateways through which workload is distributed to remote hosts on which you cannot install agents.
Many installations deploy a clustered Domain Orchestrator for high availability and scalability of the deployment.
A clustered Orchestrator consists of two or more nodes. In normal operations, workload is shared across the nodes of the Orchestrator. More nodes can be added to scale out the capacity of the Orchestrator as necessary. To provide High Availability, other nodes in a cluster assume Orchestrator node responsibilities if it fails, until it recovers.
Each Orchestrator node is installed on a different host. You install and upgrade each node separately.
If you initially installed an Orchestrator in a standalone configuration, rerun the installation wizard to reconfigure it as a node of a clustered Orchestrator.
- Load Balancer
CA Process Automation supports hardware and software load balancers, for example:
- Apache (with functional limitations)
The Apache load balancer is supported for communication between upgraded agents and a clustered Orchestrator. However, it does not support the protocol that the simplified communications mechanism requires. You can continue using the deprecated communication model with Apache. However, if you plan to deploy CA Process Automation with a software load balancer, CA Technologies strongly recommends that you use NGINX.
- High-availability CA EEM
CA Embedded Entitlements Manager can be configured with a failover node for deployments that require a full high-availability configuration.
Advanced Configuration Options
- Non-Domain Orchestrators
You can partition automation workload by deploying other Orchestrators. As with Domain Orchestrators, these non-Domain Orchestrators can be clustered.
Consider the case where some workload must run in a specific data center or geographic region and the CA Process Automation system requires a different configuration in each location. One approach is to deploy an Orchestrator in each data center and use Orchestrator-level configuration to override Domain-level configuration appropriately.
A standard deployment has one Domain and a single environment (the Default Environment).
You can partition a CA Process Automation domain into multiple environments. Then, you can tailor various aspects of the Domain configuration to each environment. For example, with multiple environments you can configure aspects one way in a content development context and another way in a testing or production context.
Each environment can have a specific Library so you can potentially have different versions of content in the different environments.
Environments also partition workload. Any specific Orchestrator is associated with one environment. The Default Environment has the Domain Orchestrator and can have one or more non-Domain Orchestrators. All other environments have one or more non-Domain Orchestrators. Each Domain Orchestrator and each non-Domain Orchestrator can be clustered (multiple nodes) or nonclustered (one node).
Environments can also help you partition workload in a production context. For example, a service provider could deploy one environment per customer. This setup allows running the same standard automation content across multiple environments whose workload is physically partitioned. These environments that run the same content are configured differently and, potentially, running in different geographic locations.
- Data Store Implications of Adding Environments and Non-Domain Orchestrators
You have flexibility in how you assign the sharing of data stores across Orchestrators. The typical illustrated associations are:
- One Reporting data store that all Orchestrators in the Domain share. Although you cannot share any data store across Domains, it is possible to have more than one Reporting data store.
- A Library data store for each environment, where all Orchestrators in the same environment share each Library data store.
- One Runtime data store per Orchestrator (required). Each standalone (nonclustered) Orchestrator has a Runtime data store. Likewise, each clustered Orchestrator uses a single Runtime data store.
In a simple deployment with a nonclustered Domain Orchestrator in the Default Environment, the CA Process Automation data stores are installed in one database on one database server.
Adding more environments and installing non-Domain Orchestrators significantly increases the complexity of the data store configuration required.