Components
Each implementation of a Blue Prism environment consists of a Database along with any of the composite components, each of which provides optional functionality based on the requirements of the business
Regardless of the size or criticality of your Blue Prism environment, it is important to ensure that it is properly secured and access to and from the environment is rigorously managed. See the Security section for more details
To understand more about the architecture requirements and recommendations, take a look at our Reference Guides in the Related Documents section below.
The Four Key Components
The Blue Prism Database can only be installed on Microsoft SQL Server. PaaS (Platform as a Service) databases, such as Azure SQL are also a viable option.
The Blue Prism Database is the data store for all Blue Prism configuration data, execution data, encrypted credentials, as well as the repository for logs and audit information.
The schema can be created from a SQL script, or through the Blue Prism GUI on an Application Server \ Interactive Client.
See also - under Related Documents on the bottom of this page:
- Data Sheet - Provisioning a Blue Prism Database Server
- Data Sheet - Maintaining a Blue Prism Database Server
See also - Infrastructure Reference Guide (NDA required. Available on request)
The Application Server has a few basic uses in Blue Prism. Firstly, it manages database connections between the Database and Runtime Resources. Secondly it houses the scheduler component, allowing Processes to be run without user interaction. Thirdly it hosts the encryption key files, which are used to decrypt sensitive information such as Credentials and Work Queue Item details.
In larger Blue Prism environments, it is recommended to have more than one Application Server to handle the larger amounts of traffic. Multiple Application servers should be load balanced, using, for example, F5 or Citrix Netscalar.
It is recommended to install the Application Server on a Server Operating System.
See also - under Related Documents on the bottom of this page:
- Data Sheet - Credential Manager
- Reference Guide - Load Balancing
- Data Sheet - Securing Network Connectivity
- Data Sheet - Secure Windows Authentication
The Runtime Resource, sometimes called a Robot, or Digital Worker, is the component where an automation runs. The Line of Business applications that are being automated need to be installed upon the Runtime Resource machine. The Runtime Resources ideally need to have a specification that exceeds that of their human counterparts’ machine, due to the increased pace at which automations run compared to when a human runs the same process. Virtualization of Runtime Resources is highly recommended to promote ease of management and scalability.
See also - under Related Documents on the bottom of this page:
- v6 Data Sheet - Remote Access Tools
- v6 User Guide - Login Agent
Interactive Clients can come in one of two forms: Development or Control Room. Both use the same installation media, but GUI functionality should be restricted by the internal Blue Prism Logical Access Model (LAM).
The Development Interactive Client is used in a non-Production environment only to build Blue Prism Processes and Objects. It is important to note that the machine that a Process or Object is created upon is as similar, in build and configuration, to the Runtime Resource in Production that the automation will run upon. This will reduce the number of issues caused by inconsistencies.
The Control Room Interactive Client is used in Production environments and is used to Manage and Schedule Processes.
Common Technical Design Mistakes
Although seemingly straight forward, the design and implementation of any Blue Prism infrastructure requires thought, future proofing, and employment of best practice to ensure an ongoing successful and scalable RPA capability.
Many customers make similar mistakes when designing and implementing their infrastructure. The most commonly encountered mistakes, how to avoid them, and how to rectify them are detailed.
Many customers dive straight into their Blue Prism implementation with no proper technical design and\or a Technical Architect that is not familiar with Blue Prism. Having both is essential to producing an initial Blue Prism environment which is secure, scalable, fit for purpose and low maintenance.
When installing Blue Prism, you are given one of two choices for authentication. The first is Blue Prism native authentication whereby authentication to Blue Prism is determined by users which are kept encrypted in the Blue Prism Database. This is most suitable for easily accessible non-production environments. The other option is Single Sign On (SSO) where Blue Prism is integrated with the users Active Directory.
Once chosen, the authentication type cannot be changed without significant effort and risk. It is therefore recommended that the authentication choice is carefully considered before any installation occurs.
Note. As of V7.1 a Blue Prism database is no longer created as either Native or SSO. New Blue Prism databases all start as Native authentication, SSO can then be configured as an option.
The minimum specifications for a Blue Prism database server, as laid out in various guides are often taken as actual specifications by customers. They are, as literally described, minimum specifications. They will allow your Blue Prism environment to function, but not scale, and not perform at the peak of the application's performance. As the Blue Prism database is the most important factor in Blue Prism performance it is recommended to spec the Database server as highly as practically possible.
Customers often initially underestimate their expected use of Blue Prism and co-habit their Blue Prism Database on a shared server, potentially hosting other application’s databases. In order to be easily scalable, it is recommended to start your Blue Prism implementation on a new, dedicated Database server, intended only to be used for Blue Prism.
Using a Public Cloud (E.g. Azure \ AWS \ Google Cloud) is a convenient way to build a scalable and elastic Blue Prism environment. There are also such advantages as PaaS Databases such as Azure SQL which allow you all the flexibility of a Database, without having to manage an actual Virtual Machine.
Note – For more information see the Blue Prism Reference Architecture Guides in the related documents.
By far the most common mistake made by Blue Prism customers is not setting up Session Log maintenance. Session Logs are created every time a Process is run, even including running in Debug mode through the Studio. By default, no Session Log archiving is configured. This can lead to an ever-growing Database which in turn leads to a poor Control Room performance and a very difficult time trying to remove Gigabytes worth of old data. It is therefore imperative that Session Log Archiving is set up from the first day of implementation of a Blue Prism environment. Session Log archiving can be achieved from the GUI using the System -> Archiving. Similarly, the automateC.exe command line tool can be used. Session Logs can be deleted from the database in bulk using the house keeping scripts supplied by Blue Prism Customer Support on request.
Alternatively, in Version 6.5+ Data Gateways can be employed to directly pipe Session Logs to a third-party File, Database, http Endpoint, Application, etc, thus never storing Session Logs in the Database in the first place.
Consider if Session Logs are going to be archived (kept outside the database), rather than deleted, then ample, secure storage will be required to host the Logs.
By default, there is no data housekeeping in Blue Prism. If the amount of data is allowed to continue to grow unchecked, this will lead to performance problems and ultimately a loss of service. Housekeeping scripts which can be used to cull the amount of data for Work Queue Items, Audit Events and Scheduler Logs are available from Global Customer Support on request.
Regular SQL maintenance tasks are essential to maintain the performance levels of a Blue Prism Database. Indexes should be rebuilt frequently, as well as database integrity tasks.
Note – For more information see the Data Sheet “Maintaining a Blue Prism Database”.
Although a community-supported and acceptable solution, the use of non-persistent Runtime Resource VDIs can add many layers of complexity and difficulty to running a successful RPA capability. Persistent VDIs, which use the same image as Development Interactive Clients is the recommended method. This ensures that not only is the machine a Process is developed on is the same as the machine the Process is run upon, but that each time the machine is logged on, the machine has the same specification, settings, applications, GPO's etc, as the previous time.
Do not always automatically assume that the latest version of Blue Prism is going to be right for you. Read the release notes and determine which functionality you require rather than automatically choosing the most recent release. This is specifically applicable when choosing a version to upgrade to.
Blue Prism customer often find themselves being very reliant on a digital workforce sooner than they think in their RPA journey. Therefore, building a Blue Prism environment which is resistant to a hardware outage is a consideration that should be made prior to building.
Design and Build a Blue Prism environment with High Availability and Disaster recovery in mind. Employ the use of Load Balancers, SQL replication, and\or redundancy in Runtime Resources.
Blue Prism V6+ offers several different connection modes which define the protocols that the inter-component communications use. Commonly customers use the default connection mode of “WCF: SOAP with Message encryption and Windows Authentication” due to its ease of setup. The connection mode “WCF: SOAP with Transport encryption” may be a better choice. It requires certificates to implement, which may dissuade some customers, but in reality, is only a small overhead. There are two advantages to Transport Encryption.
Firstly, it adds an extra level of encryption by encrypting the whole network packet, including the headers and trailers. This may be a requirement of your local IT Security Policy.
Secondly, it has been shown to give a performance enhancement over Message Encryption.
Rather than starting with Message Encryption and switching to Transport Encryption for either security or performance reasons, users could save themselves time and the effort of component reconfiguration by starting initially with Transport Encryption.
Each Production Blue Prism environment should also have the accompanying route-to-live environments of
Development and UAT. This is to ensure, for example, that infrastructure changes can be tested, product upgrades can be assessed, housekeeping scripts can be tested, issues with the process design do not impact the live service, etc. It also provides the ability to implement stringent change control methodologies.
Development Interactive Clients should be as similar to Production Runtime Resources as possible to ensure Processes and Objects run seamlessly between the two.
Many customers start with a very small-scale Blue Prism environment, and quickly start to see the benefits. This generally leads to a rapid upscale in the number of licences and Runtime Resources. It is therefore a good idea to start with an over-sized environment or one that can scale easily. This will prevent any issues in constantly having to scale up the existing infrastructure.
Although all aspects of Blue Prism security can be implemented at any time, it is advised to ensure your environment is as security-conscious as possible from the time it is built. See the Security section for more detail.