Blue Prism Architecture and Infrastructure
Core components
A Blue Prism environment is built from several cooperating tiers. Interactive clients are the thick-client desktops used by developers and controllers. Runtime resources are the execution machines that host digital workers (previously called robots). Application servers broker connections and host the logic that talks to the database (SQL Server), which holds processes, objects, releases, queues, schedules, and audit logs. Resource PCs connect to the application server, not directly to the database. Optional components include the hub for credential management, load balancers, and the Blue Prism API / command-line interfaces for automation of the platform itself.
Sizing and topology traps
Questions frequently test the difference between interactive client and runtime resource licensing and behaviour. A common trap is assuming runtime resources can be used for development, or that a single application server removes the need for high availability. Remember that the database is the single source of truth and is the most common bottleneck; scaling the number of runtime resources without considering database throughput is a classic wrong answer.
Connectivity and ports
Runtime resources use the application server connection details; the application server uses the database connection. Firewalls must allow the resource-to-app-server and app-server-to-database paths. A trap is that opening resource-to-database directly is neither required nor recommended.
Rule of thumb
For a 10-process, 20-digital-worker estate, plan at least two application servers behind a load balancer and size the database for concurrent queue transactions, not just for the number of workers.
Worked example
If 30 workers each poll a queue every 5 seconds, that is 6 transactions per second of queue reads before any work is done. If the database cannot sustain that polling rate, increase poll intervals or use work queues configured with appropriate priorities rather than adding more workers.