This article covers upgrading from the last version of Awaken Scripting to the first version of Intelligent Agent, providing specific considerations that need to be examined or resolved as part of the upgrade process. Numerous potentially breaking changes were made in 6.0.53; as such, please pay particular attention to this article when upgrading a 4.6 Awaken Scripting System to 6.0 Intelligent Agent.

 

Important: depending on the exact version that you are upgrading from and user browser settings, users have a chance of being presented with an IIS error screen when first trying to load the website after the upgrade; simply having the user clear their browser's cookies should resolve the issue.

 

Important: it is strongly recommended that all Fields in operational Workflow Versions be updated to the newest versions after the upgrade; most Fields should continue to work normally after the upgrade, but this will ensure they continue to do so in future.

 

 

 

 

Prior to version 6.0.53, versions of Microsoft SQL Server back to 2012 SP2 (11.0) were supported for usage as the Intelligent Agent Database.

 

As of version 6.0.53, the minimum supported version of Microsoft SQL Server is 2016 (13.0).

 

While Awaken Intelligence always aim to provide support to common architectures, these deprecated versions are no longer in the core support stream for Microsoft, and lack functionality that effectively hampers the performance and ease of support of Intelligent Agent on current versions of Microsoft SQL Server. As such, the decision has been made to formally remove support for these older versions.

 

If operating on an affected version of Microsoft SQL Server, please perform an upgrade/migration to a compatible version before performing your Intelligent Agent upgrade.

 

Note: this change does not affect the ability to communicate with databases of these older versions, for example via an External Data Source Field in a Workflow. It only applies to the database server that Intelligent Agent is installed on.

 

 

Prior to version 6.0.53, during installation a database role was automatically created within the Intelligent Agent installation database called CALLSCRIPTER, which was then assigned the minimum required permissions to operate the Intelligent Agent Application. This role was then assigned to the appropriate entity that would be actually operating the Intelligent Agent Application.

 

As of version 6.0.53, this role has now been removed and replaced with one named IA_APP to reflect the current application name and role's purpose.

 

If you had been making use of the CALLSCRIPTER role previously, for instance by assigning additional users or groups against the role, or adding additional permissions to the role, then you will need to reassign any additional assignments that you may have made to the old CALLSCRIPTER role, and may need to update any deployment or monitoring tools.

 

 

Prior to version 6.0.53, versions of Redis back to 3.0 were supported, including the abandoned Redis for Windows project that ran that version.

 

As of version 6.0.53, the minimum supported version of Redis is 6.0.

 

While Awaken Intelligence always aim to provide support to common architectures, these deprecated versions are no longer supported by the Redis project, and lack functionality that effectively hampers the performance and ease of support of Intelligent Agent on current versions of Redis. As such, the decision has been made to formally remove support for these older versions.

 

If operating on an affected version of Redis, please perform an upgrade/migration to a compatible version before performing your Intelligent Agent upgrade.

 

 

Prior to version 6.0.53, using a redundant Redis solution via Sentinel was only partially supported. This could lead to problems in the event of a failover being triggered within the Sentinel group.

 

As of version 6.0.53, the Redis configuration within Intelligent Agent has been expanded with a new option, as well as a change to the existing configuration in Intelligent Agent to connect properly to Sentinel rather than Redis directly.

 

Once the initial upgrade has been performed against the Intelligent Agent System, the Caching Settings should be updated to specify the Sentinel service name (this is commonly mymaster by default), and the endpoint(s) to reference the Sentinel node(s) rather than the Redis node(s) - commonly just a case of changing the port number from 6379 to 26379 if co-locating the Redis and Sentinel nodes and using default settings.

 

When upgrading subsequent Intelligent Agent Instances within the Intelligent Agent System, you may be asked by the installer to provide Redis details; if so, provide the current primary Sentinel node's details and service name.

 

In the event of lingering problems with Redis' operation in Intelligent Agent, flushing the Redis DB and recycling the Intelligent Agent Website application pool(s) is the suggested troubleshooting action.

 

Important: if using a version of Redis lower than 6.2.0, then the Sentinel endpoint(s) will likely need to be specified by IP and port rather than using hostname or Fully Qualified Domain Name (FQDN). This is due to a Sentinel limitation, and will potentially cause problems when changing the Caching Settings unless it is accounted for.

 

 

Prior to version 6.0.53, when installing Intelligent Agent, the IIS Application Pool would be automatically configured to operate as the LocalSystem identity by default. This was required in order to operate the Windows Services that powered various Intelligent Agent functionality, but meant that the entire IIS Application Pool for the Intelligent Agent Application was running at an elevated permissions level that was a security risk.

 

As of version 6.0.53, the IIS Application Pool identity is now installed using the ApplicationPoolIdentity virtual account, providing reduced permissions, and isolation between different IIS Application Pools.

 

After your upgrade, if currently using the default LocalSystem identity it is recommended that the IIS Application Pool be adjusted to use the new default. To do so, edit the Advanced Settings for the IIS Application Pool, and set the Identity to ApplicationPoolIdentity in the "Built-in Account" list.

 

Important: as this new virtual account has minimal permissions, you will need to explicitly assign permissions to any folders or assets that the Intelligent Agent Application will need to access - for example, the folders containing input/outputs for the Mail Merge Control, or Report Schedules. This can be achieved by assigning permissions against the IIS_IUSRS group, or specifically to that IIS Application Pool via the IIS AppPool\<Name of your IIS Application Pool> - for example, IIS AppPool\IntelligentAgent_Production.

 

 

Prior to version 6.0.53, Intelligent Agent made use of Windows Services on the Intelligent Agent webserver(s) to operate various scheduled actions, such as the Message Processing Service. This necessitated that the IIS Application Pool was running as a privileged identity in order to create and manage these Windows Services.

 

As of version 6.0.53, Intelligent Agent now handles these scheduled actions via components within its own IIS Application Pool directly, and the configuration/state of these "services" are now automatically propagated across all connected Intelligent Agent Instances within the Intelligent Agent System.

 

As a result, if you had been accessing local or network resources via these Services, such as accessing attachment files for Email Fields, then you will need to ensure that appropriate permissions to access these resources has been assigned to the configured IIS Application Pool identity. You will also need to restart all required Services, and should ensure that the old Windows Services have been removed; in the Windows Services UI they will be named CSSM_<InstanceName>_<ServiceName>, for example CSSM_Production-01_SocialMediaDataService.

 

Important: previously, a non-standard configuration was possible with Services configured and operated differentially across varied-permission webservers in a single Intelligent Agent System (for example, a pair of webservers with one being inside a DMZ and the other in the core network). This is no-longer supported due to the centralised configuration and operation of the Services.

 

Note: previously, the Services logged to individual and separate files. Now, all of these log entries will be output to the core web.log files by default.

 

 

In version 6.0.53, the Intelligent Agent System has been moved to an MVC architecture, with a resulting change in the URLs used across the application. While every effort has been made to preserve backwards-compatibility to these previous URLs via redirects, it is recommended that the old URLs be updated to their new equivalent wherever they are used.

 

Here follows an (inexhaustive) list of locations that should be checked and updated where possible:

 

The following SQL snippets can be used to locate any outdated homepage or Desktop Tab assignments across Users, Groups, or product-wide respectively:

 

The following SQL snippet can be used to locate any outdated RenderHTML occurrences:

 

 

Prior to version 6.0.53, the Communication Toolbar Provider Service had to be enabled in order to power the agent toolbar functionality of integrations such as PureConnect.

 

As of version 6.0.53, this Service has been removed as defunct, as the required functionality is now handled by the core Intelligent Agent application, and the Communication Toolbar Settings have been simplified.

 

For the majority of clients using an affected integration, the expected resolution is to simply enable the functionality in the Communication Toolbar Settings menu. This is a notable change to the configuration and operation for these integrations, and it should be confirmed that agents are still able to make normal usage of the toolbar functionality after the upgrade.

 

 

Prior to version 6.0.53, when uploading images to Intelligent Agent via either the Image Control or the Stylesheet editor, these were uploaded to the current Intelligent Agent Instance's webserver as a file. This meant that for Intelligent Agent Systems with multiple Instances, it was necessary to manually load the files to each webserver, or place them in a shared location which was manually linked to instead.

 

As of version 6.0.53, when uploading images to Intelligent Agent, they are now stored within the database and are therefore accessible directly to all webservers automatically.

 

While images that have been uploaded using the previous mechanism will continue to be available and usable, it is strongly recommended that all images be re-uploaded using the new mechanism to regularise their access and availability.

 

For images used in Stylesheets, it is recommended that they be re-uploaded manually as the entire Stylesheet section has been redesigned. If the Stylesheets use images that are also used in Image Fields in the Workflows (e.g., logos), then the below process for Fields should be used first, and the Stylesheets can then instead be updated by using the "Browse" option to select a previously-uploaded file.

 

If the number of Image Fields used in Workflows is small, then it is possible to simply re-upload the images manually for each Field; however, if there are many Image Fields then it may be preferable to perform a bulk update. In either case, the first step would typically be to use the following SQL snippet to identify all relevant Image Fields in order to assess the required work:

 

 

If the number of Fields to be updated is substantial, then the process for doing the bulk update is as follows:

 

It is recommended that the original SQL snippet then be re-run to identify whether any Image Fields have been missed. If any images cannot be automatically re-linked for some reason, for example due to a change in file name, then they can be manually re-linked via the "Browse" option in the Field's Image Source wizard instead.

 

 

Prior to version 6.0.53, there was a limited set of functionality available under the umbrella name of Cloud API. This was predominantly used in order to facilitate remote popping of Campaigns for agents.

 

As of version 6.0.53, a redesigned and expanded suite has started being produced under the Cloud API name, and as a result any clients using the previous Cloud API functionality will need to update their solutions.

 

Prior to performing their upgrade to 6.0.53, clients making use of the previous Cloud API functionality should contact their Intelligent Agent vendor to request new credentials as well as the new endpoints. This request will need to specify:

 

These details must be accurate, valid, and complete for the provision of the new Cloud API details. In particular, if the email address isn't valid and able to receive emails then the initial password mails will not be received, and if the System ID and Name details are incorrect then any calls made to the Cloud API will be rejected.

 

Once the request has been received, it will be processed and then a pair of initial credential emails will be sent to the provided email address. At this point, the general guidance from the Integration - Cloud API article should be followed and thoroughly tested to validate that the core functionality is properly configured, and also that your external trigger for the Cloud API pops has been appropriately updated for the new endpoints, credentials, and request/response structures.

 

Important: these details are Intelligent Agent System-specific, so separate credentials would be needed for both a development and production System. It is recommended that the change is first tested on a development System before commencing the production upgrade.

 

 

Prior to version 6.0.53, while the Bootstrap libraries were integrated into the Intelligent Agent websites, the appearance of Fields within Workflows still had a dated, square-edged appearance.

 

As of version 6.0.53, all of the hardcoded Field stylings have been revisited and reworked to provide a more modern and Bootstrap-like appearance to Workflows, and to make use of core Bootstrap classes against Fields where appropriate.

 

As a result of this change, some Field size and positioning changes are to be expected. If you are making use of very rigid Workflow layout or tight margins, then Workflows may need careful review and/or remediation to ensure that they are still acceptable both visually and functionally (e.g., avoiding Field overlap with Floats).

 

 

Prior to version 6.0.53, if any Field that executed a webservice (e.g., an External Data Source) received a response that didn't have an HTTP status code in the 200-299 range, it would present the agent with an error dialog and halt before triggering any Column Mappings or Update Links, as well as not mapping the HTTP Status Code back to the Workflow.

 

As of version 6.0.53, it is now configurable which HTTP status code ranges will be treated as failing and therefore not perform Column Mappings, Update Links, or display the error dialog to the agent. In all cases, the HTTP status code will now be properly mapped back to the Workflow (if configured). The default configuration for non-updated fields should still be to only accept HTTP status codes in the 200-299 range, however prior to updating these Fields they won't display the agent error dialog on non-200 codes any more.

 

All webservice-executing Fields should be updated after upgrading to 6.0.53.

 

In case of any "workaround" processes having been built into Workflows to provide pseudo-error handling, these may need to be removed and replaced with error handling based upon the new functionality that's available. All webservice-executing Fields should be updated to the newest versions available to ensure that the new error handling functionality is available and operational for the desired ranges, and that there's no unexpected change to agent experience.

 

The following SQL snippet can be used to locate any webservice fields:

 

 

Prior to version 6.0.53, the displayed button text for all "Command" Controls (e.g. the Genesys Cloud Command Control) was misassigned to the "Text" attribute.

 

As of version 6.0.53, the displayed button text for all "Command" Controls has been reassigned correctly to the "Button Text" attribute. This means that all of these Fields will have any displayed button text reset to default.

 

It is advised that the displayed button text for these Fields be noted before updating them, and then the required displayed button text be reapplied following this update.

 

The following SQL snippet can be used (prior to updating) to locate any "Command" Controls:

 

 

Prior to version 6.0.53, the Progress Bar Control had been created as a custom HTML solution to provide the observed functionality.

 

As of version 6.0.53, the Progress Bar Control has been redesigned to instead use the core Bootstrap Progress Bar classes and functionality.

 

As a result of this redesign, all Progress Bar Fields must be updated to latest Control version after the upgrade to 6.0.53, or else they will not be visible within the Workflow.

 

To find all Progress Bar Fields within the Intelligent Agent System that haven't been updated to the latest version, the following SQL snippet can be used:

 

 

Prior to version 6.0.53, there was a simplistic and limited Stylesheet editor, which could only set the logo image, background image or colour, and the text and/or background colour of a limited selection of Field elements.

 

As of version 6.0.53, the Stylesheets Section has been entirely redesigned so as to allow the usage of CSS or SCSS code to give rich and deep styling capabilities to the Workflows.

 

As a result, all pre-existing Stylesheets are incompatible with the new methodology, and will need to be recreated within the new Stylesheet editor and then re-applied to the Workflows as required. Notes/examples of sufficient detail should be recorded for all pre-existing Stylesheets to allow them to be recreated after the upgrade.

 

To see whether a Stylesheet has been set as the default, the following SQL snippet can be used before the upgrade to 6.0.53 is performed:

 

To produce a list of the Stylesheets that have been manually assigned, and which Workflows they are assigned to, the following SQL snippet can be used before the upgrade to 6.0.53 is performed:

 

Important: if using manual CSS injection anywhere within Workflows, it is strongly recommended that that content be reviewed (due to a high likelihood of the underlying CSS selector needing to change), and be lifted out into a Stylesheet instead.

 

 

Prior to version 6.0.53, a number of the Script.Email Helper Functions allowed specifying that they would act against a mailbox specified by a named Connector.

 

As of version 6.0.53, these Helper Functions have been extended to include the ability to also specify the type of Connector. This has meant that Workflows using these specific Helper Functions already will need to have their JavaScript updated before the Workflows will work again.

 

The Helper Functions that will need to have the additional parameter included:

 

The following SQL snippet can be used to identify any Fields within your Workflows that contain an affected Helper Function:

 

 

Prior to version 6.0.53, there existed a System Variable named [var_csCallerName] that ostensibly was automatically populated with the caller's forename and surname. However, this functionality never existed, and the variable and description were a remnant of the previous product.

 

As of version 6.0.53, this System Variable has been removed from Intelligent Agent.

 

If you are using this System Variable, for example to manually store the caller's name, then after the upgrade you will need to either re-create the Variable in affected Workflows, or adjust the designed processes to avoid this usage. Failure to do so will result in an error like the following being displayed to agents on affected Pages:

 

The following SQL snippet can be used to identify any Fields within your Workflows that reference the removed System Variable:

 

 

Prior to version 6.0.53, there was a default logger within the logging.config file called CallScripter.UI.Login that reported on WARN-level events such as failed login attempts.

 

As of version 6.0.53, this logger has been reassigned as CallScripter.UI.Controllers.AuthController within Intelligent Agent. This means that unless the logging.config file is updated, visibility may be lost on WARN-level authentication events.

 

It is recommended that the logging.config file be updated to replace the CallScripter.UI.Login logger for the new CallScripter.UI.Controllers.AuthController logger, using our guidance for modifying the logging configuration.