Author: rsoika

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:

Continue reading “BPMN Versioning”

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

Imixs-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.

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.