Integrating and Using YAWL in Liferay Portal
In the context of my final thesis, I examined how YAWL can be integrated and used in the Liferay Portal environment, i.e., how portal users can access their respective workqueue and workitems from within the portal. To achieve this goal, I developed a sample application based on a very common business process, the check-in of new employees. The most parts of the developed integration and implementation components are generic, e.g., the workqueue portlet can be used with any YAWL engine and for any YAWL participant reachable via network or internet. The provided sources allow to derive Your own application context.
The Outcome of this examination
1. Detailed Description of the Integration Concept and its Implementation
To understand the entire context and all correlations, I strongly recommend to read the thesis document. An overview over all applied concepts and technologies as well as detailed explanations of the most important implementation steps are provided there. The document should be easy to read also for those whose english is not perfect. The most important chapters are 2 (Examination Environment Components) and 3 (Integration Approach). The appendix contains setup instructions for the sample instructions which can easily be derived to own application contexts. Note: Read the document! You will not succeed in just trying arround. You also should be firm with the basics of YAWL (and its Resource Service) and Liferay Portal.
This component contains all implementations which make YAWL go together whith Liferay Portal. To manage workflows and workitems of portal users, YAWL needs to be aware of the portal’s organisational data. So, the current users and roles are fetched from the portal and mapped to the YAWL organizational model. This is done by special classes which communicate which Liferay’s service APIs. This component also contains the codelet classes which are responsible for persisting data (by use of the persistence layer component) and for triggering activities in the portal (in this case, a new portal user is created by a YAWL task).
3. Persistence Layer
As the name suggests, this component manages the persistence of the sampe application and can be easily derived to another application context. It is able to write/read data to/from the database which is provided/requested by YAWL tasks. The database access is done by Hibernate (i.e., Java entity classes are required) while YAWL provides and requests XML. By use of the HyperjaxB framework, this persistence layer is able to work with both XML and Java classes. So, it is possible to access the database from YAWL as well as from a Java portal application. The provided project does also contain the configuarations and build steps (i.e., datatype definitions and entity generation) to create a persistence layer for Your own application context. Of course, a couple of programming would need to be done manually.
4. Liferay Portlets
The third component contains the Liferay Portal applications (i.e., the visible part of the implementation). The Workqueue Portlet is absolutely generic and provides access to any YAWL workqueue which is accessible over local network or internet. This portlet allows to change a workitem’s state (accept, start, suspend) and to start woking on it. Work on a task can be done by three ways: open the workitem in a separate brwoser window, delegate the workitem by email (link) or QR-code to another person or device, open the workitem in the Workitem Portlet inside the portal.
The portlets for data overview and data details correspond with the application context (i.e., the check-in of a new employee in this case). They provide access to the data collected by YAWL workflows by use of the Persistence Layer mentioned above. The data overview portlet also provides the ability to trigger YAWL workflows, i.e., when the basic data of a new employee has been recorded, the check-in workflow can be started without leaving the portal.
In contrast to the portlets for workqueue and workitem, the portlets for data overview and data details are not generic at all. Because the Vaadin framework used for portlet implementation was not in the focus of this elaboration, these applications are kept simple and the data forms are created by hand. You can adjust them to Your own datatype or business context manually or have a deeper look into Vaadin. This framework is very versatile and provides plugins for almost every demand. Automated forms are also available.
The provided sources do not represent a click and run application. To try it out, You have some work to do. As mentioned above, I strongly recommend to
- read the thesis document
- have a thorough look on the source files
If there are any questions, use the forum on the YAWL User Group page. Please choose a meaningful subject/threadname.
If required, I will add more info to this article to answer frequently asked questions. To show how complex concept and implementation are – and hence, how important it is to read the document at first – the following image visualizes the overall architecture of my thesis projects. Red and blue are already existing components of YAWL and Liferay, the white components have been implemented and integrated during this elaboration.
1. The thesis document as pdf: http://files.freihoff.org/thesis/thesis.pdf
2. http://files.freihoff.org/thesis/LiferayAddons.zip contains files to configure Liferay and to prepare the portal for Vaadin applications.
3. http://files.freihoff.org/thesis/PersistenceLayer.zip is first of three Maven projects represents the persistence layer including Hyperjaxb3, data access objects and generated entity classes.
4. In http://files.freihoff.org/thesis/Portlets.zip the second Maven project can be found. It contains the implementation of the portlet application.
5. http://files.freihoff.org/thesis/PreparedBundle.zip contains a prepared bundle which already contains Liferay Portal, the YAWL core services, the YAWL extensions, the persistence layer and several configurations. Only the installation of the Vaadin control panel, Vaadin version upgrade and widgetset compilation are required before the portlets can be deployed.
6. http://files.freihoff.org/thesis/ResourceServiceLibs.zip provides all necessary dependencies for the use of the persistence layer in the YAWL WMS.
7. The sample workflow and the XML schema defined business object are stored in http://files.freihoff.org/thesis/Specifications.zip. The business object definition is available in two versions (for HyperjaxB and for YAWL). The version for YAWL is already included in the workflow specification.
8. http://files.freihoff.org/thesis/YawlCoreServices.zip contains the YAWL core services in version 3.0beta. Tested and working latest builds are
already included as well as configurations and extensions. Note: If You want to use the 3.0release version, You have to replace the YAWL dependencies which are included in the project.
9. http://files.freihoff.org/thesis/YawlExtensions.zip as the third Maven project contains the extensions for the Resource Service. These are the
organizational data import, the codelets and the CSS file.