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);

 

Why is Imixs Workflow distributed under GPL?

Since the early beginning of the Imixs Workflow project all results are subject to the general public license (GPL). This license grants the broadest freedoms for users. There are many software systems available with this license. The most popular is the operating system Linux or the database server MySQL. So we are all using this kind of software license. Remember, you can not go into the Internet without the help of Linux.

But when you take a closer look on the smaller parts of software systems – the frameworks – a lot of these frameworks are subject to a lesser general public license like the LGPL, the Apache or Eclipse license. The argument of the software vendors behind those software license is to encourage widespread usage and adoption. But this means also to enable adopters to restrict the usage of there software build on thus a framework. This all is common practice and I think there is no need to discuss the pros and cons. So why is Imixs Workflow distributed under GPL?

The idea behind the Imixs Workflow project is to provide organizations, companies and users with a flexible software solution, to manage their business processes. Business processes are subject to constant change. And a workflow management system must provide the opportunity to follow this change. Therefore, we think that the user of Imixs Workflow must be able to adapt their software solution to meet their own needs.
From this point of view there no reason to restrict the usage of the software in any way. And as the objective group of Imixs Workflow is the final user rather than the software developer we believe that the GPL is a better solution to achieve this goal.
We do not want to discourage ISVs to use the Imixs Workflow for there own software project. Every person including software developers are free to use the Imixs Workflow for there own project. But remember that it is your commitment to pass that freedom also to other users.

SINGLE SIGN ON (SSO) FOR BUSINESS APPLICATIONS ON LIFERAY WITH GLASSFISH

To integrate business applications into a Liferay portal infrastructure is a major challenge. One of the most common requests is a single sign on (sso). Once a user has logged into the portal he should also access business applications which run outside the portal container.

With a new implementation of a “Imixs Login Module” it is now possible to integrate business application seamless into Liferay portal. The module makes use of the Liferay API to validate the user session and enables applications to authenticate users on any Java Enterprise application running in a Java EE 6 sever environment. The login module is implemented on the JSR-196 specification with is a standardized authentication mechanism for Java EE.

With the help of the Imixs Login Module it is not necessary to setup a complex single sign on server infrastructure. The Login module allows to use the existing user management of Liferay Portal server. We have tested the login module with GlassFish Application Server 3.1 and Liferay 6 on Windows and Linux plattform.

NEW JAVA EE 6 WORKFLOW ENGINE

With the latest release 3.0 Imixs provides now the first full Java EE 6 compliant workflow engine. The BPM solution can be used together with any of the newest Java EE web- or application servers like Glassfish 3.1, JBoss 6 or Geronimo.

Imixs Workflow focus on human based workflow typical used in organisations and enterprises. The Imixs Workflow provides users with all necessary information during a business process, like task lists, a process documentation or messaging features. The workflow management system helps users to start a new process, finding a document and complete running jobs. Continue reading “NEW JAVA EE 6 WORKFLOW ENGINE”

RELEASE 3.0 STARTED

We are now starting the next release of the Imixs Workflow 3.0

See: http://java.net/jira/browse/IMIXS_WORKFLOW-90

The general idea behind the new 3.0 release was to make use of the new EJB 3.1 container features. Because the current Imxis EntityServiceBean is in some methodes a little bit deprecated. One reason was the early implementation in the beginning of JEE5. The JPA methods are optimized for Toplink Driver which is no longer supported. So its time to make an Update!

General requirements for the new Workfow Engine

  • Replace the Entity Bean based on ItemCollection with a Map Interface
  • Use of EJB 3.1 features (JPA Map Feature)
  • Simplify the packaging (Light EJB API)
  • Optimize Scheduler Feature (persist settings in a entity)
  • No changes to the Workflow Service API – to make migration easy

Migration

A Migration is necessary as one of the main goals is to pesist no longer the ItemCollection Object but a simple portable Map Interface.
So we need a way to migrate application from Version 2.x to 3.0. As we learned in migrations from 1.x to 2.x this is not an easy work.
The goal of the new migration strategy must be a background migration.
So a tool should migrate workitems from a old datastorage into a new one running independed of a productive workflow app. This can be done by monitoring the $modified timestamp. As we know most of the data will not be changed during migration this can be done easily .