BPMN Versioning

Running BPMN models in a BPM system often requires to take care about the internal version of a BPMN model. This occurs, for example, in scenarios where you run multiple instances of an active process in a live system with different versions of the same BPMN model.

The Imixs-Workflow Engine provides a nice mechanism to manage different versions of a BPMN 2.0 model. This allows to setup complex production environments with different models and different model versions at the same time. A model version, which is placed as an extension element of a BPMN 2.0 model can be evaluated by the Imixs-Workflow engine:
imixs-bpmn-versioning
Continue reading “BPMN Versioning”

Microservice Architecture for Workflow Applications

With our new project Imixs-Microservice we now provide a solution to build workflow management applications based on a modern microservice architecture.

Imixs-Microservice encapsulates the Imixs-Workflow Engine into a microservice architecture. The service can be bound to any business application, independent from the technology behind. This allows business applications to change the business logic without changing a single line of code. Thus the state of a business object can be controlled through the workflow model.

Based on the comprehensive functionality of the Imixs-Workflow Engine the Imixs-Microservice is empowered to control business data in various ways. Imixs-Microservice can send E-Mail notifications, log business transactions and secures any kind of business data.

The Imixs-Workflow Modeller can set an ACL for each single state in a business process model. This allows the definition of highly complex business applications and waves a security layer around each process instance.

 

The Rest Service API

Imixs-Microservice provides a flexible REST Service API which can be accessed from any platform and any kind of application. The Web Service is based on JSON and XML objects and allows an easy integration in existing projects (Java, .Net, PHP, …). Once deployed a new Workflow Model can be defined using the Eclipse based Imixs-Workflow Modeller. Any business object can be bound to a new business process by posting a JSON or XML based process instance. The state is then controlled by the Imixs-Workflow engine and can be requested and updated in various ways.

Runns with Docker

DockerImixs-Microservice provides a docker image. This makes is easy to run Imixs-Microservice in a Docker container and provides a powerful way to integrate a full featured workflow engine into a microservice architecture. The Docker image can be used as a template for custom projects and provides a scaffold to start with a microservice achitecture.

 

Imixs-Workflow and Imixs-Microservice are Open Source projects and can simplify the development of business applications in various ways. The Imixs Software Solutions provides professional services and support for building enterprise workflow management solutions.

 

Building transaction save business logic

As I posted in my last blog about JSF and Transactioncontext, it is importend to keep the transaction context in mind when developing a business application within JSF. When you use the Imixs-Workflow Engine you normaly don’t need to think about transactions because Imixs-Workflow takes care about processing a workitem in a full controlled transaction context. But developing with JSF can lead into situations where the business logic is not allways encapsulated correctly in a single transaction. Look at the following example of an Imixs-Workflow web application based on JSF:

//jsf bean...
@EJB WorkflowService workflowService;
...
public String process(ItemCollection workitem) {
 workitem=workflowService.process(workitem);
 // evaluate result and trigger another process step...
 if (workitem.getItemValueString('department').equals('finance')) {
    workitem.replaceItemValue('$activity',APPROVE_BY_MANAGEMENT);
    workitem=workflowService.process(workitem);
 }
 ....
}

In this example, the process method of the front-end controller evaluates the result of a process step and calls a second process for the same business object. Now you have the problem that the workflowService will run in two separate transactions. As I mentioned in my blog this can result into unexpected database results.

When you are working with Imixs-Workflow, the solution is quite simple: Just put your business logic into Imixs-Workflow Plugi-In. Plug-Ins are always controlled by the WorkflowManager and called inside a single transaction. So there is no risk that your business process runs in an undefined context.

Imixs BPMN

Imixs Workflow is an open source project providing a powerful workflow engine to manage any kind of business process. The main objective of such a Workflow Engine is to control the states defined in the business process. The transmission from one state into another is defined by Activities. The typcial way to describe such a process flow is a state diagram. As the common standard the Business Process Modelling Notation – BPMN has been established in the last years.

BPMN Modelling

BPMN provides an easy way to describe a business process from the perspective of an user or a software system. In case of a human based workflow BPMN can also be used to describe the view from one or may users participating in such a process. In the following section we will demonstrate how to use BPMN to create a model for the Imixs-Workflow.

First of all you need to remember that one of the most important tasks of a workflow engine is to control the state of a business process. This means that a process instance can always be defined by its state. So the first step using BPMN is to model the states of a business workflow.

In BPMN there are only two predefined states known. The Start Event and the End Event. They are describing the begin and the end of a business process:

bpmn-modelling-example1

Each state between the Start and the End event can be described with the BPMN Task element. A Task describes not only the state of the process but also the general task which need to be performed in a specific situation. So we can extend the model by defining additional BPMN tasks to describe our states the process can take:

bpmn-modelling-example2

This example describes the states of a simple Ticket Workflow. The different states a Ticket can have are

  • Open a new Ticket
  • Processing Ticket
  • Solving the Ticket

Defining Events and Transitions

What we have done so far is an important step in describing a workflow model with BPMN. We defined all the tasks a business process can take and which can be identified by the workflow system to control the status of the process. Now we extend this model by adding new elements.

A business process typically defines activities which can be performed on a specific process instance. Each task depends on a state and defines a transition from one state into another. This is the workflow logic we need to design a complex business process. Using BPMN we can model this by using Gateways and Event Elements. A Gateway is used to define on ore many transistions from one state into another. A Event Element is used to describe the activity which can be performed by an actor during the workflow.  Lets see the next example:

bpmn-modelling-example3

Here we extended our simple state diagram with Gateway and Event elements to describe the activities in our ticket workflow.

If new ticket was created we defined the State ‘Open Ticket’. From this state we defined the events ‘accept’ or ‘close’ which can be triggered by the actor creating the ticket. When the event ‘accept’ is performed the state of the Ticket changes in ‘Processing Ticket’. Again we define a Gateway with now two possible transitions. When the event ‘solve’ is triggered by the actor the business process ends in the state ‘Solved’. If the event ‘reopen’ is performed we go back to the first state ‘Open Ticket’ to repeat the Workflow.

What you have seen here is a simple business process. We use the BPMN to describe the different states a process instance can have and also the Events which can be performed by an actor to process a ticket. A workflow system like the Imixs Workflow Engine can control the status of a process instance in the business model. Also the events triggered in this model can now be controlled by the workflow engine to change the states.

The Imixs Workflow System

The Imixs Wokflow provides a rich set of functions to control a business process and define the state of a process instance. In each change of a state triggered by an activity (task) Imixs Workflow updates a lot of properties of each singe instance. For example:

  • Read- and write-access to a process instance
  • Process documentation and process history
  • Ownership of a process instance
  • E-Mail notification to the next participant
  • Business-Rules to perform complex business logic
  • Versions of a process instance
  • Scheduled Events triggered by a timer
  • Summary and detail description of an instance
  • Form elements for a user frontend

These technical descriptions can be added into a workflow model and also in a BPMN model using the BPMN Version 2.0.

Read more about the Imixs Workflow technology at:

Imixs Micro-Service-Architecture

The Imixs Workflow project provides a REST API to access all resources concerning a process management system. This Interface was designed to access the Imixs Workflow from any external client. It provides methods to create, update and read workitems

In various projects there is a requirement to integrate external master data which is not part of the process management system. An example there for is the customer or address data located in a remote system.

To access such external data from the workflow application in a general and easy way we think about a generic  kind of micro-service-architecture to be used to access any external data. Continue reading “Imixs Micro-Service-Architecture”

How to migrate from GlassFish to WildFly

The Imixs Workflow Project was started in the early beginning of the JEE5 Specification. Since than all workflow components where tested on GlassFish V2 and V3. GlassFish is a great application server and still the Reference Implementation for JEE. So we recommend the usage of GlassFish for development and in production for our customers.

But since Oracle announced stopping commercial support for GlassFish and recommend there customers to use WebLogic in productive environments its time for open source projects (like the Imixs project) also look for alternatives. And the brand new JEE Server WildFly from RedHead is such an alternative. WildFly is based on the well known JBoss Application server and a promising platform for JEE Open Source Projects. In the following sections I will explain what is necessary to migrate a JEE Project form GlassFish to WildFly. Continue reading “How to migrate from GlassFish to WildFly”

Why we need Workflow Engines…

Building robust scalable business applications becomes more and more efficient since the Java Enterprise standard (Java EE) has reached a level where developers can concentrate on the business logic and not about all the backend stuff like database management or security issues.
So from this point it easy today to setup a new business application in short time with reasonable effort. The Java Persistence API (JPA) provides a natural way to map the business objects from the real world into a software system. The JAAS Standard makes it easy to add security. And with different connectors we can connect a business application also to existing applications to exchange any kind of data. So it seems that everything is prepared for developing big business applications. Why should we think about managing the business process? Isn’t it easy enough to add all the required information into our business objects as simple attributes? Continue reading “Why we need Workflow Engines…”

How to integrate Workflows into Business Applications

Integrating a workflow engine into a business application provides a lot of benefits in implementing a variable business process. The goal of such an integration is to find a flexible way changing the business process and the behaviour of a business application without reimplementing or changing a single line of code.

There are in general tree different kinds of possible integration scenarios. Continue reading “How to integrate Workflows into Business Applications”

Model-Binding versus Method-Binding

The common way to implement an Imixs Workflow application is to bind a business object to a workflow model and process it by calling the Imixs Workflow engine.

  @EJB
  WorkflowService wfm;
  ItemCollection workitem=new ItemCollection();
  .... 
  // set model data
  workitem.replaceItemValue("$modelversion", "1.0.0");
  workitem.replaceItemValue("$processid", 100);
  workitem.replaceItemValue("$activityid", 10);
  // process workitem
  workitem=wfm.processWorkItem(workitem);

We call this a ‘model-binding’ because you bind your business object during the development of your application to a workflow model. This means that you typical first design your workflow model and after that you start implementing your application. So as a developer you know the model and can assign a possible workflow activity into your business object. Imixs Workflow provides different methods to compute the possible workflow activities during runtime so you are not forced to hard code the activities in your code.

THE METHOD-BINDING

But in some cases you might need to follow a different strategy. In a scenario where the modeling process takes place very late, you may not be able to bind your business objects to an workflow activity by assigning an activityID. This situation occurs when you first develop your business methods, and then need to link them to workflow activities of a workflow model. This means that the method call itself identifies the activity in the workflow model to be processed by the workflow engine. So each method call is bound to an workflow activity. We call it the ‘method-binding’. To provide an appropriate model, the process designer need to know the different business methods implemented from the workflow application. So he can bind the method-name directly to the workflow activities of a workflow model.

This kind of late binding enforces to work with Interceptor classes. This concept is a common way in Java EE to implement cross-cutting functionality. So the solution here is to intercept the call of a business method and find the corresponding workflow activity in a model. Then you can process the business object.

 

   @EJB
   WorkflowService wfm;
   ItemCollection workitem=findWorkitem();
   ItemCollection activity=findActivityByMethod(workitem,methodName); 
  .... 
  // set activityid
  workitem.replaceItemValue("$activityid", activity.getItemValueInteger("numActivityID");
  // process workitem
  workitem=wfm.processWorkItem(workitem);