Realizing the value of IBM Business Process Manager in the WebSphere Portal environment, Part 3: Agile development of custom user interfaces using Web Experience Factory

This article introduces an agile approach to developing custom user interface components for IBM® BPM processes leveraging the IBM Business Process Manager REST API. By adding a transformation layer between IBM BPM and IBM Web Experience Factory, you can create user interfaces and adapt them to process data changes with little effort. This content is part of the IBM Business Process Management Journal.


Wolfram Richter, Certified IT Specialist, IBM

Wolfram Richter photoWolfram Richter is a consultant with the IBM Software Services for WebSphere organization. He has a 9-year history in IBM middleware and BPM technology, and specializes in integrating SAP solutions with IBM software. Before his current assignment, he worked as a pre-sales IT specialist and in education and training. Wolfram lives and works in Germany. In his spare time, he likes to spend time with his family, go jogging and fix things in his house. As he writes this, Wolfram realizes that there can never be enough spare time.

Sandro Schwedler, Certified IT Specialist, IBM

Photo of author, Sandro SchwedlerSandro Schwedler works as an Certified IT Specialist for IBM Software Collaboration Services. His areas of expertise include middleware, XML, Portlet, and Java Enterprise Edition (JEE) development. He holds a degree in Information Technology from the Berufsakademie Stuttgart, Germany.

26 September 2012


Part 1 of this article series explained how IBM WebSphere® Portal can augment IBM Business Process Manager (IBM BPM) with capabilities such as advanced personalization of user interfaces and content management. Part 2 showed you how to integrate the native IBM BPM user interface technology (Coaches) into the portal environment. This article explains how to create native portal UI components (portlets) to implement a custom user interface for IBM BPM tasks using IBM Web Experience Factory. It focuses on the "completing work" use case, creating a task processing portlet that retrieves and displays the task input data from IBM BPM and is able to complete the task with the results provided by the user. Such a portlet can leverage advanced WebSphere Portal concepts and APIs such as dynamic user interfaces, inter-portlet communication, personalization and mobile UIs.

This article introduces a novel approach to process data received by REST API by introducing an additional processing step. This step transforms the business data payload of the API call results into an XML format that is described by an XML Schema. UI generating tools, including but not limited to the Web Experience Factory, can use this schema to automatically generate the UI and bind it to the business data.

This approach is very agile: most of the required code is generic and can be provided as a library before starting the development. The initial creation of a user interface is a predetermined sequence of steps which could even be automated. A change in the task input or output data structures is simply a matter of regenerating and reimporting the schema. The traditional approach to consuming the REST API would require much more effort: for each task, the user interface developer would need to add each UI control individually and would need to add specific coding logic to bind each UI control to the API call results or inputs. This set of controls and the coding would have to be revisited whenever the task input or output data structures change.

While this article focuses on Web Experience Factory, the general approach is applicable to any framework that supports automatic UI generation based on XML schema. The Web Experience Factory related part of this article does not provide step-by-step instructions. An understanding of common Web Experience Factory concepts like builders and service models is required to follow and recreate the scenario. Please have a look at the Web Experience Factory wiki to get an understanding of these concepts.

Technical environment considerations

A fully portal-based UI also requires other use cases to be implemented that are out of the scope of this article. Most important is the "get next task from list" use case: here the user is shown a task list that allows him or her to pick the task to work on. This task list has to provide the task ID to the task processing portlet. The Unified Task List can fulfill this role, and it is simple to create a custom task list portlet using the IBM BPM REST API. The article Advanced techniques and patterns for business process client development provides detailed information how to use dynamic user interface technology in WebSphere Portal to connect a task processing portlet with a task list.

Page flow

Using Human services and the REST API, it's possible to use IBM BPM as a page flow engine to WebSphere Portal. This means that the sequence of pages within a portlet or a sequence of dynamic UI portal pages could be modeled and executed in IBM BPM.

The portlets can use the Resume Service API call to nudge the Human service to its next state, and can modify its variables using the Get/Set Data Service API calls. The sample code provided with this article can also handle Human service models. A detailed discussion of this approach is however outside of the scope of this article.

IBM BPM business process definitions (BPDs) provide two options for user task implementations:

  • Human services are the typical IBM BPM UI, consisting of a number of Coaches, the page flow logic between them, and the management of input, output and private variables.
  • External implementations manage only input and output variables and do not contain any UI logic. That logic needs to be implemented externally to IBM BPM, hence the name. They used to be called external activities in WebSphere Lombardi Edition and earlier versions, a name which still appears in IBM BPM in some places, such as the REST API.

This article's portlet uses an external implementation to retrieve the task input data from IBM BPM and to provide the completed task output to IBM BPM.

The sample code provided with this article has been tested with IBM Business Process Manager V7.5.1, WebSphere Portal V8 and Web Experience Factory V7. Since the REST API calls did not change significantly in IBM BPM V8, we expect the scenario to work with the latest release of IBM BPM.

Single Sign-On (SSO) between WebSphere Portal and IBM BPM must be configured in order to be able to forward authentication tokens from WebSphere Portal to IBM BPM. For development or proofs-of-concept HTTP basic authentication may be sufficient. The Information Centers of both products provide detailed information how to configure SSO.

Overall development approach

Developing a scenario where WebSphere Portal is the user interface for IBM Business Process Manager is straightforward when using the Web Experience Factory (see Figure 1):

  1. The IBM BPM developer designs the BPD, or the sequence of activities and decision nodes, as well as process data structures.
  2. The IBM BPM developer then provides implementations for each activity. Activities using the IBM BPM native UI can be implemented using Human services. Activities using a portal-based UI should be implemented as external implementations.
  3. The IBM BPM developer plays back the BPD, navigating to the external implementation, and passes its task ID to the portlet developer.
  4. The portlet developer queries the external implementation model using the REST API. The API call results contain a description of the input and output variables, though not in XML Schema Definition (.xsd) format.
  5. To make them consumable in Web Experience Factory, the portlet developer transforms the API call results into XSD using an XSLT stylesheet and imports the resulting schema definition into the model.
  6. The portlet developer creates a user interface for these input and output data structures. Since the type information is now available in XSD format, this step is automated using Web Experience Factory.
  7. The portlet developer wires the user interface to the proper API calls, especially for retrieving the task input data and providing the task output data upon completion of the task. This again requires some transformation: the task input data needs to be transformed so it will match the XSD in step 3, and the task output data needs to be transformed into the JSON format that the API call expects as input.
  8. Whenever the signature of the external implementation changes (which might happen rather frequently with an agile development approach), the portlet developer simply re-executes step 3. This causes the XSD to be updated, which automatically alters the UI generated fromit. Of course, if the data structures change significantly, further fine-tuning of the UI might become necessary.

Figure 1 illustrates the development approach.

Figure 1. Overview of the development approach
UML sequence diagram of the development approach

(See a larger version of Figure 1.)

This development approach uses two REST API calls at development time to query the model metadata:

  • Task API / Get Task Details provides the external activity ID required to retrieve the external implementation model.
  • Process API / Get External Activity Model returns the external implementation model, including a description of the input and output data formats in the <item><value> XML format described in Listing 1.

Acquire an XML schema for external implementations

An XSD of the external implementation's input and output data structures is key for an efficient development approach. It enables the Web Experience Factory builders to automatically generate the user interface - without having to program each input field manually. This allows for efficient iterative development where changes to the data structures can be incorporated by simply reimporting an updated schema definition.

The IBM BPM tooling does not provide a native capability to export the signature of an external implementation as XSD files. The workaround, to create a General System service or Integration service with the same signature, to expose it as web service operation and to retrieve its WSDL, requires unnecessary effort on the part of the IBM BPM developer. Another approach is to infer a schema from sample data. By applying heuristics, a value of "true" could be interpreted as xsd:boolean, a value of "hello" as xsd:string, a value of "123" as xsd:integer, and two or more occurrences of a value as an array, and so on. For input and output data structures, it is however very laborious to provide sufficiently complex sample data. However, this may be a valid approach for simple data structures where sample data can be created fairly easily, such as the task list.

Using the REST API, the HTTP GET call against the external implementation Model Resource returns a description of the external implementation model. Listing 1 contains a sample of such a model represented in XML. This description is structured as name/value pairs, both in the XML and JSON representation.

Listing 1. External implementation model in XML (excerpt, edited for brevity)
<bpm:ResponseData xmlns:bpm=""
    <data xmlns:xsi=""
        <name>GM Approval EA</name>
        <customProperties />
            <item key="requisition">
                <value xsi:type="cmn:Map">
                    <item key="type">
                        <value xsi:type="ns7:string">Requisition</value>
                    <item key="isList">
                        <value xsi:type="ns7:boolean">false</value>
            <item key="currentPosition">
                <value xsi:type="cmn:Map">
                    <item key="type">
                        <value xsi:type="ns7:string">Position</value>
                    <item key="isList">
                        <value xsi:type="ns7:boolean">false</value>

While this is not an XML schema that the Web Experience Factory can consume, the XML representation can be easily converted into XSD using an XSLT transformation. We enjoy a certain freedom when creating such an XML schema definition, since the schema will not be used to describe the interface of the external implementation per se. The REST API provides all call results, including the task input data, as name/value pairs like the model shown in Listing 1. When submitting the task results back to the IBM BPM server, the REST API expects the task output data to be provided as JSON.

The conversion needs to ensure that the provided input data can be converted into a valid XML document to populate the UI controls, and that a valid XML document containing the task output data can be converted into the proper JSON format that the IBM BPM server expects as result of the external implementation. Ideally, the schema should allow representing and distinguishing between the following features without having to resort to additional standards such as xml schema instance (xsi):

  • simple typed data, such as xsd:string , xsd:dateTime , xsd:integer , etc.
  • empty xsd:string
  • complex typed data
  • arrays
  • empty arrays
  • null (unset) values

Sample transformation tools

Sample transformation tools are provided for download with this article. They use the following strategy to create a schema:

  • Complex typed data is represented as <xs:complexType><xs:sequence>.
  • Null values are represented as non-existing elements. Therefore, all <xs:element>s have the attribute minOccurs="0".
  • Arrays are not represented using the attribute maxOccurs="unbounded". This would not allow distinguishing between a null value for the array and an empty array. Instead, arrays are represented as anonymous complex types containing a <xs:sequence> of <xs:element>s named "item" and typed with the translated array item type. Therefore, for a null array there is no element, for an empty array there is an empty element with the name of the IBM BPM data field, and for an array with values there is an element with the name of the IBM BPM data field, which contains one element called "item" for each array item.
  • Simple typed data is represented using the corresponding XSD simple type. An empty string is therefore an empty element.
  • The set of external implementation input and output data fields is translated into <xs:complexType>s, whose name is a concatenation of the external implementation name and "_input" or "_output" respectively.
  • Optionally, an arbitrary target namespace can be defined.
  • Optionally, global elements can be created for all complex types with the same name as the type.

The sample code should be treated as such; it is not optimized for performance and has not been tested extensively for functional issues. It consists of three Java™ classes:

  • sample.bpm.schemagen.ActivityImplementationModel analyzes the XML representation of an external implementation model or Human service model and generates an XSD. It provides access to key information such as model name, input and output data types, private variables (for Human services), and so on.
  • sample.bpm.schemagen.TaskDetails analyzes the XML representation of the Task Details REST API call results. It converts the task input data into XML which validates against the schema generated by ActivityImplementationModel.
  • sample.bpm.schemagen.XMLtoJSONHelper takes a valid XML representation of the task output data and converts it into JSON suitable for completing the task.

As an example, Listing 2 is the transformed external implementation model of Listing 1. The XML <item><value> information has been transformed into a valid XML schema, and additional information on the model is made available.

Listing 2. Results of ActivityImplementationModel.analyzeHSorEAModel() (excerpt, edited for brevity)
implname:	GM_Approval_EA
impltype:	1
isExtAct:	true
isHumSrv:	false
inputType:	{http://targetnamespace}GM_Approval_EA_inputs
outputType:	{http://targetnamespace}GM_Approval_EA_outputs

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema elementFormDefault="qualified" targetNamespace="http://targetnamespace"
    xmlns:bpm="" xmlns:tns="http://targetnamespace"
    <xs:complexType name="GM_Approval_EA_inputs">
        <xs:sequence maxOccurs="1" minOccurs="1">
            <xs:element maxOccurs="1" minOccurs="0" name="currentPosition" 
                type="tns:Position" />
            <xs:element maxOccurs="1" minOccurs="0" name="requisition" 
                type="tns:Requisition" />
    <xs:element name="GM_Approval_EA_inputs" type="tns:GM_Approval_EA_inputs" />
    <xs:complexType name="Requisition">
        <xs:sequence maxOccurs="1" minOccurs="1">
            <xs:element maxOccurs="1" minOccurs="0" name="approvalNeeded" 
                type="xs:boolean" />
            <xs:element maxOccurs="1" minOccurs="0" name="date" type="xs:dateTime" />
            <xs:element maxOccurs="1" minOccurs="0" name="department" type="xs:string" />
            <xs:element maxOccurs="1" minOccurs="0" name="empNum" type="xs:integer" />
            <xs:element maxOccurs="1" minOccurs="0" name="gmApproval" type="xs:string" />
            <xs:element maxOccurs="1" minOccurs="0" name="gmComments" type="xs:string" />
            <xs:element maxOccurs="1" minOccurs="0" name="instanceId" type="xs:string" />
            <xs:element maxOccurs="1" minOccurs="0" name="location" type="xs:string" />
            <xs:element maxOccurs="1" minOccurs="0" name="reqNum" type="xs:string" />
            <xs:element maxOccurs="1" minOccurs="0" name="requestor" type="xs:string" />
            <xs:element maxOccurs="1" minOccurs="0" name="status" type="xs:string" />

Prepare the BPD

The BPD used for this scenario is a modification of the Hiring Sample. This BPD is available in each IBM BPM installation, but needs to be adapted to employ an external implementation. To do this, create an external implementation with the same input and output data structures as the GM Approval Human service shown in Figure 2.

Figure 2. External implementation for the GM Approval
External implementation for the GM Approval

In the BPD, select the GM Approval activity and choose the newly created external implementation as the implementation. Don't forget to recreate the input and output mappings from and to the process variables.

Web Experience Factory development

Two REST API calls are required to properly complete an external implementation:

  • Task API / Get Task Details provides the task input data in the <item><value> format shown in Listing 1.
  • Task API / Complete Task requires the task output data, rendered in URL-encoded JSON format.

Other typical task handling use cases, such as claiming, unclaiming or reassigning tasks, are outside of the scope of this article. Nevertheless, you can use the same technical approaches with them as well. Figure 3 shows the runtime behavior of the web application (portlet) to be built. The Web Experience Factory retrieves the task input data from the IBM BPM Process Server and transforms the task data into an XML format. This XML is valid according to the XSD of the business objects created during development and can, therefore, be rendered in the generated UI. To complete the task, the task output data is transformed into the URL-encoded JSON format required by the API before submitting it to the IBM BPM server.

Figure 3. Runtime behavior of the target solution
Runtime behavior of the target solution

Because of the different viewpoints of IBM BPM and portlet developers, it's important to agree on the following terms to prevent confusion:

  • Task input data is what is provided to the end user (IBM BPM viewpoint). It is, however, the output of the Get Task Details REST API call (Web Experience Factory viewpoint).
  • Task output data is the result of the end user's doing and is to be returned to IBM BPM in order to continue the process (IBM BPM viewpoint). It is input to the Complete Task REST API call (Web Experience Factory viewpoint).

In the following sections, the Web Experience Factory viewpoint is used whenever input or outputs of API calls are being referenced, and the IBM BPM viewpoint is used when referring to task input or output data.

Consuming an IBM BPM REST service operation in Web Experience Factory

Web Experience Factory includes a REST Service Call builder that can invoke all REST APIs provided by IBM BPM, as shown in Figure 4. It can execute every HTTP method and work with any type of content, be it JSON or XML. It can also generate result schemas from sample invocations or allow you to provide your own custom schema for the invocation results. The following section describes how you can use this builder to execute any kind of IBM BPM REST operation, using the Get Task Details API call as an example. Note that the concepts explained in this section are wrapped in service provider models for IBM BPM available for download with this article.

Normally the URL of the REST endpoint is provided as an input parameter in the builder configuration interface. Since most IBM BPM REST API operations parameters like the task ID are part of the URL, the URL needs to be built dynamically during runtime. Because of this, the REST Service Call builder needs to be combined with an Action List builder in which the URL is assembled.

Figure 4. A variable defines the REST URL for the REST Service Call builder
A variable defines the REST URL for the REST Service Call builder

Create a variable and use this variable as parameter for the URL of this REST call, as shown in Figure 4. Add an Action List builder call to initialize this variable with a value provided as input to the operation of the service model. The Action List builder initializes the URL variable based on a base variable (server and port) and extends it with dynamic information such as the task ID. Then it executes the REST service call and returns the result of this call, as shown in Figure 5.

Figure 5. An Action List initializes the REST URL and executes the REST operation
Action table in an Action List initializing the REST URL and executing the REST operation

The REST service call builder also needs a schema for the result of the call. This is the schema of the base API call, including the task input data payload in <item><value> XML format, and not the schema of the business object itself. By default the builder executes the HTTP method on the URL provided and infers a schema based on the retrieved result. Since the URL is assembled dynamically and therefore is not available at development time, a sample result needs to be provided. The easiest way to do that is to deploy a text file containing a sample result on the development server. Place the text file in your Web Experience Factory project directly in, or in a subdirectory of, WebContent and deploy the project. Enter the URL of this file as sample result as shown in Figure 6. Check Cache Schema to indicate that you don't want Web Experience Factory to rebuild the schema during runtime. This ensures the model will also work outside of the development environment.

Figure 6. Deploying a sample XML result on the development server for schema generation
Result schema section of the REST service call builder

The REST Service Call builder allows for providing a username and password to leverage HTTP basic authentication. This option is not useful outside of testing scenarios because the end user credentials are not available after login. The Advanced section of builder allows you to configure the forwarding of HTTP cookies. This way, an authentication token can be sent from Portal to IBM BPM by forwarding the LtpaToken2 cookie to IBM BPM. For the token to be accepted by IBM BPM, SSO needs to be configured as described earlier.

Errors during service invocation can occur at multiple places, such as the transport layer or within IBM BPM. The former result in an exception being thrown in the REST call, which can be caught and handled by an error handler. The latter results in an HTTP status code other than 2XX in the response, which can be queried and reacted on in the Action List (row 5 in Figure 5).

Finally, add a Service Operation builder and wrap the action list. This way service consumers can integrate the operation and provide a user interface for this operation.

Consuming the IBM BPM API service models

The service models provided for download provide a generic layer you can use to speed-up IBM BPM client development in Web Experience Factory. These models are aligned with the grouping of API calls used by the IBM BPM REST API tester and follow the implementation approach described in Consuming an IBM BPM Rest service operation in Web Experience Factory. There are three different service models:

  • IBPMProcessAPI.model provides operations to retrieve process related meta-information, such as the External Activity model describing (among other things) the business object structure of an external implementation.
  • IBPMServiceAPI.model contains operations on Human services that are not currently used in this example.
  • IBPMTaskAPI.model includes operations to manipulate a task, such as retrieving task details including input data, claiming, unclaiming and completing a task.

The service models were designed to be a generic low-level representation of the REST API. They do not translate the API call inputs or results, and operate on the untranslated HTTP bodies used in the REST API.

Figure 7. Generic service models wrapping IBM BPM REST API calls
The Project Explorer displaying the the service models for consuming IBM BPM REST operations.

All operations included in these models follow best practices for Web Experience Factory development. Using a Service Consumer builder call, you can consume these services in your models to implement a user interface for an IBM BPM external implementation. You can also run the service models without any user interface model because Add Testing Support has been enabled.

Server name, user name and password must be provided as context variables. You can specify these values in the Context Variables section of the Service Consume Builder, as shown in Figure 8.

Figure 8. In Service Consumer builder you can specify server endpoint settings for the task service model
Context Variables section in the Service Consumer builder

Schema generation for task input and output data

As described in Acquire an XML Schema for external implementations at development time, Web Experience Factory needs an XML schema describing the task input and output data itself to generate a user interface. Such a schema differs from the one created by the REST Service Call builder, which describes the <item><value> formatted XML stream. To add the schema to your model, do the following:

  1. Store the Get External Activity model REST API call results in a file. This can be done either by copying and pasting from the IBM BPM REST API Tester web application, or by running it through the TCP/IP Monitor. This API call expects an External Activity ID as input, which can in turn be acquired using the Get Task Details REST API call on a sample task.
  2. Run the XML file through the analyzeHSorEAModel operation in the ActivityImplementationDescription class. The class contains a main method which takes a reference to the XML file and an optional target namespace as parameters and prints out the task input and output schema and additional metadata as depicted in Listing 2.
  3. The generated task input and output data schema can be imported using a Schema builder call and used in a Variable builder call (builder calls 7,8 and 9 in Figure 9). With that schema you can use standard Web Experience Factory techniques to generate a user interface (builder calls 10 and 11 in Figure 9). This approach applies to the input data as well as the output data of the task.

XML transformation at runtime

Generating a schema at development time is the first use case of the sample transformation classes described above. These classes are used again for the initialization and transformation of the task input and output data at runtime.

The getTaskDetails operation in the IBPMTaskAPI service model takes a task ID as input and returns an IXml structure containing both task metadata and input data in the format described in Listing 1. Listing 3 provides a sample of how to retrieve the task input from the results of the Get Task Details API call. It retrieves the task input data schema from the web application and identifies its target namespace and the input data root element. It then invokes the static TaskDetails.analyseTaskDetailsXML() method and returns the resulting XML document as an IXml object.

Listing 3. Retrieving a task input variable from the Get Task Details API call results
import org.w3c.dom.Document;
import com.bowstreet.webapp.Schema;

public IXml getTaskInputFromTaskDetails(WebAppAccess webAppAccess,
        IXml taskDetailsData, String schemaBuilderCallName) 
            throws TransformerException {
    //get a DOM representation of the Get Task Details API call results
    Document taskDetailsDataDoc = XmlUtil.createDOM(taskDetailsData);
    //get target namespace from schema
    Schema schema = webAppAccess.getWebApp().getSchema(schemaBuilderCallName);
    String tns = schema.getSchema().getTargetNamespace();
    //find task input data root element
    String rootElement = "root";
    try {
        for (String elem : schema.getSchema().getRootElements()) {
            if (elem.endsWith("_inputs")) {
                rootElement = elem;
    } catch (Exception e) {            
        e.printStackTrace(); //should not happen
    // convert results from Get Task Details API call to XML
    TaskDetails td = 
        TaskDetails.analyseTaskDetailsXML( rootElement , tns, taskDetailsDataDoc);    
    return XmlUtil.createXml(td.getData());    

The completeTask operation in the same service model expects a String containing a URL-encoded JSON representation of the task output data. Listing 4 is an example for the conversion of the task output data into the URL-encoded JSON format. It creates DOM representations of the task output data and the schema and invokes the static XMLtoJSONHelper.getURLEncodedJSONfromXML() method to perform the conversion.

Listing 4. Transforming a Web Experience Factory IXml variable to a URL-encoded JSON string
import org.w3c.dom.Document;
import com.bowstreet.webapp.Schema;


public String getJSONFromVariable(WebAppAccess access, IXml outputVariable, 
		String schemaBuilderCallName) throws TransformerException {
    Schema schema = access.getWebApp().getSchema(schemaBuilderCallName);
    Document outputDom = XmlUtil.createDOM(outputVariable);
    Document schemaDom = XmlUtil.createDOM(schema.getSchema().getSchemaSource());
    return XMLtoJSONHelper.getURLEncodedJSONfromXML(outputDom, schemaDom);

Use a Linked Java Object (builder call 5 in Figure 9) to make the transformation operations in these classes available to the Web Experience Factory model. Using an Action List, you can assign the transformed data to a variable or invoke a service operation with it.

Building a portlet

Figure 9 shows the model of a simple task processing portlet, available for download. It contains only the builder calls necessary for the complete work use case and very little beautification of the generated UI (builder calls 12-16). In a real-world scenario, further calls would be necessary to interact with a task list (the task ID is provided in a variable, builder call 6) or to handle portal dynamic user interfaces. Using the page automation features of Web Experience Factory, the user interface could be further improved by adding Web 2.0 features like drag and drop or type ahead.

Figure 9. Model of a task processing portlet for the GM approval step in the Hiring Sample
Model of a task processing portlet for the GM approval step in the Hiring Sample

Figure 10 shows the sample portlet presenting an input form and a submit button to complete the task.

Figure 10. Portlet UI for the "GM approval" step in the Hiring Sample
The Hiring portlet running in WebSphere Portal 8

Helpful tools for dlient development

For IBM BPM client development, two tools greatly improve productivity and speeds up understanding of the IBM BPM APIs:

  • The REST API Tester web application allows testing any REST call from a browser window and displays the request structure, as well as the results of the call. You can access the REST API Tester at http://server:port/bpmrest-ui.
    Figure 11. The REST API Tester enables testing all REST services available on IBM BPM
    The REST API Tester enables to test all REST services avaiable on IBM BPM
  • A TCP/IP Monitor like the one available in Eclipse allows tracing any TCP/IP call, so you can monitor HTTP headers, HTTP bodies and HTTP error messages. Just configure a local port to receive packages and a server and port as a receiver of the port. Working alongside the IBM BPM Rest API Tester, you can monitor the REST calls including HTTP header and body messages. Note that the TCP/IP Monitor will not work for HTTPS messages. It is recommended that you develop using HTTP and enable HTTPS in production environments.
    Figure 12. The built-in Eclipse TCP Monitor displaying an IBM BPM Rest call
    The built-in TCP Monitor of Eclipse displaying an IBM BPM Rest call.


The authors would like to thank Julia Butzeck and Hauke Juhls for reviewing this article and providing valuable feedback.


This article showed how portlet user interfaces for IBM BPM tasks can be generated almost automatically using Web Experience Factory. All of the sample code provided is generic and works with any task input or output data structure. The accompanying development approach to create a task UI consists of following a short sequence of predetermined steps. It also enables the rapid turnaround cycle required by agile development: a change in the task input or output data is just a matter of re-executing some of these steps. The remaining manual activities - acquiring the external activity model, transforming it to a schema definition and importing it - could even be wrapped in a custom builder to fully automate the task.


Transformation sample sourcesample.bpm.schemagen.jar29KB
Factory ArchivebpmIntegrationSample.zip66KB



developerWorks: Sign in

Required fields are indicated with an asterisk (*).

Need an IBM ID?
Forgot your IBM ID?

Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name

The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.


All information submitted is secure.

Dig deeper into Business process management on developerWorks

Zone=Business process management, WebSphere, DevOps
ArticleTitle=Realizing the value of IBM Business Process Manager in the WebSphere Portal environment, Part 3: Agile development of custom user interfaces using Web Experience Factory