Blue Prism contains a mechanism by which components making up the configuration of Blue Prism can be transferred between different Blue Prism environments
The Release Manager allows bundles of components to be defined as a 'package'. The created package can then be exported into a file as a 'release'.
A package provides a mechanism for collecting a list of elements which should make up a release. It is created within the Release Manager in the Blue Prism client.
A package consists of a name and description, and its contents. The contents of a package can be made up of any or all of the following components:
- Visual business objects
- Web service definitions
- Process groups
- Environment variables
- Work queues
Once a package has been created, you can create a release from it.
Packages can be modified or deleted from within Release Manager.
If a package contains a component which is deleted, the reference to that component is removed from the release
A release represents a package at a particular point in time – in more practical terms, a release is a file with all the contents of a package saved into it.
It is made up of a name, some release notes, and the detailed contents of the packages – where the package contains the list of components, the release contains the components' data.
Create a release
When a release is created, the file is saved to the hard drive, and an entry is saved to the database containing details about the release, such as its name, release notes, user, date/time created and its contents at the time that the release was created. Note that if the package contents change or if components within the package are deleted, the release's contents on the system remain the same.
A release is saved to a file, usually with a .bprelease extension. This can then be imported into another Blue Prism 4.1+ environment. When a release is imported into an environment, an entry is recorded on the database for that release too. This records similar details to the above releases, except that instead of the creating user and date/time created, the details will include the importing user and date/time imported.
Import a release
A release can be imported from within Release Manager, or by choosing Import from the File menu within the Blue Prism client.
The different components use different rules to determine how they should react to conflicts in the target system – most components require some form of user input to indicate the action that should be taken if such a conflict should occur.
The rules defining how each supported component is handled are given below:
- If the target environment does not contain a process/VBO with the same ID or name as the incoming process, it is imported without any further user intervention.
- If the target environment contains a process/VBO with
the same ID as the incoming process, the user is prompted
- Overwrite the existing process (Default)or,
- Save the process with a new ID.
- If the target environment contains a process/VBO with
the same name as the incoming process, the user is prompted
- Rename the incoming process (Default) or,
- Overwrite the existing process/VBO or,
- Rename the existing process.
Visual business objects (VBOs)
- VBOs are handled identically to processes.
Web service definitions
- If the target environment does not contain a web service with the same name as the incoming service, it is imported without any further user intervention.
- If the target environment contains a web service with
the same name as the incoming service, the user is prompted
to do one of the following:
- Overwrite the existing web service (Default)
- Choose a new name for the incoming web service
- Choose a new name for the existing web service
- Incoming process groups are merged with existing process groups with the same name in the target environment. If the incoming group contains processes being imported which are not part of the existing group, they are added once the incoming processes have been imported.
- If no environment variable exists in the target system with the same name, the variable and its value in the source environment at the time of creating the release are set in the target environment.
- If an environment variable is found in the target environment with the same name, it is updated with the incoming description and datatype. If the existing value cannot be converted to the incoming data type, the incoming value is set in the target environment, otherwise the current value is retained.
- If no credential exists in the target environment with the same name, the user is prompted for a username and password to set in the credential, and it is created.
If a credential already exists in the target environment with the same name, the incoming credential is merged with it, such that the incoming description is set in the existing credential, and any incoming processes associated with the credential are associated on the target system.
The existing username and password are not affected by importing an identically named credential.
- Regardless of the existence or otherwise of the credential, the user has the option of not importing the credential as part of the import process.
The default encryption scheme must be in place on the target environment before any credentials can be imported, otherwise an error will occur and the import operation will fail.
- If no work queue with the same name exists in the target environment, one is created with the incoming details.
- If a work queue with the same name exists in the target environment, its details (key field and max attempts) are overwritten by the incoming queue. Any items in the queue will be unaffected by these changes.
- If no schedule exists with the same name as the imported schedule, it is created, with no scheduled sessions, in the target environment.
- If a schedule with the same name exists within the
target environment, its description, timing data and task
structure is overwritten with the incoming schedule
definition. Note that:
- Note that if there exist any tasks with the same name as those being imported with the schedule, their descriptions and their "On Success" and "On Exception" settings are overwritten, but the list of scheduled sessions will be retained.
- Also note that if the existing schedule is 'retired' it will not be rejuvenated by importing a schedule over the top of it, although its data will change – it will have to be 'unretired' manually if required.
Although calendars can't be explicitly added to a package, if a schedule requires a calendar to function, it is included along with the schedule in any generated release.
- If no calendar with the same name exists within the target environment, it is created there
- If a calendar with the same name exists within the target environment, it is overwritten with the incoming calendar data.
- If no font with the same name exists on the target system, it is created with the incoming details.
- If a font with the same name exists, it is overwritten with the incoming font.
There exists a mechanism with which a release can be verified against the environment from which it came – this checks to see if there have been any changes in the environment since the release was created.
Before the release manager, Blue Prism supported the import and export of single processes or visual business objects. Files created from these earlier versions of Blue Prism can still be imported using the same mechanism as importing a release – just change the file filter in the File Open dialog to look for *.xml files rather than *.bprelease files.
If you need to export a process / visual business object with a view to importing it in an older version of Blue Prism, you can still do so by opening the process / object in Process Studio / Object Studio and choosing File > Export > This Process or File > Export > This Page to export the process or the page as before.
This video shows you have to clone, export, and import Blue Prism processes.