Architect: BPM
 Oracle BPM Suite
BPM, SOA, Middleware, Enterprise Architecture, All Architect Articles

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.

  • Components that are always present:
    • At least one BPM Engine with its corresponding DB Schema
    • One Directory Repository DB Schema
    • An end-user process client (typically the BPM Workspace application)
    • An administration client (BPM Process Administrator application)
  • Optional components:
    • One LDAP Server
    • More BPM Engines
    • One Process Monitoring Service
    • Multiple BPM Workspaces
    • Custom Java clients
    • Archiving Viewer application
    • Workspace Administrator application

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
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
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
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.

BPM Core

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:

  • From a logical point of view, a BPM Engine is the deployment target for Business Processes, which are not live until they are deployed and running in a BPM Engine. The BPM Engine will be responsible for creating, storing, and moving around instances of processes deployed within it. All updates on the state of a process instance are performed by the BPM Engine that is running that process.

  • From a runtime point of view, a BPM Engine is a service that executes process tasks. These tasks are defined by the BPM processes as process activities. Executions can be triggered externally by clients or internally in the background. The BPM Engine also provides query services so external clients can search for instances of processes.

  • From a physical point of view, the BPM Engine takes different forms depending on the selected product. It is a standalone Java process in the case of Enterprise Standalone. It is a J2EE Enterprise Application (.ear) in the case of Enterprise for WebLogic and WebSphere. A single product is chosen for a BPM Environment: either Standalone, WebLogic, or WebSphere.

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 Engines are created in a BPM directory. This is a metadata repository where all the definitions, including engines, processes, organization, and resources, are stored. When an engine starts executing, it reads its configuration parameters from the BPM directory, and the processes deployed, etc. Once a BPM Engine is created, it represents only a logical definition. The next section describes the engine types.

BPM engine as a J2EE application
The BPM J2EE Engine runs as an EAR application deployed in a J2EE container (WebLogic or WebSphere). The EAR contains EJBs, MDBs, and Servlets that together conform to the BPM Engine. An EAR file must be generated from the BPM Process Administrator for every defined BPM Engine. This EAR file is then deployed to a J2EE server or cluster. Deploying to a cluster allows many servers to run the BPM Engine concurrently, allowing the dynamic addition and removal of servers to adapt the processing capacity and support server failures transparently. In the case of a BPM Engine deployed to a cluster, any of the cluster servers can respond to requests for any of the processes deployed in the BPM engine.

BPM engine as a Java process
The BPM Standalone Engine runs as a background Java process, and requires no J2EE or Web container to run. Only one Java process runs the engine at any time (it is called the active engine), but one or more Java processes can remain in standby mode as backup engines. When the active engine stops responding, one of the passive engines will take over and become the active engine. The Standalone BPM Engine has its own thread, connections, and request management, which are highly configurable.

BPM engine-exposed services
The BPM Engine exposes several services through which it can communicate with external clients. These interfaces contain operations to manipulate, query, and create instances of the processes deployed in the BPM Engine. These services are represented by the dots figures above, and are described in the following sections.

Business Processes and BPM Engines
Business Processes typically interact with each other, for example, to kick-off a sub-process, or notify another process of some event.

  • From a design perspective, two interacting processes need not run on the same BPM Engine. Discovery and communication between BPM Engines is handled automatically by internal BPM Engine frameworks. Nevertheless, in some cases it is necessary to configure the location of remote BPM Engines (we will cover this in subsequent articles).

  • From a client perspective, and with PAPI clients in particular, the location of processes is transparent. Different versions of the same process can be deployed in different engines (only one version can be active). BPM clients connect to the BPM directory, then discover engines running the processes they are interested in, and finally connect to those 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?
As stated earlier, BPM Engines are just deployment targets for Business Processes. Processes can be deployed in any of the BPM Engines defined in your BPM Environment.

  • From a runtime point of view, once a process is deployed to one BPM Engine, it cannot be moved to another — unless you deploy a new version of the process. However, that will result in two separate but duplicate deployed processes, one active and the other deprecated.

  • From a physical point of view, the communication protocols to be used between BPM Engines depends on type of them (Standalone or J2EE), and if the engines are defined in the same or different organizations. In the case of J2EE engines, BPM clients (e.g. Workspace) must also be configured to communicate with the BPM engines properly.

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.

  • From a logical point of view, the service looks for new process instance events (creations, executions, completions) that have occurred since last run and transforms those events into aggregated rows to be used by the BAM dashboards.

  • From a runtime point of view, each environment has a its own instance of the Process Monitoring Service. Each instance will query the runtime database schema of each BPM Engine defined in the BPM Directory to look for new events, which will then be aggregated. The results are stored in a specific database schema for Real-Time BAM and/or Process Data Mart. The routine to fill the BAM schema runs every five to ten minutes, while the one that fills the Process Data Mart runs only once a day.

  • From a physical perspective, the service runs continuously as a standalone JVM in the background, and it is independent of the type of BPM Engine (Standalone, WebLogic, WebSphere) and if the engines are stopped or started. The service has no user interface and it only reads the BPM Engine database schemas, and writes to the specific database schemas (BAM or Process Data Mart). As it runs standalone, it connects to databases using the built-in JDBC drivers, making direct connections, it just cannot use J2EE datasources.

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

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 clients

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
PAPI is designed to support an interactive process portal -- BPM Workspace, for example — in which many end-users interact with the same set of processes. Some optimizations have been made to improve the performance of PAPI clients, including the caching in memory of information about processes, information about parts of the organization, and so on. This is an important consideration when using PAPI, since those operations can take some time. PAPI clients require connectivity only to the directory and the engine. PAPI clients do not talk to each other, nor do they access resources used by Business Processes. PAPI clients can run as standalone Java processes, or deployed in clusters or web servers farms. The only caveat is that each instance of PAPI (each Java process) requires a copy of the entire cache (organization, metadata, process instances), which demands lots of memory. The configuration of the PAPI cache is a critical consideration in most environments. This cache keeps a copy of the basic information of all active (not completed) process instances. Consequently, the memory footprint of PAPI clients depends on the number of active instances and the number of connected clients. We will discuss this in detail in future articles .If the PAPI client is not designed as a back-end service -- a command line application, for example — it is important to adjust the configuration to minimize the initialization overhead. It may also be necessary to disable the instance cache.

BPM Workspace web application
BPM Workspace is the most important end-user application. The BPM Workspace is to Business Processes what Outlook is to email: the main interaction application. For an overview of this application, please read the documentation. BPM Workspace is a PAPI client, but it has additional functionality that is important to understand. From a topology perspective, it is a healthy practice to have BPM Workspace always available, at least to do manual exception handling in the Business Processes. BPM Workspace provides lots of functionality on top of PAPI: support for screenflows, dashboards, custom page layouts, etc. The application also supports a lot of UI customization through stylesheets and other configurations. Authentication and Single Sign On are important BPM Workspace considerations. BPM Workspace can trust the Web Server (Tomcat, WebLogic, etc) to authenticate and connect remote users. We will cover the topic of security in depth in future articles.

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.

  • The Process-WS service exposes certain Business Process activities as web service operations. In particular, it can be used to create new process instances and send notifications to existing process instances. Business Process activities must be explicitly marked as exposed to be added to the service. Technically, this service is provided by the BPM engine itself. Upon engine start-up, it reads all process definitions and finds which activities are marked. The interface exposed by this service is defined by the arguments of the exposed activities (creation and wait notification), which means the service interface is directly related to the process definitions.

  • The PAPI-WS service exposes most of the operations of PAPI through a SOAP interface. This service is provided by a separate PAPI-WS web application. This application is deployed as any other web application, and creates a web service wrapper around PAPI functionality. The PAPI-WS service is also in turn a PAPI client, because it uses that API. The interface exposed by this service is similar to the API, and it is independent of the deployed processes. PAPI-WS can interact with any process deployed in the environment.

Administration clients

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.

  • The BPM Process Administrator provides configuration and administration for Organization, Engines, External Resources, and most importantly, Business Processes, and is used to deploy Business Processes to BPM Engines. In addition to the technical configuration of the BPM Directory connection, the BPM Process Administrator also handles configuration for the rest of the environment.

  • From a technical point of view, the BPM Process Administrator requires connectivity to the directory (in order to administer the directory) and to the BPM engines in order to monitor and control them (stop, start). The BPM Process Administrator can also create the database schemas required by the BPM Engines, BAM, Data Mart, and Archiving Viewer.

  • The BPM Workspace Administrator application is responsible for configuring Workspace (PAPI) views and presentations available to Workspace users. It is used mostly by business owners or administrators who want to provide customized, role-based views and presentations to users. For example, it can provide a monitoring view for managers and a prioritized work queue for those in non-managerial roles.

  • The BPM Archiving Viewer is a web application that is used to view archived process instance information. This information was moved out of the BPM Engines and into the archiving database.

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?
There are no product restrictions on the number and type of BPM clients working in a BPM environment. Those decisions are based entirely on the environment's architecture. Most environments will only use BPM Workspace, while others may elect build their own end-user UI, either using PAPI or web services. A third option is to write back-end services that perform specific operations on processes, such as creating an instance when a message arrives at a queue. One point of interest in these distributed environments is the synchronization of information across the different components. For example, if a process instance is updated by a task executed in the BPM Engine, the updated state of the process instance must be propagated to any PAPI client that might be listening for updates. Another example is that if a new process is deployed, it should appear immediately in BPM Workspaces and be available for use. The frequency and method of updating the different components of the environment are important considerations in properly enabling changes in the environment. This subject, too, will be covered in detail in future articles.

Supporting services

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:

  • Required for each BPM Directory:
    • Directory metadata (process definitions, engine configuration, authorization, and organization)
    • BAM - if the feature is enabled
    • Data Mart - if the feature is enabled
  • Required for each BPM Engine
    • Runtime information (process instances, audit trails)
    • Archiving - if the feature is enabled (same schema can be shared)

Database Support
Each of the schemas listed above requires its own connection information, independent of the other schemas. While it is common to have all the DB schemas in the same database server, this is not required. An environment can use different database servers, even from different vendors (Oracle, DB2, etc).Essentially, configuration parameters are similar for all of the above cases. There is no difference between directory and BAM configurations. Clustered databases (like Oracle RAC) are supported, with some additional configuration, but there is no difference for the clients .Configurations using database versions other than those specifically supported by Oracle BPM may be viable, though that viability depends entirely on the JDBC driver capabilities bundled with the database product and the application server (if applicable). Problems encountered on such platforms are beyond the scope of Oracle BPM support — unless the specific problem can be reproduced in an supported configuration.

Obtaining database connections
There are two ways a BPM application can obtain a database connection: directly, via the built-in JDBC drivers, or using J2EE datasources. Standalone applications like BPM Admin Center, Process Monitoring Service, and the Standalone BPM Engine always use JDBC drivers. J2EE BPM Engines always use J2EE datasources. PAPI Clients, such as BPM Workspace, can use JDBC drivers as well as J2EE datasources, depending on where they are running and how they are configured .In the case of J2EE datasources, configuration is done with J2EE configuration applications, such as WebLogic Console. BPM applications acquire datasources based on the JNDI name defined in the configuration.

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.

  • From a physical point of view, BPM Workspace still runs in a separate JVM, typically the built-in Tomcat server, and communicates with WCI remotely (the two components run separately). For the BPM Directory integration, WCI information is access in the same manner as with any LDAP provider.

WebLogic Portal Integration (WLP)
Integration with this portal is accomplished by creating a portal application that includes BPM Workspace portlets plus all the client PAPI libraries. This application is then deployed in WLP, and thereby incorporated into the portal.

  • From a physical point of view, the BPM Workspace portal application runs on the WLP Java process, in the same way BPM Workspace web application runs on Tomcat or WebLogic.


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.

Technical Integration
From a technical point of view, LDAP becomes part of the directory metadata, so any application that requires access to the BPM Directory schema will also require access to LDAP (for example: BPM engines, PAPI clients, and Process Administrator).Since access to LDAP is read-only, anonymous access is used. Nevertheless, secure connection and authentication can be configured. LDAP connections are pooled to improve performance. Another LDAP feature normally used is authentication, using the simple user/password provided by LDAP. Process authorization information is never obtained from LDAP. Rather, it is stored in the BPM Directory schema. Also, there are options to administer organizational units (OUs) in BPM, rather than being obtained from LDAP.

Functional Integration
BPM defines users, groups, and organization units in a single, well-defined structure. This differs from how many organizations define those concepts, especially with regard to the relationships between elements. For example, Oracle BPM defines that a user can only belong to one organizational unit — a rule some organizations do not follow. Oracle BPM assigns roles to users and groups, while some organizations might assign roles to the organizational unit. It is important to understand that in every case the LDAP structure must be mapped to the BPM organization model. This mapping exercise is critical, and must be done to insure that the mapping between the organization and BPM structures is clear.

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
From a logical point of view, the BPM Engine Process Service basically exposes an RPC interface. This interface is exposed via different protocols, depending on the type of engine:

  • In Enterprise Standalone it uses a custom, high performance Java RMI protocol

  • In Enterprise for WebLogic and WebSphere, it is exposed as Enterprise Java Beans (EJBs), which use the application server protocol stack (WebLogic T3, IOOP, etc). These EJBs are part of the BPM Engine EAR application that is installed in the application server.

PAPI Clients automatically discover the location of the engines, and select the appropriate protocol based on the engine type.

Other BPM Engine Services
Another service exposed by the BPM Engine is Process-WS, which we described previously .The last service exposed by the BPM is the B2B service, which is used to communicate with engines from different organizations (environments, different customers; basically, different directories). This service is used internally between BPM engines when they need to interact with processes deployed in a remote engine.


The PAPI-WS application, already described in detail in this article, is indeed a service provider.

Connecting Services and Clients
Having already described components and services, let's now focus on describing the capability of connecting all these things together .In this section the objective is to enumerate and briefly describe the communication links between components. We'll cover the steps to configure these links in future articles .Oracle BPM allows many different topologies, ranging from simple and small configurations to high capacity multi-machine configurations. The possibilities to define environments follow some few simple rules. Once you understanding those rules it is easy to understand system configuration. As previously mentioned, it is possible to define multiple BPM Engines and multiple clients, both PAPI and Web-Service based. Let's take a look at the required connections between the components, and the necessary protocols .All BPM Engines and PAPI clients must have a connection to the directory. This is a DB connection to the metadata directory schema. If information about users and groups is read from an LDAP, all applications must be able to connect to the LDAP server.

Choosing a topology
Many factors can influence the selection of a topology:

  • Business Processes load: the number of process instances, activities in the process, and people interacting with the process

  • Leveraging existing infrastructures (e.g. WebLogic servers)

  • Leveraging existing knowledge (e.g J2EE, Java)

  • Corporate policies (e.g. separation of backend and frontend application)

  • Reliability, availability, and performance requirements

  • Cost: one is generally cheaper than two.

Topology Definition Guidelines
A few guidelines, as defined by product capabilities.

  • At least one BPM Engine must be defined. More can be defined, but they must all be of the same type (Standalone, WebLogic or WebSphere).

  • Processes can be deployed into any of the defined BPM Engines. Interactions with these processes (by clients and other processes) are unaffected by the by the engine on which they are deployed.

  • Each BPM Engine can be configured independently, and optimized for specific use cases, such as user-interaction or backend execution.

  • There can be as many BPM clients as required. Different clients can coexist (BPM Workspace, Java and Web Service clients).

  • BPM Workspace (and PAPI clients) can be in the same J2EE server as the BPM Engine, but they can also be in a different server.

  • PAPI clients (BPM Workspace, PAPI-WS application) can be deployed in clusters or server farms independent on the BPM engine type or deployment.

  • Each PAPI client can be configured independently, taking into consideration the PAPI and application-specific parameters.

  • PAPI clients can interact with any of the processes, assuming the underlying communication is configured properly (especially in J2EE).

  • BPM Engines, PAPI clients, and any BPM applications require connection to the BPM Directory.

  • BPM Workspace web layout (CSS, images) can be customized per deployment, by modifying the WAR file.

  • BPM Workspace user layout (panels, dashboards) are customized globally by role or user, and cannot be changed per deployment.

  • The BPM Workspace and the BPM Engine are applications that consume a lot of resources. The decision to locate them in the same target server or cluster has important performance implications.

  • Communication between BPM Workspace and the BPM Engine requires specific configuration, depending on whether they are in different clusters or domains. It is actually is easier to configure BPM Workspace when deployed in different domains, as opposed to different clusters.

  • Sticky sessions must be enable if load balancers are used to distribute loads between BPM Workspace applications.

We'll publish more guidelines as they emerge.

What's Next

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.