Skip to Content

    Generally, you start implementing your business process by modeling the so called ‘happy path’ – the execution flow if everything works as expected. Then you start testing and things start misbehaving and only then do you start patching the flow. Most of the time it is something simple, like a wrong mapping for instance, but when it comes to exceptions there are several conceptually different approaches which can be used.

    An excellent presentation on types of exceptions and common patterns for handling them in BPMN can be found on the SAP Developer Network, Exception Handling Patterns. The pattern outlined in this article can be viewed as an upgrade of the one for handling system faults from the presentation.

Introduction

    System faults are, by definition, caused by a technical problem somewhere along the execution path and are not related to business logic. This pattern deals with business exceptions – those are exceptions declared and thrown by client code. As such, it is important to note that in order to handle them with boundary events they must be declared as thrown by the web service.

Business exceptions

    Business exceptions, also known as client exceptions, are exceptions generated by client code and not by the underlying framework. As such, they relate mostly to wrong input rather than external events, but the latter are not excluded.

  
     We will be working with automated activities in BPM – web service calls which tend to be a weak point in such scenarios due to their nature. Web service invocations can fail in a variety of ways.

The pattern – Human Exception Handling

    Say that a service invocation failed in your already productively running process in SAP NetWeaver BPM. What would you like to be able to do?

     You can always resume the failed process from the NetWeaver Administrator in which case the invocation will be retried but that is not always a solution. Sometimes you might want to resume the process because there are other parallel activities which should not be harmed but you don’t want to retry the WS invocation just yet – maybe wait for an external condition or modify the input. This is the case most of the times when the failing activity resides within a sub-process; you don’t want your entire process to fail just because of a single sub-process.

This is where the pattern gives you the freedom and flexibility to react in your own way, based on your scenario.

Exception handling pattern example

    As can be seen from the BPM model, if the automated activity executes successfully the process will just continue the main flow. If it fails, however, simply resuming the failed process doesn’t always fix what’s wrong and doesn’t necessarily provide you with a solution so you might need control over how things continue.

     The “Error Admin UI” human task above is just an example that signifies that control. You can do several things with that task – either display the error message, provide options for the administrator* whether to skip or retry service invocation or give the ability to modify the context if there is something wrong with the input.

*Administrator – this is an additional role that has to be introduced and might not be in the specification of your business process. It represents an application administrator, one that ensures the smooth technical execution of the application.

Implementation

    The implementation is quite straightforward – you just need to model around your boundary event from the automated activity. The example shows what the model might look like in SAP NetWeaver Developer Studio if you want to provide an option to skip/retry the invocation at an arbitrary time.

Summary

    We found this pattern to be of great use for weak points in the process and to provide a greater level of flexibility than SAP NetWeaver BPM provides by default.

 

The Author

Kristiyan is part of the NetWeaver CE/BPM Integration Projects team at SAP Labs Bulgaria. The team has years of experience developing customer-like Composite Applications. Implemented scenarios are focused on Business Process Management and working on complex hardware environments with heavy integrations with other SAP solutions like NW MDM, NW PI, ERP and others.

To report this post you need to login first.

Be the first to leave a comment

You must be Logged on to comment or reply to a post.

Leave a Reply