Welcome!

Weblogic Authors: Yeshim Deniz, Elizabeth White, Michael Meiner, Michael Bushong, Avi Rosenthal

Related Topics: Weblogic

Weblogic: Article

Building Business Processes Part 2

WebLogic Integration development best practices

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
  • More Stories By Vijay Mandava

    Vijay Mandava joined BEA as a technical manager in the Professional Services organization in 1999. He now works as a principal systems engineer in the Systems Engineering organization. Vijay is a Sun certified Java programmer and a BEA certified Weblogic Server developer.

    More Stories By Anbarasu Krishnaswamy

    Anbarasu Krishnaswamy has over 15 years of IT industry experience, nine of which were with BEA. In his current role as the Enterprise Architect Lead, he leads the enterprise architecture and SOA practices for the central region professional services at BEA. As a SOA practitioner, he has helped several customers with SOA transformation and implementation. His experience also includes design and development of Java/J2EE applications, client/server computing, Web development, and enterprise application integration (EAI). Anbarasu holds a MBA from NIU and an MS in computer science and engineering.

    Comments (0)

    Share your thoughts on this story.

    Add your comment
    You must be signed in to add a comment. Sign-in | Register

    In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.


    IoT & Smart Cities Stories
    In today's enterprise, digital transformation represents organizational change even more so than technology change, as customer preferences and behavior drive end-to-end transformation across lines of business as well as IT. To capitalize on the ubiquitous disruption driving this transformation, companies must be able to innovate at an increasingly rapid pace.
    Predicting the future has never been more challenging - not because of the lack of data but because of the flood of ungoverned and risk laden information. Microsoft states that 2.5 exabytes of data are created every day. Expectations and reliance on data are being pushed to the limits, as demands around hybrid options continue to grow.
    "MobiDev is a Ukraine-based software development company. We do mobile development, and we're specialists in that. But we do full stack software development for entrepreneurs, for emerging companies, and for enterprise ventures," explained Alan Winters, U.S. Head of Business Development at MobiDev, in this SYS-CON.tv interview at 20th Cloud Expo, held June 6-8, 2017, at the Javits Center in New York City, NY.
    The explosion of new web/cloud/IoT-based applications and the data they generate are transforming our world right before our eyes. In this rush to adopt these new technologies, organizations are often ignoring fundamental questions concerning who owns the data and failing to ask for permission to conduct invasive surveillance of their customers. Organizations that are not transparent about how their systems gather data telemetry without offering shared data ownership risk product rejection, regu...
    The best way to leverage your Cloud Expo presence as a sponsor and exhibitor is to plan your news announcements around our events. The press covering Cloud Expo and @ThingsExpo will have access to these releases and will amplify your news announcements. More than two dozen Cloud companies either set deals at our shows or have announced their mergers and acquisitions at Cloud Expo. Product announcements during our show provide your company with the most reach through our targeted audiences.
    Bill Schmarzo, author of "Big Data: Understanding How Data Powers Big Business" and "Big Data MBA: Driving Business Strategies with Data Science," is responsible for setting the strategy and defining the Big Data service offerings and capabilities for EMC Global Services Big Data Practice. As the CTO for the Big Data Practice, he is responsible for working with organizations to help them identify where and how to start their big data journeys. He's written several white papers, is an avid blogge...
    When talking IoT we often focus on the devices, the sensors, the hardware itself. The new smart appliances, the new smart or self-driving cars (which are amalgamations of many ‘things'). When we are looking at the world of IoT, we should take a step back, look at the big picture. What value are these devices providing. IoT is not about the devices, its about the data consumed and generated. The devices are tools, mechanisms, conduits. This paper discusses the considerations when dealing with the...
    Machine learning has taken residence at our cities' cores and now we can finally have "smart cities." Cities are a collection of buildings made to provide the structure and safety necessary for people to function, create and survive. Buildings are a pool of ever-changing performance data from large automated systems such as heating and cooling to the people that live and work within them. Through machine learning, buildings can optimize performance, reduce costs, and improve occupant comfort by ...
    Business professionals no longer wonder if they'll migrate to the cloud; it's now a matter of when. The cloud environment has proved to be a major force in transitioning to an agile business model that enables quick decisions and fast implementation that solidify customer relationships. And when the cloud is combined with the power of cognitive computing, it drives innovation and transformation that achieves astounding competitive advantage.
    With 10 simultaneous tracks, keynotes, general sessions and targeted breakout classes, @CloudEXPO and DXWorldEXPO are two of the most important technology events of the year. Since its launch over eight years ago, @CloudEXPO and DXWorldEXPO have presented a rock star faculty as well as showcased hundreds of sponsors and exhibitors! In this blog post, we provide 7 tips on how, as part of our world-class faculty, you can deliver one of the most popular sessions at our events. But before reading...