Kolban's Projects

Apache Velocity Integration

Apache Velocity is an Open Source template engine that takes as input a text string and a set of variables and returns the original text string with variable references replaced with their values. In addition to simple name/value mapping, Velocity has many other features and options which makes it an extremely versatile template language including conditionals and looping.

Seeing the capabilities of velocity, the goal of this project was to see how it could be integrated into a IBPM solution. A Java Connector was written which wraps the Velocity template library and exposes it as a trivially invocable service from a BPD activity or as a nested call within the another service component.

The input to the Velocity Service are two parameters.

One parameter is a text string that is an instance of a velocity template. This can be hard coded, retrieved from a managed file or retrieved from a URL. The second parameter is a IBPM Map variable. The keys in the map are the velocity variable names and the values are the IBPM variables.

This component is an alternative to the JavaScript functions supplied as core as part of the product. It has advantages in a number of circumstances such as repeating iterations, conditions as well as having the definition of macros and other powerful capabilities. The details and value proposition of the Apache Velocity project can be read about here:

Making use of this wrapper removes the need for anyone to have to know Velocity coding APIs and makes its functions immediately available for use.

The Velocity Template Language

The Velocity Template Language (VTL) is a simple yet powerful language that is used to process text. Here is a quick summary

Variable references

A variable name prefixed with a $ symbol will be expanded during rendering.

Here is some text $name will replace the name variable

An alternative style is to place the variable name in curly braces




are identical

Function invocation



#if (expression) … #elseif (expression) … #else … #end

#set($variable = "value")


## This is a comment

#* This is a multi line comment *#

#foreach ($variableName in $listVariable) … #end

These are only some of the more commonly used capabilities. The VTL is much richer and one should examine the VTL user guide and reference for more details. The reference for VTL can be found at the "VTL Reference".

In order to run, velocity needs the following mandatory pre-reqs

Unfortunately, with the latest levels of Velocity, these won't work. The latest versions of these classes need to be added to the packaging.

See also:

XSLT DataHandler

Although not supplied with WPS by IBM, this section describes a project that constructed an XSLT DataHandler.

XSLT can be used to construct output from an input XML document and an XSL template that describes how the transformation should work. This can be used to convert one XML document format to another. If we had an XSLT DataHandler, then the output data generated by the DataHandler could be generated by the XSLT processing.

If the incoming data were an XML document but not of a format suitable for converting to a Business Object, the XSLT DataHandler could be used to transform the incoming XML to BO format XML before building the BO.

The XSLT DataHandler has one configuration parameter which is the name of an XSL Template file. This file should be packaged as part of a deployed project.

At a technical level, and usually not seen be consumers of the datahandler, the input formats support by the DataHandler can be:

To use the DataHandler, obtain the XSLTDataHandler.jar file. This contains the implementation of the solution.

Add the JAR into the WID project or library that is to use it.

<Info Needed>

In WID, add the new DataHandler in the BindingRegistry.

Converting a BO to a plain XML

The following stylesheet can be used to transform a BO to a plain XML:

<?xml version="1.0" encoding="UTF-8"?> <xsl:transform xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="2.0"> <xsl:output standalone="omit" encoding="UTF-8" omit-xml-declaration="yes" media-type="text/xml" method="xml" indent="yes" version="1.0" /> <xsl:template match="/child::element()"> <xsl:element name="{local-name(.)}"> <xsl:copy-of copy-namespaces="no" select="child::*" /> </xsl:element> </xsl:template> </xsl:transform>

Author: Neil Kolban

Date: 2011-01-02

EMail: [email protected]

IBM BPM 7.5 Coach Auto-save

Consider a coach screen being shown to a user. The user enters a bunch of data and then goes for lunch. The system then crashes or his browser crashes … and he has lost his work. The question becomes … how could we have saved his work?

At a high level, let us imagine that periodically we wish to save the current state of data entered into fields. We will assume that we have some external mechanism to do just that. Next we should assume that if a page is re-loaded, we have a way to determine the uniqueness of the page and re-load any saved data that was auto-saved.

The saving of data will be accomplished by an Ajax call passing in the name/value pairs of the fields we wish to save.

Process and Task Data Explorer

This is a project that I flag as "experimental". I have chosen to make it available now just in case anyone may have some use of it. The project is a BPM v8 Process App that, when installed, provides the user with a table of all the process and tasks found in the system. Clicking on a row in the table shows the details of that particular task.

The application is launched from Process Portal within the Dashboards section:

There are some context menu options available by right clicking on a row but these haven't been fully polished yet.

The solutions is implemented in a combination of Coach Views and Dojo.

It is available for download from here:

http://www.neilkolban.com/DATAOLD/DataFiles/Process_and_Task_Data - 2012-07-24.twx

Out of Office support

Consider a user being out of the office or away on vacation or being out sick. He may wish any new tasks that were routed to him to be re-routed to someone else for a period.

One way of achieving this is to have a demon process that runs every period (say every 15 minutes). This process could look for new tasks that have been assigned to our user. If found, they could be re-assigned to another user.

Turning this into a generic story … we could have an algorithm that reads as follows:

Every 15 minutes, run the following:

Find the set of tasks that have been created since last time we looked and are not yet in the Closed state; For each unique user owner of the tasks { Retrieve the out of office instructions for the userid (if present) Execute the out of office instructions for the userid for each of the tasks owned by this userid }

Page 1394

No Comments
Back to top