Cisco Cisco Process Orchestrator 3.0 User Guide

Page of 242
 
1-14
Cisco Process Orchestrator User Guide
OL-30196-01
Chapter 1      Understanding Service-Oriented Orchestration and the Cisco Process Orchestrator
  Process Orchestrator System Components
Process Orchestrator Server (Process Engine)
At the core is the Process Orchestrator Server, which executes automated processes. This component is 
responsible for:
  •
Creating instances of running processes
  •
Orchestrating the execution of these processes
  •
Configuring multiple servers to work together for load balancing and in an active-active 
configuration to achieve high availability.
Role-Based Access Control (RBAC)
Windows performs authentication of the user connecting to Process Orchestrator against Active 
Directory. The authentication is done prior to connection to the Process Orchestrator server, and the 
Process Orchestrator server simply relies on the results of that authentication. No special end-user 
account management is necessary for Process Orchestrator.
In Process Orchestrator, authorization is performed using a Role-Based Access Control System. Roles 
are a collection of permissions. Users are assigned to roles that give them the ability to perform the 
actions allowed by the role. 
Typically, roles are defined according to a standardized job function within IT. Examples might include 
Level 1 Helpdesk, Level 2 Helpdesk, Cloud Technical Administrator, Network Configuration, SAP Basis 
Expert, and so on. Security groups already in the directory for the users in these job functions are then 
typically assigned to the roles.
Process Database (Configuration & Audit)
This database is closely associated with a Process Orchestrator high availability environment (that 
includes one or more servers) and stores process definitions and other configuration information. In this 
environment, the Process Orchestrator Server (Process Engine):
1.
Loads process definitions and other configuration information at startup. Then, as appropriate, it 
starts instances of processes. 
2.
Stores the state of running process instances into the Process Database. This persistence allows 
resiliency across server restarts and supports load balancing and high availability in an multi-server 
environment.
3.
Stores auditing data in the Process Database to record change as users interact with the system, (such 
as to make a configuration change or invoke a process manually). 
Reporting Database (Data Warehouse)
This second database stores data needed for longer-term retention and storage. This can include a copy 
of auditing data that can groom more slowly than the Process database, as well as summary information 
for each process that ran. This data is organized for reporting, with flat relational tables, and can be 
summarized. Automation content can also add data, such as performance measurements, to the reporting 
database.