WebSphere Lombardi exception handling and logging


Exception handling is a programming language construct designed to handle the occurrence of some condition (exception) that changes the normal flow of execution. Handlers generally save the current state of the flow and execution and will switch to a predefined handler flow.

Business Process Modeling Notation (BPMD) supports exception handling constructs that you can use to model exceptional flows within the business process. The process author is explicitly responsible for creating the design time solution to deal with all types of exceptions. This requires a thorough understanding of all of the process' services, coaches, integration points, Business Process Definition (BPD) routing policies, and the business process itself.

In a well architected process, exceptions should not cause a process to fail; instead, the work flow travels down a path specifically designed to deal with that exception (the exception path). To model the ideal exception path, it is important to understand where potential exceptions can occur within the process or service.

There are two types of exceptions that can occur:

  • Process exception: This occurs when there is a problem with one of the components used by a process or service. Process exceptions are often caused due to temporary errors such as connectivity failure, timeouts, or design time code errors.
  • Business exception: This is an exception that occurs due to the outcome of a decision in the process. The actual process internally triggers this type of fault. A business exception is designed as part of a business process and is raised by the business process if the process cannot proceed due to:
    • Data validation failure
    • Insufficient privileges
    • Known business conditions on which the process should be put on hold

Business exceptions allow you to create cleaner processes and to define exceptional situations of the process as true exceptions.

Exception handling overview

The exception handling solution approach will be based on the following design considerations:

  • For a BPM application, business and process exceptions may need different handling mechanisms. Therefore, the approach should give the user a facility to handle these two types of exception independently.
  • Some of the process and business exceptions can be of trivial severity and should not cause the process instance to abort. The exception handling approach makes a provision for handling such non-fatal exceptions and allows the process to continue or retry once these exceptions are taken care of.
  • Business exceptions (and in some cases process exceptions as well) may need to be handled using an interactive workflow. The exception handling approach makes a provision for the developers to implement interactive sub-processes for handling exceptions.
  • There are no unhandled process exceptions. All the runtime exceptions are handled in either the individual activity, or in the process level depending on the type of the exception (whether it needs a retry or not).

WebSphere Lombardi has an out-of-the-box feature that deals with exceptions. The design patterns and best practices covered in this article will help make your solution more robust. Since exceptions can occur in both the Business Process Definition and service layer, there are different methods to deal with both types of exceptions. During exceptional situations, WebSphere Lombardi gives the calling service an opportunity to address the exception, such as:

  • Additional contextual logging information.
  • Passing additional information to the user.
  • Executing an alternate execution path.

Best practice indicates that exception handling should include retry logic (where possible) or routing the task to an administrator to resolve. WebSphere Lombardi has a default mechanism to model a business exception called the exception path. There is also a default mechanism to deal with process exceptions (commonly referred to as runtime) called the exception event.

Exception events

An exception event listens to run-time exceptions or throws an exception on behalf of the instance. You can use exception events while the process needs to raise a business exception.

The general rules while using exception events are:

  • Exception events can be “Attached” or “End”.
  • Attached exception events listen for exceptions, end exception events throw exceptions.
  • Exception events can only be attached to an activity.
  • If an exception occurs while the process is executing an activity to which an exception event is attached, the process flows along the sequence line that is attached to the exception event.
  • If an exception occurs and there is no exception event attached to the activity where the exception occurs, the exception is propagated up the Business Process Definition call stack until it reaches a nested process that contains an activity with an exception event attached to it, or until it reaches the top of the stack.

Exception handling using WebSphere Lombardi

Exception handling is the basic requirement of every application to handle any unexpected behavior of the application. The same can be done in WebSphere Lombardi with the help of exception events.

A typical exception handling scenario in WebSphere Lombardi is depicted in Figure 1.

Figure 1. Capturing an error message and Step ID that are passed to the exception handling activity
Capturing an error message and Step ID that are passed to the exception handling activity
Capturing an error message and Step ID that are passed to the exception handling activity

The different types of exceptions are system exceptions, process level exceptions, and business exceptions:

  • If an exception is due to a system level error, then let the error bubble up to the process level so that the exception can be caught in the process level. The system level error includes syntactical error, null pointer exception, web service timeout, database connection timeout, and so on.
  • If a process level exception occurs, then it is routed to the support lane or activity. The user of the support lane can view the error and act accordingly.
  • Business exceptions are also raised and explicitly routed to the support lane or activity instance. The user of the support lane or activity will rectify the error and send it back to the main flow.

Each activity of the process should be assigned a “Step ID”. An “Intermediate Exception Event” is attached to each step to identify the activity at which the exception has occurred. This is important as the process needs to resume at that activity once the exception has been handled. In the “Post Assignments” of the Intermediate Exception Event, the “‘Error Message” and “Step ID” are retrieved and stored in the process level variables.

If there is an exception at a particular step, the intermediate exception event catches the exception and passes it to the activity, which is designed to handle exceptions. The captured “Error Message” and “Step ID” are passed on to the exception handling activity.

Based on the severity of the exception, the exception activity can take one or more actions:

  • Log the message and return the control back to the activity where the exception had occurred.
  • Send an email notification and return the control back to the activity where the exception had occurred.
  • Pass on the details so that the support user can take action and then kick start the instance from the portal

"Step ID” indicates at which step the exception has occurred. “Error Message” has a detailed exception message, which is shown to the user at the Exception Coach in the Error Handling Activity.

WebSphere Lombardi logging framework

The logging solution detailed in this article is based on the Apache Log4j API and uses file-based logging approach.

However, the complete logging solution approach is based on following factors:

  • The logging needs to take into consideration requirements if they are already standardized or structured at the enterprise level.
  • Consider the amount of data required in the log (time, event, and user information) or additional information like payload, custom messages, and so on.
  • The level of logging can vary from process to process based on the urgency and needs of the process.
  • The logging data storage can be file-based or database-based, subject to requirements.
  • There can be an additional need for logging intimation, which can be in the form of an email to the support group to study the log if or when it is needed.
  • If a certain threshold is reached, consider backing up the logging files.

The solution uses standard features of WebSphere Lombardi to implement the logging solution:

  • Define logging objects.
  • Call the generic logging service.

Logging in WebSphere Lombardi

Logging is done using the following activities:

  • Invoke the log: A business process activity (generally the exception handler activity) invokes a log API. If an event or service call needs to be logged, create a logging task at the beginning and end of each service where logging is required.
  • Populate the wrapper object: The logger object is populated with relevant payload information. The object can generate process instance specific data, such as process name, current activity, current logged in user, and the current instance ID.
  • Call the customized logging service: This information is passed along with the log message to the WebSphere Lombardi generic logger service, which needs to be mapped. This service can also add features to send notification or intimation to the users of the log.
  • Call the WebSphere Lombardi generic logging service to log the information to the file: This is an in-built service in WebSphere Lombardi that is specifically used for logging. Based on the requirement, even this service can be customized. You can use the log service to set priority and, finally, make the entry into the designated log file as shown in Figure 2.
Figure 2. WebSphere Lombardi generic logging service
WebSphere Lombardi generic logging service
WebSphere Lombardi generic logging service

Exception handling guidelines

The following guidelines will help you to incorporate efficient exception handling in a Business Process Definition:

  • Do not clutter the most business-facing Business Process Definition with error handling, if possible. Keep in mind that exceptions and errors are typically technical concerns rather than business concerns. The only exceptions and errors that should be visible on the top-level Business Process Definition are the ones the business tells you about and cares about. This rule may carry down to sub processes, depending on how deep in the process the business is involved. Still, at some point, exceptions and errors will have to be handled properly.
  • Consider how hard it will be to "recreate" the business process instance. If it is trivial to recreate the Business Process Definition from the starting data, then failures have a lower severity, as an error can be handled by creating a new Business Process Definition instance with the same inputs. If it is difficult to recreate the Business Process Definition from the starting data (or even the current state data), then the impact of a Business Process Definition failure is much higher and should be given greater attention. In these cases, wrap the parts of the process that are most error-prone with appropriate error handling. This enables the use of “retry” logic if necessary.
  • Consider that the error handling in Business Process Definition is not the error handling in a COBOL mainframe program. In a Business Process Definition, errors can be routed to people, who are, after all, the key elements of the process. Think of how people can be leveraged to resolve errors, rather than letting a Business Process Definition fail or write to a log file waiting for an administrator to pick up. For example, one customer routes a task to an administrator to look at fixed-width data feeds when the data fails so that they can find the errant characters and fix or delete them. Another customer routes a task to a person when fixes cannot be properly recognized using the Optical Character Recognition (OCR) technology, which needs human interpretation. Who should the process notify when an error occurs, and does the notification domain depend on the type or severity of the error? Leverage people to preserve the business process when possible.
  • Consider when it is acceptable for the Business Process Definition to fail or end as a result of an exception or error. There are times when an error or exception path means that the Business Process Definition should end. Think about whether any such conditions exist for the Business Process Definition and implement them accordingly.
  • Keep the error handling simple. Do not over-engineer a common utility for error handling. Log the error as close to its occurrence as possible. If possible, route the process to a person who can handle the error. This routing may have been thought of and designed by the business, but perhaps not. Even a system administrator can have tasks routed to him or her. Keep the diagram as simple as possible, while still addressing the errors. If necessary, collect an activity and its attached error handling into a sub process to keep the parent process "cleaner."


This article discussed exception handling and logging from a BPM perspective. It identified the types of exceptions encountered in a BPM scenario and how to handle them using the out-of-the-box features of WebSphere Lombardi. It also discussed the default log on mechanism in WebSphere Lombardi.


The authors would like to thank Srinivas Bannigol for his help in reviewing this article.

Downloadable resources

Related topics


Sign in or register to add and subscribe to comments.

Zone=Business process management, WebSphere
ArticleTitle=WebSphere Lombardi exception handling and logging