Open topic with navigation

TIBCO® BPM Enterprise 5.5.0

# TIBCO BPM Enterprise Reference Architecture

TIBCO BPM Enterprise, like most enterprise software, is intended to be used in conjunction with a standard set of software and hardware infrastructure. It is not a software appliance, TIBCO® BPM Enterprise Concepts Guide 19 | Introduction to TIBCO® BPM Enterprise and therefore, cannot be installed on a machine and used in a safe and secure manner. Such an approach can be suitable for some development and "proof of concept" purposes. However, using TIBCO BPM Enterprise in this way in a production environment is not recommended. For this reason, a reference architecture is proposed that defines the kind of deployment that is expected for TIBCO BPM Enterprise in a production environment. For more information, see TIBCO® BPM Enterprise Getting Started.

This section describes the logical topology of the recommended architecture.

It is presumed that TIBCO BPM Enterprise is the primary component in the system supported by the reference architecture. It is also presumed that the Kubernetes system is only used to support TIBCO BPM Enterprise. However, typically the Kubernetes system hosts multiple enterprise systems, and possibly other components that comprise part of the overall system for which TIBCO BPM Enterprise is the primary component.

The following diagram shows the logical structure of the reference architecture:

Legend

| Components of the Kubernetes system.
| Parts that comprise TIBCO BPM Enterprise.
| Infrastructure parts specifically required for TIBCO BPM Enterprise. In some cases where the Kubernetes system is shared by multiple enterprise systems, one or more of these parts may also be shared.
| These are standard components that will already be in place within the target organization.

Note: In the illustration, worker or "minion" node connectivity is only shown on the far right-hand Kubernetes node. This connectivity is replicated across all of the Kubernetes worker nodes.

The illustration shows a tiered architecture, where it is expected that users will access the TIBCO BPM Enterprise system via the internet or a VPN, and that the system will be administered remotely from the data center that is hosting the complete system. Each tier of the system is encapsulated in its own "zone" bounded by two firewalls. As is conventional for such architectures, it is not possible to cross more than one firewall boundary from any system.

Above the outer tier of the system is the application user (represented by the TIBCO BPM Enterprise web client) and the Kubernetes administrator, which is a separate and distinct persona from the TIBCO BPM Enterprise administrator. Both of these users will not have any physical access to the machines hosting Kubernetes or any other component of the system. End users are typically not able to log in to these machines. The Kubernetes administrator may have an operating system login to these systems, but will not be able to log in remotely.

The top tier of the diagram contains a conventional web DMZ. This contains the required load balancer for the TIBCO BPM Enterprise system. This will also be a reverse proxy, to facilitate the indirection required to access this system via an external system. The reverse proxy will implement the sticky session capability required by TIBCO BPM Enterprise. Also located in this tier is the jump system (located on a Bastion server) that is used to administer the Kubernetes system. Typically, access to this server is only possible via a VPN (not shown on the diagram).

The middle tier contains the Kubernetes system. This must consist of at least one master node and one worker node, although, typically, there are two or more worker nodes. The diagram shows three worker nodes (this being the default used by some cloud services). Each worker node will house one or more pods that consist of a set of containers required for a particular application. In the case of TIBCO BPM Enterprise, the pod will typically consist of the mandatory TIBCO BPM Enterprise container. Other pods may also be present on the worker nodes. They may be required by other applications or for the required capabilities of the installed Kubernetes system.

The bottom tier contains the enterprise infrastructure used by Kubernetes and TIBCO BPM Enterprise. This tier contains the LDAP directory required by TIBCO BPM Enterprise, which is most likely the directory used by the organization running applications in TIBCO BPM Enterprise. This tier also contains the database required by TIBCO BPM Enterprise, the SMTP email server used to send work item notifications and emails from executed email tasks, as well as the container repository used by Kubernetes.

Log files are emitted as standard log files for the docker container. These files are then managed at the pod level by Kubernetes. In a production environment, it may be necessary to combine these logs in a way that a single log file is available on a machine that is not a Kubernetes node or is available in a log management system.

The replica set is the primary mechanism to be used for HA/FT purposes. The minimum number of replicas should be one per node. Scaling will be performed using standard Kubernetes HPA mechanisms.

High availability and fault tolerance is provided using Kubernetes replica sets.

Did you find this helpful?

Yes No
Great!
Thanks for taking the time to give us some feedback.
Sorry about that

Why wasn't this helpful? (check all that apply)

Could not find what I was looking for
Instructions confusing or unclear
Instructions did not work

Want to tell us more?

Please select at least one option or provide details about the issue!!

Error occurred while submitting feedback.

Error2 occurred while submitting feedback.

TIBCO® BPM Enterprise

Copyright © 2015-2024. Cloud Software Group, Inc. All Rights Reserved.