Embedding a custom client type into the human task editor

Product documentation


The human task editor offers two client types by default, the Business Process Choreographer Explorer and the Portal client type. It is possible to add custom client types to the human task editor with help of an Eclipse extension point. This document explains how to do this.


If you want to define your own client to interact with the human task manager, you may want to define parameters for this client during the modelling of a human task, for example, you could define parameters to specify which UI components should represent the input or output message of the task, instead of using a default representation. After deployment, these parameters are available through the appropriate human task manager API. The client can use them to decide which UI components to show.

To make it possible to change the client parameters during the modelling, there must be a possibility to define new client types and to change its parameters in the scope of the human task editor. For this, you can use the extension point com.ibm.wbit.tel.ui.clients. It provides the possibility to define new clients, to add some visual information, such as display name and icons, and to hook property pages into the editor which can be used to modify the client parameters.

For example: you have a client based on the rich client technology of Eclipse 3.0. It contains, amongst other things, a view that displays input and output message for specific tasks. It may look like this:

There is a section for the input message, and one for the output message. The messages will be rendered in a default way, but it is possible to replace the default rendering with customized representations, for example to use a fancy calendar for the shipping date. These customized representations are contained in plug-ins which must be installed in the client as well.

But how does the client know what plug-ins to take for a specific human task? To handle this, the client asks the human task manager for parameters. This is how the parameters for this example look like in the human task XML language:

Whereas the first two parameters are meant to specify the plug-ins which contain the customized representations, and the last parameter defines where to get the plug-ins (or updates for them) from.

To define these parameters during the modelling of a human task, you have to "tell" the human task editor that there is an new client type you want to work with: you have to embed the new client type into it. Therefore you have to create an Eclipse plug-in, implement the extension point com.ibm.wbit.tel.ui.clients and deploy it to your WebSphere Integration Developer installation.

(Hint: If you are not an experienced Eclipse developer, read this document:
It contains a step-by-step-instruction about how to create a simple client and how to deploy it with help of the Update Manager.)

This is what the extension point implementation for the example client looks like:

After the client was deployed, you can add it using the toolbar of the editor's client area:

The appropriate property page looks like this:

The class RcpClientDetailsPage creates and layouts the shown controls.

If you do not want to implement the property section by yourself, it is possible to define the parameters directly in the extension point implementation. This results in a generic representation of the parameters. The property section for the client would then look like this:

Whereas the extension point implementation would be:

Now you have an idea of how to use the human task editor's client extension point. For more information about the attributes of the extension point, see the appended extension point documentation:


Document information

More support for:

WebSphere Integration Developer
Human Task Editor

Software version:

6.0, 6.0.1,,, 6.0.2,, 6.1,, 6.1.2, 6.2,,, 7.0,,,

Operating system(s):

Linux, Windows

Software edition:

All Editions

Reference #:


Modified date:


Translate my page

Content navigation