Porting Activiti Explorer to Liferay Portal

In the following blog post,  I have highlighted the matter of embedding Activiti BPMS inside a Liferay Portal. With Activiti Explorer built in Vaadin and Spring, it is fairly easy to use entire  components in a totally different environment. 

Proof of concept fork with Tasks and Admin portlets is available in 
https://github.com/tlipski/Activiti/tree/master/modules/activiti-portlets.

Porting Activiti Explorer to Liferay Portal

Activiti is a popular Open Source, BPMN2.0-compliant BPMS that provides a great overall package. Not only there is a library that can be embedded inside your application, but Activiti also comes with an Explorer web application, which provides an ergonomic user interface for basic operations:

But, Activiti is "just" a BPMS - you can run your processes with it, maybe even connect to Active Directory, Alfresco or ESB - but if you want to embed it in your intranet/extranet portal, you are almost on your own. 

Please note, that embedding Activiti in portal is not the same as using it to manage portal assets - for example, as a replacement for Liferay's Kaleo Workflow. The matter discussed here is more focused on using all of Activiti features, including user interface.

Luckily, this is when frameworks used in Activiti pay off - Activiti Explorer is written in Vaadin 6 and Spring. With component oriented approach from Spring and UI modularity encouraged by Vaadin, it is fairly easy to port this application to Liferay. We can extract entire components from Activiti Explorer (e.g. Tasks panel) and use them in a whole new environment.
Extracting and re-using entire components requires much more work in a classical MVC approach and even may not always be possible. Also, portlet support in Vaadin makes a whole task much more pleasant.

For the impatient: The code is available in my fork of Activiti 5.13-SNAPSHOT: http://github.com/tlipski/Activiti, especially in activiti-portlets module https://github.com/tlipski/Activiti/tree/master/modules/activiti-portlets.

Necessary steps

"Fairly easy" does not mean without any effort. There are differences between a standard Vaadin application and a portletized one:

• Portlet descriptors are necessary
• GUI should be divided into separate portlets
• Spring-Vaadin integration is different due to a portal-specific request life-cycle
• Navigation can be provided by portal - including friendly URLs, which makes for a more standard user experience.

In addition to that, some mechanisms used by Activiti are already provided by Liferay Portal and we need to bridge them:

• Users and Groups should be managed by Liferay Portal
• Authentication data should be taken from a portlet container
• Mail notifications could possibly use Liferay Mail API

Some other things have to be taken into account as well:

• Distribution and management of Vaadin widgetset and version - we should use Vaadin Control Panel portlet and Liferay to manage Vaadin dependencies. This requires special handling, since Activiti Explorer 5.13 utilizes dCharts Vaadin Add-on.
• Vaadin theme used in portlets - which is also customized by Activiti, but should be coherent with portal's look & feel.

Current state of work

It is nice to theorize, but certain things need to be verified in practice. At this moment, my fork at http://github.com/tlipski/Activiti provides:

• Activiti Tasks portlet, which works in a user's context as if the user would log in to Activiti Explorer app. The portlet provides full functionality, including operations as starting a new task, fetching it from a task list, displaying task's events, assignment/ownership transfers, file attachments and so on.
• Activiti Admin portlet in Liferay Control Panel - most tabs seem to work fine - except Users and Groups, which should be disabled as we are using Liferay Portal to do that.

Implementation details:

On the implementation side, most noteworthy changes which have been implemented in activiti-portlets module: https://github.com/tlipski/Activiti/tree/master/modules/activiti-portlets are:

• IdentityProvider implementation utilizing Liferay API (need to work on user photos though!)
• Spring-Vaadin bridging for portal (see my previous post).
• Custom portlet applications and main Window class. The interesting detail here is that with Vaadin portlets, you should not set width of components to 100%, as it will result in 0px height. Generally speaking, the height in Vaadin portlet components should be set to undefined - null, or a preset value in pixels.

Next steps?

Connecting Liferay with Activiti brings a myriad of new possibilities, but before that, some basic things need to be done:

• More portlets! Reporting and Processes tabs need their respective portlets, but also "start process" portlet might be worth considering since we can manage UI contents in a more flexible way.
• More testing! If anyone is interested in testing Activiti portlets in Liferay, let me know and I will provide prebuilt applications. So far, I've used Liferay 6.1 GA2 CE and H2 in-memory database for Activiti.
• Friendly urls - especially for tasks resolved by id, and for interportlet communication - e.g. when starting a process.

Why Vaadin is different - and how can it make your web application great

on the example of Aperte Workflow
Vaadin
Vaadin is an Open Source widget-oriented, Java Rich Internet Application web framework, which allows programmers to develop browser-based user interface entirely in Java - server-side.
That's it. This is what makes Vaadin different and this is what is game-changing in comparison to almost any other popular web framework.

100% JVM

Because everything is written in Java and runs server-side, you can do things, that were almost impossible or very painful for web frameworks before:

• Have one, coherent application, with its logic seperated according to your needs - not to what the framework designers had in mind
• Apply Java programming patterns (compile-time polymorphism, inheritance, etc.) to all of your code - and build your application from coherent modules using these patterns.
• Write app in a scripting language of your choice - in Scala, Clojure, Common Lisp, Groovy - anything that runs on JVM as a scripting language
• Debug user interface logic using standard tools - not just in a sandbox mode
• Introduce plugins to your application using OSGi framework
• Develop rapidly, by reloading your code in mere seconds - e.g. using JRebel agent or even OSGi framework

Vaadin still allows programmers to access the browser side - but in a controlled way, using Add-ons - Vaadin Add-on Directory provides ecosystem for those. And for most applications - you can easily build them using just the standard ones, provided by Vaadin out-of-the-box.

...and more

JVM itself would be enough, but Vaadin is not only great in the idea itself, but also in implementation. The applications have eye-friendly look out of the box, you can also apply custom CSS and themes easily.
The UI is well-optimized even in comparison to client-side only frameworks - and it works on all modern browsers out of the box (IE6/7 - with some downsides too!).
There is even mobile device support with Vaadin TouchKit, Vaadin also supports JSR168/286 portals (e.g. Liferay Portal) and even Google App Engine.

Vaadin & Aperte Workflow

Aperte Workflow is an Open Source BPMS - the application that eventually is built during the introduction on BPM-class system to an enterprise. Aperte Workflow is designed with strong emphasis on modularity, re-usabiliti and extensibility of solutions created.
User interface in Aperte Workflow is built on Vaadin. The approach for BPM task UI concept in Aperte Workflow is that for each human task, user interface is built from reusable blocks or components (in Aperte Workflow terminology: widgets). Such components can be process-aware (e.g. display process instance data) or just organize other components.

With Vaadin, creating these components is a blast, even for someone new to the concept. You just code your component in Java - implementing some interfaces or extending ready-to-use classes. Vaadin widgets are there - so, for example - you don't have to worry on how to implement your own or incorporate existing suggesting combo box or grid - they are already here, well designed, optimized to work together with other combo boxes.
After coding - you just deploy/update them to a plugin mechanism. Being written entirely in Java, we can manipulate them in our plugins very easily. We don't have to build a set of JavaScripts to provide RIA experience to the users - but neither we have to refresh web page after every user action.

So the code->deploy->test->code->deploy->... cycle is very short - and still we write our application in plain old Java. I wouldn't even attempt to try to implement such thing with pure GWT or JSF.
Plugin mechanism provides integration with an Aperte Workflow web-based modeler - which is based on Signavio core, but more complex elements specific for Aperte Workflow were written in Vaadin too.

Use of Vaadin in modeler allowed us also to engineer preview mechanics to some components (more to come) - for example, Advanced Process Data widget, which provides generic-form feature (it's just one plugin, not an obligation or part of the Aperte Workflow core - you can use, you can replace it, or you can use other implementation, or just go with your own plugins) generates preview in real-time. And the preview is the same code and configuration that will be run in the real user interface for a real BPM task.
What else Vaadin has allowed us to do with relative ease, is that Advanced Process Data Widget provides JSR223 scripting support - for validation and manipulation of the configured form.

Summary

In Aperte Workflow, we have chosen Vaadin as our UI framework, not only to save ourselves from spending too much time coding the user interface. We have chosen it mainly because with Vaadin, it is possible to create much more modular RIA web application than with any other framework we have seen.
Will Aperte Workflow be possible without Vaadin. Sure - but with much bigger effort and budget. And the result would be underwhelming without Vaadin - or we would have created our own, imperfect implementation of Vaadin.
More information:

• Vaadin website
• Book of Vaadin (there is even an ebook version for Kindle, iPad, Android, etc.)
• Vaadin widgets gallery
• Vaadin Add-ons directory
• Aperte Workflow

Aperte Workflow - why another BPMS?

What is Aperte Workflow?

Aperte Workflow is a BPMS (Business Process Management Suite) designed and developed by BlueSoft. The project has started in 2011 and is currently approaching version 2.0.

BlueSoft is an Independent Software Vendor specializing in custom, tailor-made IT solutions for the enterprise customers - based either on Open Source or proprietary software.

The company itself comes with over 9 years of experience in developing such solutions, which gives a certain perspective on how things should be done. But still, young enough to be able to innovate effectively.

Why build another Open Source BPM solution?

That is a good question, and we ask it ourselves every time we forego existing, available technology and start creating something new. 

With Open Source BPMs and Aperte Workflow, the decision came from a simple observation: that every time you need to deploy a BPM-based solution (be it Open Source or commercial software) in a real application, which provides real processes, used by real users, you need to build an application around it.

You have to provide at least:

• Integration with Customer's authentication/authorization mechanisms.
• Custom User Interface. Forms with text, number and date field are great, but usually the business requirements are much more complicated. 
• Integration on the browser-level with Customer's intranet portal (desktop based BPMS in my opinion are a total misunderstanding) - or some kind of base for BPM application.
• Enterprise integration with the Customer's other IT systems (CRM, ERP, ...).
• Flexible data model

And yes, it is possible to build such solution yourself. Integrate existing technologies into one solution, learn how to use them, find bugs in your code and in the code of the technologies you are using - and then, finally you can start developing your processes. 

This is exactly what Aperte Workflow provides - a ready-to-use, well-tested and mature product, which provides a platform or a placeholder for your processes and custom mechanisms. Done right, with reusability, scalability and performance in mind.

We do not aim to it be a complete solution for your business process (although it is very easy to build one with Aperte Workflow!) - we understand, that every process in every company can be a little different. But, there are some things that have to be done for every BPM deployment, so why not do them once and right?

For us, Aperte Workflow is different from the other solutions, as it approaches problems on a different level. We do not try to provide an answer to every problem that rises during BPM deployment in an organization - but rather to provide means, that the solution will be worked out easily and will be coherent with other parts of the deployment and will be re-usable in other areas.

What Aperte Workflow provides?

Aperte Workflow provides common things that usually have to be built when deploying BPM in an organization. But, since this is a standalone product, even more features, that wouldn't be usually implemented in a custom BPM deployment are provided.

Portal Integration

Aperte Workflow integrates with JSR168/286 compliant portals (e.g. Liferay). By doing so, you do not only have an awesome integration with existing portal or enterprise IT infrastructure (e.g. Active Directory, NTLM, ...), but you also have a place to introduce and integrate other applications.

Using JSR168/286 allows you to standarize and unify all your browser-based applications - into a one, coherent intranet portal. 

Custom User Interfaces

With Aperte Workflow, user interface for each human task (on the task list or in details) is built from re-usable components. These components, provided as plugins, can provide:

• all-round, generic features, such as simple input form or a tabsheet organizing other components
• specific features - usable in most of the processes, such as comment form or process history log
• custom business logic - related to a certain process or organization, a CRM customer search form would be an example for that.

The UI is provided by Vaadin, therefore its customization requires no HTML/CSS skills - it is programmed directly in Java. And with Vaadin, we can build beautiful, rich web interfaces with ease.

Enterprise integration

Aperte Workflow allows users to build automated steps as plugins. As with User Interface, some of them can be quite generic (e.g. invoke Drools), others - very specific. All of them can be reused in different processes without any trouble.

Also, Aperte Workflow comes with a sample plugin, that embeddes Mule ESB as an OSGi service. Other plugins can deploy simple Mule services, and processes can invoke them using Mule automated step. But - this is just a convienent sample of integration mechanisms and if for example ServiceMix would to be embedded as an integrated ESB - why not?

Extensible data model 

Aperte Workflow's data model is built with JPA/Hibernate. That grants us significant portability with little effort, but also allows the plugins to provide their own data model without performance downgrade - the data model is mapped directly to SQL database. 

BPMN2.0 modeler

When designing BPM system from scratch, around existing BPM engine or solution, you usually have to configure process in two places - one for the BPM engine and the other for your customizations. Rarely you would take the effort to create a graphical, coherent tool to do that. 

But, as Aperte Workflow is designed for more than one deployment, such effort pays off. That's why we have taken Signavio Core Components BPMN2.0 editor and combined it with our configuration controls into one, complete, browser-based process modeler.

How Aperte Workflow is built?

We have decided to build Aperte Workflow on top of existing, Open Source technologies. That not only saves us from the trouble of building everything from scratch, but also provides other, even more significant advantages:

• Maturity from the start. We don't have to test, mature and grow our components. They are already checked by thousands of their users and built around their feedback.
• Much easier to learn. It is much easier to start using or diagnose a problem with a solution built from technologies you are already familiar with, or that have a thriving community around them.
• New features. If you are using your own software, there is a great chance, that all the features have to analyzed, provided, tested and checked by you. 

Aperte Workflow is built from many Open Source libraries and frameworks, to mention only the most significant:

• Liferay Portal as a default JSR168/286 container
• jBPM and Activiti BPM engines - it is also possible to user other implementations
• Vaadin as a default framework for building user interfaces
• Apache Felix - an OSGi framework
• Hibernate - ORM/persistence
• Mule ESB - as a sample embedded ESB provider

Create once, use many times

Aperte Workflow is great when it comes to building reusable components. Yes, many processes may differ, but building blocks for them can be re-used many times. Some of them, such as simple form displaying/editing process attributes or comment input form can be universal across the whole world, other - can be universal only in a specific organization - for example CRM customer search form would be applicable to many processes but only in current organization.

As Aperte Workflow is created in Java(tm) technology, the natural and simplest way to provide plugin mechanisms is to use an OSGi framework. OSGi is great, because it provides a standarized, well-thought way to:

• isolate each plugin within its classloader space - with its own libraries and dependencies
• provide a means for plugins to communicate with each other
• manage dependencies between plugins

With Aperte Workflow, reusability is provided on many levels, in compliance with the spirit of Service Oriented Architecture. Aperte Workflow services (bundled in OSGi plugins) can provide for example:

• user interface components
• automated steps performing business logic or integration
• localization (I18N)
• custom mechanisms that access Aperte Workflow API - e.g. start processes or provide embedded ESB for processes
• process dictionaries

and many more..