This reference architecture takes advantage of the provided BPM Suite 6.3 installer script to establish a basic clustered environment configuration with an architectural structure transferable to use cases on a larger scale.

The automatic configuration creates three ZooKeeper instances, a Helix cluster that uses these instances, and two Quartz datastores (one managed and one unmanaged). This Red Hat JBoss BPM Suite setup consists of two EAP nodes that share a Maven repository, use Quartz for coordinating timed tasks, and have business-central.war, dashbuilder.war, and kie-server.war deployed. To customize the setup to fit your scenario, or to use clustering with the deployable ZIP, see the BPM Suite Installation Guide Section regarding Custom Configuration (Deployable ZIP). You can also get more information in the JBoss EAP documentation.

BPMS 6.3 includes the Business Central and Dashbuilder web applications, which are hosted on the EAP 6.4.7 servers. Supporting libraries are added to the EAP 6.4.7 servers as a module layer. Security policy files and a few configurations are also applied to the EAP domains.

BPMS uses Git repositories for both its asset repositories and workbench configurations. In this reference environment, Apache ZooKeeper is leveraged as a clustered and replicated VFS for the Git repositories.

Application artifacts are stored as Maven projects. Each repository may contain one or more projects, each of which is described by a project object model (.pom) file and may contain various asset types.

BPMS 6.3 uses the central PostgreSQL database instance to store runtime process information, Quartz timer data and audit log information that is used for business activity monitoring. For clients with a large number of process executions, it may be advisable to use a separate database for the BAM data. Persistence for Business Central is configured in the _persistence.xml _file but the changes required to separate the datasources is outside the scope of this guide and depends on the execution model.

BPMS 6.3 includes a number of modules and web applications that are configured and deployed on top of JBoss EAP 6.4.7. Accordingly, the foundation of the BPMS environment is the setup of an EAP 6.4.7 cluster via the BPM Suite installer script.

In this reference architecture, ZooKeeper is clustered alongside EAP, so that three nodes of ZooKeeper and Helix run alongside each of the EAP 6.4.7 nodes.

An Apache ZooKeeper cluster is known as an ensemble and requires a majority of the servers to be functional for the service to be available. Choosing an odd number for the cluster size is always preferable. For example, both a three-member and a four-member cluster can only withstand the loss of a single member without losing a functioning majority, so groups with an odd number of members provide higher efficiency.

ZooKeeper allows BPMS to replicate its Git repositories. Only a single instance of ZooKeeper is required to allow BPMS to replicate its data; the ZooKeeper ensemble serves to provide redundancy and protect against the failure of ZooKeeper itself.

Helix works in conjunction with ZooKeeper as the cluster management component that registers all the cluster details (the cluster itself, nodes, resources).

Whereas ZooKeeper was previously responsible for replicating other locally maintained data, including deployments, this is no longer the case. When utilizing Business Central, as exemplified by the example application developed herein, the persistence database is utilized for deployment synchronization and other BPM data. When choosing to utilize the Realtime Decision Server or Intelligent Process Server, both being derivations of the KIE Server, the controller of the execution server assumes responsibility for deployment replication.

With BPM Suite 6.3, when choosing to use a KIE Server derivative, Business Central can be used to manage the KIE Servers and their containers, however, you can’t utilize the runtime views of Business Central, such as Process Definition, Process Instances, Process Tasks, etc. This functionality is currently slated for inclusion in BPM Suite 7, where the Business Central execution server will be replaced with KIE Server integration.

The BPM Suite installer script requires a data store for both EAP and BPMS instances, the latter of which utilizes persistence of active business process data, audit log and Quartz timer data. While various storage options are possible, given the interface with the persistence layer via JDBC, a single instance of PostgreSQL is assumed to have been established beforehand within this document with user jboss and password password1! allowing general access to all required tables.

While this single instance could be considered a single point of failure, the database itself can also be clustered, but the focus of this effort is BPMS 6.3 and clustering of the data source is beyond the scope of this reference architecture.

This reference architecture provides a step-by-step guide to the design and development of an example application. The completed application is provided in the attachments and is also directly available for download from the Red Hat customer support portal. Refer to the section on BPM Suite Example Application for further details.

This reference environment provides protection against failover as well as opportunity for load balancing at various levels for multiple tiers and components. This includes:

BPMS 6 provides the Business Central application as a design and development environment as well as an analysis and testing tool and a production runtime platform. Developers and analysts may use the web process designer to create or update business processes and the various rule editors to implement business rules. In later stages, test scenarios can help verify expected functionality and the QA facilities are useful for reviews. Finally, in production, Business Central may be used either directly through its forms to start processes and work on forms, or through its REST interface to delegate the same functions from a custom application. The latter set of activities can broadly be categorized as runtime and distinguished from the type of design-time work that was described earlier. With the incorporation of KIE Server functionality, partitioning of business knowledge and clustering of environment components allows for independent scalability of such runtime environments, while simplified usage and deployment of different rules knowledge bases within different containers also provides a natural decoupling between the authoring and execution phases of a rules-based application.