Imixs-Workflow is the first open source workflow engine running on Jakarta EE 9. The latest version 6.0 can be run on every modern application server supporting the new cloud native industry standard. This allows you to digitize your business processes in a modern, portable and open IT environment.
Jakarta EE is a set of specifications that enables the world wide community of java developers to work on cloud native Java enterprise applications. Imixs-Workflow integrates into this technology and provides you a powerfull, stable and sustainable way to map your business processes according to the BPMN 2.0 standard.
For many years, Java EE has been a major platform for mission-critical enterprise applications. Imixs Workflow was founded on this technology from the first beginning. In order to accelerate business application development for a cloud-native world, the Java EE specification moved to the Eclipse Foundation enabling a community-driven collaboration and a more open innovation.
Version 6.0.0 and Java 11
With version 6.0.0, Imixs Workflow adapted the existing technology to the new Jakarta EE 9 specification and modernized various areas of the open source workflow engine. At the same time, with this release, the switch to Java 11 is now completed.
Rule Engine based on GraalVM
The integrated business rule engine of Imixs Workflow is now based on the GraalVM technology. With the new rule engine, business rules can now be written in different popular languages and can be combined with additional features and libraries. This allows the design and the execution of more complex business processes based on the BPMN 2.0 standard.
With the Jakarta EE 9 application ‘Imixs-Process-Manager‘, the Imixs Workflow project provides a reference application for a quick start. The project is hosted on Github.
Imixs Workflow is 100% open source and we invite you to participate in it. There are different ways how you can do that. Join the Imixs Workflow Project now on GitHub. You can help to improve the project by reporting bugs or start a new discussion.
The real-time processing of a continuous stream of business data and events is becoming increasingly important in modern IT architectures. This type of architecture, in which events are building the centre of data processing, is also known as a Reactive Streaming Architecture. In the following we will show how to solve some of the related challenges with the help of a workflow technology.
Let’s take a closer look at this type of architecture first. Basically, the event-based processing of data is not new and has actually been developed for decades in various specialized domains such as the financial sector. But since the last few years, new standards for processing data streams have emerged. Technologies like Apache Kafka, Storm, Flink or Spark are gaining popularity and pushing a new hype.
From industrial production systems to multiplayer computer games, so-called Streaming Architectures are used more and more frequently in order to be able to process big data in real time. Streaming architectures have developed into a central architectural element of modern technology companies. In many companies real-time streams have become the core system in their architecture.
The goal is to be able to integrate new system solutions more quickly and to connect any kind of data streams. The streaming architecture is not only found at technology giants such as Ebay, Netflix or Amazon, but today in every modern technology company that is working on the digitization of its business processes. So what are the main challenges in building such an architecture?
For most self managed Kubernetes environments the SQL database is one of the most important infrastructure parts. Typically SQL database servers are not designed to run on distributed nodes in an environment like Kubernetes. One solution is to run a single SQL database in a Kubernetes POD with a distributed filesystem like Longhorn or Ceph. This works well for example with PostgreSQL in most situations. Of course this can have some performance impacts and requires fast SSDs. Another solution is to run a distributed SQL Database like Cockroach. With the latest version of the Imixs-Cloud project we now offer a smart solution to run a SQL Database cluster within a self managed Kubernetes cluster.
Note: CockroachDB does not support the isolation level of transactions required for complex business logic. For that reason the Imixs-Workflow project does NOT recommend the usage of CockroachDB. See also the discussion here.
CockroachDB is a distributed SQL database with a build in replication mechanism. This means that the data is replicated over several nodes in a database cluster. This increases the scalability and resilience in the case that a single node fails. With its Automated-Repair feature the database also detects data inconsistency and automatically fixes faulty data on disks. The project is Open Source and hosted on Github.
CockroachDB supports a lower level of ACID transactions. This means guaranteed atomicity, isolation, consistency, and durability of data is not the same quality as in a PostgreSQL database . However CockroachDB can be used in combination with Jakarta EE and JPA. Supporting the PostgreSQL wire protocol, CockroachDB can be used with the standard PostgresSQL JDBC driver.
With the latest update of the Imixs-Cloud project the Kubernetes cluster environment now also supports GitOps. GitOps describes a concept in which a git repository can be used for the entire management process of an application – from development to deployment to maintenance. With the directory structure of separate sub-directories for each application the core concept of Infrastructure as Code was already supported by Imixs-Cloud from the beginning.
Now the project integrates the Open Source project Argo CD in its tool chain. If you already have a Imixs-Cloud environment running you can start Argo CD within seconds. Just edit the ingress deployment with your own Internet domain and start the deployment:
In this blog I will explain how to setup and customize Wildfly to run your Jakarta EE application on Kubernetes. We use this setup in our own Open Source project to run modern Jakarata EE applications on Kubernetes. You can find this project on Github.
Wildfly is Jakarta EE 8 compatible and includes the latest Eclipse MicroProfile in version 3.3. It provides a modern application framework out of the box to simplify the development of web applications and microservices. All runtime services minimize the heap allocation and applications are starting very fast with a minimum of memory.
To setup a database realm (JDBCRealm) in Payara Micro is a little bit tricky because some settings have changed in the past and so there is no clear updated example. This blog post shows a configuration example for Payara 5.2 in combination with a data source based on the Workflow project Imixs-Office-Workflow.
The digitization of business processes has become a key challenge for organisations and enterprises. From the development perspective, essentially two things are needed for a modern application design:
a process description – created using the BPMN 2.0 standard
a runtime environment – to execute and persist business data in a secure way
With the Imixs Process Manager we are now releasing a new platform that combines the design and the execution of business processes in a highly scalable and easy to use environment. Organisations can start quickly and develop and test their own business process. And of course the open source platform can be customized and extended to be used for development as well as for production.
The Imixs Process Manager comes with a Docker profile that can be started within seconds in a containerised environment like Kubernetes.
A business process is designed with the help of the Imixs-BPMN modeller tool. New models are uploaded and executed directly within the Imixs Process Manager.
With the new build-in custom form generator, the Imixs Process Manager allows the definition of custom forms directly in a BPMN 2.0 model without writing one line of code. New forms are defined by a XML template which brings much more flexibility into the process design.
With the new release v5.2.0, the open source workflow engine Imixs-Workflow now supports the asynchronous execution of BPMN events.
This feature is a big step forward especially in a microservice architecture. The new so called AsyncEvents make it much more easier to decouple a Rest API call from the processing life cycle of the workflow engine. In this way the request-response pattern shows better performance and allows a very clear design of complex business processes.
The AsyncEvents were already part of the Imixs-Microservice project in a pre-release and become now a core feature of the Imixs-Workflow engine. Especially in more complex architectures, the use of the so-called SAGA Pattern is an important building block. With asynchronous events Imixs-Workflow is now supporting this design pattern as a core feature. Read also our blog about building powerful microservice solutions with the SAGA Pattern.
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.
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.