DocsInter-component communication
This section provides an overview of the key communication channels that are used between the various Blue Prism components.
Standard Blue Prism Enterprise communication
Blue Prism Enterprise with Hub Control Room communication
Communication details
Further information about the typical communication that takes place between the Blue Prism components is detailed in the table below.
|
Communication |
|
Description |
|---|---|---|
|
Application server |
A |
Instructional: schedule robots (TCP) Communicates with the appropriate runtime resource to advise that a specific process is scheduled to be run. Once advised, the runtime resource then establishes a WCF/.NET connection with the application server to retrieve the process configuration and for on-going communication. Instructional: configure and control robots (TCP) Communicates with the appropriate runtime resource to advise that a specific process is to be run. Once advised, the runtime resource then establishes a WCF/.NET connection with the application server to retrieve the process configuration and for on-going communication. |
|
B |
Database communication (typically TCP/IP – optionally leveraging certificate-based encryption) Connects directly to the database for read/write operations as requested by the various Blue Prism components. The connection security is defined by: the connection to SQL Server; the configuration of the SQL Server instance, or through use of external technologies such as IPSec. |
|
|
Runtime resource |
C |
Operating communications (WCF/.NET) Communication such as, process configuration retrieval; submitting system or process logs; saving changes; and requesting a single-use token prior to communicating with a runtime resource; takes place over a secure WCF connection which is established with the application server. Instructional: resource pool communications (TCP) Where implemented, runtime resources communicate with members of the same resource pool for the purpose of distributing process execution tasks. |
| Interactive client |
D |
Operating communications (WCF/.NET) Communication such as: process configuration retrieval; submitting system or process logs; saving changes; and requesting a single-use token prior to communicating with a runtime resource; takes place over a secure WCF connection which is established with the application server. |
|
Blue Prism API |
E |
Operating Communications (Typically TCP/IP – optionally leveraging certificate-based encryption) If the API has been configured to use Windows Authentication for the account that the API will use to communicate with the Blue Prism database, the Blue Prism API application pool in IIS will need to be updated to run as a user with appropriate access to the Blue Prism database. |
|
Hub/Authentication server |
F |
Operating communications (REST/HTTP) To interact with the Blue Prism API directly, at least one service account with permission to the Blue Prism API must be created in Blue Prism Hub to store the client ID and secret that users must provide to Authentication Server in order to authenticate their requests. Should users require different levels of permissions for interactions with the API, separate service accounts should be created and assigned the appropriate level of permissions. Authentication server operating communications (WCF/.NET) To add users from Authentication Server into Blue Prism and to synchronize the user data, the details of the service account created to make authenticated requests to the Authentication Server API must be configured on the Blue Prism application server. |
Default ports
Whilst all ports used by each component are configurable, the default ports are detailed below:
|
Component |
Default port information |
|---|---|
|
Application server |
Listens for TCP traffic on 8199 (configurable). |
|
Application Server Controlled Resources (ASCR) |
The default value for gRPC is 10000 (configurable). For WCF, this value is applied to the outbound function only. The inbound function defaults to port 80, which is opened on the interactive client and is not currently configurable. |
|
Interactive client |
If using .Net Remoting, receives inbound traffic on the callback port number as defined within the connection to the application server. |
|
Runtime resource |
Listens for TCP traffic on 8181 (configurable). If using .Net Remoting, receives inbound traffic on the callback port number as defined within the connection to the application server. |
Where there are multiple application servers co-hosted on a single operating system it is common for each to use an independent, dedicated port. This may be common where there are multiple Blue Prism environments.
Where there are a multiple runtime resources configured on a single runtime resource machine, each will be configured to listen on an independent, dedicated port.
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.
Multi-site single sign-on
If Active Directory forests/domains are hosted on separate physical networks to the Blue Prism application server, it may be necessary to provide domain controller name mapping records to ensure the application server can query the Active Directory domain. For more information, see Troubleshooting – Single sign-on for details.
Name Resolution
The communication that takes place between Blue Prism components requires the ability to resolve the IP address of the target machine using its name. An example of such communication is when the application server instructs a runtime resource to start a process based on the configured schedule, or when a runtime resource communicates with another in the same resource pool.
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
- 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.
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.
