Update from 10.1.1 to 10.1.2

The guide describes how to perform upgrade from 10.1.1 to 10.1.2 version of WorkFusion Intelligent Automation Cloud.

Prerequisites

You have WorkFusion Intelligent Automation Cloud 10.1.1 up and running.
All business processes in Control Tower are stopped.
All workers in Marathon are destroyed.

To destroy workers, go to the Marathon UI, on the top right side, click More " ... ", and choose Destroy item -> Destroy Group.

Download and extract patch

To download and extract the patch, connect to the INT server via SSH and run the following commands as <linux_installation_user>:

Change directory to PACKAGE_DIR (where the installer was extracted during initial installation of 10.1.1, for example: INSTALL_DIR/wf_installer). Ensure that PACKAGE_DIR is writable for <linux_installation_user>:
```
$ cd PACKAGE_DIR
$ sudo chown -R <linux_installation_user> ./
```
Create the patches directory and download the patch:
```
$ mkdir patches
$ cd patches/
$ curl -o 'patch_10.1.1-10.1.2.tar.gz' '<patch download url>'
```
If the Internet access is not available on the Integration server, download the patch to PACKAGE_DIR/patches/ directory with any available method.

Extract the patch:

$ tar xzf patch_10.1.1-10.1.2.tar.gz

After the extraction, in the PACKAGE_DIR/patches/, you will find the patch_10.1.2.sh script and the patch_10.1.2 directory. Example:

$ ls -la
drwxr-xr-x. 12 ec2-user ec2-user       4096 Sep 27 17:20 .
drwxr-xr-x. 29 wfuser   wfuser         4096 Sep 27 15:27 ..
drwxrwxr-x.  6 ec2-user ec2-user        134 Sep 27 17:17 patch_10.1.2
-rwxrwxr-x.  1 ec2-user ec2-user       1246 Sep 27 16:00 patch_10.1.2.sh

In config.yml, ensure that value of parameter workfusion_mtls_client_port is set to 7081.

To edit config.yml, use the following command:
```
$ cd PACKAGE_DIR
$ ./install.sh edit_config int
# you'll be prompted for decryption password
```
Also, ensure that Nexus and MS SQL users passwords are valid.

In most cases you don't need to change passwords in config.yml. If you encounter issues (for example, error message with invalid credentials), edit config.yml, update it with valid passwords, and rerun the patch. The patch is idempotent, so it is safe to rerun.

For example, after the initial installation of 10.1.1, Nexus or MSSQL passwords may be changed manually in the environment for some purpose. In this case, you need to actualize them in config.yml, because the patch will use them during the execution for updating DB schemas and Nexus artifacts.
```
nexus_admin_pass

mssql_dba_pass
mssql_ct_pass
mssql_ws_pass
mssql_sqc_pass
mssql_rpa_pass
mssql_pm_pass
mssql_dm_pass
mssql_ocr_pass
mssql_automl_mms_pass
```

note

If you patch the system in the Multi-point (Legacy) way, repeat these steps for all servers.

Apply patch

Apply the patch, depending on your installation approach:

For single-point setup

Prepare the environment variables. On the INT server, run the following commands as <linux_installation_user>:

$ export ANSIBLE_PRIVATE_KEY_FILE="</path_to_ssh_key>"   # Path to SSH key for connection to all Linux servers as <linux_installation_user>
$ export ANSIBLE_REMOTE_USER="<linux_installation_user>" # <linux_installation_user> provided in config.yml

Run the below commands one by one to apply the patch.

$ cd patches/
$ ./patch_10.1.2.sh apply int        # update INT server to 10.1.2 state
$ ./patch_10.1.2.sh apply bep-master # update BEP Master server to 10.1.2 state
$ ./patch_10.1.2.sh apply bep-agent  # update BEP Agent server(s) to 10.1.2 state
$ ./patch_10.1.2.sh apply app        # update APP server to 10.1.2 state
$ ./patch_10.1.2.sh apply ocr        # update OCR server to 10.1.2 state
$ ./patch_10.1.2.sh apply rpa        # update RPA server to 10.1.2 state

Cleanup cached resources such as RabbitMQ queues, or workers data:
1. On the INT server (or in case of the HA setup, on the first INT server), stop all services that are running on all servers. For that, go to PACKAGE_DIR and run the following commands as <linux_installation_user>:
```
$ cd PACKAGE_DIR
$ ./install.sh stop_services full -e skip_bi=true    # Stop all services on all servers before cleanup of RabbitMQ queues
```
2. On the INT server (or in case of the HA setup, on all INT servers), start RabbitMQ as runtime user <wfuser>:
```
$ wfmanager start rabbitmq
```
3. On the INT server (or in case of the HA setup, on the first INT server), cleanup Rabbit queues as runtime user <wfuser>:
```
$ rabbitmqctl list_queues --vhost bep | awk '{ print $1 }' | xargs -L1 rabbitmqctl delete_queue --vhost bep
```
4. On the BEP Master server (or in case of the HA setup, on the first BEP Master server), cleanup worker data as runtime user <wfuser>:
```
$ rm -rf /opt/workfusion/vds-data/workers/app/*
```
On each Linux server, stop the supervisord service as runtime user <wfuser>:
```
$ wfmanager shutdown
```
Run the following steps as a user with the root permissions:
1. For each Linux server, set kernel ulimits parameters and ensure that the following strings are present in the /etc/security/limits.conf file with correct values:
```
1. domain: "*", type: "-", item: "nofile", value: "number of vCPU * 25000"
2. domain: "*", type: "-", item: "nproc", value: "number of vCPU * 1280"

Example for 4-vCPU server:

*   -   nofile  100000
*   -   nproc   5120
```
2. For each Linux server, set supervisord process ulimits parameters and ensure that the following strings are present in the /etc/systemd/system/supervisord.service file with correct values:
```
1. LimitNOFILE="number of vCPU * 25000"
2. LimitNPROC="number of vCPU * 1280"

Example for 4-vCPU server:

LimitNOFILE=100000
LimitNPROC=5120
```
3. On each Linux server, ensure that no running services are owned by the runtime user <wfuser>:
```
$ sudo ps aux | grep wfuser
```
4. On each Linux server, reload the systemctl configuration and start supervisord:
```
$ sudo systemctl daemon-reload
$ sudo systemctl start supervisord
```
5. Log out from all sessions on servers for changes to take effect.

On the INT server (or in case of the HA setup, on the first INT server), switch to <linux_installation_user>, and start all services:

$ exit   # switching back to <linux_installation_user>
$ cd PACKAGE_DIR
$ ./install.sh start_services full -e skip_bi=true    # Start all services on all servers

Update worker's jar file on RPA server(s): copy file /opt/workfusion/tmp/workers/com/workfusion/spa/ct/worker-app/10.1.0.2.1/worker-app-10.1.0.2.1.jar from the INT server to the <rpa_install_dir>\worker directory on RPA server(s) with any available method.
Restart RPA server(s) with any available method.

Patching is completed. It may require about five minutes for Control Tower to start. If you see error 503 in browser right after the patching, wait a bit.

For legacy setup (multi-point)

To apply the patch on the Linux servers:

Run the following commands on each Linux server in the following order: INT → BEP Master → BEP Agent(s) → APP → OCR.

$ cd PACKAGE_DIR/patches/
$ ./patch_10.1.2.sh apply int        # Run on INT server to update it to 10.1.2 state
$ ./patch_10.1.2.sh apply bep-master # Run on BEP Master server to update it to 10.1.2 state
$ ./patch_10.1.2.sh apply bep-agent  # Run on BEP Agent server(s) update them to 10.1.2 state
$ ./patch_10.1.2.sh apply app        # Run on APP server to update it to 10.1.2 state
$ ./patch_10.1.2.sh apply ocr        # Run on OCR server to update it to 10.1.2 state

On all Linux servers, run the following command as the runtime user <wfuser> to stop all services:
```
$ wfmanager stop all
```
Cleanup cached resources (RabbitMQ queues, workers data):
1. On the INT server (or in case of the HA setup, on all INT servers), as runtime user <wfuser> start RabbitMQ:
```
$ wfmanager start rabbitmq
```
2. On the INT server (or in case of the HA setup, on the first INT server), cleanup Rabbit queues as runtime user <wfuser>:
```
$ rabbitmqctl list_queues --vhost bep | awk '{ print $1 }' | xargs -L1 rabbitmqctl delete_queue --vhost bep ```
```
3. On the BEP Master server (or in case of the HA setup, on the first BEP Master server), cleanup worker data as runtime user <wfuser>:
```
$ rm -rf /opt/workfusion/vds-data/workers/app/*
```
On each Linux server, stop the supervisord service as runtime user <wfuser>:
```
$ wfmanager shutdown
```
Run the following steps as a user with the root permissions:
1. For each Linux server, set kernel ulimits parameters and ensure that the following strings are present in the /etc/security/limits.conf file with correct values:
```
1. domain: "*", type: "-", item: "nofile", value: "number of vCPU * 25000"
2. domain: "*", type: "-", item: "nproc", value: "number of vCPU * 1280"

Example for 4-vCPU server:

*   -   nofile  100000
*   -   nproc   5120
```
2. For each Linux server, set supervisord process ulimits parameters and ensure that the following strings are present in the /etc/systemd/system/supervisord.service file with correct values:
```
1. LimitNOFILE="number of vCPU * 25000"
2. LimitNPROC="number of vCPU * 1280"

Example for 4-vCPU server:

LimitNOFILE=100000
LimitNPROC=5120
```
3. On each Linux server, ensure that no running services are owned by the runtime user <wfuser>:
```
$ sudo ps aux | grep wfuser
```
4. On each Linux server, reload the systemctl configuration and start supervisord:
```
$ sudo systemctl daemon-reload
$ sudo systemctl start supervisord
```
5. Log out from all sessions on servers for changes to take effect.
On all Linux servers, run the following command as runtime user <wfuser> to start all services:
```
$ wfmanager start all
```
On the INT server (or in case of the HA setup, on the first INT server), generate configuration files for the RPA server. Run the following command as <linux_installation_user>:
```
$ ./patch_10.1.2.sh generate_conf rpa
```
Copy generated nginx configuration files from the first INT server's directory distr/win_confs/rpa_configs/<rpa-hostname> to the <rpa_install_dir>\nginx\conf directory on RPA server(s) with any available method.
Update worker's jar file on the RPA server(s): copy file /opt/workfusion/tmp/workers/com/workfusion/spa/ct/worker-app/10.1.0.2.1/worker-app-10.1.0.2.1.jar from the INT server to the <rpa_install_dir>\worker directory on the RPA server(s) with any available method.
Restart the RPA server(s).

Patching is completed. It may require about five minutes for Control Tower to start. If you see error 503 in browser right after the patching, wait a bit.

Verify installation

Once the update is completed, check WorkFusion Platform with Business Process (BP) and Manual Task. The OCR must be activated. For that on the INT server (in case of the HA setup, on the first INT server), run the following commands as <linux_installation_user>:

$ ./install.sh check app -e test_rpa=true -e test_ie=true -e test_desktop=true -e test_ocr=true -e test_ml=true

For more information on the post-installation checks, see Post-installation tasks.

Rollback

Rollback is performed in the same manner as the apply operation, but option rollback is used instead of apply.

To roll the changes back:

On the INT server (in case of the HA setup, on the first INT server), run the following commands as <linux_installation_user>:

$ cd <patch-dir>
$ ./patch_10.1.2.sh rollback <server-role>  # Will bring desired server to 10.1.1 state.

# Available options for <server-role>: int, bep-master, bep-agent, app, ocr, rpa.

Repeat steps from the Apply section to restart services:
- For single-point setup repeat steps 3-7.
- For multipoint setup repeat steps 2-7.

WorkFusion Documentation

10.1.2

Prepare for installation

High availability setup

Standard setup

High availability setup

Standard setup

Install OCR Windows server

Logs management

Security settings in Control Tower

Prerequisites

Download and extract patch

note

Apply patch

For single-point setup

For legacy setup (multi-point)

Verify installation

Rollback