General
Use this tab to define the CRE license distribution and a threshold RoboServer version.
License Distribution
Select the CRE license distribution mode.
Option |
Description |
---|---|
Static |
In this mode, CREs are distributed evenly between online RoboServers in the cluster. A CRE is an integral unit, and you cannot split one CRE among multiple RoboServers. For example, if you have six CREs but five RoboServers in a cluster, each RoboServer gets one CRE; therefore, one CRE remains unused. Note The number of CREs in a cluster must be equal to or bigger than that of
RoboServers. If you assign fewer CREs to a
cluster than the number of
RoboServers
present in the cluster, the cluster is disabled.
To adjust the number of CREs, in the
Action column for the cluster, from the
|
Dynamic |
In this mode, RoboServers receive the licenses from the cluster per request. A RoboServer can get as many licenses as it requests if they are available. In this mode, RoboServers communicate only with the Management Console and block other requests, such as API calls. Important Dynamic license distribution mode is supported by
Kofax RPA
version 10.3 and later. Version 10.7 and later support this mode immediately after installation. To use
dynamic license distribution, in versions 10.3 to 10.6, install the latest fix pack for the corresponding version. See Enable
Dynamic License Distribution Mode in the
Kofax RPA
Upgrade Guide.
|
Threshold RoboServer version
Defines the Kofax RPA version number, after which legacy robots should not be upgraded beyond. Helps perform a smooth upgrade of robots and block robots from running on a RoboServer they have not been tested on.
Robots with the product version below the threshold value are forwarded to the nearest newer version of a RoboServer. All the robots above the threshold value are distributed between RoboServers in accordance with strict version matching. That is, a robot with a product version higher than the threshold value can only be run on the RoboServer of the same product version.
For example, if a threshold value is set to 10.2.0.0, distribution of several random robots between several random RoboServers uploaded to the cluster looks similar to the following pattern:
10.2.0.0 RoboServer | 10.3.0.0 RoboServer | 10.5.0.0 RoboServer | 10.7.0.0 RoboServer | |
9.7.0.0 robot | Matching | - | - | - |
10.1.0.0 robot | Matching | - | - | - |
10.3.0.0 robot | - | Strict version matching | - | - |
10.4.0.0 robot | - | - | - | - |
10.7.0.4 robot | - | - | - | - |
All robots with product versions below the threshold value are successfully matched with a RoboServer of the equal or higher version.
The 10.3.0.0 robot has a strict version matching as its product version is above the threshold value and it has a RoboServer of the same version in the cluster.
The 10.4.0.0 robot has no matching and cannot be run as its product version is above the threshold value and no RoboServer of the same version in the cluster is available.
The 10.7.0.4 robot has no matching and cannot be run as its product version is above the threshold value and no RoboServer of the same version in the cluster is available.
By default, threshold value is set to the current Management Console version.