Imixs Workflow is a powerful BPM framework to build robust and scalable business applications on top of the Java Enterprise platform.
The latest release 3.0.3 provides a new Plug-In to integrate business rules in long running business processes. This Plug-In provides a new way to implement complex business workflows even faster.
The release includes also an update of the Workflow Admin Client to manage running process instances. The Imixs Workflow engine, which is based on the Java EE specification, provides a lot of enhancements concerning optimistic locking, exception handling and the introduction of additional remote interfaces.
Also the Imixs REST service API includes different enhancements which can be used togehter with workflow clients based on JavaScript frameworks like jQuery.
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);
IMIXS WORKFLOW ENGINE 3.0.2 FINAL RELEASE
Today we released the latest version of Imixs Workflow 3.0.2.
This release includes a lot of minor updates, bugfixes, and new features. It provides a new logging and exception API that makes a integration easier.
With a new security interceptor model, application-based dynamic user roles can be now bound directly into a process instance. The Imixs REStfull API offers now full support of JSON objects. It is now possible to exchange all business data in JSON format from a JavaScript-based client included in the Imixs-Script library. Also the management of multi workflow model versions is now improved.
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.
Business Applications with HTML5 and JavaScript
We started a new subproject called “Imixs Workflow Script!“. This project allows you to build workflow applications only using HTML and JavaScript! This is really cool and I believe it’s the most easiest way to develop web based workflow applications.
‘Imixs Workflow Script!’ combines the benefits of jQuery with the capabilities of the Imixs Workflow engine. Imixs Workflow Script! is a JavaScript library providing methods to interact with the Imixs Workflow engine through the Imixs RESTfull Service API. The Imixs Workflow engine is used as a back-end service deployed on a Java EE application server like GlassFish.
Including the script library into a HTML page, ‘Imixs Workflow Script!’ automatically detects certain areas and fills these areas with workflow data. Also the data of input fields can be posted easily back to the workflow server.
The Project includes a sample application showing how ‘Imixs Workflow Script!’ works.
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.
Workflow REST Service examples
With the Imixs RESTfull service interface it is very easy to access any workflow instance. The following section gives some examples which can be tested live using the Imixs Online Demo. To access the Web Service interface you need to login with the user ‘Manfred’ and the password ‘demo’ Continue reading “Workflow REST Service examples”
Mobile Workflow Apps
Today I would like to demonstrate how to build a HTML5 Web application for mobile phones. My example application will display business data from a back-end application provided by a RESTfull service interface. The data is in json format, which is a common data format especially for mobile applications. Here you can see the result:
HOW TO CHANGE THE MYSQL DATABASE ENGINE
When you are running Imixs Workflow on a Linux Server using MySQL the database default engine is typically ‘MyISAM’. This is a fast engine type.
But for transactional systems it is recommended to use a database engine which is supporting transactions. This database engine in MySQL is called ‘InnoDB’. When you change the default engine type in your MySQL setup an new Imixs Workflow instance will create tables based on this engine type. But you can also simply change the engine type from ‘MyISAM’ to ‘InnoDB’ with a sql script:
ALTER TABLE `CALENDARITEM` ENGINE = InnoDB; ALTER TABLE `DOUBLEITEM` ENGINE = InnoDB; ALTER TABLE `ENTITY` ENGINE = InnoDB; ALTER TABLE `ENTITYINDEX` ENGINE = InnoDB; ALTER TABLE `ENTITY_CALENDARITEM` ENGINE = InnoDB; ALTER TABLE `ENTITY_DOUBLEITEM` ENGINE = InnoDB; ALTER TABLE `ENTITY_INTEGERITEM` ENGINE = InnoDB; ALTER TABLE `ENTITY_READACCESS` ENGINE = InnoDB; ALTER TABLE `ENTITY_READACCESSENTITY` ENGINE = InnoDB; ALTER TABLE `ENTITY_TEXTITEM` ENGINE = InnoDB; ALTER TABLE `ENTITY_WRITEACCESS` ENGINE = InnoDB; ALTER TABLE `ENTITY_WRITEACCESSENTITY` ENGINE = InnoDB; ALTER TABLE `INTEGERITEM` ENGINE = InnoDB; ALTER TABLE `READACCESS` ENGINE = InnoDB; ALTER TABLE `READACCESSENTITY` ENGINE = InnoDB; ALTER TABLE `TEXTITEM` ENGINE = InnoDB; ALTER TABLE `WRITEACCESS` ENGINE = InnoDB; ALTER TABLE `WRITEACCESSENTITY` ENGINE = InnoDB;
This sql script did not connect to a specific database. For this reason it is necessary that you connect fist to the database the changes should be assigend. To run the script you can use the mysql command line tool in the following way:
First save the script into a local script file (e.g ‘mysql_innodb_imixs’). This file will be called later from the mysql console.
Now connect into the mysql Server:
mysql -u root -p
next select the database where the engine should be changed:
mysql> connect mydatabase;
finally you can run the script with the following command (assuming the you have stored the script before into a file named ‘mysql_innodb_imixs’ which is located in the current directory) :
mysql> source mysql_innodb_imixs;
Thats it. Now you tables will use the new Database engine ‘InnoDB’.
When you configure the JDBC Datapool connection from your Glassfish Server it is strongly recommended to use a ‘javax.sql.XADataSource’ connection. This DataSource type supports the transaction scope provided by the Imixs Workflow System.