Remote Upgrade will only work from Orchestra R5.3 to later versions. You should always upgrade to the next version, e.g. 5.3.0 to 5.3.1.
The reason for this is that there needs to be a controller software (Daemon), in place within the Queue Agent in the Branch Hub or on the PC running the Queue Agent. This Daemon is included in Orchestra R5.3, and later, making it possible to manage Remote Update.
For specific instructions about the Daemon, please see the Release Notes document!
Introduction
Remote Update of Queue Agents means the possibility to update the Software running on a distributed Queue Agent without physical contact with the actual Branch Hub or PC running the Queue Agent software, but to be able to do it from the Central Orchestra installation.
Queue Agent and Queue Agent Profile Handling
For more information about how Queue Agents are handled, how Queue Agent Profiles are created, which files are mandatory and optional, and so on, please refer to “Queue Agents” .
Synchronizing of Queue Agent
Before the upgrade from one version to a later can be made, the new Profile version must be downloaded to the machine on which the distributed Queue Agent is located, e.g. a BranchHub or a PC server. This is called synchronizing.
Different distributed Queue Agents may have different functionality and settings, e.g. different Terminals, different applications and different databases etc.
Queue Agent Profiles are created to define what software files and which parameters that shall be applied for one or more Queue Agents.
An Agent Profile consists of configuration parameters (stored in database) and a zipped file containing the (web-) applications and required configuration files, such as language files and scripts. The Agent Profile zip file typically contains the Workstation Terminal, the Reception Terminal, and other applications that should be upgraded.
Create a new Agent Profile when a new Queue Agent version is released or when you are about to perform other changes on a Queue Agent. By creating a new Agent Profile, a Queue Agent could easily be reverted in case of any failure during deployment.
It is only recommended to change/update an existing Agent Profile if e.g. a change of a parameter is needed, or a language property file should be added or changed.
Agent Profile Synchronization
The performance bottleneck when it comes to remote upgrade of distributed Queue Agents can be the synchronization of the Agent Profiles. It is highly depending on the network bandwidth between the Central Orchestra installation and the Queue Agents. Once the synchronization is done, the upgrade is taken care of by each Branch Hub or the distributed Queue Agent PC. This is triggered by a command in Central.
Synchronization can take very long if the bandwidth is low. The upgrade can however not be started until that step is done and the upgrade itself will not take long but should be done outside business hours, so that it will not disturb your daily routines too much.
Queue Agent Pre Deployment Script
A typical use case for the pre deployment script is to reset the database.
Queue Agent Post Deployment Script
A typical use case for the post deployment script is to include some tests to ensure that the Queue Agent is working properly. In case of failure, a roll back of the Agent Profile will be done.
Orchestra Distributed Queue Agent Upgrade
If the distributed Queue Agent version is lower than Orchestra 5.3, the Queue Agent must be reinstalled (the upgrade function of the Queue Agent comes when 5.3 has been installed). Follow the instructions in chapter “Distributed Queue Agent” .
Do not have files in the Queue Agent installation directory open during upgrade!
If you have changed Orchestra Central to run on another port than 8080, it is no longer possible to synchronize a new Agent Profile to the distributed Queue Agents. Therefore, you must first upgrade the distributed Queue Agents, using Remote Upgrade, with the new port, before the central number is changed.
Regression Test
What is covered by the Regression Test naturally largely depends on what your system looks like, how many Branches you have, which hardware you are using and so on.
However, we suggest that you perform tests on the Branch that you have deployed as the first Branch and that you test scenarios that relate to the normal scenarios of your business, such as calling customers, printing tickets, making sure that correct surfaces are displayed on printers, media displays and so on.
Performance Test
As with the Regression Test, this depends a lot on the size and load of your system.
We suggest that you run some kind of load tests, using tools and load scripts especially developed for this kind of task.