Navigation
  • The MicroGuide to Process and Decision Modeling in BPMN/DMN: Building More Effective Processes by Integrating Process Modeling with Decision Modeling
    The MicroGuide to Process and Decision Modeling in BPMN/DMN: Building More Effective Processes by Integrating Process Modeling with Decision Modeling

Entries in BPMN (15)

Saturday
Dec212013

Business Rules and Business Process Exceptions

Often a business process team will create a working prototype of a business process. These prototype might arrise from 'use-cases' or business cases.

This idealized process develops a deep understanding of the final version, yet much of the important work remains. You should even consider executing this development artifact in a test bed. Yet to complete a business process, the technical team should detail the process diagram with the necessary scheduling, exceptions and compensations. The purpose of the details is to erect a more complete process model. The business processes should act on all the messages, including the system failures. The process should handle every anticipated exception.

There are 3 types of exceptions may affect process execution:

 

  • Technical exceptions
  • Transient exceptions
  • Business exceptions

 

As we will see, business rules can create, named business exceptions. If the BPEL is transactional, the process should compensate for transactions that fail to complete. In compensation, the process cleans up or backs out records from ERP’s, operational datastores or data warehouses.

Often processes should be complete within a time period, so there could be time out actions noted on the diagram. Business processes usually receive a message and translate that message into yet another message for consumption by the next part of the process. BPMN is powerful for developing time-outs, exceptions and compensations. As seen in the BPMN fragment below, you can attach time-outs, exceptions and compensations directly to a subprocess task list. When time-outs, and exceptions occurs within the two process tasks, the BPEL traps these at the point of the subprocess.

 

 

 

 

In this scenario, a grant authorization system evaluates grants and records the data. The time-out BPMN (the clock) will raise a time-out exception and wait. The diagram reports any exception that occurs (the zigzag) to the exception task. The compensation takes care of a record in the grant database.

You can model BP’s with advanced abilities that suspend processing, or communicate with disconnected, mobile processes. They can add new technology such as RFID. These powers yield opportunities for the enterprise to fine-tune their most complicated practices. Yet to develop these capabilities you should understand how BPM tools use the three types of exceptions and what you must plan for when developing the production version of the process diagram.

A process diagram should use exception handlers to redirect the process flow in case a transient or business exception happens. However, no process can manage every exception. There are technical exceptions that will cause the entire process instance to suspend.

 

Technical Exceptions

Technical exceptions occur when the process causes the BPMS instance to fail. An internal server exception should be abnormal; however there are operational circumstances that cause these. Technical exceptions include

The common Java Null Pointer exceptions
Exceptions caused by Illegal Argument exceptions, (suppose an external operational system decides to change a field from 10 to 20 characters)

Server database exceptions, out of tablespace, violation of database constraints

These are outside and therefore invisible to the calling subprocess. Processes cannot handle them because the execution state of the process has stopped. When this technical exception happens, the current transaction is always marked for rollback. The process throws the exception to the scheduler or message router.

Transient exceptions

A transient exception is usually caused by code external to the server like database connections or connection pooling exceptions. Within the scope of the current transaction, a transient exception is visible and the process can catch it with an exception handler. If the exception is not handled in the scope of the current transaction, the subprocess marks the transaction for rollback and throws the exception to the scheduler or message router. The process is suspended.

The suspended process can be restarted and resume processing after the database connection or some other condition is restored.

Business Exception

A business exception is one that can be expected by the process. Examples of these exceptions include:

Exception raised by an activity, a specific, named exception is raised, for instance a business rule could raise a named exception.

Exception caused by receiving an error message (like an SOAP fault). 

 

If the exception is not handled in the scope of the current activity, the activity fails. When the activity defined a coordinated transaction, the transaction is committed. When no exception handling takes place Exception processing begins and leads to compensation and the failure of the process.

Business Rules Decisions and Business Exceptions

Many organizations use BRMS to validate and transform incoming transactions. Validations and transformation are important types of 'decisions' that a business process makes with the data within process flows.

This is a common decision pattern: evaluate a set or transactions, say from an incoming data set. Each record that fails the validation should be stored in an area for latter cleanup. You can either handle the validation directly, with values in the process flows or you can raise a business exception, create a reusable process for handling the exception and move on. Another common decision pattern validates user form input, in a workflow. Users might correctly complete a form and send it to a process flow. If there are business rules that violate complex data and business conditions, the process should collect data from the user at a latter date.

Figure 2 is an example of what I am describing. A decision service validates incoming data. If the data does not pass validation, the subprocess raises a named exception, otherwise the record is processed.

The basic idea is to design your exceptions, time-outs and compensations to enlarge the flexibility of the process and allow most process to continue unattended. Handle the process and move on.

 

Diagram complexity

The complete business process diagram has many important exception features that must be accommodated. Unfortunately, these additional boxes and notations make it difficult for business users to understand. It would be nice if BPM diagramming tools would permit users to disable display of exceptions, compensations and timers attached to subprocesses. The tasks following these should also not be displayed. This would clarify the core nature of the process and create a more useful business engineering tool.

Friday
May172013

Process Interactions in Orchestrations and Choreography  

We have common definitions for process, business rules, operational decisions, business events and other things that are important to process modeling. And, I have mentioned my favorite ones (here). But we frequently ignore one of the very important aspects of process modeling: interactions. Fingar and Smith mentions in ‘Business Process Management, the Third Wave' that an interaction is the use of process desktops that allows people or participants to interact with the process. This includes workflow emphasizing assignment, task management and form-based data entry.  So, interactions gave rise to the idea of task oriented process instances that are started by a form. We see this in today’s process monitor and task list in most BPM suites. A form is a completed interaction that spawns an instance. This was, arguably, a new concept in 2002.


The BPMN 2.0 specification (here) also delves into the concept of interactions. Section 10.1 says that a public process represents the interaction between a private business processes and another processes or participants. The interaction is the glue. In the specification, human interactions are a type of task with human involvement. Manual and human tasks have particular icons in BPMN that indicate that human involvement is required to complete the task. See the two figures below.

 

The Human Task &  Manual Task

Remember: a manual task is a task that is expected to be performed without the aid of any digitized business process. An example might be the nurse delivering medication to a patient. This is contrasted with a user task which is performed with the assistance of a software application or is scheduled through a task list manager. An example would be the approval of a request or deciding a proposition.

Interactions are critical to the concept of choreography. A key characteristic of choreography is that it is an activity representing an interaction between two parties rather than a unit of work. According to Dumas, "The Fundamentals of Business Process Management”, the interaction can be one-way, where a message is exchanged or two-way, where messages exchanged bring a return message. Each message has an initiator and a recipient. Indeed, the BPMN spec states that "choreographies formalize way business participants coordinate interactions. This gives rise to the 'conversation' shape center defined in the spec.

In Wikipedia the interaction is defined as ‘a kind of action that occurs as two or more objects have effects upon one another’. This is fundamental in the concept of the business process.

Thursday
May022013

White Space in the Standards: Business Rules, Data and Process Modeling in BPMN

According to the Specification (here), BPMN is constrained to support only the concepts of modeling that are applicable to Business Processes. This means that other types of modeling done by organizations for business purposes is out of scope  for BPMN. Therefore, the following are out of the scope of the BPMN specification:

  • Definition of organizational models and resources
  • Modeling of functional breakdowns
  • Data and information models
  • Modeling of strategy
  • Business rules models

Since these subjects are critical to Business Processes, the relationships BPMN is supposed to be evolving. We also know that operational decisions need data to decide, so at this point BPMN is incomplete with respect to creating executable business processes. An executable BPMN diagram might be more complex — it is inadequate to create an executable specification.

BPMN has a data shape, the data object. A data object is a rectangle with the upper right corner folded over, as shown here:

The text label for a data object can be found underneath the shape.  Often the current state of the data object is shown as an attribute shown in brackets under the text label.  As the diagram progresses, the state of the data object can easily be read, as displayed in the Figure below.

Figure: Use of data artifact shapes.

As with the text annotation, the association line attaches the data artifact to another shape. Data Class shapes can be associated with tasks, gateways, events, sequence lines, or message lines.  In message flow, data objects portray the “payload” or content of messages.  

The use of data objects is optional.  Some diagrams may concentrate on flow, while others show the complete details Data artifacts do not directly affect the sequence flow or message flows.  Data objects provide additional information, some of it reflected in the XML schema, without changing the basic behavior of the process.  For instance, the Data Object elements can optionally reference a DataState element, which is the state of the data contained in the Data Object. The data object can detail the metamodel’s XML particularly with a ‘callableElement’. Uses the following additional elements:

  • ioSpecification,
  • inputSet,  
  • Data Input,

The data input and output are detailed in the purchase order approval example above. When a BPMN editor draws a Data Association to an Activity or Event it should generate this supporting invisible substructure.

As mentioned, the specifications are naive with respect to the origin mutation and alteration of data attributes. I've always maintained that this is the realm of business rules (mostly). That business rules through examination of data in order to decide Bolivian conditions controls specific aspects of operational decisions. Some of that data exploration includes analytics such as regressions, projections, and other techniques.

I believe the BPM industry needs to progress on standards with respect to business rules: the representation how they use things like Business Objects expressed in UM, and other expressions of the operational aspects of the business process. The BPMN specification pretty much admits weakness in this. So, even with the data input and output elements of BPMN, more needs to be done in order to specify a business process in a way that does not very important code aspects. The OMG spec on business rules (PRR) seems to be moving very slowly and it doesn't offer a clear connection to the process modeled by BPMN.

Sunday
Jul082012

Messages and Sequences in a ‘Requesting Feedback’ Process

In a linked-in question on the BPMN group, Lotfi Al-Hussami posed a basic modeling problem in BPMN. Quoting here:

“As an example, we have the following process that we will call "Get feedback":
- A company X "Send forms" to people by e-mails
- People fill forms, so every person receiving  the message "Fills form"
- Company X "Process forms"

At first glance this looks like a pretty simple problem to solve, as shown in the process below. If the process merely prepares the correspondence then our process, ‘get feedback’ will handle the messages as shown below: 

 

So the location of the intermediate event is dependent on what level the process is responsible for the messaging. Strictly reading the name of the first subprocess in our example the first example is probably most correct. Also, we are using the external black-box pool to denote the customer.

The Survey Pattern

In many cases, organizations want to aggregate feedback. Sometimes a process gathers data from an unknown number of participants. The process requirement wording might be:

  • Request feedback from at least %20 of the customers.
  • A minimum of 20 participants are required for the class to be scheduled.

The process does not know the number of instances of an activity at run-time. We can use a survey pattern when we don’t know how many responses or instances of an activity happen. Here the process must wait until all instances are completed. Then other activities start. Often, while some activities execute or are completed, new ones might be created- your process might ask for more responses. This

A Survey Process

The figure below presents a model of the survey, marketing or feedback scenario. In the example an email form invites a response from customers in the process. The loop awaits a satisfactory response, as determined by a decision. Here is a short description of the process:

  1. An incoming message starts a survey. The ‘email Recipients’ task send email to a mailing list.
  2. The survey process loops for incoming email. The results of the survey are tallied by the ‘survey decision’ activity, which calls business rules that decide the adequacy of the survey.
  3. A gateway decides if the survey results are satisfactory. Usually the gateway is optional. BPM tools specify the looping conditions.

 

The black box pool shows a notation, verticle bars, for multiple customer participants.

Other examples of the usages for this pattern include:

  • Getting bids for work from multiple trading partners,
  • Awaiting the delivery of multiple shipments from vendors to a facility before completing a process.

The multi-participant pools should be displayed in this case. You assign this pattern when the process must respond to multiple unknown quantities of events.

The elements of the pattern are:

  • A request from multiple sources by email, messaging, html or other sources
  • A loop that awaits the arrival of information from these sources
  • A decision to approve the survey and business rules for this decision: a call to the rules engine to decide when the survey response is satisfactory.

A process that receives the request and loops between the approver and requestor until the approver is happy with the request.

Cardinality is the Key

Returning to Mr. Al-Hussami example, process-oriented thinking should focus the requirements on a single instance of an interaction. So, a single survey form should be met by a single process response. We can compose a working, single-person survey into a more powerful pattern, such as the pattern that we have described here. When you are working with process requirements in BPMN, verify that you are thinking in terms of the singular entity, and then build your requirements from there.

 

Tuesday
Jun122012

Starting Processes Multiple Ways in BPMN

In BPMN 2.0, there are several ways to start processes with multiple events. There is a ‘multi-start’ event which looks like this:

 

Because they are abstract, multiple events can be hard to understand. Generally, a multiple event is "shorthand" notation for multiple events triggering a process. Triggers could include messages, timers, conditions, signals, escalations and other event types.

So, usually when a modeler is working with a requirement to start a process – multiple ways, we suggest the multiple-event gateway.  With event based gateways, a path is chosen based on an event. For example, "web form" is a possibility. Also, there could also potentially be no response at all. The Figure below shows an example of handling all three of these events from one gateway.

 

Multiple events on a event based exclusive gateway

The event-driven exclusive gateway can come in the start of a process, or in a sequence as an intermediate shape. When the gateway is at the start of the process, the event shape inside the diamond is the start multiple start event (single thin line). The figure shows the use of the intermediate, event-driven gateway after an ordinary start of a process.  The BPMN2.0 spec also has a starting form with a single thin circle at the center. We end the pattern with a data-based exclusive merge because with the ‘exclusive’ type of the multi-start gateway.

There is also an inclusive form of the event-gateway, but that is the topic for another conversation.