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.

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!

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 analyse the SQL data for an Imixs Workflow Entity

The data of an Imixs entity object is stored in a set of datatables based on the JPA objects provided by the imixs-workflow-engine module.

In some cases it can be interesting to verify the values of an ItemCollection separated into the SQL datatables which are used to select sub sets of entities. If you know the $Uniqueid of a ItemCollection you can select the values using a SQL statement on your SQL database like this:

select * from TEXTITEM 
where ID IN (select textItems_ID 
             from ENTITY_TEXTITEM 
             where Entity_ID='13b334b3e6e-f9b13d6')

In this example all text values for an entity with the $Uniqueid ’13b334b3e6e-f9b13d6′ are returned.

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