| Architect: BPM
The BPM Environment Explained
by Mariano Benitez
A functional description of the applications and services that are part of an Oracle BPM Environment
Published September 2009
In this article you will find a functional description of the applications and services that are part of an Oracle BPM Environment. An Oracle BPM Enterprise Runtime Environment is composed of different applications and services. They can be installed and configured in different topologies to handle many different scenarios, supporting different usage patterns. To fully utilize this flexibility you need to understand the function and capabilities of each piece.
This article refers to Oracle BPM 10gR3, and most of the content can apply to Oracle BPM 6.0.
A BPM environment is the technical infrastructure in which Business Processes execute. This includes BPM engines that drive the process flow, end-user applications with which people interact with processes, and all the supporting applications, including databases and application servers. In this article series we define the term BPM Environment as all the runtime components (applications and services) that work together to enable execution of Business Processes.
This article, the first in a series, presents an overview of the different applications and services that compose a BPM Environment, along with descriptions of the functional interactions between them. The objective is to give a high-level overview of the technical ecosystem, describing the components of the environment, and the different topology alternatives for those components.
Subsequent articles in the series will cover the details of each major configuration area, including the BPM Directory, the BPM Engines and the BPM Workspace. These article assume an understanding of those and other relevant Oracle BPM 10.3 terms. For more information, please refer to the relevant product documentation.
BPM Technical Infrastructure
Let's start with a brief description of the components of a BPM Environment. Some components must always be present for the environment to run, while others depend on the activation of features or external requirements. Oracle BPM supports a variety of topology arrangements of these components, ranging from very simple and small to corporate wide, supporting the entire organization. The most common components in the environment are listed below. We assume readers understand the general purpose of each component.
At the end of the document we will describe the rules for combining all of these components in a topology, and provide guidelines for choosing the right one for your organization.
Examples of Oracle BPM Enterprise Environments
The following graphics provide a high-level view of the different moving parts. These graphics show three types of artifacts: boxes, dots, and arrows, each representing different points of interest in the diagram.
Boxes represent the applications and services in the environment. Dots represent the services exposed by the applications (the boxes), and the arrows represent a connection between one application and a service exposed by another.
Figure 1: Simple environment using Oracle BPM Enterprise Standalone
Figure 1 illustrates the architecture produced as a result of completing the configuration wizard included in Oracle BPM Enterprise Standalone. It contains a single BPM Engine Standalone. It also contains web applications deployed in the web server included with the product.
Figure 2: Simple environment using Oracle BPM Enterprise for WebLogic
Figure 2 illustrates the architecture produced as a result of completing the configuration wizard included in Oracle BPM Enterprise for WebLogic. It contains a single BPM Engine for WebLogic and web applications all deployed in a single WebLogic server instance.
Figure 3: Clustered environment using Oracle BPM Enterprise for WebLogic
Figure 3 illustrates a complex environment in which the BPM engine is deployed in a cluster of WebLogic domain A, and BPM Workspace as well as PAPI-WS are deployed in a different cluster of domain B. This is a very scalable topology, typically used in large installations. Also, the applications are configured to use an LDAP server to obtain user and group information.
The Components of a BPM Environment
This section focuses on the boxes presented in the graphics above. These boxes represent applications running as part of the environment. We consider applications any of the following: standalone Java processes, Web and Application Servers, Web Applications, J2EE Enterprise Applications (EARs), database servers, LDAP servers, etc.
From this perspective, we can divide the components of a BPM environment into three groups: BPM Core, BPM Clients, and supporting services. Every BPM environment will contain components in each of these groups.
There are two main components at the core of a BPM Environment: the BPM Engine, and the Process Monitoring Service.
The BPM Engine
The BPM Engine is the component that effectively executes business processes. The BPM Engine is the core element of every BPM Environment. An environment must contain at least one BPM Engine. Let's describe the BPM Engine from different points of view:
There are many configuration parameters with which to customize the behavior of BPM Engines, for things like threads, ports, database connections, and retries. Each BPM Engine can be configured independently to better serve the Business Processes that run within it. This configuration and customization will be covered in detail in subsequent articles in this series.
Where is the BMP Engine defined?
BPM engine as a J2EE application
BPM engine as a Java process
BPM engine-exposed services
Business Processes and BPM Engines
In most BPM environments all Business Processes run in a single BPM engine. In some cases, however, there may be many engines running in the same BPM environment.
How many BPM engines in your environment?
There are two possible cases in which BPM engines defined in different BPM Directories will interact. In the first case, we have B2B communication between different organizations. And the interaction is limited to inter-process communication (IPC); end-users do not see instances of the other organization's processes.
In the second case, a very big organization has different BPM directories for different divisions or functional areas, rather than centralizing all processes in a single BPM directory. In this scenario end-users must see process instances running in BPM engines defined in different BPM directories. This can be achieved by configuring BPM clients (e.g. BPM Workspace) to simultaneously connect to multiple BPM directories. The BPM client will then aggregate the information from all engines and present a unified view to the end-user. This is referred to as a federated PAPI client, or a federated BPM Workspace.
The Process Monitoring Service
The Process Monitoring Service is responsible of building the aggregate information of process instance executions and metrics. This information is used by BAM Dashboards and the Process Data Mart. For an overview and configuration on BAM and the Process Data Mart, read the documentation.
The Process Monitoring Service has a very specific and critical purpose. Without it, Workspace Dashboards would not get accurate information to display process dashboards. In some cases, when the service has not been running for a long time, it must read and aggregate many events, consuming considerable time and resources.
BPM clients are applications that interact with Business Processes running inside BPM engines.
Most BPM clients will connect to the BPM engines through the services exposed by the engine. But there is another kind of BPM client: those that interact with Business Processes through external resources, like a JMS queue, a file system, or a database table. In this case it is the Business Process itself - as part of its definition - the one that establishes an interaction by pushing and pulling information through these resources, defining a contract with the external entity to exchange information. This kind of clients are not covered in this article. From the point of view of which BPM engine service the client uses to connect, we have two big groups: PAPI clients, which use the internal process service, and Web Service clients. There is another group of clients, related to administration. BPM Process Administrator fits in this category, but there are others.
PAPI stands for 'Process API', and refers to the Java API these clients use to interact with the BPM engine. PAPI is embedded in many BPM web applications bundled with the BPM Enterprise products, the BPM Workspace web application being the most relevant example. In a nutshell, PAPI performs many critical functions from the point of view of the end-user. It is configured to authenticate and authorize end-users, find available processes in the BPM Directory, connect to BPM Engines that are running those processes, and return instances information to end-users. PAPI is the only Java API available for process interaction. In future articles we will cover how to configure PAPI clients to connect to the BPM Engines according to the topology.
PAPI client runtime characteristics
BPM Workspace web application
Web Service clients
Web Service clients can choose between the two available services: the Process-WS service exposed by BPM engines, and the PAPI-WS application.
This category includes the BPM Process Administrator, which is the main administration tool, along with BPM Workspace Administrator, and the Archiving Viewer. These web applications are not used for day-to-day tasks, but they are important in the configuration and administration of the environment.
Classification by application type
There are several types of process clients, including end-user applications and back-end systems. End-User applications can be part of the product, i.e. BPM Workspace, or custom-built applications, either web- or desktop-based. Most environments will have at least one end-user application through which process users interact with the systems. The application to be used is based on a design decisions made by the development team. That application must communicate with the BPM Engine in order to access the process information and invoke operations on the processes.
How many BPM clients in your environment?
A number of supporting services are required to complete the BPM Environment, including Databases, LDAPs, and Web and J2EE servers. The specific service requirements depend on the configuration, topology, and BPM Engine flavor. The purpose and topology of some of these services are described below. (The technical details on configuring these elements will be addressed in a future article.)
All configuration and runtime information is stored in the database. Only log files, caches, and bootstrap information is stored in the file systems on the host machines. Oracle BPM requires separated database schemas for each specific function:
Obtaining database connections
J2EE Application Servers
Application Servers can be used as containers for the BPM engine and/or the BPM clients (BPM Workspace, for example). Any combination is supported, assuming the appropriate configuration. For example: A BPM Workspace running on WebLogic can connect to a Standalone BPM Engine. A standalone Java PAPI client could also connect to a BPM Engine deployed in WebLogic. If the type of BPM Engine selected is WebLogic or WebSphere, BPM Engines will always run as a J2EE application installed in a single server or a cluster.
J2EE resources used by the BPM engine
As previously stated, BPM Engines running in a J2EE application server will use container datasources to access the directory and engine schemas .In addition to those required schemas, each BPM Engine requires two messaging resources: a queue and a topic. These JMS resources are required to achieve functionality that the Standalone BPM Engine can implement without them. Application servers provide no framework for background executions, so the JMS queue is used to trigger background executions along with a Message Driven Bean (MDB). The BPM engine will produce a message when an automatic task must be executed. The MDB will then pick up that message and execute the task. The JMS topic is used to push information to all PAPI clients. BPM Engines need a way to propagate changes to all PAPI clients, and those clients listen for messages in that topic. The BPM Engine puts a message in the topic when there is news to publish, and clients read the message and update the internal caches accordingly (the BPM engine is the publisher and PAPI clients are the subscribers).
Web Portals: Web Center Integration, WebLogic Portal
Oracle BPM is integrated with Portals in different ways. Some BPM web applications, BPM Workspace in particular, can be surfaced through Web Center Integration (WCI) or WebLogic Portal (WLP). Another alternative is to build custom portlets, using PAPI, that will be published in portals. This last case is no different from any custom PAPI application .Besides the front-end integration, there is also the possibility to trigger process actions when a portal event occurs. For example, a process instance can be created when a discussion is started in a forum. This integration can PAPI, too, or it could just use Web Services to invoke the operation .Now let's take a look at the main portal technologies supported by Oracle BPM WebCenter Integration (WCI). Upon installation of a BPM extension in WCI, BPM Workspace automatically appears as a new portal page. BPM Workspace is surfaced in WCI as a series of portlets and a default page with the default BPM Workspace sections. BPM Workspace attachments are also integrated with WCI, either with Knowledge Directory or Collab. You can also assign a discussion or project to a process instance, or trigger an instance creation upon any event in WCI .The integration with WCI also includes integration with WCI users and groups, so BPM can create a BPM Directory that reads users and groups from WCI. This is achieved using a virtual LDAP interface that is provided either by WCI Virtual LDAP or Oracle Virtual Directory.
WebLogic Portal Integration (WLP)
LDAPs are used as source of organization information, specifically users, organizational units and groups. This integration is very flexible and configurable, to accommodate many different LDAP structures.
Services required by Business Processes
If your business processes integrate with any other system (e.g. a payroll database, a credit check web service, or a queue with trade operations), those services become part of your BPM environment. Those services are necessary for your processes to execute. Configuration of such resources is mostly performed in BPM Process Administrator.
Services provided by BPM Components
Now that we've described the applications, let's move to the services they provide. We will only focus on the services provided by the BPM Applications, describing the different services providers, which clients typically consume those services, and the protocols available to connect to the services. The most important service provider is the BPM Engine. Every process instance operation occurs in the BPM Engine. Operations are triggered either automatically by the engine, or externally by a BPM client, which has to use one of the engine services to trigger the operation .The main service exposed by the BPM Engine is the internal Process Service. This service is mainly used by PAPI to interact with the engine. Every PAPI client uses this service to query and invoke process instances. Consequently, the BPM Workspace and any PAPI client application will connect to this service.
BPM Engine Process Service
PAPI Clients automatically discover the location of the engines, and select the appropriate protocol based on the engine type.
Other BPM Engine Services
The PAPI-WS application, already described in detail in this article, is indeed a service provider.
Connecting Services and Clients
Choosing a topology
Topology Definition Guidelines
We'll publish more guidelines as they emerge.
This article has provided an overview of the moving parts in a BPM environment. Subsquent articles in this series will dive into the areas of configuration that allow our environment to run properly.
Mariano Benitez, a BPM Architect for Oracle, has been building BPM software for more than seven years, and has been involved in various aspects of IT, including developement, mangagement, sales engineering, professional services, and support.