In my last blog I explained the core concepts behind the Microservice Saga Pattern. In this blog I will address the problem from a more practical perspective by demonstrating how Imixs-Workflow can be used as a Saga Orchestrator within a Microservice architecture. First, I would like to give a brief review of the main concepts of the saga pattern. Later I show some implementation examples.Continue reading “Microservice Saga Pattern with Imixs-Workflow”
Everyone is talking about cloud technologies and of course every modern project relies on a microservice architecture. A variety of technologies and methods contribute to the success of this architecture pattern. But what does cloud native actually mean for the business world? How do companies and organizations implement business processes successfully beyond the big technology promises?
The basic idea of a microservice architecture is to break down the technical requirements of a software system into the smallest possible and therefore manageable services. The advantage: services created in this way can be developed independently of each other with different technologies by different teams. At the same time, we see new methods and technologies to connect, monitor and scale these services.
But just looking at the technology does’t mean that software can be developed faster and better. I would therefore like to compare some of these methods and technologies from the microservice architecture with the requirements for the development of business applications.Continue reading “Cloud Native and Business Transactions”
With the latest version 5.1.0 the Imixs-Workflow project introduces a BPMN based Rule Engine.
The BPMN Rule Engine uses Conditional Events to evaluate a business rule. This is a powerful mechanism to describe rules in a BPMN model and evaluate a given workitem.
The BPMN Rule Engine provides an easy way to describe also complex business rules based on a visual model. The rules are evaluated as a chain of conditional events. The engine evaluates the data of a given workitem.
To initialize a BPMN Rule Engine a Imixs BPMN Model instance need to be loaded first.
bpmnRuleEngine=new BPMNRuleEngine(model); workitem = new ItemCollection().model(MODEL_VERSION).task(100).event(10); workitem.setItemValue("a", 1); workitem.setItemValue("b", "DE"); // evaluate rule Assert.assertEquals(200, bpmnRuleEngine.eval(workitem));
The model instance can either be taken from a running instance of the Imixs-Workflow engine or loaded on demand from the file system:
// load BPMN model from input stream Model model = BPMNParser.parseModel(inputStream, "UTF-8");
The workitem can contain any kind of data to be evaluated by the business rules. Internally the Imixs BPMN Rule Engine is based on the Core-RuleEngine which supports various script languages to describe a rule.
More details about the Imixs BPMN Rule Engine can be find on the project site.
With the upcomming version 5.0.0 the Imixs-Workflow engine is integrated into the Eclipse Micoroprofile API.
The Enterprise Java technology has evolved with the industry for nearly two decades to support distributed application architectures based on RMI/IIOP, Web Services, and REST. The MicroProfile is the next step in that evolution. Since Imixs based on Java Enterprise technology stack, it is consistently to expand the technology to the new standard. As a developer this will bring you more features and a much smarter way to run the Imixs-Worklfow engine within a microservice architecture.
The Version 5.0.0 will provide the following APIs:
- Metrics – This allows you to monitor Imixs-Workflow with Tools like Prometheus or Grafana
- Health Check – The Health Check API can be used to probe the state of an Imixs-Worklfow instance from another machine (i.e. a kubernetes service controller)
- Config API – Configuration data can now come from different locations
We will provide soon more documentation and examples on how you can run Imixs-Workflow in a Microservice Infrastructure. If you have questions please joint our community!
The hexagonal architecture is a design pattern introduced by Dr. Alistair Cockburn.
A hexagon is a closed body and according to his pattern, an application is assumed to be a hexagon. Whatever is relevant to the business logic of an application gets to reside inside the hexagon and the rest is arranged outside. In this way, the business logic can be easily tested without worrying too much about external factors. So and this matches perfectly into the world of microservices.
The ‘Business Process Model And Notation’ standard is a well designed notation for describing business workflows. BPMN 2.0 becomes the standard for modeling business logic and fits very well the model driven software design in agile software projects.
The BPMN language, which is based on XML, was intended for users at all levels, from the business analysts who create the initial design, to the developers who implement the technical details, and finally, to the business users responsible for managing and monitoring the processes. BPMN 2.0 has evolved to become a complete specification trying to fit the needs to all people involved in the design of a business process. But writing BPMN in XML and visualizing business processes becomes nearly impossible without the use of a graphical tool.Continue reading “BPMN 2.0 – The Extension Mechansim”
In the following short tutorial I will explain how you can manage multiple versions of a workflow model and how Imixs-Workflow supports multiple model versions in a productive business application.
The Imixs-Workflow engine supports multiple model versions from the same process model. Each time a running process instance is updated, the Imixs-Workflow engine applies the same model version as the process instance was created with. Therefor the Imixs-Workflow engine compares the internal model version with the model versions provided by the model repository. In case the current model version is no longer supported, the active process instance will be automatically upgraded to the latest version available in the repository. With this feature it is possible to manage different versions of the same workflow process. To distinguish different model versions, you need a versioning concept.
The concept of “Semantic Versioning” from Tom Preston-Werner will be the basis for the versioning method of process models. Applying the semantic versioning, the version number is separated into three digits:
1. 2. 3 | | |-- patch level | |-------- minor version |-------------- major version
The first digit indicates the major version number. This is in our case the general main release of a model. The major version number should only be increased if a general redesign of whole the process model was done.
The minor version number is used for new functions and enhancements in the process flow. For example after adding a new task or a new event, the minor version number should be increased.
The last digit is used for the Patch Level of a model. It indicates bug fixes or changes of naming or wording.
The semantic versioning can be perfectly used for the BPMN model file. This helps you to manage different version within your modellng tool:
We typically prefix the filename with the process name to maintain different workflows in the same directory. In the example above we have an Invoicing workflow in the version 1.0.0. The model file itself should also be stored in a code repository like Git. This allows you to remove deprecated models from your code base.
The Model Version
Also the Imixs-Workflow Model holds a separate version number. This version number is mandatory and can be maintained in the Workflow Profile of the Imixs-BPMN modeling tool:
We prefix the version number again with the process name followed by a two-digit version number. Applied to the “Semantic Versioning” only the Major and Minor Version number is used here!
The reason for this shorter version number is, that the model repository of a business application should not hold different patch levels of the same model. Remember, the patch level is only used to indicates bug fixes or changes of naming or wording. Only if the model is extended functional the minor version number is increased or in case of a new process variant the major version number:
Modelversion File Version Comment ---------------------------------------------------------- invocing-1.0 invocing-1.0.0.bpmn First draft invocing-1.0.1.bpmn typo invocing-1.1 invocing-1.1.0.bpmn additional approval invocing-1.1.1.bpmn change mail message invocing-1.1.2.bpmn change history text invocing-2.0 invocing-2.0.0.bpmn new Invoicing process
In this example version 1.0 of the Invoicing process was first patch with a typo and next extended with an additional approval, which leads to Minor version 1.1. In this version again then some text changes were made. And finally a complete new Invoicing process was designed, with leads to the new Major version 2.0.
From the view of the running process instances only 3 different model versions exist. From the view of the code repository the model file exists in 6 different versions.
With the concept of “Semantic Versioning” process models can be easily handled in different versions. Even if you need to patch an already running model, you don’t need to worry about polluting the model repository of your business application if you use only 2 digits for internal model version.
In this short tutorial, I would like to show you how you can run a human cenctric workflow engine on Jakarta EE. Jakarta EE is the successor of Java EE and like the previous version, Jakarta EE offers you a full stack Java platform for enterprise applications. The Open Source Workflow Engine Imixs-Workflow is based on this platform from the early beginning of Java EE.
Imixs-Workflow provides you with a powerful, scalable and transactional workflow engine for Java Enterprise Applications. You can embedded the workflow engine in your Jakarta EE project or run the engine as a Microservice based on Jakarta EE.
The idea of the project is to move most of the usual business logic into a model. As a result you can change and optimize you application in a model driven way. The project supports the Business Process Modeling Notation (BPMN 2.0). BPMN enables you to describe your business process from different perspectives. You can describe the organizational aspects just to give people an understanding of your process. And you can as well model the technical details to execute your process with Imixs-Workflow engine. Continue reading “Tutorial: Imixs-Workflow and Jakarta EE”
With the latest version of Imixs-Workflow we support now a consistency Lucene search index coupled with the Java EE container based transaction concept.
Writing a Lucene Index during a Java EE transaction, coupled to JPA database operations, it becomes quickly difficult to keep the Lucene index consistent. The reason is that a lucene index can become inconsistency if you write the lucene index within a long running Java transaction. In case the transaction fails lately, there is no way to roll back the already written lucene index automatically. This is different to the build-in roll-back functionality of a SQL database which is only writing new data in case the transaction succeeds. Also clients reading the index before a running transaction is closed will read uncommitted index data which will lead to wrong search results. Continue reading “Lucene Index Consistency”
Within the Imixs-Workflow project we started our first sample application based on the new Jakarta EE web framework MVC 1.0. The sample application demonstrates how an Imixs-Workflow application can be build with MVC 1.0.
The interesting thing here is that you only need a few lines of code to get the full functionality of a human-centric workflow engine. This is possible because in addition to the existing Jax-rs Rest API, the Imixs-Workflow engine provides services which can be easily adapted by the core concepts of an MVC-Application. Continue reading “First MVC 1.0 Workflow App”