Operations and Insight
The elements below should be considered as important for any Blue Prism implementation.
Remote Access Tools
In order to underpin a secure physical or virtual infrastructure, Blue Prism recommends the use of remote access technology to configure, control and monitor Blue Prism solution components. The data sheets at the bottom of this page (and in our Documents section) provide guidance on the types of remote access tools that are suitable as well as the features and considerations that should be applied when selecting a technology.
Session Logs Archive
Blue Prism can log all stages of the process and its objects to the central session log, providing a transparent and detailed audit trail of all process activity. A data policy should be created to define the policies regarding data held in Blue Prism work queues and logs. Depending on the level of detail selected, the session logs can begin to consume a large amount of disk space. A sensible archive strategy will allow the production database size to be kept to a minimum whilst still allowing retrieval of log files, should business units require them. This mitigates the critical failure due to lack of disk space.
An archive policy should be created and documented. It will need to be reviewed periodically, as more and more processes are automated.
If archiving data, ensure the archive location is as secure as the database. The content of session logs can be configured at a Process level, but may contain potentially sensitive data. Similarly, Work Queue Items, Schedule logs and Audit Information in the Database should also be house kept. Information in these tables will remain indefinitely unless a maintenance plan is put in place to control the amount of data. Pre-made SQL scripts to do these actions are available from Blue Prism Global Customer Support on request.
Backup
A clear backup policy for automated processes should exist. This includes processes in production and development. This allows normal operation to resume in the event of any data losses on the database server. A centralized, nightly backup of the database server is recommended. In addition to a Full backup, Differential Backups should be taken hourly and Transaction log backups should be made regularly (every 15 minutes is the recommend cadence). Any backups taken should be stored securely and/or in line with any Industry Compliance.
Other organizations may wish to implement a secondary layer of backup for further assurance, using the Blue Prism software product's export facility to backup Processes and Objects. The backup policy should be documented and regularly reviewed as part of the Robotic Operating Model creation.
Monitoring
The below details the methods and techniques that can be used to monitor a Blue Prism implementation. It covers both alerting and reporting of process exceptions as well as the monitoring of the components of the Blue Prism infrastructure such as Interactive Clients, Application Server(s), Runtime Resources and SQL Databases.
A Blue Prism infrastructure will comprise a number of different components each of which can be monitored and polled to verify that it is available and responsive. When monitoring the Blue Prism components, standard third-party tools and techniques can be used to evaluate the following:
-
Health of allocated hardware (e.g. disk space, CPU utilization, network connectivity)
-
Availability of specific windows services (e.g. service started, responding on the appropriate port)
-
Windows Event Viewer entries.
SQL Server is of paramount importance in the Blue Prism architecture and any performance or availability issues with this component are likely to be the source of a number of other issues that may be experienced across the other Blue Prism components. As well as the health of the allocated hardware, it is recommended that the SQL Server Instance(s) that host Blue Prism databases should be monitored for functionality and responsiveness
- Hardware health:
- Standard health-checks (e.g. available disk space, CPU utilization, network connectivity).
- SQL specific health-checks (e.g. that applied SQL limits are not being reached (database size, log file size)). This should be applied to all Blue Prism databases as well as the default databases for the instance(s) such as tempdb.
- Availability of specific windows services: There are a number of standard SQL services that should be verified as being started including those responsible for providing backup and maintenance functionality.
- Windows event viewer: The event viewer of the SQL Server should be reviewed for any errors or warnings which may affect the availability or performance of the SQL Server.
Where a Blue Prism Application Server is implemented, the health of the allocated hardware should be monitored as should the Blue Prism specific windows services.
- Hardware health: Standard health-checks (e.g. disk space, CPU utilization, network connectivity)
- Availability of specific windows services: Verify that the Blue Prism Server windows service is started. A worthwhile test is to ensure that the Application Server is able to receive TCP connections on the configured port (by default the port is 8199).
- Windows event viewer: Events are written to a custom windows event log called Blue Prism. The event source can be compared to the name that the Blue Prism Server service is given when it is installed (by default “Server Service – Default”). Typically any event item that is of type "Error" is worth further investigation.
The Runtime Resources are responsible for executing the Blue Prism processes and therefore both the health of the allocated hardware as well as their ability to receive and return communications should be monitored.
- Hardware health: Standard health-checks (e.g. disk space, CPU utilization, network connectivity)
- Availability of specific windows services: There are no Blue Prism specific services to monitor in relation to this component, however a worthwhile test is to ensure that the Runtime Resources are able to receive TCP connections on the configured listening port (by default - 8181).
- Windows event viewer: For Blue Prism versions v4.1 and later, events are written to a custom windows event log called Blue Prism.Typically any event item that is of type Error is worth further investigation.
Alerting
In addition to the functionality provided within Control Room for controlling and monitoring the runtime resources, additional notifications about Processes and Schedules can be provided through use of Alerts.
Process alerts can be used to notify specified users when certain actions occur for selected processes within the Blue Prism environment and are configured on a per user basis.
This can help to provide process level monitoring which may be useful for identifying wider problems which affect the smooth running of Blue Prism.
Users can select which processes they would like to monitor, what actions they are interested in being told about, and also the method by which they would like to be notified. Additionally, if there is a desire to monitor additional actions, manual alert notifications can be designed into any Blue Prism process.
As with Process Alerts, Schedule Alerts are used to notify specified users when certain actions occur for selected schedules within the Blue Prism environment, and are configured on a per user basis.
Users can select which schedules they would like to monitor and they can select the method by which they would like to be notified. Additionally they can choose whether notifications are required at the schedule, or more detailed schedule task level.
Where additional or specific alerts are required, it is possible to design custom alert notifications into any process. Such custom alert notifications can be very sophisticated (e.g. waiting for the same error to occur a number of times) and can take a wide number of actions (e.g. sending an email, raising an SNMP trap). These custom alerts can provide a great deal of flexibility and elegance to process level monitoring.