In this tutorial I explain some of my experiences in extending the Eclipse BPMN2 Modeler with custom elements and properties. I am extending the BPMN2 Modeler to provide a custom BPMN runtime extension for the Imixs-Workflow Project. You will find the results of this project here.

With JEE6 and JSF2 we finally have the great feature of bookmarkable URLs. This fixes one of the most awful faults of JSF that pages were not bookmarkable. An application can now become bookmarkable with some modifications. (See details about bookrmarkble URLs in Ryan Lubke’s Blog)

In a JSF web application you will usually have a <h:command link> or <h:commandbutton> like this:

In this example the action method returns a navigation outcome. Since JSF2 this action outcome can be also a jsf page URL (e.g /page/my_page.xhml), so no more explicit navigation rule is necessary. But the result is not bookmarkable.

To replace this with a bookmarkable URL you can replace the JSF component with the new <h:link>. See the following example:

The result is simmilar to a <h:commandLink> with the difference that the URL is now set to the browsers URL. So far this new link can be bookmarked, but it is not automatically working. To resolve this new URL you have to customize your jsf page to evaluate the new query param (in this example my_page.xhml).

This is a case where replacing <h:commandButton> with <h:button> will not work out of the box. This is because the outcome property can not evaluate the action result which can – in my case – also become null. To solve this the navigation rules come back into the game. You can achieve the same result as shown in the first example with a navigation rule placed in the faces-config.xml. See the following example:

This examples returns the worklist for the User ‘admin’ from a Imixs-Workflow Rest Service running on localhost port 8080.

If you don’t specify the media type Imixs-Workflow will return an HTML output. You can see this also in your Browser. But Imixs-Workflow also supports the media types JSON and XML. To request the same URL in JSON you can add a Header parameter like this:

If you know the UniqueID of a workitem, which is included in the worklist result you can also request a single Workitem from the Imixs-Workflow. See the following curl example to request a workitem in JSON format:

If you want to test what is possible with Imixs-Workflow REST API and curl you can try the Imixs-Microservice. Imixs-Microservice provides a full featured Workflow System based on a REST API. Imixs-Microservice also supports Docker so you do not need to install a Application Server by your self.

Today I want to talk about a detail in the JSF Framework, which is on the first view not obviously. In different to Spring, business logic placed in a JSF front-end controller (JSF Backing Beans) did not initializes a separate transaction context. Normally business logic which need to be transaction save should be spread out into EJBs. EJBs are the recommended place for business logic. So in JSF/EJB business logic should be put into stateless session EJBs and controlled the page flow of a web application through the so called front end controllers – JSF Backing beans. As I mentioned before spring starts a transaction context also in front-end controllers, but jsf does not.

So what is the problem here? When you look at the following JSF example, you maybe will not recognize the problem at first:

The JSF front-end controller method ‘process(businessobject)’ injects an EJB and calls two ejb methods. This will propaply work without any side effects. But it can produce errors in some cases. The problem in this pattern is that the front-end controller performed two apparently dependent business actions completely separately. If these two methods need to be transaction save but are operating on the same database entities this can result in serious problems. In a high concurrent system indeed this pattern can cause a corrupted DB state even if you thought JPA will solve all the transaction stuff for you.

The reason for the unexpected behavior is the missing wrapping transaction. Each ejb method starts it own transaction with all the transaction control provided by the ejb container. But the hole business method is not transaction save.

To solve this you have two possible solutions:

1) add a UserTranaction context to the front-end controller:

In this example now the jsf controller starts itself the UserTransaction. As a result both EJB methods (with default transaction mode ‘mandatory’) run in the same transaction context. Even operations on the database in a high concurrent system will be transaction save.

2) Merge the EJB Methods into one transaction save business method

The second solution merges both ejb methods into a single EJB method call:

Now the new ejb method is transaction save an there is no need to fiddle with UserTransaction in the jsf fornt-end controller.

The second solution is recommended because there is no more risk that the transaction context is split by the front-end. And you can reuse the new ejb method easily with now need to think about the transaction context scenarios.

Maybe this will help you solving some problems with jsf transaction context in the future.

I run into a situation with a git repository that I was no longer able to switch between branches. Git complains about uncommitted changes. But I was sure that my local repository should not have any changes.

For force a hard checkout and pull use the following git commands. NOTE: this will overwrite any local changes – so be careful:

If you start developing a business application you have two different approaches. In the first one – and this is the typically one – you start with the modelling of business objects. For example you have a “car” which can be easily modeled in a business object. You have a “buyer” and a “seller” which can be also simply stored into separated data tables. That’s it! It looks so easy to develop a business applications like in this example for a “used car dealer”. What you do is to describe the real things from the surrounding world into objects using a programming language of your choice. Today we have a lot of frameworks to map the real world things into databases and object orientated application frameworks. This all works well – at a glance. But as we all know, the real world is anything but simple. And in the moment when you realize that “used cars”, “sellers” and “buyers” have more complex relationships you need new objects like a “sales contract” and a “driver‘s license”. A “credit agreement”and a “warranty”. And you see that the things of the real world are not so easy as they seems to be in the first time.

A complete different approach to develop a business application is to get rid of the things of the real world. In this case you don’t look for what the persons do with the things. But you look for why they do the things they do. Now you are looking at the process behind the things in our real world – the business process. In the example of our “used car dealer” you can see a buyer showing interest in a car – his desire to buy. You see the dealer who tries to regulate the payment and all the things which can happen when you buy or sell a car.

Now when you try to model this in your business application your thoughts revolve around what people do and what happened during the entire process. And this is the idea of a business process application or a workflow application. Talking about the objects and data tables as we do in the beginning we now need objects like “events”, “activities”, “process states”, “actors” and “time ranges”. This is more abstract because we are now looking behind the things in your visible world. The funny part of this developing is, that you will realize that it does no longer matter if your seller sells cars or flowers or if you buyer is interested in a used car or a holiday travel. Your application becomes more abstract and you begin to model the real abstraction of the world.

When you start developing a business application in the second way you don’t ask your customer what the things are he what’s to save into a database. You ask him why he need an application to do his work better.

Take a look at our open source project Imixs-Workflow. It maybe can help you to get on that way.

To setup a PostgreSQL database connection in GlassFish is quite simple. There is one point which required special attention. First, it looks sufficient for the GlassFish DataPool configuration to only define the parameters “DatabaseName”, “User” and “Password”. By default, the URL has the value:

Otherwise it can happen that GlassFish losts the connection and is unable to find any tables. When you change your pool configuration don’t forget to restart GlassFish.

EclipseLink – DataSources!

If you configure postgresql in GlassFIsh or WildFly it seems to be very important that the additional property ‘url’ is always set with the corresponding jdbc connection url. Even if the setup wizzard (wildfly) did not fill this param!

Today I was faced with a really strange problem concerning JPA, EclipseLink an MySQL. I have Service EJB (3.1) with some JPA Entity Beans. They are joined with @OneToMany constraints. I am deploying my application typically under GlassFish 3.1 with MySQL Database. Everything works fine so far. But in some really strange cases – long complex transactions with a lot of updates and inserts I got a JPA Exception like this:

I was confronted with such error messages in the past and solved them by changing the transaction boundaries in my code by encapsulating some of the jpa stuff in separate methods with new transaction context.

But The real reason for this kind of error is an inaccurate mapping of the database schema in MySQL made by EclipseLink. My table ‘ENTITY_WRITEACCESS’ is a crosstable needed for a @OneToMany relationship of my JPA entity beans. I never looked at the schema in detail, because in my opinion that is stuff of the OR-Mapper.
The problem was that per default no CascadeType is defined for a @OneToMany relationship. But even when you define a CascadeType like CascadeType.DELETE – which is also implied by CascadeType.ALL – to your entity beans this will not necessarily be reflected to the database schema generated from the OR-Mapper. When you look at the generated schema you’ll notice that ON DELETE CASCADE is not added to the constraint. When you alter your schema and Add ON DELETE CASCADE to actual tables this will fix the problem above.

Note that this all depends on the JPA implementors how the constrains are created. So take a look at your generated table schemas.