Blue Prism Infrastructure Reference Guide
Blue Prism Infrastructure Reference Guide
REFERENCE GUIDE
Major Version: 6
Document Revision 1.0
The information contained in this document is the proprietary and confidential information of Blue Prism Limited and should no t be
disclosed to a third party without the written consent of an authorised Blue Prism representative. No part of this document may be
reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying without the written
permission of Blue Prism Limited.
All trademarks are hereby acknowledged and are used to the benefit of their respective owners.
Blue Prism is not responsible for the content of external websites referenced by this document.
Blue Prism Limited, Centrix House, Crow Lane East, Newton-le-Willows, WA12 9UY, United Kingdom
Registered in England: Reg. No. 4260035. Tel: +44 870 879 3000. Web: www.blueprism.com
It is recommended that, to start, readers should become familiar with the various components that feature within
a Blue Prism environment and identify the architecture most suited to the deployment being considered. The
relevant guides can then be used to provide supplementary information and design considerations for the chosen
deployment model.
1.3. Information
Summary information about the Blue Prism components and examples architectures are provided, followed by a
series of guides; each dedicated to the specific features, functionality and consideration of each:
This section provides a series of examples which illustrate some of the configurations that could be applicable
dependant on a number of factors such as the size and business criticality of the proposed system.
Information about the minimum specifications of each Blue Prism component can be found within the respective
guides such as the B lue Prism Database Server Guide.
The Blue Prism Network Connectivity Guide provides an overview of the typical communication that occurs
between each of the Blue Prism components.
In each of the following examples the specifications for the B lue Prism Runtime Resources and B lue Prism
Interactive Clients remain static:
The specification of Interactive Clients used for development and the Runtime Resources must meet the
collective recommendations of the in-scope target applications. (E.g. SAP, Office, Kana etc.)
A useful indicator is to base the specification on an equivalent device used by an end-user to automate
those same applications.
Interactive Client
1 per developer / controller
Advantages C onstraints
Very quick to implement / provision No separate development or test environment - production
Re-uses existing desktops resources must be sacrificed for development and test activities
Requires minimal investment There must be commonality across desktop builds
Low level of dependency on IT SQL Server Express database may be used, but performance and
capacity may be limiting
Physical security of components must be considered
Advantages C onstraints
Fast to implement / provision Requires commonality across desktop builds
Some re-use of existing desktops Physical security of components must be considered
Database is secured and managed by IT Application server may receive a lower level of IT
Process development and test can be delivered support than required (treated like a workstation vs
without constraining production (separate server)
development and test environments and dedicated
runtime resources)
Separate Application Servers for Dev/Test versus
Production allows product releases to be applied
separately.
Advantages C onstraints
Quick to scale – as already virtualized There may not be an IT support model in place for
Database performance and capacity easily scaled virtualized desktop devices
Process development and test can be delivered Speed to implement / provision
without constraining production (separate Cost of virtualization technology
development and test environments and dedicated
runtime resources)
Virtualization aids commonality across components
Separate Application Servers for Dev/Test versus
Production allows product releases to be applied
separately.
Two sets of 50 virtualized Runtime Resources, each with a dedicated Application Server.
Virtualized Interactive Clients which are used remotely.
A DR site with up to 100 Runtime Resources and a single Application Server connected to a replicated copy
of the database.
Advantages C onstraints
Highly resilient and scalable – full capability on standby There may not be an IT support model in place
suitable for business critical processing for virtualized desktop devices
No geographic constraints across development, test or Speed to implement / provision
production Cost of virtualization technology
Consistency across developers and environments that Development / Test environments to be
reduces support overhead provisioned separately.
Five sets of 100 virtualized Runtime Resources, each with a dedicated Application Server.
Virtualized Interactive Clients which are used remotely.
Advantages C onstraints
Quick to scale – as already virtualized There may not be an IT support model in place for virtualized
Database performance and capacity easily scaled desktop devices
Virtualization aids commonality Speed to implement / provision
Basic level of contingency in case of Application Cost of virtualization technology
Server failure Development / Test environments to be provisioned
separately.
It is also common for the components in each environment to be configured to interact with appropriate instances
of the applications. For example, the Runtime Resources in the development and test environment would ideally
be configured to interact with non-production instances of the line of business applications.
Any cases being worked at the time of failure will be reported as exceptions and must be either reset or
referred for manual attention. Commonly these are reviewed as part of the business as usual management
that is carried out by the Controllers who oversee the platform.
Each Blue Prism Server must be configured with identical encryption schemes.
Runtime Resources are resolved by their network name, which is typically the machine ID. The machines
on Site B will have different IDs to those in Site A, so alternative DR schedules may be required to start the
processes on these alternative VMs. Resource Pools may be used to aid this process.
The database must be replicated accurately and frequently in order to maintain the state of the cases
being worked in the Blue Prism queues.
Latency considerations must be reviewed if routing Application Server or Database traffic across sites.
3.7.3.1. Active/Passive
In addition to the general considerations, the following considerations may also be relevant
When Site B is activated, the network names of devices must either match those in Site A or the Interactive
Clients and schedules must resolve the names to the new network address – this is outside the scope of
Blue Prism
It may be necessary to configure alternative schedules that use the identifiers of the DR Runtime Resources
in the event of failover.
3.7.3.2. Active/Active
In addition to the general considerations, the following considerations may also be relevant
The choice of virtualization technology and the method in which it is deployed will determine the maximum
number of virtual images that can be provisioned on a given host. Guidance should be sought from the technology
provider in relation to specific advice or limitations, particularly where high availability (HA) is being implemented
as part of the virtualization solution.
The specifications below assume that the following hardware requirements is appropriate for the Blue Prism
Runtime Resources:
This specification must be reviewed to ensure that it is
Example: Blue Prism Runtime Resource appropriate to meet the collective recommendations of
the in-scope target applications (E.g. SAP, Office, Kana
Single Processor
etc.) and the Operating System used.
2 GB RAM
35 GB Hard Disk Drive A useful indicator is to base the specification on an
Windows desktop Operating System equivalent PC used by an end-user to automate those
same applications.
Further information on the minimum requirements for this component can be found within the B lue Prism Runtime
Resource Guide.
The specification of Interactive Clients used for development must meet the collective recommendations of the
in-scope target applications. (E.g. SAP, Office, Kana etc.)
A useful indicator is to base the specification on an equivalent PC used by an end-user to automate those same
applications.
1
All minimum requirements must consider the selected operating system as well as the applications to be automated.
* Examples of standard operational software includes: anti-virus; device monitoring or remote access tools; Microsoft Office;
email clients.
4.4. Networking
The main components that Interactive Clients initiate communications with include:
Runtime Resources
For the purposes of monitoring, controlling and manually triggering processes on a given Runtime
Resource (TCP).
Application Server
The Application Server is used for all database connectivity.
Third Party Applications
See the B lue Prism Runtime Resource Guide for network considerations where the Interactive Client is used
for developing and configuring processes.
Sample diagrams and default port settings are provided within the B lue Prism Network Connectivity Guide.
The B lue Prism Virtualization Guide provides advice for provisioning a server to host virtual Runtime Resources.
The specification of Interactive Clients used for development must meet the collective recommendations of the
in-scope target applications. (E.g. SAP, Office, Kana etc.)
A useful indicator is to base the specification on an equivalent PC used by an end-user to automate those same
applications.
2
All minimum requirements must consider the selected operating system as well as the applications to be automated.
* Examples of standard operational software includes: anti-virus; device monitoring or remote access tools; Microsoft Office;
email clients.
Application Server
The Application Server is used for all database connectivity.
Third-Party Applications
The type of connectivity required between the Runtime Resources and third party applications will depend
on the nature of the automation. The majority of Blue Prism automation takes place via the GUI and
therefore the runtime resources simply need the same level of access as a typical end-user of the given
application. Where deeper connections (e.g. direct database, web service, message queues) are required
the appropriate ports and access will need to be configured.
Sample diagrams and default port settings are provided within the B lue Prism Network Connectivity Guide.
The type of account used to log the respective Runtime Resource onto the network should be carefully considered
as this could restrict the type of applications that can be automated by each of the Runtime Resources. It should
be noted however, that for applications which are not secured using Active Directory integrated authentication,
the Runtime Resources can be configured to use credentials independent of those used to authenticate the device
onto the network.
Native Authentication
If using native authentication the Blue Prism Runtime Resource will not be able to authenticate with the
applications that use Active Directory integrated authentication (single sign-on).
D omain Account
If an Active Directory domain account is used to log on to each Blue Prism Runtime Resource there are
increased options for connecting to applications which are secured using either native or Active Directory
integrated authentication (single sign-on).
Additionally the Blue Prism Runtime Resource can used the configured domain account to authenticate
against Blue Prism environments that are configured to use single sign-on.
The access and permissions assigned to the accounts used by the Runtime Resources should be evaluated to see if:
The accounts are configured to allow access to the necessary applications and network resources that may
be required by the processes (including network locations etc.).
The accounts need to be members of appropriate Active Directory groups.
The accounts are restricted from performing certain types of action on the local machine that may be
required as part of an automated process. (e.g. logging to the event viewer; using the command prompt
etc.)
5.5.2. Login methodology
Blue Prism Runtime Resources must be logged in and listening, to be able to receive instructions and execute
processes. It is therefore necessary to consider the options for how the login will take place each day and following
system restarts.
No authentication
Removing the need for these components to follow an authentication procedure allows each device to
launch the operating system without the need for any manual or automated login interaction.
If the applications to be automated use Active Directory integrated authentication this option may not be
appropriate.
Automatic authentication
Configuring the devices to log in automatically using locally stored credentials allows the respective device
to launch the operating system without the need for any manual intervention; however the security of the
credentials would need to be considered.
If the applications to be automated use Active Directory integrated authentication, the automatic login
would need to log the resource on to the network using an appropriate domain account. Consideration
should also be given to whether the password(s) should be set to expire.
Manual authentication
Named users could be responsible for manually restarting the devices and entering the relevant
credentials. Consideration should be given to: the availability of users to carry out the task; the impact this
would have on the speed of restarting a machine; the security of the credentials; the impact if it is required
out of hours; the suitability of remote connectivity tools for this task.
Automated authentication using the Blue Prism Login Agent (recommended)
Each Runtime Resource which has been appropriately configured 3 and where Blue Prism Login Agent has
been installed, can be automatically logged in by Blue Prism.
Blue Prism Login Agent is used to securely store the credentials for each Runtime Resource and use these
to automatically log in, or unlock the device. It additionally provides functionality for managing the
passwords and can adhere to password history and complexity rules. This option may be the most suitable
where the Runtime Resources authenticate directly against a secure Active Directory domain and where
the processes include automating applications which are secured using Active Directory authentication
(single sign-on).
Further information on Blue Prism Login Agent is available within the following collateral:
o Blue Prism Data Sheet - Secure Windows Authentication
o Blue Prism User Guide - Login Agent
3 The pre-requisites for Login Agent must be considered to ensure its suitability in a given environment.
It is recommended that where possible, consistent settings should be applied across all of the Blue Prism Runtime
Resources to ensure commonality and therefore reduce the complexity of process development.
Where processes are scheduled to automatically start early in the morning, the Runtime Resources should be
allowed to remain in an idle state overnight. Some processes may involve inherent periods of idleness whilst the
applications remain on screen. This too should not result in a lock-out.
Display themes should be set to not use transparent or opaque window borders.
It may also be necessary to remove or reduce compression, as this can affect the way that the graphical interface is
presented to the end user, which in turn can have a negative impact on the interpretation of the screens by the
Runtime Resources.
E.g.
“C:\Program Files\Blue Prism Limited\Blue Prism Automate\automate.exe” /resourcepc
/public
It is strongly recommended to additionally configure the Runtime Resources to authenticate against the
Blue Prism platform by specifying valid Blue Prism credentials.
For information about configuring multiple Runtime Resources on a single Runtime Resource see the Running
multiple Runtime Resources section.
It is essential that physical access to these components is restricted to prevent unauthorised users from directly
monitoring the actions being taken, and getting access to the data that is being processed. Additionally this helps
to prevent users from being able to interrupt the process and take control of the data and applications that the
Runtime Resources have authenticated against.
For security reasons, granting access to the Runtime Resources once established is not recommended – the ability
to restart, shut-down and start up the instances should be sufficient.
Where remote access is granted to the Runtime Resources, such access should be subject to appropriate control
and monitoring. Further information is available within the User Accounts, Remote Access and Security Guide.
Each process that runs simultaneously on a single Runtime Resource must be able to successfully identify
the application(s) that were launched for its use. (E.g. if there are 5 processes each using Internet Explorer,
each process must be able to successfully identify which is the appropriate one to use).
Conflicts can occur if a thick client application is used as part of processes that run simultaneously,
particularly where only one instance of the application can be launched at a given time (e.g. Microsoft
Outlook).
Where multiple instances of a single application are used simultaneously, it is necessary that actions taken
in one instance, do not affect the others. (i.e. logging out in one instance should not automatically log the
user out of all instances).
It may not be possible to use this approach where the processes use thin client technologies.
Where the Runtime Resource connect to an Application Server, the connection must be configured to use
dynamic ports for callback to avoid conflicts. If the callback port is statically defined, it will not be possible
to operate multiple Runtime Resources on a single Runtime Resource unless a separate connection is
configured for each.
To configure a single Runtime Resource to have multiple Runtime Resources it is necessary to modify the
start up configuration to initialise multiple instances of Blue Prism, each with its own listening port.
The v6 User Guide – Installing Enterprise Edition provides instructions on how setup this configuration.
It is also necessary for the amount of space required by the Event Log to regularly reviewed and for appropriate
maintenance to take place.
Further details on monitoring are contained within the v6 Data Sheet - Monitoring.
The key features that are provided by the Blue Prism Application Server include:
Marshalling all connectivity between the Blue Prism components and the database.
Provision of the Secure Credential Store.
Data encryption and decryption capabilities.
Scheduled process execution.
Using Windows Authentication for the database connection which negates the requirement to store the
username and password within a Blue Prism configuration file.
Storing the encryption keys within individual files and manually applying additional controls such as use of
transparent encryption and restricting access to the files.
It is important to note that where access is granted to this component, a given user will have access to this
potentially sensitive configuration information for each environment - it is therefore important that this
component is suitably secured and subject to restrictions in terms of physical and remote access.
4
All minimum requirements must consider the selected operating system as well as the applications to be automated.
* Examples of standard operational software includes: anti-virus; server performance monitoring tools; remote access
technology
Runtime Resources
For the purposes of triggering scheduled processes on a given Runtime Resource (TCP).
D atabase
Connectivity with the database server uses SQL Server drivers and is therefore configurable. By default
connectivity occurs using TCP.
Due to the high levels of communication between the Application Server and Database it is necessary for
Application Servers and the respective Databases to be physically located locally to minimise latency
between the components.
6.5. Application Server configuration
The v6 User Guide – Installing Enterprise Edition provides instructions on how to configure an installation of Blue
Prism to take on the role of a Blue Prism Application Server.
The common configurations for provisioning multiple Blue Prism Application Servers include:
Where multiple Blue Prism servers are deployed for the same environment each one must be configured to
use the same time zone.
The configuration of the encryption schemes on each server must be identical to allow all servers to
perform consistent encryption and decryption of sensitive data.
6.7. High availability and redundancy
See the High Availability and Redundancy Guide within this document for information.
The solution permits any number of instances of the Blue Prism schema to be deployed within a given SQL instance
on Microsoft SQL Server, allowing multiple Blue Prism environments to be configured within a single Microsoft SQL
instance.
Support is also provided for Microsoft SQL Azure. Refer to the Blue Prism Reference Architecture for Microsoft
Azure for further details.
Key Features:
Central repository for all Blue Prism configuration information such as processes, objects and workflow
configuration.
Third-party system user credentials store.
Work queue repository.
Stores audit information and production process log data – a transaction log of each process running in the
environment.
7.2.1. Sizing
The requirements of the database server directly correlate to the number of deployed Blue Prism Runtime
Resources.
5
Data File size should be reviewed during implementation according to logging requirements, running hours and data
retention policy as this will vary if data is retained for prolonged periods.
Product Driven
The software will create and maintain the database during installation and upgrades. CREATE and ALTER
TABLE privileges are required by the Blue Prism Server.
Script Driven
SQL scripts for database creation and updates can be provided by the product support team.
Datareader
Datawriter
[All roles prefixed with bpa_] E.g.
o bpa_ExecuteSP_DataSource_bpSystem
o bpa_ExecuteSP_DataSource_custom
o bpa_ExecuteSP_System
The roles prefixed “bpa_” are only available once the database has been configured using the in-product Create
Database functions or manually using the CreateScript.
The minimum SQL permissions do not provide appropriate privileges to carry out Create, Configure or
Upgrade database actions, therefore an appropriate administrator account will need to be used when any
of these actions are required:
Consideration should be given to the proximity of the Database Server to the Blue Prism Application Server and
Runtime Resources, particularly when implemented across large or multi-site networks. Where network latency is
an issue, it will be made more prominent by the frequency of the queries performed.
Commonly the Blue Prism database will receive direct connections only from each Blue Prism Application Server
within a given environment.
In some circumstances, such as where Application Servers are not deployed, any Blue Prism component can be
configured to establish a direct database connection. This will be subject to the application of appropriate routing,
authorization and access settings.
The number of connections that will be established by each directly connecting device is managed by the .NET
Framework through use of SQL connection pools.
Further information on the key tables within the Blue Prism database is provided within the Appendix.
Sessions are used by Blue Prism to record all of the appropriate stages followed by a runtime resource as part of
executing a business process. The amount of logging for each stage is configured as part of the process design but
typically each log generated will include:
In order to maintain integrity, the generation of sessions and associated session logs occurs
synchronously as part of process initiation and execution. Whilst the amount of data per
transaction is low, the frequency and requirement for rapid processing by the database is
paramount.
Each work item attempt is represented by an individual record in the BPAWorkQueueItem table, therefore if a
work item is worked, terminated and a retry action generated, it will be represented by two rows in the table.
Work items can be assigned tags which provide supplementary information such as categorisation and these are
defined in the BPATag table and each assignment of a tag to a work item attempt is represented by a record in the
BPAWorkQueueItemTag table.
The BPAWorkQueueLog is used to record each operation which alters a work item (e.g. additions, status change,
deletions).
Login / Logout
Changes to environment-wide settings
Create/Update/Delete of: business objects; processes; queues
When recording changes to processes and objects all details of the changes being applied are capture d to allow for
comparison or rollback at a later date.
The audit log table (BPAAuditEvents) can grow to be quite large where there is a high frequency of
updates to processes or objects. This typically does not affect production databases as the largest
number of changes take place in development or test environments.
7.8.5. Alerts
Alerts can be configured to indicate to end-users when certain events are detected within sessions or schedules.
An alert is targeted to a particular user and has a delivery method (e.g. pop-up box, system sound etc.). Each
individual alert is stored in a record on the BPAAlertEvent table.
The user accounts used by the runtime resources to authenticate against the network or workgroup.
The user accounts the Runtime Resources will use to access and automate the line of business applications.
The user accounts used by Blue Prism controllers, and developers to configure, develop, release, deploy
processes and the associated queues, schedules and settings.
Security should also be considered in reference to:
Access (including remote access) to the various Blue Prism components (e.g. Application Server, Runtime
Resources, Interactive Clients, Database Server etc.)
The logical access permissions granted to each user in relation to the actions available to them within a
given Blue Prism environment.
8.2. User Accounts: Runtime Resource network authentication
Considerations for the user accounts to be used when Runtime Resources are authenticated to the domain or
workgroup include:
The credentials for the user accounts used as part of a Blue Prism process are securely stored, independently of the
process definition, within a centralised Credential Management repository.
Access to specific credentials is restricted to specific Runtime Resources, processes and users in order to prevent
authorised use within the environment.
Blue Prism processes can be configured to periodically change the line of business application password(s), taking
account of necessary password complexity requirements, which ensures that the credentials are not known by any
human operator.
Alternatively Blue Prism can be integrated with Active Directory Domain Services for controlling and configuring
user access and control. See the Active Directory Integration Guide for more information.
Microsoft Remote Desktop Connection (RDP) is explicitly specified as being unsuita ble for remote
control of a Runtime resource, as the remoting connections are intrusive – meaning that the RDP
session would interrupt ongoing automated processing.
Considerations for selecting a suitable remote access tool are detailed within the v6 Data Sheet – Remote Access
Tools.
Examples of roles that are often reviewed as part of this definition are included below:
Further guidance on establishing appropriate logical access permissions is provided as part of the Blue Prism
implementation methodology.
Enforces existing security policies for the Runtime Resources (e.g. password reset and complexity
requirements).
Allows Active Directory Group Policy Objects (GPO) to be used to enforce user specific settings.
Simplifies access to network resources such as shared drives, mailboxes, printers etc.
9.2. Active Directory allows natively secured internal Blue Prism communications
When the Blue Prism components are deployed within an Active Directory Network Infrastructure configured with
appropriate domain trusts, communication message security is enabled by default for the necessary inter -
component communication.
Further information on securing connections by enabling message security is provided within the Securing Network
Connectivity Data Sheet.
9.3. Configuring the Blue Prism Platform to authenticate user access via Single Sign-on
Where Blue Prism is deployed within a single Active Directory Forest, it can be configured to allow users to
authenticate against the platform using Single Sign-on. It essentially requires an Active Directory Security Group to
be mapped to each relevant Blue Prism security role after which users will be granted access to the platform based
on their Active Directory Security Group membership.
Valid scenarios for deploying Blue Prism with Single Sign-on include
1. Where all user accounts and all Blue Prism components reside within a single Active Directory Forest with
appropriate trusts between all relevant domains.
2. Where all user accounts and all Application Servers and Interactive clients reside within a single Active
Directory Forest with appropriate trusts between all relevant domains, and where Blue Prism Runtime
Resources reside outside the domain and network. These Blue Prism Runtime Resources will not be able to
carry out authentication tasks e.g. they cannot be used to host Blue Prism Web Services, and they Blue
Prism Interactive Client on these devices cannot be used.
Active Directory Integration for user authentication must be configured as part of the database
creation therefore it is important to establish whether this is required prior to installing and
configuring Blue Prism.
Built-in Groups or Groups with derived membership such as Domain Users and Authenticated Users
should not be used. It is recommended specific Security Groups are created and these should be
mapped to Blue Prism Security Roles. Likewise if using nested group membership, the nested
groups should not be built-in groups.
Additionally Active Directory Security Groups that contain Foreign Security Principals or members
with unresolved SIDs can present querying difficulties and therefore such configurations are not
recommended.
3. Associate each Blue Prism Role with the respective Active Directory security group.
Within Blue Prism each Blue Prism Role should be linked with the appropriate Activity Directory Security
Group. It should be noted that it is possible for there to be a different number of security roles based on
the environment (E.g. a Production Environment will not normally have a Developer role configured as
development should not take plcae directly within production).
Further information on Active Directory configuration is provided in the v6 User Guide – Installing Enterprise
Edition.
B
E
A B A
A
C
Further informaton about the typical communication that takes place between the Blue Prism components is
detailed in the table below.
Where there are a multiple Runtime Resources configured on a single Runtime Resource, each will be configured to
listen on an independent, dedicated port.
10.2.2. Latency
Consideration should be given to the connectivity between the Blue Prism components, as any network latency will
be made more prominent by the frequency of the queries performed.
Latency must be minimal between the following components:
Application Server(s) and the respective Database Servers
Interactive Clients and Application Server(s)
The only communication channels that are designed to support high-latency connections are those to/from the
Blue Prism Runtime Resources, however consideration to this should be applied when designing the process
automations to ensure appropriate performance. E.g. in terms of the frequency of communication with the other
components such as requesting or writing items from the database, writing logs, updating queue items, auto-save
settings etc.
By default, the communication takes place using the short-name of the target machine (e.g. using robot001, not
robot001.mydomain.local) and requires DNS to be configured appropriately.
System Administrators can optionally change this setting if appropriate for the deployment:
Register and communicate using machine (short) name – default
Register using machine (short) name, communicate using FQDN 7
Register and communicate using FQDN
Register: The name format used when registering Runtime Resources is the one which is featured when managing
and configuring the platform (e.g. within session logs, schedules and control room etc.).
Changing the name format used for registering components will require each to register as new devices within the
environment meaning that any previous Runtime Resource configuration may need to be repeated (e.g.
configuring Resource Groups and Resource Pools, assigning access to credentials, schedule configuration etc.).
Connect: The name format used when connecting to the devices and is therefore the name that must be resolvable
to an IP address from each of the devices were connections can be initialized.
10.2.4. IP Layer Security
In addition to the controls natively provided by the platform, additional network protection can be achieved
through use of industry-standard technologies such as IPSec which is able to protect all application traffic over an
IP network.
7 Resource Management. Following the reset, the affected Runtime Resources and all Controllers should be restarted.
By default these communications are unsecured and contain a very high level instruction and do not include
sensitive or exploitable information.
The controls implemented for this communication include:
Origin authentication: A single-use token is passed which the receiver validates with the Blue Prism
Application Server. This allows the receiver to validate the originator had the authority to issue the
message.
Session authentication: A single-use token is passed which the receiver validates with the Blue Prism
Application Server. This allows the receiver to validate the originator had authenticated with the Blue
Prism Application Server prior to generating the message.
The single-use token referenced above is generated by the Blue Prism Application Server and verified by the
recipient via the operational communications channel.
Whilst these instructional communications are unsecured by default, for advanced implementations applicable
Runtime Resources can be configured to apply encryption by leveraging a local certificate. When appropriately
configured, certificate-based encryption is applied to all communication received by the device on a given port
irrespective of the origin. Blue Prism web services accessed on configured devices will require a HTTPS prefix.
The certificate common name(s) will need to accurately reflect the paths used for all communications to
the Runtime Resource on a given port.
The devices connecting to the Runtime Resource(s) will need to trust the issuer (Certificate Authority).
The start-up parameters for the Runtime Resource will need to be configured to leverage the certificate.
Examples include scenarios such as where the Application Server receives a request from:
a Runtime Resource requesting a process definition after being instructed to start processing.
a Runtime Resource writing a log to the database (via the Application Server).
A Runtime Resource requesting a credential for use when executing a process.
an Interactive Client updating a process definition.
an Interactive Client updating an execution schedule.
Each Runtime Resource (and Interactive Client) will communicate over a WCF connection with a nominated
Application Server via the server’s listening port (default: 8199).
The Key Distribution Center (KDC) for the communications is located on an Active Directory domain controller and
uses Active Directory as its account database and, where required, the Global Catalog for directing referrals to
KDCs in other domains.
.NET Remoting includes a number of controls when the Blue Prism platform is deployed into an Active Directory
network infrastructure 8 :
C ontent confidentiality: .NET NegotiateStream is used to natively provide both key derivation and data
encryption/decryption. SPNEGO is used to select the underlying security protocol, and the security context
via negotiation between the client and server through use a set of security tokens generated by the
SPNEGO GSS-API mechanism.
D ata Integrity: .NET NegotiateStream is used to natively provide data encryption and signing using the
negotiated security mechanism. The signature used as part of the VerifyMessage functionality to validate
the integrity of the content.
Origin authentication: Active Directory, as the KDC, performs the role of a trusted third-party and is
responsible for providing confidence that the message has genuinely originated from the identified
principal in addition to the verification that is applied by interrogating the message signature.
Message replay protection: Reply protection is natively achieved through use of a ticket containing a
session key and an encrypted session key identifier which is cached along with the timestamp of the
original request.
Non-repudiation: .NET NegotiateStream Protocols use of Active Directory as the KDC and trusted third-
party provides confidence that the message is genuine and cannot be repudiated as it contains information
(a session key) encrypted with the senders master key which the recipient must contact the trusted third-
party to be able to verify.
Session authentication: .NET NegotiateStream Protocol relies on the SPNEGO security protocol which
selects between Kerberos (preferred) and NTLM. Authentication is performed as part of the negotiation to
select the security protocol through the exchange of opaque security tokens generated by the SPNEGO
GSS-API mechanism.
8
Data encryption is only available for .NET Remoting when Blue Prism is deployed within an Active Directory network
infrastructure.
Operational controls: How the platform is configured operationally to execute work can impact the
behaviour when it responds to a failover or recovers from an outage. This can relate to a number of areas
such as process design, demand management, frequency of schedules, management of process exceptions
etc.
Availability of target systems: The availability of the business systems which are accessed by the automated
processes will impact the ability of the platform to operate successfully.
Underlying Architecture: The hardware and core services on which Blue Prism relies must be configured to
be appropriately resilient.
This section provides information relating to providing resilience at the architecture level.
D atabase server: a core component of the platform and, as it is the realtime repository for audit and
operational logs, the platform is configured to cease processing whenever the database cannot be
contacted.
High availability and/or redundancy is achieved through use of native SQL Server technologies (e.g.
clustering, mirroring, AlwaysOn Availlabity Groups) or by third-party redundancy and replication
technologies.
Application server: used to marshall all connections with the database and to provide critical functiona lity
as processes execute. All operating Interactive Clients and Runtime Resources require a connection to an
available Application Server. As the execution within the platform is stateful, a persistent connection is
required. Likewise if the connection between a Runtime Resource and Application Server is interupted, the
Runtime Resource will periodically attempt to reconnect.
Redundancy is achieved by provisioning additional Application Servers; and High availability is achieved
through use of routing or load balancing such that traffic is directed to an available component.
Due to the stateful nature of execution within the platform, items being actively worked at the time of
failover or re-direction will fail and be routed for human intervention.
Additional platform components include:
Runtime Resource: responsible for executing the processes, each runtime resource is commonly located on
a separate virtual device.
Redundancy is achieved by provisioning additional Runtime Resources; and High availability can be
achieved through use of Active Queues or Blue Prism Resource Pools. Both of these features represent
groups of Runtime Resources and provide funtionality to scheduled or manually allocated to be allocated
to an available Runtime Resource.
Interactive Client: the client software accessed by users either to develop and test processes; or to control
and monitor the platform.
Redundancy is achieved by provisioning additonal devices and directing users to an available component as
they establish a connection.
The simplest approach for load balancing is to use DNS round-robin with a low Time to Live (TTL) setting. Where
organizations have existing technologies it can be possible to complement this approach by introducing an
application aware utility that is able to validate the health of the Application Server(s) and to manage the DNS
records accordingly. Commonly such functionality can be provided with the DNS platform, by software load
balancers, or within monitoring platforms such as Tivoli or Microsoft Operations Management. Further information
on this topic is available within the Data Sheet – Load Balancing Guide.
Alternative solutions such as Microsoft Server Clustering, third party replication and routing solutions or other
software/hardware load balancers may be used to provide this functionality.
Health of allocated hardware (e.g. disk space, CPU utilisation, network connectivity).
Availability of specific windows services (e.g. service started, responding on the appropriate port).
Windows Event Viewer – should be actively reviewed for any errors raised on all devices which are part of a
Blue Prism environment.
Additionally Blue Prism provides a number of features and techniques that can be used to assist with monitoring
process execution and any associated errors.
Process and Schedule Alerts can notify administrators or controllers, directly on their own desktop, using a range of
indicators including:
Pop-ups
Sounds
Taskbar Icons
Additionally custom notification types can be implemented such as sending an email
or raising an SNMP trap.
General Documentation
Product Overview High level overview of Robotic Process Automation and the Blue Prism Platform.
Release Notes Version specific release notes detailing key features and functionality included in
the release.