Blue Prism Technical Architect cheat sheet

Blue Prism separates the interactive client, the runtime resource (bot), the application server, and the database; sessions are brokered by the connection layer, not by peer-to-peer calls.

Supported relational back ends are Microsoft SQL Server (primary) and Oracle; the database holds process definitions, work queues, logs, and credentials, so it is the single source of truth.

A runtime resource executes published processes only; it cannot edit process logic, which enforces separation between build and run environments.

Application Server runs as a Windows service and exposes a WCF-based endpoint; clients and resources connect to it by host name and port, so firewall rules must allow that port from both tiers.

Blue Prism Hub and Interact are separate web applications with their own IIS and database prerequisites; they are not installed by the core Blue Prism installer.

Each runtime resource needs a Windows interactive session because UI automation requires a desktop; running as a service without an interactive session breaks most surface automations.

Licensing is enforced per runtime resource plus per interactive client; a resource without an available licence cannot be started even if a session is connected.

High availability is achieved at the database and application server tiers; a single runtime resource is not clustered, so resilience comes from multiple resources and retry logic.

ROM is structured around foundational components: vision and strategy, organisation, processes, technology, people, and governance; each component has defined roles and artefacts.

Core roles include the Process Analyst, Solution Designer, Developer, Test Analyst, and Controller; the Controller owns queue health and incident triage at run time.

The Centre of Excellence owns standards, reusable assets, and change control; business units own process selection and benefit realisation.

Process selection uses a pipeline scoring model weighing volume, standardisation, exception rate, data quality, and regulatory exposure before build begins.

A change advisory gate applies to any process already in production; changes are raised as a controlled release, never edited directly on a production resource.

Benefit tracking compares pre-automation effort baselines against post-automation handling time and exception rework, reviewed at a fixed cadence.

Segregation of duties requires that the person who builds a process is not the sole approver of its production release.

A Process Design Instruction (PDI) is produced before build and captures process steps, inputs, outputs, systems touched, exception paths, and volume profile.

Decompose work into a driver process that owns queue items and one or more business object actions; keep the driver thin and put reusable logic in objects.

Design for restartability: every queue item must be independently processable, and partial completion must be recorded before the next irreversible step.

Prefer a queue-driven, producer-consumer pattern over long linear processes; producers create items, consumers process them with controlled concurrency.

Identify the process's natural transaction boundary; the queue item is usually that boundary, and its status transitions define the recovery model.

Data flow should be explicit: define what is read, transformed, written, and logged, so that rework after an exception is bounded.

Non-functional requirements (throughput, peak concurrency, latency, availability window) must be agreed in design, because they drive infrastructure sizing.

Naming conventions: processes and objects use a consistent prefix or business-domain naming, and every stage carries a description of its purpose.

No hard-coded values in stages; environment-specific values belong in Environment Variables, and business constants belong in a controlled data store.

Every loop must have an explicit termination condition and a page-level recovery path; unbounded loops are a defect.

Use the Block stage with a recover/resume pair for any group of stages that must be retried as a unit, and rethrow after the last attempt.

Exception handling follows a layered pattern: local recover for expected errors, page-level recover for retryable faults, and process-level escalation to the queue.

Keep pages small and single-purpose; deep nesting and very long pages raise defect rates and slow review.

Use the standard stages for their intended purpose: Calculation for expressions, Decision for branching, Multi-Calc for batch assignment, Collection Manipulation for data shaping.

Every process should expose clear start-up inputs and a defined end state, so it can be invoked by a scheduler or by another process.

Business objects expose actions; the calling process never touches UI directly, so interface changes are contained inside the object.

Separate the object into pages by concern: launch, attach, read, write, close, and utility pages for parsing.

Object actions should be idempotent where possible; a repeated write must not duplicate a record, so check-before-write patterns are standard.

Use the object's internal work queue or input/output parameters for data exchange; avoid passing large collections through many nested calls.

Attach and detach logic must handle the case where the target application is already running, already logged in, or has crashed.

Read actions return a collection or a defined output parameter; never rely on screen state being visible to the caller.

Clean up in a finally-style path: close windows the object opened, release application handles, and reset the object's internal state.

Application modeller entries define launch parameters, attach mode (by process name, window title, or handle), and the element tree used by the object.

Prefer API or database integration over UI automation when the target system exposes a stable interface; UI is the last resort, not the default.

Match on stable element attributes (automation ID, name, class) rather than screen coordinates or ordinal position, which break on layout change.

Spy modes differ by technology: Win32 for classic Windows controls, UIA for modern frameworks, browser modes for HTML, and region or image modes as fallbacks.

For web targets, keep the browser version and driver aligned with the supported matrix; mismatches are a common source of intermittent attach failures.

Terminate the modelled application cleanly after use; orphaned processes accumulate and degrade the resource over long unattended runs.

Use wait stages with timeouts for asynchronous screens instead of fixed sleeps, which inflate cycle time and still fail under load.

Work queues are the primary data structure: each item has a key, a priority, tags, data, status, and attempt count, and status transitions are auditable.

Item statuses progress through New, In Progress, Exceptioned, and Completed; deferred items return to the queue after a defined interval.

Queue retention settings control how long completed and exceptioned items remain; set them to satisfy audit needs without unbounded growth.

Encrypt sensitive fields at the queue level; data at rest in the database is otherwise readable to anyone with database access.

Collections are in-memory and are lost on session termination; persist anything that must survive a restart to a queue or an external store.

Bulk data operations should be batched; per-row database calls across thousands of items dominate cycle time.

Data quality checks belong at the producer stage, so bad items are rejected before they consume consumer capacity.

Credentials are stored in the Blue Prism credential store, never in process logic, text files, or environment variables in plain text.

A credential has a name, a username, and a password; processes reference it by name and retrieve the password only at the point of use.

Access rights are role-based: users and roles are granted permissions per folder or process, and least privilege applies to both designers and controllers.

Audit logging records logins, changes to process definitions, and credential access; the log is the evidence trail for regulatory review.

Service accounts used by runtime resources should be dedicated, non-interactive where possible, and excluded from broad domain admin groups.

Rotate credentials on a defined schedule and after any staff change; rotation must not require editing process logic.

Network traffic between tiers should be encrypted, and database access restricted to the application server and authorised administrators.

Classify exceptions: business exceptions (data invalid, stop and mark item) versus system exceptions (transient fault, retry then escalate).

Retry with a bounded attempt count and a backoff interval; unlimited retries hide defects and saturate the queue.

Wrap each queue item in a recover block so that one failure does not terminate the whole session; mark the item exceptioned with the reason.

Preserve the exception detail and the current stage name in the item's data, so triage does not require re-running the process.

Use the process's clean-up path to close applications and release resources even when the item fails.

A crashed resource leaves items In Progress; a recovery routine must detect stale in-progress items and return them to the queue.

Alerting thresholds (consecutive failures, queue age, exception rate) trigger controller intervention before service levels are breached.

Promote releases through development, test, and production environments; never build directly in production.

A release is a packaged set of processes, objects, and dependent resources exported from one environment and imported into the next.

Environment variables hold the per-environment differences (URLs, credentials references, file paths), so the same process logic moves unchanged.

Version processes and record the version in a release note; a rollback plan must identify the prior known-good package.

Change control requires approval, a test evidence record, and a deployment window agreed with the business.

Compare the source and target environment before import to catch missing dependencies such as objects, credentials, or environment variables.

Post-deployment verification runs a smoke test against the live systems before the scheduler is enabled at full volume.

Throughput per resource = available run seconds / average handling time per item; total capacity = throughput per resource multiplied by the number of licensed resources.

Measure handling time on a representative sample under realistic data volumes; pilot timings on small batches understate contention.

Concurrency is bounded by the target application's tolerance, licence terms, and database contention, not only by the number of bots.

Queue priority and tags let high-value work pre-empt bulk work without building separate processes.

Identify the bottleneck tier (UI interaction, database, API rate limit, network) before adding resources; adding bots to a saturated back end reduces throughput.

Account for non-processing time: login, application start-up, scheduled maintenance windows, and retry overhead all reduce effective capacity.

Plan headroom for peak volume and for rework of exceptioned items, typically a margin above the average daily workload.