Once you have defined your preferred way of building your Business Services projects into your executable type (i.e., as Container images, Native Executable, or standard JARs) you are ready to define your deployment strategy.

Follow industry-standard software development practices to version your Business Services projects on Version Control Systems (VCS), and to automate the deployment process of your Business Services using widely adopted services and tools.

While BAMOE does not dictate how you deploy your Business Services to your production environment, there are a few important considerations you need to take into account, especially if you are using stateful Workflows.

Creating your database schema for stateful Workflows using BAMOE Installation DDL scripts

To initialize your application database, BAMOE provides a set of DDL (Data Definition Language) scripts in the bamoe-{version}-db-utils.zip deliverable that can be manually applied by a database administrator.

The Installation DDL scripts provided allow you to create from scratch the Database for the different BAMOE subsystems for PostgreSQL, Microsoft SQL Server, and since 9.2.1, Oracle.

The provided scripts can be executed in any order, and the required tables will be created in the database that will be used by the BAMOE Workflow engine.

Contents of bamoe-9.2.1-db-utils.zip
Figure 1. Contents of bamoe-9.2.1-db-utils.zip

Make sure you have KIE Flyway disabled to guarantee your Business Service containing stateful Workflows subsystems configured with persistence will not try to apply changes to your database schema in your production environment.

kie.flyway.enabled=false

If everything is correctly set, at the first project execution all the tables will be automatically added.

Evolving stateful Workflows across Business Service deployments

When deployed Workflow services start to be consumed and Process Instances start to be created, if you subsequently make changes to the project or the BPMN files and re-deploy, there are a few things to be considered.

As a general guideline, it is safe to deploy a new version of your application if there are no changes to Workflow models (BPMN files) or if your BPMN files are Straight-Through Processes (STPs). However, when the Diagram (Sequence Flow) of a stateful Workflow model changes with new nodes, and/or new “paths” of execution, you should not just update your BPMN file(s) in-place and deploy a new version of your application. Instead, it is recommended that you keep the current BPMN file(s) unchanged and duplicate them under a new name (and with a different ID), so that new Process Instances can be created based on the new version, while old Process Instances can continue their original Sequence Flow normally, based on the old Workflow model.

The pseudo-timeline below shows the safest strategy for evolving your Workflow models across many deployments.

  • First deploy (v1):

    • + MyWorkflow.bpmn (Added)

  • Second deploy (v2):

    • ⊙ MyWorkflow.bpmn (Kept, but deprecated. Do not allow creation of new Process Instances from it.)

    • + MyWorkflowV2.bpmn (Added)

  • Third deploy (v3):

    • - MyWorkflow.bpmn (Deleted once there are no more active Process Instances)

    • ⊙ MyWorkflowV2.bpmn (Kept)

There is no limit for how many different "versions" of a Workflow you can deploy in the same application. It may take some time for all Process Instances of an old version to be completed, and you can keep evolving your Workflow models by following this strategy.

Implementing multi-Pod Business Services containing stateful Workflows with a single database

When running multiple instances of a process service on multiple Pods in the Compact Architecture, you must assign a unique Jobs Service Management ID to each instance. This is to avoid multiple instances attempting to assume leadership over the Jobs Service and connection to the shared database and utimately the failure of the service.

Note
 Jobs will only execute on the Pod where they were originally scheduled.

Each instance of a Business Service must have its own unique Jobs Service Management ID. This can be specified at application startup using the following configuration option:

kogito.jobs-service.management.heartbeat.management-id=<id_string>

Where <id-string> does not need to follow any pattern or order and only needs to be unique for each Pod in the deployment. If you do not specify a string it defaults to kogito-jobs-service-leader.

This configuration option can be set in a number of ways including:

  1. Environment variable (recommended) (preferrably via Kubernetes' ConfigMap, that manages environment variables for a Pod)

  2. System property

  3. META-INF/application.properties

Note
 We do not document tools and best practices for testing a deployment configuration or recovery in a multi-Pod setup, however we recommend thorough testing of scenarios such as Pod failure, load balancing, and database replication prior to deploying in a multiple Pod configuration.