DMS with Imixs-Workflow and MySQL

The Imixs-Workflow project offers a professional and modern way to manage a business process in enterprises and organizations. This Workflow platform focus mainly on human-based workflows with means long living business processes and also business processes with a lot of data. Typical you can also use Imixs Workflow for DMS functionality as it cares about not only the data access and an easy way to find a business workflow but also Imixs-Workflow can managed large data objects like documents (PDF, MS-Word, MS-Excel, Photos or documents provided from a scan process).

DMS with MySQL

As Imixs-Workflow solutions are mostly running on open source platforms the Database Management System (DBMS) MySQL is a typical platform to store the process information. Imixs-Workflow uses an Binary-Large-Object format (BLOB) to store documents together with other process data.

But storing large data into MySQL can become a little bit tricky if your data exceeds the 1MB border which can happen immediately if your store documents. To prepare you MySQL Server to handle such amount of big data there are some MySQL settings witch need to be checked before. The settings can be set global by editing the [mysqld] section int the /etc/mysql/my.cnf file.

max_allowed_packet

The setting “max_allowed_packet”  defines the maximum size of the data included int sql statement. It shuld be set to a size of the expected maximum file size.  Example:

max_allowed_packet = 16MB

innodb log buffer size

The second important setting is the parameter “innodb_log_file_size” which should be large enough to do two things:

  • Accommodate any big BLOB or TEXT fields
  • Holding bigger transactions

If the innodb_lof_file_size is to small the EJB container can throw the following kind of exception:

11:19:34.237+0200|WARNING|glassfish3.1.2|org.eclipse.persistence.session.file:/mnt/opt/glassfish3/glassfish/domains/domain1/applications/reemtsma_pl/office-aeo-mms-ejb-1.1.1_jar/_org.imixs.workflow.jee.jpa|_ThreadID=96;_ThreadName=Thread-2;|Local Exception Stack: 
 Exception [EclipseLink-4002] (Eclipse Persistence Services - 2.3.2.v20111125-r10461): org.eclipse.persistence.exceptions.DatabaseException
 Internal Exception: java.sql.SQLException: Lock wait timeout exceeded; try restarting transaction
 Error Code: 1205
 Call: UPDATE SEQUENCE SET SEQ_COUNT = SEQ_COUNT + ? WHERE SEQ_NAME = ?
     bind => [2 parameters bound]

We recommend the following setting:

innodb_log_buffer_size = 100M
innodb_buffer_pool_size = 1G
innodb_log_file_size = 1G

After changing the configuration restart mysql with the following command:

mysql -uroot -p -e"SET GLOBAL innodb_fast_shutdown = 0;"
service mysql stop
rm -f /var/lib/mysql/ib_logfile*
service mysql start

Using the innodb_fast_shutdown = 0 forces InnoDB to completely purge transactional changes from all of InnoDB moving parts, including the transactional logs (ib_logfile0, ib_logfile1). Thus, there is no need to backup the old ib_logfile0, ib_logfile1.

Read more details about this topic here.

Imixs BPMN

Imixs Workflow is an open source project providing a powerful workflow engine to manage any kind of business process. The main objective of such a Workflow Engine is to control the states defined in the business process. The transmission from one state into another is defined by Activities. The typcial way to describe such a process flow is a state diagram. As the common standard the Business Process Modelling Notation – BPMN has been established in the last years.

BPMN Modelling

BPMN provides an easy way to describe a business process from the perspective of an user or a software system. In case of a human based workflow BPMN can also be used to describe the view from one or may users participating in such a process. In the following section we will demonstrate how to use BPMN to create a model for the Imixs-Workflow.

First of all you need to remember that one of the most important tasks of a workflow engine is to control the state of a business process. This means that a process instance can always be defined by its state. So the first step using BPMN is to model the states of a business workflow.

In BPMN there are only two predefined states known. The Start Event and the End Event. They are describing the begin and the end of a business process:

bpmn-modelling-example1

Each state between the Start and the End event can be described with the BPMN Task element. A Task describes not only the state of the process but also the general task which need to be performed in a specific situation. So we can extend the model by defining additional BPMN tasks to describe our states the process can take:

bpmn-modelling-example2

This example describes the states of a simple Ticket Workflow. The different states a Ticket can have are

  • Open a new Ticket
  • Processing Ticket
  • Solving the Ticket

Defining Events and Transitions

What we have done so far is an important step in describing a workflow model with BPMN. We defined all the tasks a business process can take and which can be identified by the workflow system to control the status of the process. Now we extend this model by adding new elements.

A business process typically defines activities which can be performed on a specific process instance. Each task depends on a state and defines a transition from one state into another. This is the workflow logic we need to design a complex business process. Using BPMN we can model this by using Gateways and Event Elements. A Gateway is used to define on ore many transistions from one state into another. A Event Element is used to describe the activity which can be performed by an actor during the workflow.  Lets see the next example:

bpmn-modelling-example3

Here we extended our simple state diagram with Gateway and Event elements to describe the activities in our ticket workflow.

If new ticket was created we defined the State ‘Open Ticket’. From this state we defined the events ‘accept’ or ‘close’ which can be triggered by the actor creating the ticket. When the event ‘accept’ is performed the state of the Ticket changes in ‘Processing Ticket’. Again we define a Gateway with now two possible transitions. When the event ‘solve’ is triggered by the actor the business process ends in the state ‘Solved’. If the event ‘reopen’ is performed we go back to the first state ‘Open Ticket’ to repeat the Workflow.

What you have seen here is a simple business process. We use the BPMN to describe the different states a process instance can have and also the Events which can be performed by an actor to process a ticket. A workflow system like the Imixs Workflow Engine can control the status of a process instance in the business model. Also the events triggered in this model can now be controlled by the workflow engine to change the states.

The Imixs Workflow System

The Imixs Wokflow provides a rich set of functions to control a business process and define the state of a process instance. In each change of a state triggered by an activity (task) Imixs Workflow updates a lot of properties of each singe instance. For example:

  • Read- and write-access to a process instance
  • Process documentation and process history
  • Ownership of a process instance
  • E-Mail notification to the next participant
  • Business-Rules to perform complex business logic
  • Versions of a process instance
  • Scheduled Events triggered by a timer
  • Summary and detail description of an instance
  • Form elements for a user frontend

These technical descriptions can be added into a workflow model and also in a BPMN model using the BPMN Version 2.0.

Read more about the Imixs Workflow technology at:

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”

Version 3.1.7 of Imixs Workflow released

We finally released the new version 3.1.7 of Imixs WorkflowThe new release includes a lot of improvements and some minor bug fixes. New features included in the new version are:

  • Workflow REST API support for JPQL Expressions
  • Improved REST API for POST methods
  • A new Test Suite to simulate workflows from the REST client
  • Support of country specific date format in wokflow history and E-Mail notifications
  • New functionality for performance analyse of the EntityService
  • A new CRUD operation for saving workitems in isolated transactions

The new version is available on GitHub.

Read more about Imixs Workflow on http://www.imixs.org

Language specific business process modelling

With the next release of the Imixs Workflow Engine Imixs provides a way for language specific business process modelling. The upcoming release supports country and language dependent text blocks in a workflow model. With the new attribute ‘locale’ a item value can be formatted in a country and language specific code – independent form the server setting. The new attribute supports the ISO 639 language and also the ISO 3166 country code.

For example to format a date value in German date format the following expression can be used:

<itemvalue format=\"EEEE, d. MMMM yyyy\" locale=\"de_DE\">datdate</itemvalue>

This feature gives more flexibility into the workflow model and allows to model country and language specifiy formats in one model.

Read more about the Imixs Plugins API.

How to test business logic

Testing the business logic of an enterprise application is mostly a little be tricky. In different to simple UI tests which can be performed with typical test-frameworks like HtmlUnit or Selenium, testing the business logic from the view of multiple test users can get very complicated very quickly. For example, if you test several steps in a comprehensive workflow for different users, you need to test if these users are allowed to perform specific tasks in the workflow. In such a scenario you need a group of test users to verify the different situations of access levels and you need to login and logout these users several times during your test case.

With the new release of Imixs Workflow the open source project provides now a powerful test framework which can be easily used in a JUnit Test. The Framework makes use of the Imixs REST API and simplifies the way to test complex workflow scenarios. To build your test case can setup a new WorkflowTestSuite and register a list of users which will be affected from the test case:

@Before
 public void setup() {
 testSuite = WorkflowTestSuite.getInstance();
 testSuite.setHost("http://localhost:8080/minutes-rest/");
 testSuite.joinParty("admin", "password");
 testSuite.joinParty("anna", "password");
 testSuite.joinParty("ronny", "password");
 testSuite.joinParty("eddy", "password");
 testSuite.joinParty("Anonymous", null);
 }

With this setup you can now easily test different scenarios and also create a new process instance or process specific workflow steps.

The following example shows how to test if a user currently has more than one task in his task list:

@Test
 public void worklistTest() throws Exception {
   Assert.assertNotNull(testSuite.getClient("anna"));
   List<ItemCollection> result = testSuite.getWorklist("anna");
   Assert.assertTrue(result.size() > 1);
}

Also the creation and the processing of a single workitem can be performed easily:

@Test
 public void processWorkitemTest() throws Exception {
   ItemCollection workitem=new ItemCollection();
    workitem.replaceItemValue("type", "profile");
    workitem.replaceItemValue("$ModelVersion", "1.0.1"); 
    workitem.replaceItemValue("$processid", 200);
    workitem.replaceItemValue("$activityid", 10);
    workitem.replaceItemValue("txtName","some test");
    workitem=testSuite.processWorkitem(workitem, "anna");
    Assert.assertNotNull(workitem);
    String uid= workitem.getItemValueString("$UniqueID");
    WorkflowTestSuite.log(Level.INFO,"UID=" +uid);
    Assert.assertFalse(uid.isEmpty());
 }

The important aspect of the WorkflowTestSuite is, that each test will be performed through the REST API of the Imxis Workflow Engine. So the test framework guaranties that during a test case the user will be authenticated against the back-end and the specific access level of each users joining the test case can be tested. This simplifies the way to test complex workflows and will improve your enterprise software development.

The Imixs WorkflowTestSuite is part of the upcoming release 3.1.7 of Imxis Workflow. Read more details here.

New Workflow Engine 3.1.6 released

Today we released our latest version 3.1.6 of the Imixs workflow engine. Imixs Workflow is a java framework for a human and adaptive process management. These kinds of software frameworks are typically used for business applications with flexible interactive user interfaces. Examples of these are approval workflows or  workflows in project management software.

The Imixs Workflow Engine is based on the Java Enterprise Specification JEE and provides a transactional and scalable BPM engine with an easy to use modelling tool.

The new release includes different improvements and bug fixes. A major change included in this release is the new project structure. The project is based on Maven and all submodules ‘core’, ‘engine’, ‘web-tools’ and ‘rest-api’ are now managed in a maven multi-module structure. This simplifies the integration and will lead to more and shorter release cycles. According to the new release the Imixs Workflow project has been migrated from Oracles Java.net platform to GitHub. This is an important step towards a more simplified access for developers and IT companies.

Read more on http://www.imixs.org

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”

EJB 3.0 and the TransactionAttributeType REQUIRES_NEW

Today I would like to share my experience about the EJB  TransactionAttributeType “REQUIRES_NEW”. The goal of this attribute is to isolate a method from the current transaction context and run the code in a new separate transaction. The transaction attribute can simply be annotated to a method:

@TransactionAttribute(value = TransactionAttributeType.REQUIRES_NEW)
 public void processSingleWorkitem(ItemCollection aWorkitem) {
 workflowService.processWorkItem(aWorkitem);
 }

But this annotation can become a little bit tricky if you need such a construction in a single EJB. Continue reading “EJB 3.0 and the TransactionAttributeType REQUIRES_NEW”

Imixs migrates to GitHub

We have now started the migration of the Imixs Workflow sources from Subversion to Git. In the past all sources of the Imixs Workflow Project were available on java.net. But now we started the migration to GitHub. This will make it easier for the community to join the project.

In addition we also plan to reorganize the Maven Project structure from a single project structure to a multi-module structure. The reasons for this step are a new deployment plan for the maven artifacts. With the multi-module structure we can simultaneity release all parts of Imixs Workflow. This was also made in the past. But with the new structure we can simplify the maven release process.

Join us on GitHub!