En

Deployment of the Platform Managed by the Orchestrator#

Deployment Diagram of the Sherpa RPA platform managed by the Orchestrator shows the interaction options of the Orchestrator with other components of the Sherpa RPA platform:

  • RDP server with Unattended user accounts – Sherpa Coordinator Service + Sherpa Unattended Robot
  • Developer workstation (Windows) — Sherpa Designer + Sherpa Robot
  • Client workstation (Windows) – Attended Robot
  • Workstation with a browser.

Process Sequence#

The following sequence describes how a workflow moves from development to execution by an Attended or Unattended Robot.

  1. The developer creates a workflow in Sherpa Designer and debugs it with a local Sherpa Robot. The completed workflow is transferred to a User or Robot workstation by copying the configuration file, or published from Sherpa Designer to Sherpa Orchestrator.

  2. The server component Sherpa Orchestrator maintains communication with robots running on client machines, stores robot configurations and script versions, shared global variables and credentials, logs and screenshots of robot operations, audit logs of the orchestrator, Users, Roles, and Accounts of the Orchestrator itself, licenses for all platform components, and script execution statistics.

  3. Users and administrators open the Sherpa Orchestrator web interface in a browser to manage resources, configure the system, and view statistics. The server installation includes Nginx, PHP, and a relational database: MariaDB by default, or PostgreSQL.

  4. Local users launch the Sherpa Attended Robot to execute locally stored scripts as needed. During script execution, the Sherpa Attended Robot can send the Orchestrator the current status, tasks, logs, values of global variables and credentials, or receive tasks, values of global variables, and credentials from it.

  5. When started by a schedule, API call, Robot command, or another supported condition, Sherpa Orchestrator sends a task to Sherpa Coordinator Service on the terminal server. The service creates an RDP connection to the local or remote Unattended Robot account. Several such accounts can run concurrently on one terminal server.

    Access to the Unattended robot account is made with the login and password provided by the Orchestrator.

    After logging in, the corresponding instance of Sherpa Unattended Robot starts, connects to the Orchestrator, receives the task to execute the script, and the script itself stored in the orchestrator.

    During script execution, the Sherpa Unattended Robot can send the orchestrator the current status, tasks, logs, values of global variables and credentials, or receive tasks, values of global variables, and credentials, commands for "soft" or "hard" termination of the script.

    After completing the script execution, the Sherpa Unattended Robot logs off from its account.

Attended Robots run local workflows autonomously. Sherpa Orchestrator provides centralized management of multiple Robots and their interaction.

Connecting to an External Database#

This section describes connecting the application to a database prepared by an administrator. For a highly available database, the administrator defines the topology, replication, load balancing, and server failover procedure. The number of virtual machines and IP addresses depends on the chosen solution and is agreed during deployment design.

In the Sherpa Orchestrator 5.9.4 Docker distribution, connection parameters are set in /opt/SherpaOrchestrator/.env. The database administrator must prepare an accessible connection endpoint, a database, and credentials in advance. When changing the endpoint of an existing installation, the target database must contain that installation's data.

The following steps are required to configure the connection:

  1. Set the parameters for the selected database system in .env:

    Database system Database selection Connection endpoint Connection parameters
    MariaDB DB_ENGINE=mysql MYSQL_HOST — database server or load balancer address MYSQL_PORT, MYSQL_USER, MYSQL_PASSWORD, MYSQL_DB
    PostgreSQL DB_ENGINE=pgsql POSTGRES_HOST — database server or cluster endpoint POSTGRES_PORT, POSTGRES_USER, POSTGRES_PASSWORD, POSTGRES_DBNAME, POSTGRES_SCHEMA_NAME

    The endpoint must be reachable from the orchestrator container. Preserve the existing archive database parameters when configuring the primary database connection.

  2. From /opt/SherpaOrchestrator, recreate the application container to apply the environment variables. The application will be unavailable while the container is being recreated:

    docker compose up -d --no-deps --force-recreate orchestrator

  3. Check that the application starts without database connection errors:

    docker compose logs --tail=100 orchestrator

    After startup, the Orchestrator web interface should open. If the connection fails, check the endpoint, port, database accessibility from the container, and account permissions.

The orchestrator container receives parameters through env_file: .env. In the standard docker-compose.client.yml, it has no depends_on dependency on the database. Setting the database endpoint does not require adding DB_HOST, commenting out such a dependency, or manually editing backend/config/config.ini and backend/config/phinx.php.