IADA to Director migration

SS&C | Blue Prism® Director is an upgrade from IADA. This guidance explains how the migration from IADA to Director will affect your existing orchestration configuration and includes details of the main differences between the products. The SS&C | Blue Prism® Cloud team will facilitate every aspect of your IADA to Director migration.

The IADA process templates have been redesigned to cater for the new Director functionality. These process templates are available to download from the Blue Prism Digital Exchange (DX), if required.

Following migration, updates to existing processes shouldn’t be necessary, unless you need to exclude or include features and make supplementary updates to the processes. For more information, see the Blue Prism Director user guide.

Differences between IADA and Director

The main differences between IADA and Director are described below:

  • With Director, orchestration for each digital worker can be controlled at process and/or work queue level. This means that all digital workers no longer need to be capable of running every process and don’t need to be identical.
  • Director uses a Restful API instead of a SOAP web service to add items to work queues and advise the next best item for processing. Restful APIs are more flexible, have better security, and increased performance.
  • The Advise Next Best Item action in Director returns the item ID, which makes it easier to identify the next item for processing. This is a much more efficient method of locating the item data.
  • Whereas IADA relies on tags to indicate priority and SLA, Director has separate values for SLA and priority while adding items to the queue.
  • Unlike IADA, Director provides the option to include or exclude work queues and/or processes while advising the next best item.
  • The Add to Queue action in IADA is replaced by the Blue Prism Director Business Object, which calls the Director Web API.
  • The Hub Control Room Work Queues page provides users with a summary of all the work queues that are currently running or paused for your connected Blue Prism Enterprise environments. Additional columns support Director users with performance metrics and SLA reporting.

Migration scripts

As part of the IADA to Director migration, a number of scripts are run on your Blue Prism Cloud platform to:

  • Identify and then export the IADA process names that need to be converted to Director.
  • Add the Director license.
  • Import the Director customer package into Blue Prism Enterprise.
  • Create the credentials required to access Director from Blue Prism Enterprise.
  • Create the Blue Prism Director Web Service in Blue Prism Enterprise.
  • Migrate references from IADA to Director.
  • Convert work queue items from IADA to Director. This is done by extracting the priority, SLA, and process name from the IADA tag and populating the corresponding columns created to store these fields in BPAWorkQueueItem table.
  • Create a service account called DirectorSvc, to be used by Blue Prism Enterprise to send requests to Director.

Validating the migration

Following the migration from IADA to Director, you can carry out the following validation to ensure the migration has been successful, and familiarize yourself with the changes:

  • Validate that the AddToQueue and AdviseNextBestItem actions are taking into account SLA, priority, processes, and work queues.
  • Confirm that the BPAWorkQueueItem database table now includes the following additional columns:
    • sla
    • sladatetime
    • processname
    • issuggested
  • Ensure that the Add to Queue action in IADA has been replaced by the Blue Prism Director Business Object.
  • Check that the Director Web API service is available in Studio.
  • If applicable, check that you can add work queue items from Interact, by adding SLA and priority to the Interact form.

Migration rollback

In the unlikely event of any unforeseen issues with the migration, a backup of your IADA environment will be made prior to running the migration scripts. This means that any changes can be rolled-back and the issues addressed before re-attempting the migration.