Posts

Posted on

Imixs-Workflow 4.5 Released

Today we released the new Version 4.5.0 of Imixs-Workflow. The version now has a full support of Java EE7. The release also includes also several improvements in JSF components and The Rest-API. Here is an overview about the latest changes:

New Features

  • The XMLItem now supports mixed value lists
  • New Extend FileData Object with custom attributes
  • LuceneUpdateService – provides a new ItemAdapter class to improve the extension mechanism
  • Full Java EE7 Support
  • Performance improvements for the imixs-faces module
  • RestService supports now custom reports to open spread sheets

Enhancements

  • JobHandlerRebuildIndex – allows to overwrite the Block_Size and Time_out
  • MailPlugin – Performance improvements

Bugfixes

  • WorkflowKernel – fixed computeNext Task – conditional Events computed correctly after changed conditions

A data migration is not needed. Existing applications can switch directyl to 4.5. Only JSF modules should adapt the new JSF Controllers. You can find details here.

Posted on

How to Manage Model Versions

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-Model-Management

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.

Semantic Versioning

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

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.

Minor Version

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.

Patch Level

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:

invoicing-1.0.0.bpmn

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.

Conclusion

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.

Posted on

Imixs-Workflow Version 4.4.4

Imixs-Workflow Version 4.4.4 is now released! The latest version includes two important improvements and shows a much better performance.

  • LuceneSearchService – Flush Event Log
    This improvement solved an issue with overrun Lucene Event Logs. Tests showed that the latest version runs stable and with better performance.
  • BPMN: Conditional Events
    BPMN models, using conditional events, can now be parsed correctly even if the model contains standard BPMN elements between an event and the condition:

The most important improvement of version 4.4 was the transaction support of Lucene event logs. With version 4.4.4 of Imixs-Workflow, this feature is now stable and shows also a very good performance in long running transactions.

Posted on

Simulating Workflows

With the new project Imixs-Mock  you can now simulate your Imixs-Workflow BPMN models in an easy way. The project provides a full mock of the Imixs-Workflow engine and allows to test and simulate different workflow scenarios. Imixs-Mock simulates the full processing life-cycle including all workflow plug-ins. You can specify also a subset of plug-ins to test specific business logic in your workflow project.

To add the mock into your own workflow project just add the following dependencies:

<dependency>
  <groupId>org.imixs.workflow</groupId>
  <artifactId>imixs-mock</artifactId>
  <version>4.4.0</version>
  <scope>test</scope>
</dependency>
<!-- JUnit Tests -->
<dependency>
  <groupId>junit</groupId>
  <artifactId>junit</artifactId>
  <version>4.8.1</version>
  <scope>test</scope>
</dependency>
<dependency>
  <groupId>org.mockito</groupId>
  <artifactId>mockito-all</artifactId>
  <version>1.9.5</version>
  <scope>test</scope>
</dependency>

Now you can write your jUnit test class to verify your BPMN model. See the following example code:

@Test 
public void testSimple() {
  workitem = new ItemCollection();
  workitem.model("ticket-workflow-1.0").task(1000).event(10);
  workitem.replaceItemValue("_subject", "Hello World");
  try {
    workitem = workflowMockEnvironment.getWorkflowService().processWorkItem(workitem);
    Assert.assertNotNull(workitem);
    Assert.assertEquals(1100, workitem.getTaskID());
    Assert.assertEquals("manfred", workitem.getItemValue("namowner", String.class));
  } catch (AccessDeniedException | ProcessingErrorException | PluginException | ModelException e) {
    e.printStackTrace();
    Assert.fail();
  }
}

The Imixs-Mock allows you to simulate different users processing a process instance. In this way you can verify the Access Control List (ACL) of a process instance and the assignment of process owners in complex workflow scenarios.

You will find the full example on Github.

Posted on

Tutorial: Imixs-Workflow and Jakarta EE

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”

Posted on

Imixs-Workflow Version 4.4 Released

Today we released our new Version 4.4 of Imixs-Workflow. The new release 4.4.0 includes new features, several bug fixes and minor enhancements of the Imixs-Workflow API.

The most important new feature is the Lucene Index which is now supporting transnational Read Committed. In the past, after a transaction was roll backed, in some situations the lucene index contains uncommitted entries, which leads to unexpected search results. With the new version 4.4 a complete re-implementation of the Lucene UpdateService has been realized. The indexer is now more robust and reflects only committed transactions. 

Another new feature is the GenericSchedulerService. This new service interface can be used to implement custom schedulers. The implementation of such a scheduler is now quite easy and the scheduler is automatically managed by the new SchedulerService EJB.  In the next releases we will re-implement also the existing WorkflowScheduler. 

Read more about the project at: www.imixs.org. If you have suggestions or comments please contribute on Github.  

Posted on

Generate and Export SEPA Files with a Workflow Engine

The Imixs-Workflow project now supports the generation of SEPA files. The Single Euro Payments Area (SEPA) is a payment-integration initiative of the European Union for simplification of bank transfers denominated in euro. Imixs-Workflow started the new adapter project Imixs-SEPA-Adapter to simplify the SEPA integration in any kind of finance workflow. The project provides a new scheduler service to generate SEPA files on a daily basis. For example this adapter can be used to export the results of an invoice approval process into a SEPA file which can be used in any payment software.

Free and Flexible Adaptability

The Imixs-SEPA-Adapter is based on BPMN 2.0 and the Imixs-Report functionality to allows a free adaptability of the SEPA export to any custom workflow project. This adaptability is important because invoicing workflows differ from company to company. The adapter integrates seamlessly into an existing process and can be realized with a standard or a custom workflow mode based on the BPMN 2.0 standard.

 

The SEPA file generated by the adapter can be distributed into the task list of the companies finance team or sent via E-Mail notifications. For security reasons the distribution via the task list is recommended as this fully utilize the strict access concepts of Imixs-Workflow.

Detailed information about the adapter project can be found on Github. The project is in continuous development and contributions from the community are welcome at any time.

Posted on

Lucene Index Consistency

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”

Posted on

First MVC 1.0 Workflow App

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”

Proudly powered by WordPress