10.1.2

Edit

Upgrade from 10.1.2.x to 10.1.2.2

The guide describes how to perform upgrade from 10.1.2.0 or 10.1.2.1 to 10.1.2.2 version of WorkFusion Intelligent Automation Cloud.

Prerequisites

  • You have WorkFusion Intelligent Automation Cloud 10.1.2.0 or 10.1.2.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 next to "worker" group, click More ("..."), and select 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>:

  1. Change directory to PACKAGE_DIR (where the installer was extracted during initial installation of 10.1.2, 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> ./

  2. Create the patches directory, if it doesn't exist, and download the patch:

    $ mkdir -pv patches
$ cd patches/
$ curl -o 'patch_10.1.2.x-10.1.2.2.tar.gz' 'https://spa-releases.s3.amazonaws.com:443/10.1/10.1.2/patch_10.1.2.x-10.1.2.2.tar.gz?AWSAccessKeyId=AKIAIYJMMPKAN2MQSJWA&Expires=1622024117&Signature=w%2BF7T9pgZfEbF6ATZk71u7Qe3QY%3D'

    If the Internet access is not available on the Integration server, download the patch to PACKAGE_DIR/patches/ directory with any available method.

  3. Extract the patch:

    $ tar xzf patch_10.1.2.x-10.1.2.2.tar.gz

    After the extraction, in the PACKAGE_DIR/patches/, you will find the patch_10.1.2.2.sh script and the patch_10.1.2.x-10.1.2.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.x-10.1.2.2
-rwxrwxr-x.  1 ec2-user ec2-user       1246 Sep 27 16:00 patch_10.1.2.2.sh
note

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

Apply patch

Apply the patch, depending on your installation approach:

For single-point setup

  1. On the INT server, run the below commands one by one to apply the patch.

    $ 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_VAULT_PASS="<your-ansible-vault-pass>"  # Optional. If you run this command you'll not be prompted to enter config decryption password while applying patch.

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

  2. On the RPA Windows servers, update the metricbeat configs, in file <RPA_INSTALL_DIR>\metricbeat\modules.d\workfusion.yml, change period: 60s -> to period: 300s (in both places where this line appears in the file).

  3. On the BI Windows servers, update the metricbeat configs: in file <BI_DIR>\metricbeat\modules.d, change period: 60s -> to period: 300s (in both places where this line occurs in the file).

  4. On the BI server, restart metricbeat by opening cmd as Administrator and running the following commands:

    net stop metricbeat
net start metricbeat

  5. Stop all product components, except BI. For the single-point installation, run the single command on the INT server, as <linux_installation_user>:

    $ cd PACKAGE_DIR
$ ./install.sh stop_services full -e skip_bi=true    # Stop all services on all servers (except BI)

  6. Cleanup cached resources (RabbitMQ queues, workers data):

    1. On the INT server (or in case of the HA setup, on all INT servers), start RabbitMQ as runtime user <wfuser>:

      $ 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 any BEP MASTER server) clean worker files on the file-system from the shared directory. The command cleans ip old workers' data directory on all BEP MASTERs and BEP AGENTs:

      $ rm -rf INSTALL_DIR/vds-data/workers/app/com.workfusion.spa.ct/worker-app/10.1.0.2.1

    4. On each BEP AGENT server, as <wfuser>, ensure that there are no workers running:

      $ pkill -f worker.jar # This will kill all current worker processes (if they exist)

  7. Start all product components, except BI (because we haven't stopped BI) by running the single command on the INT server as <linux_installation_user>:

    $ 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

The patching is completed. It may require for 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)

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

    $ cd PACKAGE_DIR/patches/
$ export ANSIBLE_VAULT_PASS="<your-ansible-vault-pass>"  # Optional. If you run this command you'll not be prompted to enter config decryption password

$ ./patch_10.1.2.2.sh apply int --limit <current-hostname>        # Run on INT server(s) to update it to 10.1.2.2 state
$ ./patch_10.1.2.2.sh apply bep-master --limit <current-hostname> # Run on BEP Master server(s) to update it to 10.1.2.2 state
$ ./patch_10.1.2.2.sh apply bep-agent  --limit <current-hostname> # Run on BEP Agent server(s) update them to 10.1.2.2 state
$ ./patch_10.1.2.2.sh apply app --limit <current-hostname>        # Run on APP server(s) to update it to 10.1.2.2 state
$ ./patch_10.1.2.2.sh apply ocr --limit <current-hostname>        # Run on OCR server(s) to update it to 10.1.2.2 state

# <current-hostname> is the hostname of the server on which you're executing the command

  2. Update metricbeat configs on RPA and BI servers. For that, repeat steps 2-4 from single-point-setup.

  3. Stop all product components on all servers. For that, on each Linux servers, run the following command as the runtime user <wfuser>:

    $ wfmanager stop all

    Restart the RPA component by rebooting the RPA server, or logging the RPA users off.

  4. Clean up the cached resources (RabbitMQ queues, workers data). For that, repeat the step 6 from single-point-setup.

  5. Start all product components, except BI by running the command on each Linux server as runtime user <wfuser>:

    $ wfmanager start all

The patching is completed. It may require for 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.

To verify the update, run the following command on the INT server (for the single-point installation), or from the APP server (in case of the multi-point installation):

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

Rollback

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

To roll the changes back:

  1. Run the following commands as <linux_installation_user> according to your way of installation:

    • For the single-point setup, run the commands from the INT server. In case of the HA setup, run them on the first INT server:

      $ cd <patch-dir>
$ ./patch_10.1.2.2.sh rollback int         # Will bring desired server to 10.1.2.0 (or 10.1.2.1) state
$ ./patch_10.1.2.2.sh rollback bep-master  # Will bring desired server to 10.1.2.0 (or 10.1.2.1) state.
$ ./patch_10.1.2.2.sh rollback bep-agent   # Will bring desired server to 10.1.2.0 (or 10.1.2.1) state.
$ ./patch_10.1.2.2.sh rollback app         # Will bring desired server to 10.1.2.0 (or 10.1.2.1) state.
$ ./patch_10.1.2.2.sh rollback ocr         # Will bring desired server to 10.1.2.0 (or 10.1.2.1) state.

    • For the multi-point setup, run the each command on the respective server (for example, ./patch_10.1.2.2.sh rollback int on INT, ./patch_10.1.2.2.sh rollback bep-master on BEP Master, and so on):

      $ cd <patch-dir>
$ ./patch_10.1.2.2.sh rollback int --limit <current-hostname>        # Will bring desired server to 10.1.2.0 (or 10.1.2.1) state
$ ./patch_10.1.2.2.sh rollback bep-master --limit <current-hostname> # Will bring desired server to 10.1.2.0 (or 10.1.2.1) state.
$ ./patch_10.1.2.2.sh rollback bep-agent --limit <current-hostname>  # Will bring desired server to 10.1.2.0 (or 10.1.2.1) state.
$ ./patch_10.1.2.2.sh rollback app --limit <current-hostname>        # Will bring desired server to 10.1.2.0 (or 10.1.2.1) state.
$ ./patch_10.1.2.2.sh rollback ocr --limit <current-hostname>        # Will bring desired server to 10.1.2.0 (or 10.1.2.1) state.

# <current-hostname> is the hostname of the server on which you're executing the command

  2. Repeat steps 2-7 from the Apply section:

    • Rollback metricbeat configs on RPA and BI servers.
    • Stop all product components.
    • Cleanup rabbitmq queues and workers.
    • Start all product components.

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

← PreviousNext →