Developing a custom tree iWidget for WebSphere Business Space that retrieves data from a REST service using Apache Wink

Develop an iWidget to display a tree structure and deploy it in Business Space powered by WebSphere®. The iWidget you'll develop in this article is basically a viewer that fetches the data by invoking a RESTful web service, which returns data in JSON format. The article covers the Dijit Tree; the Dijit TabContainer; and the Apache Wink framework for invoking the RESTful service.


Venkat Yadavalli (, Associate IT Architect, IBM

Venkat Yadavalli is an Associate IT Architect at IBM India. He has about 7 years of experience in developing enterprise applications using SOA and J2EE technologies.

Vanya Jain (, Software Engineer, Progress Software

Vanya Jain is a Software Engineer at Progress Software, and was previously employed at IBM. She has about 3 years of experience in developing applications using J2EE and web service technologies.

13 July 2011

Also available in Chinese


Business Space powered by WebSphere provides an integrated user experience for business users across the IBM WebSphere Business Process Management portfolio. Business Space, a browser-based graphical user interface provides a customizable and collaborative environment for monitoring, reviewing, and administering common business processes, such as human task flows, modeling, and performance indicators. Business users can view the content they want to see in the way they want to see it by creating mashups.

Mashups are combinations of Web applications (widgets) configured on the pages of a business space that provide content from multiple sources.

An iWidget is a browser-based component model that encapsulates Web content and can participate in content presentation frameworks. It acts as a wrapper for any Web content that you create, such as servlets, Java™ Server Pages (JSP) files, HTML, PHP, or CGI. The iWidget component provides a descriptor that wraps the Web content and allows it to be placed in another application that can render it.

An iWidget is an XML file that can contain markup that is rendered and can be supported by JavaScript files for dynamic client-side scripting and CSS files for styling the markup. JSP, HTML, or HTML fragments can also contain markups, which can also be written in Ajax. Once an iWidget is in the framework, it can generate and receive client-side events, as specified in the widget wrapper.

iWidgets contain a definition file that defines the name, scope, and contents of the iWidget. It consists of two files:

  • An XML file specifying the widget resources, data, events, and HTML markup mode.
  • A JavaScript file defining a class that is instantiated to provide iWidget functionality.

The iWidget specification provides a standard event mechanism, iEvent, that allows iWidgets from disparate sources to communicate with each other. The specification also provides a context mechanism, iContext, which controls overall management of a page, including page-level controls, layout, coordination, and standard and user-defined services. For more information, refer to the iWidget Specification v1.0 (PDF).

Overview of the sample

In this article, you'll develop an iWidget that displays data in a tree structure and deploy it in Business Space. The iWidget that you'll develop is basically a viewer for the data that is being fetched from a repository. The data is fetched using RESTful web services and the mode of data interchange between the client and the service provider is JSON.

You'll use following Dojo widgets:

  • Dijit Tree with ItemFileReadStore(as the store) and ForestStoreModel(as the model)
  • Dijit TabContainer

Figure 1 depicts what we want to achieve: an iWidget running in Business Space fetching data from a store and displaying it in a tree structure.

Figure 1. iWidget in Business Space
iWidget in Business Space

(See a larger version of Figure 1.)

The sample code used in this article is provided for download in the Download section.

Install the packages

This section describes the prerequisites for this article and the steps for installing the required packages for developing iWidgets in IBM WebSphere Integration Developer.


You'll need the following software to develop and deploy the iWidget in this article.

For development:

  • IBM WebSphere Integration Developer V7.
  • Apache Wink client module JARs for RESTful web services consumption. (Download here.)
  • IBM Dojo framework (can be enabled from within WebSphere Integration Developer).

For deployment:

  • Business Space on WebSphere Process Server.
  • Apache Wink runtime. (Download here.)

Install the packages in WebSphere Integration Developer V7

WebSphere Integration Developer V7 and Rational® Application Developer V7.5 both provide development frameworks for iWidgets. For this article, we'll use WebSphere Integration Developer. When referring to the Integrated Development Environment (IDE), we're referring to WebSphere Integration Developer. When installing WebSphere Integration Developer make sure to include the Web development tools, as shown in Figure 2.

Figure 2. Install packages
Install packages

(See a larger version of Figure 2.)

The exact version and build ID of WebSphere Integration Developer V7 we used in this article are Version 7.0.0 and Build ID 7.0.0-20091130_1326 respectively, as shown in Figure 3.

Figure 3. WebSphere Integration Developer version
WebSphere Integration Developer version

Create and configure the web project

iWidget development starts with creating the container project. The first step is to create a web project.

  1. Select File => New => Dynamic Web Project to create a new web project, as shown in Figure 4.
    Figure 4. Create a new web project
    Create a new web project

    (See a larger version of Figure 4.)

  2. In the Dynamic Web Project wizard, choose WebSphere Process Server v7.0 as the target runtime, and check Add the project to an EAR, as shown in Figure 5.
    Figure 5. Specify project details
    Specify project details
  3. Click Finish.
  4. Right-click on the new project and select Properties => Project facets and check the following options, as shown in Figure 6:
    • Dynamic Web Module
    • Java
    • JavaScript Toolkit
    • Dojo Toolkit
    • WebSphere Web (Co-existence)
    • WebSphere Web(Extended)
    Figure 6. Configure project facets
    Configure project facets

    (See a larger version of Figure 6.)

    Among other things, this operation installs the Dojo Toolkit facet. After the operation completes, a Dojo folder is created in the WebContent folder, as shown in Figure 7.

    Figure 7. WebContent folder with Dojo folder
    WebContent folder with Dojo folder

    (See a larger version of Figure 7.)

You've now completed the configuration required to develop the iWidget in WebSphere Integration Developer.

Create the iWidget

You'll create the iWidget in the dynamic web project that you created in the previous section. To create the iWidget, complete the following steps:

  1. Right-click on the new web project, and select New => Other => iWidget, as shown in Figure 8.
    Figure 8. Create new iWidget
    Create new iWidget
  2. Specify a name for the iWidget and select Simple Widget for the iWidget type, as shown in Figure 9. Since you're only interested in creating a viewer, leave the Edit mode checkbox unchecked. Checking this box indicates to the IDE that the iWidget will have both view and edit modes.

    For more information on modes and switching from one mode to another, refer to the iWidget Specification v1.0 (PDF).

    Figure 9. Create a simple iWidget
    Create a simple iWidget

    Once the iWidget is created, the editor should look like Figure 10.

    Figure 10. iWidget editor
    iWidget editor

    (See a larger version of Figure 10.)

    The DemoProject1.xml file is the iWidget configuration file that contains information about the following things:

    • Available and supported modes
    • Events published by the iWidget
    • Events handled by the iWidget
    • Resources used by the iWidget
  3. Now you need to create the DemoProject1.js, a JavaScript file for handling the events and lifecycle methods of the iWidget. To do this, right-click the WebContent folder and select New => Dojo Class, as shown in Figure 11.
    Figure 11. Create a Dojo class
    Create a Dojo class
  4. Specify the name for the Dojo class as DemoProject1 and the file name as DemoProject1.js, as shown in Figure 12. This file is provided for download for your convenience.
    Figure 12. Create a JavaScript file for event handling
    Create a JavaScript file for event handling
  5. Now you'll configure the DemoProject1.js file to be the controller class for the iWidget by modifying the DemoProject1.xml file. In the iWidget editor, select the web project and specify the value for the iScope attribute as DemoProject1 (same as the name of the .js file) as shown in Figure 13.
  6. To add the .js file as a resource for the iWidget, select the web project, then click Add.
    Figure 13. Configure the iWidget controller
    Configure the iWidget controller
  7. Select Resource and click OK, as shown in Figure 14.
    Figure 14. Add the .js file as a resource to the iWidget
    Add .js file as a resource to the iWidget
  8. In the next dialog, specify the value for the Src and Id parameters of the resource, as jsId and DemoProject1.js respectively, as shown in Figure 15.
    Figure 15. Associate the resource to the iWidget
    Associate the resource to the iWidget
  9. Select File => Save to save DemoProject1.xml.

    Adding the >DemoProject1.js file as the iScope class enables it to handle the lifecycle methods, as well as other events for the iWidget.

  10. Now add content for the iWidget. The DemoProject1.xml file contains the containers for adding Dojo widgets programmatically. In our example, you'll create widgets programmatically, so DemoProject1.xml file will just contain HTML div tags that act as placeholders for dojo widgets that will be added at runtime.

    From the iWidget editor, select the Content (view) section and add the following content as shown in Figure 16:

    <div id="_IWID_LoadingDiv"></div>
    <div id="_IWID_ContentDiv"></div<
    Figure 16. Create iWidget placeholders
    Create iWidget placeholders
    The div element is added to show the message loading and for adding runtime content. Please note the convention used for the value of the id attribute. It is advisable to follow the same convention, so that it can later be changed in the code programmatically, if necessary.

In the next section, we'll cover the implementation details for the DemoProject1.js file.

Implement the code for the iWidget

Because we're only interested in creating a viewer, our focus is on two iWidget lifecycle methods: onLoad and onView, shown in Listing 1 and Listing 2.

The code snippet shown in Listing 1 for the onLoad method specifies that this method initializes and loads all dependencies that are required for the operation of the iWidget.

Listing 1. Code for onLoad () function
onLoad:function() {
 try {	
//Consolidated invocations of requires ().Here we can add all those 
//dependencies that will be required for the iWidget
var newHeight = this.iContext.rootElement.offsetParent.offsetHeight;
var newWidth = this.iContext.rootElement.offsetParent.offsetWidth;
if (newHeight > 0) {
 this.widgetHeight = newHeight;
 if (newWidth > 0) {
 this.widgetWidth = newWidth;
   this.widgetPath =;
   this.imagePath = this.widgetPath + "/images";
   var id = this.iContext.widgetId;
   this.contentDiv = dojo.byId("_"+ id + "_ContentDiv");
   this.loadingDiv = dojo.byId("_" + id + "_LoadingDiv");
  // set up loading message
  this.loadingDiv.innerHTML = "<img src=\"" + this.imagePath + "/loading.gif\"/>"+
 } catch (ex) {
    //call the mixed-in exception handler to catch/log 
//any exceptions that occur in here 
     this.handleException(this.CLASSNAME, "onLoad()", ex.message, ex);

The onView method is called immediately after onLoad. The code snippet shown in Listing 2 specifies that any element (Dojo widget) that needs to be rendered is created in this method and added to the DOM node of the container div.

Listing 2. Code for onView() function
onView:function() {
     //Display the loading message.

//This method holds the actual implementation where the Dijit controls are 
//instantiated and added to the contentDiv     

  //Hides the loading message.      


  • You can use console.debug statements for effective debugging of the JavaScript code.
  • Be aware that when console.* is used for debugging, widgets will not work Internet Explorer 6.

Now let's look at the definition of createView, shown in Listing 3 and other related methods. In this method the Dijit Tree widget is constructed, its node selection event is declared, and TabPanes are constructed.

Listing 3. Code for createView() function
createView: function(){
console.debug("Entered createView()"); 
//Rewrite the URI of the location of json data. It could be a response 
//from a web service, a static json file or any other json source.
var<”specify the source of json for the Tree

//Construct the Tree Store, and specify the url for the ItemFileReadStore
this._treeRequirementsStore = new{url:jsonUrl});
//If in onView the _treeRequirements exists, i.e old tree, 
//destroy it and create new
if(this._treeRequirements) {
if(this._treeRequirements.domNode && this._treeRequirements.domNode.parentNode) {
    this._treeRequirements = null;
//Construct the TreeModel, that interfaces with the store to fetch data 
this._treeModel = new dijit.tree.ForestStoreModel({
	store: this._treeRequirementsStore,
	query: {Id: "*"},
	rootId: "treedata",
	rootLabel: "TreeStructureData",
	childrenAttrs: ["children"]
//Construct the Dijit Tree, specify the model, the Tree widget 
//interfaces with the model and gets data for rendering   	
this._treeRequirements = new dijit.Tree({
		id: "_" + this.iContext.widgetId + "_myTree",
		model: this._treeModel,
		onClick :dojo.hitch(this, "handleNodeSelected")
//Add the tree DOM node to the contentDiv

//It’s always important to call the startup (). Without call to startup 
//the tree will not show up.  this._treeRequirements.startup();

 //This method creates the Tab Panes		

  console.debug("Exited createView()");

Now look at the implementation for the createTabContainer() method, shown in Listing 4.

Listing 4. Code for createTabContainer() function
createTabContainer: function(){
console.debug("Entered _createTabContainer");
//If tabcontainer object already exists; destroy the object and its descendants	
if(this.divTabContainer) {
if(this.divTabContainer.domNode && 
this.divTabContainer = null;

//Create the Dijit TabContainer
this.divTabContainer = new  dijit.layout.TabContainer({
id: "_" + this.iContext.widgetId + "_mainTabContainer"});
//Create Pane1, there can be many panes depending upon the requirement	 	
this.pane1 = new dijit.layout.ContentPane({
                 title : 'Properties',
                 id : "_" + this.iContext.widgetId + "_tab1"});
this.pane1.domNode.innerHTML="<b>Properties for the selected Requirement</b>";
//Add all the pane/panes to the TabContainer widget		
//Add the TabContainer dom node to the contentDiv	 		
//Finally startup the TabContainer.Its important to startup the widget.
console.debug("Exited _createTabContainer");

You can divide the construction of the Tree Widget into three phases:

Using the Apache Wink framework to consume a RESTful web service

After the DemoProject1.js file is ready, you can start to build the servlet code that will actually make calls to the RESTful web services and get data in JSON format. We'll use the Apache Wink Client module to consume the REST web services. Apache Wink is a simple but solid framework for building RESTful web services. It is comprised of a Server module and a Client module for developing and consuming RESTful web services.

The Wink Server module is a complete implementation of the Java API for RESTful web services (JAX-RS) v1.0 specification. On top of this implementation, the Wink Server module provides a set of additional features that were designed to facilitate the development of RESTful web services.

The Wink Client module is a Java-based framework that provides functionality for communicating with RESTful web services. The framework is built on top of the Java Development Kit (JDK) HttpURLConnection and adds essential features that facilitate the development of such client applications.

Figure 17 illustrates the Apache Wink client architecture.

Figure 17. Apache Wink client overview
Apache Wink Client overview

In the example in this article, we'll use the Apache Wink Client module to invoke the REST URI to retrieve the JSON data needed to build the tree. All required JAR files are included in the download package.

For more information about the Apache Wink framework, refer to the Apache Wink Developer Guide

Some of the main features of the Apache Wink Client framework are:

  • Serializes and de-serializes resources using configurable JAX-RS providers.
  • Provides built-in support for various content types, including Atom, JSON, RSS, APP, CSV, and Multipart, along with corresponding object models in Java.
  • Provides support for SSL and HTTP proxies.
  • Similar to the server-side framework, the client framework has a configurable handler chain for manipulating HTTP requests and responses.
  • By default, uses the class for its core HTTP transport.
  • Allows for easy customization of the core HTTP transport mechanism.

For the example in this article, the scope of the Apache Wink Client module usage is:

  • Ability to specify timeout for connect and read.
  • Ability to specify the media type of the response we expect.
  • Ability to make a get request to the service.
  • Ability to pass query parameters.
  • Ability to specify header information.

Listing 5 shows how the Apache Wink client can be used in a servlet for retrieving the data from a RESTful web service.

Listing 5. Code for doGetData() function
private void doGetData(HttpServletRequest request,HttpServletResponse response) 
throws IOException {
#1 ClientConfig config = new ClientConfig();  
#2 config.readTimeout(120000);
#3 config.connectTimeout(120000);
#4 RestClient client = new RestClient(config);
#5 PropertyReader propReader = new PropertyReader();
#6 Resource resource = client.resource(propReader.getProperty("getDataURL"));
#7 resource.queryParam("getDataQueryParam",”2424234”);

#8 String getData = resource.accept(MediaType.APPLICATION_JSON).get(String.class);
#9 String prefix = "{'identifier': 'Id', 'label' : 'name', 'items' : ";
#10 String suffix = "}";
#11 String fullData = prefix + getData + suffix;
#12 PrintWriter writer = response.getWriter();
#13 response.setContentType("application/json;charset=UTF-8");
#14 writer.println(fullData);
#15 writer.flush();

In Listing 5:

  • The first section (#1 - #4) of the code deals with creating a RestClient for invoking the REST service.
  • In the second section (#5 - #7), you see some custom class methods like PropertyReader, which reads the values of the resource URIs from a properties file using the resource bundle.
  • In the third section (#8), we're issuing a GET request in which the MediaType is JSON and we expect the response to be a JSON string.
  • In the fourth section (#9 - #15), we're building the JSON string such that ItemFileReadStore can identify it and dijit.Tree can render it. Finally, since this is a servlet, we set the appropriate content type and flush the data from the PrintWriter.

For more details, please refer to the sample code provided for download with this article.

Once the iWidget is ready, you can deploy the application to the Business Space server. We'll deploy our application in a standalone server from IBM WebSphere Integration Developer v7.0 using Jython scripts.

Package and register custom widgets in Business Space

Before deployment, you need to package and register the custom iWidget in Business Space. To use custom widgets in Business Space, they need to be registered in Business Space and the enterprise application that contains the custom widget must be deployed. The registration information about a custom widget is stored in registration files, including catalog files that contain information about widgets and widget catalogs and endpoint files that specify endpoints that are used by the widgets.

Create an endpoint file

An endpoint file characterizes a specific endpoint. Each endpoint is identified by its ID and points to a URL using the <url> tag. Every endpoint can have multiple versions distinguished by the <version> tag. See the sample endpoint file provided for download, and shown in Listing 6.

Listing 6. Sample endpoint file
<?xml version="1.0" encoding="UTF-8"?>
<tns:BusinessSpaceRegistry xmlns:tns=""
BusinessSpaceRegistry.xsd ">

<tns:description>Location of widget root for Ap233Widget</tns:description>


Create an endpoint file called demoProjectEndpoints.xml with the contents shown in Listing 6. This endpoint file can be created anywhere, but to keep it simple, right-click DemoProject and create a folder called endpoints and place the file in that folder.

Create a catalog file

A catalog file specifies widget categories and widgets. Widgets can be grouped together in categories. A category is identified by a name and contains a list of entries specifying the widgets that belong to the category. Each widget entry is identified by an ID.

The <definition> tag points to the widget’s definition file. The tags <icon>, <preview>, and <previewThumbnail> point to images that are used for widget representation in the list of available widgets in Business Space. The widget catalog uses the endpoint you specified in the demoProjectEndpoints.xml (endpoint://{demoproject}demoprojectWidgetRoot).

The catalog file also specifies a help topic for each widget. Listing 7 shows a sample catalog file.

Listing 7. Sample catalog file
<?xml version="1.0" encoding="UTF-8" ?>
     <category name="DemoProjectWidget">
		<nls-string lang="en">DemoProjectWidget</nls-string>
		<nls-string lang="en">DemoProject Widget</nls-string>
	<entry id="DemoProjectWidget" unique-name="DemoProjectWidget">
		<nls-string lang="en">DemoProject Widget</nls-string>
		<nls-string lang="en">DemoProject Widget</nls-string>
		      <nls-string xml:lang="en">DemoProject Widget</nls-string>
 <metadata name=""></metadata>
 <metadata name="">
International Business Machines Corp.

Create a catalog file called catalog_demoProject.xml with the contents shown in Listing 7. Right-click on DemoProject and create a folder called catalog and place the file in that folder.

Create the Jython script file for endpoint registration

Now that the registration files have been created, you need to create the administrative Jython scripts. Create another folder called install and place the Jython scripts in it.

Create a Jython script called with the contents shown in Listing 8.

Listing 8. Sample endpoint file
import sys
resourcePath = ‘<path to the demoProjectEndpoints.xml  file separated by  \\>'
AdminTask.updateBusinessSpaceWidgets('[-nodeName qnode -serverName server1 -endpoints "' 
+ resourcePath + '"]')


  • When working with Jython scripts, always use double backslashes to specify a separator in file paths.
  • In our example, we split the registration process into several steps. Endpoints and widgets are registered in Business Space independently; hence, we use the updateBusinessSpaceWidgets command.
  • You may need to change the nodeName and serverName to match your environment.

Create the Jython script for catalog registration

Create a Jython script called that contains the contents shown in Listing 9:

Listing 9. Sample catalog registration file
import sys
catalogPath = '<path to catalog_demoProject.xml  file separated by \\>'
AdminTask.updateBusinessSpaceWidgets('[-nodeName qnode -serverName server1 -catalogs "' 
+ catalogPath + '"]')

Deploy the iWidget to the Business Space server

Now that all the scripts and xml files have been created, it's time to register the custom widget by running the Jython scripts.

Register the endpoint

To run the Jython script you just created, complete the following steps, as shown in Figure 18.

  1. Right-click
  2. Click Run As => Administrative script.
  3. Select WebSphere Process Server v7.0 as the scripting runtime environment and a specify a profile name.
  4. Enter -connType NONE for wsadmin arguments and specify the security credentials, if necessary.
    Figure 18. Create a run configuration for the script
    Create a run configuration for the script

    (See a larger version of Figure 18.)

  5. Verify the registration of the endpoint by doing the following:
    1. Log in to the Integrated Solutions Console.
    2. Select Resources => Resource Environments => Resource Environment Providers.
    3. Select Mashups_Endpoints => Custom Properties.
    You should see the endpoints pertaining to the widget, as shown in Figure 19.
    Figure 19. Registered endpoints in the server console
    Registered endpoints in the server console

    (See a larger version of Figure 19.)

Register the catalog file

To register the catalog file, do the following:

  1. Follow the same steps as in the previous section but run as an administrative script.
  2. To verify the registration of the catalog_DemoProject.xml, complete the following steps:
    1. Log in to the Integrated Solutions Console.
    2. Select Resources => Resource Environments => Resource Environment Providers.
    3. Select Mashups_BlobConfigService => Custom Properties.
    4. Verify that there is an entry for catalog_DemoProject.xml, as shown in Figure 20.
    5. If the catalog endpoints don't show up in the Integrated Solutions Console, you may need to restart the server.
      Figure 20. Registered catalogs in the server console
      Registered catalogs in the server console

      (See a larger version of Figure 20.)

Finally, install the enterprise application (the EAR project) for the widget on the server using the procedure described in Deploy the REST service.

Deploy the REST service

The source code provided with this article includes a sample RESTful service (DemoProjectService.war). To deploy this file, complete the following steps:

  1. Log in into the Integrated Solutions Console, as shown in Figure 21.
    Figure 21. Log in to Integrated Solutions Console
    Log in to Integrated Solutions Console
  2. Select Applications => Application Types => WebSphere Enterprise Applications, as shown in Figure 22.
    Figure 22. Select enterprise applications to install
    Select enterprise applications to install

    (See a larger version of Figure 22.)

  3. Click Install, as shown in Figure 23.
    Figure 23. Install the WAR file
    Install the WAR file

    (See a larger version of Figure 23.)

  4. Click Local file system and browse to the location of the DemoProjectService.war, then click Next, as shown in Figure 24.
    Figure 24. Select the WAR file to be deployed
    Select the WAR file to be deployed

    (See a larger version of Figure 24.)

  5. Select Fast Path and click Next, as shown in Figure 25.
    Figure 25. Select Fast path deployment
    Select Fast path deployment

    (See a larger version of Figure 25.)

  6. On the next screen, click Next, as shown in Figure 26.
    Figure 26. Configure installation options
    Configure installation options

    (See a larger version of Figure 26.)

  7. Click Next again, as shown in Figure 27.
    Figure 27. Map modules to servers
    Map modules to servers

    (See a larger version of Figure 27.)

  8. Specify /DemoProjectService for Context Root and click Next, as shown in Figure 28.
    Figure 28. Map context roots for web modules
    Map context roots for web modules

    (See a larger version of Figure 28.)

  9. Click Finish.
    Figure 29. View configuration for deployment
    View configuration for deployment

    (See a larger version of Figure 29.)

  10. You'll see a message indicating that the installation is in progress, as shown in Figure 30.
    Figure 30. Installation in progress
    Installation in progress

    (See a larger version of Figure 30.)

  11. When the installation is complete, click Save directly to the master configuration, as shown in Figure 31.
    Figure 31. Save changes to the master configuration
    Save changes to the master configuration

    (See a larger version of Figure 31.)

  12. In the Deployed Applications view, check DemoProjectService.war and click Start, as shown in Figure 32.
    Figure 32. Start the deployed application
    Start the deployed application

    (See a larger version of Figure 32.)

  13. To verify the service deployment, open a web browser to the following URL: http://localhost:9082/DemoProjectService/rest/demodata. Change the port number as appropriate for your server environment.


    • For interacting with web services and other web resources, you can install an extension to the browser (such as POSTER for Firefox) to do a test POST. For more information, refer to the Resources section.
    • For examining JSON structures, you can install a browser extension, such as JSONView for Firefox, so that the JSON payload is displayed directly on the browser screen. For more information, refer to the Resources section.
    If you see responses like those in Figure 33 and Figure 34, the service is successfully deployed.
    Figure 33. RESTful service returning data
    RESTful service returning data

    (See a larger version of Figure 33.)

    Figure 34. JSON response from the RESTful service
    JSON response from the RESTful service

    (See a larger version of Figure 34.)

Test the widget using the Universal Test Client in WebSphere Integration Developer

You can test widgets at various stages of the development process. WebSphere Integration Developer V7 provides a Universal Test Client (UTC) to test iWidgets before they are registered in Business Space. Mozilla® Firebug, a plug-in for Mozilla Firefox®, is another tool for testing widgets that provides some additional debugging possibilities. For example, Mozilla Firebug shows all HTTP requests when a page is loaded and displays errors that occur when JavaScript code is executed.

Note: Make sure that the RESTful web service WAR is deployed, as described in Deploy the REST service.

The UTC provides the ability to test a widget in a sandbox mode before it is registered in Business Space, which enables you to test a widget in isolation. To test, for example, the DemoProject widget using the UTC, perform the following steps.

  1. Right-click the widget definition file DemoProject1.xml in the Enterprise Explorer.
  2. Select Run As => Run on Server.
  3. Select a server from the list and click Finish.

The UTC for iWidgets is a JSP that reads the content from a widget definition file. To use the UTC together with Mozilla Firebug, the JSP must be opened in Mozilla Firefox. To get the URL for the UTC for iWidgets JSP, right-click Universal Test Client for iWidgets and select Properties. The the URL is shown in the Address field.

Figure 35 shows the iWidget in the UTC.

Figure 35. iWidget in UTC
iWidget in UTC
  1. Enable Mozilla Firebug in Mozilla Firefox by doing the following:
    1. From the Firefox browser window, select Tools => Add-ons.
    2. In the Add-ons window, select the Get Add-ons tab.
    3. In the search field, type Firebug and click Enter.
    4. Select Firebug Add-on and click Add to Firefox.
    5. Click Install.
    6. Once the add-on is installed, you can enable it the bug icon Bug icon in the lower right corner of the browser window.
  2. Open the URL to the Universal Test Client for iWidgets JSP in Mozilla Firefox, as shown in Figure 36.
    Figure 36. iWidget in Firefox
    iWidget in Firefox

Note: For information on debugging and troubleshooting iWidgets, refer to the Resources section.

Follow these simple steps to see the widget in Business Space:

  1. From the Servers view of the WebSphere Integration Developer, right-click the server name and select Launch => Business Space, then log in.
  2. Select Manage Space at the top, then click Create Space and name the new space Demo Space.
  3. In the Space Manager window, select Demo Space and click Edit Page.
  4. Drag the DemoProject widget, which is already registered to the server, onto the page. The DemoProject widget runs and displays the data in a tree, as shown in Figures 37 and 38.
    Figure 37. iWidget in Business Space
    iWidget in Business Space

    (See a larger version of Figure 37.)

    Figure 38. iWidget displaying data in tree structure
    iWidget displaying data in tree structure

    (See a larger version of Figure 38.)


In this article, you have learned how to develop an iWidget in Websphere Integration Developer. You have created an iWidget that is basically a viewer that fetches the data from a store by consuming a RESTful web service. The article showed you the detailed steps to deploy and run the iWidget in WebSphere Business Space. It also described the Apache WINK framework and how the RESTful web services can be communicated using the Client module of that framework.


Deployable REST serviceDemoProjectRESTService.war5MB
Project interchange for sampleDemoProjectWidgetPI.zip13.2MB



Get products and technologies


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
ArticleTitle=Developing a custom tree iWidget for WebSphere Business Space that retrieves data from a REST service using Apache Wink