How to deploy a new release of an application with zero downtime in BusinessWorks

6 min readJun 9, 2025

While BusinessWorks is commonly used in critical environments with stringent availability requirements this is crucial to not only deploy BusinessWorks in high availability configurations but also to be able to deploy new application releases without downtime.

This article is to describe two possible approaches for achieving zero downtime deployment with BusinessWorks but first there is need to explain the prerequisites that must be met.

Prerequisites

To be able to deploy a new release of an application without downtime the following conditions must be met:

· At least two instances of the application must be running in active / active mode

· The end points exposed by the new version of the application must be strictly compatible with the existing ones in terms of transport (port numbers, JMS queues, …) and message formats

For endpoints exposing messages in XML format only limited changes are possible, this covers mostly:

· Adding optional elements in Requests

· Removing optional elements in Responses

For endpoints exposing messages in JSON format there is more flexibility to make changes in the new release of the application:

· Adding optional fields and removing fields in Requests

· Removing optional fields and adding fields in Responses

For more elements on JSON message format ascending compatibility, you may check the following article:

https://emarchiset.medium.com/how-to-manage-ascending-compatibility-for-json-formats-in-businessworks-and-businessworks-container-ba6aaed0c33e

Deploy the new release of the application in the existing Appspace

In BusinessWorks 6.X, this approach is only applicable if the new application release differs from the current version by at least the Minor version element (second digit). For example, if the current version is 2.1, the new version must be 2.2 or higher. It doesn’t work if the version number differs only at micro level (3rd digit). This is an OSGi constraint.

This approach is generally recommended while it is more simple to manage.

The approach is the following:

. Starting point: the two instances of the target applications must be running

. Upload the ear of the new version (with the option ‘Replace any version’ unckecked)

. Deploy the new version of the application in the target appspace (with the options ‘Start application’ and ‘Replace any version’ unckecked)

. On one appnode of the appspace:
- stop the running application instance
- start an instance of the new version
- check the instance has started without error and is processing messages

. Repeat the same steps on the other appnode

. Once it is confirmed the new version is running fine you may undeploy the old one to avoid mistakenly starting it

. In case of problems with the new version, you may try to restart the appnodes one by one and if this doesn’t resolve the issue revert to the version previously running

For example, to deploy a new version 2.2.0 of the MyApp application currently running in 2.1.0 release in appspace AS01 made of two appnodes AS01-AN01 and AS01-AN02 you have to do the following:

1) Verify application in version 2.1.0 is running on both appnodes

2) Upload the new archive with the default option (‘Replace any version’ option unckecked)

3) Deploy new version 2.2.0 with the default options (‘Start application’ and ‘Replace any version’ options unckecked)

4) On AS01-AN01 stop version 2.1.0, start version 2.2.0

5) Check application is started and processing ok

6) On AS01-AN02 stop version 2.1.0, start version 2.2.0

7) Check application is started and processing ok

8) Undeploy version 2.1.0

The diagram below shows the configuration with the two versions deployed:

The last section of this article includes screen shots showing the step by step execution of this procedure while using the TEA.

Deploy the new release of the application in a new Appspace

In this approach there is no constraint regarding version numbers but you have to duplicate the appspace configuration which may increase resource usage.

The approach is the following:

. Starting point:
- The two instances of the target applications are running in one of the appspace
- Another appspaces is available with its two appnodes running and ready to host the new version of the application

. Upload the ear of the new version with the default option (‘Replace any version’ option unckecked)

. Deploy the new version of the application with the default options (‘Start application’ and ‘Replace any version’ options unckecked)

. On the first appnode of the active appspace:
- stop the running application instance

. On the first one appnode of the other appspace:
- start a new application instance
- check the instance has started without error and is processing messages

. On the other appnode of the active appspace:
- stop the running application instance

. On the other appnode of the other appspace:
- start a new application instance
- check the instance has started without error and is processing messages

. Once it is confirmed the new version is running fine you may undeploy the old one from the appspace that was initially active to avoid mistakenly starting it

. In case of problems with the new version, you can take the same approach to revert to the version previously running

For example, to deploy a new version 1.2.2 of the MyApp application that is currently running in 1.2.1 release in an appspace AS01A with two appnodes AS01A-AN01 and AS01A-AN02 you have to do the following:

1) Verify application in version 1.2.1 is running on both appnodes of appspace AS01A

2) Verify the two appnodes of appspace AS01B are running

3) Upload the new archive with the default option (‘Replace any version’ option unckecked)

4) Deploy new version 1.2.2 to AS01B with the default options ( ‘Start’ and ‘Replace any version’ options unckecked)

5) On AS01A-AN01 stop version 1.2.1

6) On AS01B-AN01 start version 1.2.2

7) Check application is started and processing ok on AS01B-AN01

8) On AS01A-AN02 stop version 1.2.1

9) On AS01B-AN02 start version 1.2.2

10) Check application is started and processing ok on AS01B-AN02

The diagram below shows the configuration with the two versions deployed:

Example of the deployment of a new release of the application in the existing Appspace

Using the same example as before of the deployment of a new version 2.2.0 of the MyApp application running in 2.1.0 release in appspace AS01 made of two appnodes AS01-AN01 and AS01-AN02 and using the TEA you have to do the following:

1) Verify application in version 2.1.0 is running on both appnodes