Administration of Oracle BPEL Server

A majority of organizations adopting the Service Oriented Architecture (SOA) are employing Business Process Execution Language (BPEL) as a standard for business process flow orchestration and application integration. My personal experience is limited to the Oracle (BPEL) Process Manager; however these administration concepts are quite generic and can be applied to other BPEL environments as well.

Oracle BPEL system is not a single server but instead an ecosystem of various servers. The BPEL ecosystem is considered to be down if any of its constituent elements are down. Hence monitoring the Oracle BPEL environment means monitoring each of the below entities:

BPEL Processes and Partner Links

Monitoring the health of BPEL processes is critical to meeting service-level agreements for your processes. You can probably ensure availability and meet service-level requirements by ensuring performance and functioning of the partner links your BPEL processes depend on and identifying problems in a proactive manner. The best approach is to automate tests to be performed at regular intervals and warn the admins when a particular partner link has an unscheduled service shutdown or a longer-than-expected response time.

BPEL Engine

The health of the BPEL engine is critical for your applications. Besides the status of the BPEL engine, you should also focus on statistics such as memory; CPU consumed; and business metrics such as open and closed instances, synchronous and asynchronous process latency, and load factors.

Dehydration Store

The BPEL engine stores process data in the dehydration store (typically a relational database). If you want high availability for your dehydration store, you will probably use a clustered database. Your database administrators should make sure that the database is available and performing properly.

Authentication Server

This is the server against which all your service access is authenticated. If the authentication server is down, none of your services will be usable. Hence, it is important that the authentication server is setup in a high-availability mode as well.

The Application Server on which the BPEL server is running

A typical BPEL engine runs in an application server environment. For example, Oracle BPEL Process Manager can be deployed on a J2EE-compliant application server such as Oracle Application Server, Oracle WebLogic, IBM WebSphere, or JBoss Application Server. The BPEL engine may depend on several resources and services provided by the application server, such as JDBC DataSource, JMS providers, JCA connectors, and shared libraries. The health of the application server, along with the performance of these resources, may directly influence the performance of your BPEL engine. Each application server provides several health indicator metrics. You should automate a mechanism that would proactively issue an alert before anything goes wrong with your application server.

All the activities described above can be summarized as a set of best practices followed to ensure the availability of your BPEL infrastructure:

• Establish service-level objectives for your BPEL processes and partner links.
• Keep a library of BPEL suitcases in your software library. It will help in rebuilding a system in case of server failure.
• Automate routine operations such as purging old process instances.
• Monitor the performance of partner links.
• Monitor the whole BPEL ecosystem, not just the BPEL engine.
• Keep track of BPEL ecosystem membership/topology changes.
• Keep a gold image of your configuration when everything is stable and keep updating it after every configuration change. This will help you find the cause of any possible problem due to configuration changes.
• Monitor BPEL server-specific J2EE artifacts such as the JMS queues and data sources used by the BPEL server in addition to J2EE constructs used by BPEL processes.
• Make sure that you select a management solution that can maximize your productivity and help you deliver maximum service through automation.