Integration

Digg This!

This article is the second of two on best practices in building business processes on BEA WebLogic Integration 8.1. The first installment (WLDJ, Vol. 3, issue 6) focused on team development and maintenance best practices. In this article, we will focus on best practices in building business processes with scalability, recovery, exception handling, guaranteed delivery, and high performance. This article is intended for the developers and architects of WLI applications.

Process Versioning

Best Practice
Version the process files.

Reason
It's easy to overlook versioning because the process works without any version. But it is really important to version the processes, especially for long-running processes. When a process is upgraded, the in-flight instances will either be aborted if the processes were not versioned or the deployment will fail depending upon the mode on which the server is running. The process is aborted if the server is running in iterative mode and the deployment fails if it is running in production mode.

Details
Using WebLogic Workshop's versioning feature, you can make changes to your business process without interrupting any instances of the process that are currently running. When you version a business process, you create a child version of a business process that shares the same public URI (interface) as its parent. At run time, the version of the process that is marked as active is the process that will be accessed by external clients through the public URI.

You can version business processes, but not the individual controls associated with that process or other business process-related components, such as schemas and transformations. When you version a business process, you must also version the sub-processes of that process, they are not versioned automatically when their parent process is versioned. The version of sub-process that is called depends upon the version strategy applied on it. The two strategies available are loosely coupled (version is determined at invocation time) and strongly coupled (version is set at the time the parent process is invoked).

It is important to note that versions cannot be completely different because all of them are different implementations of the same interface. This implies that the versions should have the same request, callback methods, and static message broker subscriptions.

Exception Handlers

Best Practice
Create appropriate exception handlers for the processes. Create global exception handlers for all processes.

Reason
It is natural that at any stage of the business process a checked or unchecked exception may occur. Exceptions should be properly handled in the business process. If an exception is not explicitly handled, the process may be aborted and never retried. This may also result in unprocessed messages or lost messages.

Details
Exception handlers can be created at three levels.

• Global exception handler
• For a group of nodes
• For an individual node

In general, exceptions propagate upwards from a node exception path, to a group exception path, to a global exception path until they are handled. In other words, the exception path associated with a node executes first, then the path associated with a group, and then the path associated with a start node (global path). The exception is only handled once, unless your exception path throws an exception; then the exception propagates upward again in the same order. You can take advantage of this behavior and create exception path logic that satisfies the particular exception handling necessary for your business process.

For non transactional resources, compensating transactions can be done in the exception handlers.

Recovery

Best Practice
Set appropriate redelivery properties at the process level and/or JMS queue level.

Reason
Where there are exceptions in the process, the transaction is rolled back and the process may be aborted. If appropriate redelivery properties are not set, the message that started the process will be moved to the error queue. A message that is moved to the error queue will not be processed by the business process again. Instead, an internal message-driven bean will read that message and invoke the global exception handler of the business process.

A recommended approach to avoid this situation is to have high values for retry count and retry delay.

Details
The process level properties are:

• Retry count: Specify how many times, after the first attempt, the process engine should try to execute the business process.
• Retry delay: Specify the amount of time (in seconds) you want to pass before a retry is attempted

Make sure that retries and retry intervals are appropriate. Retries multiplied by retry intervals should exceed the time it takes for JTA recovery to run.

If you need to tune your retries and retry intervals, you have the following choices:

• Carefully set retry count and retry interval in your JPDs.
• Set the retry count and retry interval of the async and error queues for each JPD project (WebApp). Note that this will break explicit retry settings on the JPD, but it is the easiest and recommended approach.

Message Broker Channels

Best Practice
Prefer using a JMS header value than using a document member.

Reason
Using a header value is much faster than using a document element since no parsing is required.

Details
A message broker channel has similar properties to a Java Message Service (JMS) topic, but is optimized for use with WebLogic Integration processes, controls, and event generators. We recommed creating multiple channels instead of having multiple JPDs listening on a single channel with subscribtion filters.

Best Practice
Create a business process to consume messages in dead letter channel.

Reason
If the channels don't have subscribers or registered subscribers don't match because filter conditions are not satisfied, then the message is placed into the deadletter channel. If there is no subscriber for the dead letter channel, the message that is put on the channel is lost as it is discarded.

Details
When a message is published to a channel and no matching subscribers are found, the message is republished to the dead letter channel that corresponds to the channel's type. WebLogic Integration provides the following dead letter channels:

• /deadletter/xml
• /deadletter/string
• /deadletter/rawData

For example, an unmatched message published to an XML channel (that is, a channel that has messageType = "xml") is routed to the / deadletter/xml channel. At design time, the dead letter channels are available when you create MB Publish and MB Subscription controls. Your business processes can publish and subscribe to the dead letter channels. For example, you can use the dead letter channels when you design error handling - you can create a business process that includes static subscriptions to the dead letter channels and design error handling code to handle the unmatched messages published to those channels.

The Message Broker module in the WebLogic Integration Administration Console allows you to monitor and manage all of the Message Broker channels in your application, including the dead letter channels.

BP Transaction Boundaries

Best Practice
Keep transaction boundaries in mind while designing a process.

Reason
There are implicit transaction boundaries in the process that will affect the behavior of a process. If they are not considered, it may result in unexpected results. Adding transactional boundaries will introduce a quiescent point for the process definition.

Details
Processes in WebLogic Integration are transactional in nature. Every step of a process is executed within the context of a JTA transaction. A transaction ensures that one or more operations execute as an atomic unit of work. If one of the operations within a transaction fails, then all of them are rolled back so that the application returns to its prior state. Depending on whether you design your business process logic such that your process is stateful or stateless, there may be one or more transactions within the context of a given process.

When you build a process, implicit transaction boundaries are formed based on where in the process you place blocking elements, for example, a control receive or a client receive. The transaction boundaries within a process change as you add process nodes. You can also create explicit transaction boundaries by selecting contiguous nodes and declaring them to be in a transaction separate from those created implicitly by the application. Resources accessed by a process may also be part of the transaction, depending on the nature of the resource and the control that provides the access.

Some of the nodes that will introduce implicit transaction boundaries are

• Event choice
• Parallel nodes
• Control receives

Stateless Processes

Best Practice
Prefer stateless processes over stateful processes

Reason
Stateful processes are implemented as entity beans and are persisted into the database when there is a quiescent point.

Details A stateless process is one that is executed in memory only and does not persist its state in the database. In technical terms, it is compiled into a stateless session bean.

Stateless processes are intended to support business scenarios that involve short-running logic and have high performance requirements. Because it does not persist its state to a database, it is optimized for lower-latency, higher-performance execution. An example of a stateless process is one that receives a message asynchronously from a client, transforms the message, and then sends it asynchronously, or synchronously, to a resource using a control. Another example is a process that starts with a message broker subscription, transforms a message, and publishes it to another message broker channel. A common use case in the field is to model a long-running business transaction. This can be built as a group of stateless business processes loosely coupled by publishing messages to channels.

Since stateless processes are compiled into stateless session beans, they ensure that data members only contain non-instance-specific data.

You cannot explicitly configure a process to be stateless. By default, a business process is Stateless until you add any blocking construct to the data flow, such as waiting for a reply or a message. This, in turn forces a transaction boundary and the process becomes stateful. Therefore, a process is stateless if it runs within only one transaction.

Stateful Processes

A stateful process is a process that runs within the scope of more than one transaction. The process has persistent state in the database and is compiled into an entity bean.

Stateful processes are intended to support business scenarios that involve complex, long-running logic and therefore have specific reliability and recovery requirements. A process is made stateful by the addition of stateful nodes or logic that forces transaction boundaries (see Transaction Boundaries). For example, a process that receives a message, transforms it, sends it to a business partner, and then waits for an asynchronous response is stateful because the act of "waiting" forces a transaction boundary.

The list of nodes that, when used, induce a quiescent point are:

• Control receive
• Event choice (except as a start node)
• Parallel branching

Some controls typically require a control receive and therefore will force a process to become stateful. A non-exhaustive list of such controls includes:

• Worklist
• Timer
• Asynchronous two-way process
• JMS subscription
• Message broker subscription

Stateful processes, because they have state in the database, have lower performance than the memory-only stateless processes. However, the persistence of the state is necessary to ensure that:

The process can recover and continue execution without loss of data in the event of a system outage during this waiting period.

System resources are used efficiently during this waiting period. During this time, the entity bean may be passivated, which will free memory on the server.

You cannot explicitly configure a process to be stateful. You know when a process is stateful when the process start node at the top of your process has a green ring.

PARALLEL NODES

Best Practice
Understand parallel nodes before using them.

Reason
Using parallel nodes alters process behavior implicitly. A parallel node changes the transaction behavior and state behavior of the process. Parallel nodes are also only logically parallel.

Details
Parallel branches of execution in a business process are logically parallel; physically the branches are executed serially by the business process engine. Business processes benefit from this logical parallelism when communication with external systems can involve waiting for responses from those external systems. While one branch of execution is waiting for a response, another branch of execution in the parallel flow can progress.

Parallel branches are synchronized only at their termination points. A join condition is defined at the termination of multiple branches to specify how the termination of branches terminates the overall parallel activity. Valid join conditions are AND and OR.

WebLogic Integration Database

Best Practice
Use separate schema (not physical database) for WLI database and application database.

Reason
This separates the WebLogic Integration tables and application tables so that different policies can be applied.

Details
Even if you have only one shared database, it is a good idea to use a separate schema (separate user) for WebLogic Integration and the application. Sometimes WebLogic Integration may create tables on the fly in development mode, which means that the WebLogic Integration user ID needs to create permissions, but the application database user is not usually given such privileges. This also separates WebLogic Integration tables and application tables, which helps in archiving and maintaining data.

Configuring Timeouts

Best Practice
Associate timeout paths to ensure that your business processes eventually terminates.

Reason
The event might never happen and the business process could be blocked forever.

Details
Timeouts can be set on a node, a group of nodes, or on the entire process. The timer on the start node starts when the process begins. The timer on a node or a group starts when the process reaches that point of execution.

Summary

The art of building software has changed dramatically in the last few years, and we don't see a single real-world project that does not use frameworks for specific modules. The projects being built integrate with disparate systems with different service-level agreements and business leaders expect visibility and management at the macro business process level. In keeping with this trend, we expect that business process management systems to become as pervasive as databases in the next five years.

In this article, we discussed best practices for building business processes in BEA WebLogic Integration 8.1, emphasizing characteristics such as scalability, recovery, exception handling, guaranteed delivery, and high performance.

References

BEA Weblogic Workshop Documentation: http://edocs.bea.com/workshop/docs81/index.html

BEA Weblogic Integration Documentation: http://edocs.bea.com/wli/docs81/index.html