Configuring IBM Business Process Management Human Task Management widgets for use in WebSphere Portal

The Human Task Management widgets in IBM® Business Process Manager V7.5 are designed to run in a Business Space environment, but they can also be run in IBM WebSphere® Portal V7. This article describes how to install, configure, and customize these widgets in a Portal environment. This enables you to build a unified environment of portlets and widgets within a single web portal page, so that you can run BPM processes and tasks in your portal pages. This content is part of the IBM Business Process Management Journal.

Andreas Schuetz (andreas.schuetz@de.ibm.com), Software Engineer, IBM China

Andreas Schuetz photoAndreas Schuetz works as a software engineer at the IBM Germany Research and Development Lab in Boeblingen. He currently works on the Human Task Management widgets and the Business Process Choreographer Explorer. Andreas joined IBM in 1998, and worked on the installation and configuration of IBM WebSphere MQ Workflow. Since 2005, Andreas has been involved in the development of BPM clients, such as Business Process Choreographer Explorer and Business Process Choreographer Observer. In 2008, he also began working on building widgets for IBM Business Process Manager.



Elke Painke (Elke.Painke@de.ibm.com), Software Consultant, IBM China

Elke Painke photoElke Painke is a Software Consultant, and works on the BPM test team at the IBM Research and Development lab in Boeblingen, Germany.



13 February 2013

Also available in Chinese

Introduction

IBM Business Process Manager Advanced V7.5 includes Business Space powered by WebSphere V7.5 (hereafter Business Space), which provides an integrated Web 2.0 user experience for business users across the IBM Business Process Management (BPM) portfolio. It also includes Human Task Management widgets, which business users and managers can exploit to interact with business processes and human tasks in Business Space. These widgets can also be configured to work in the IBM WebSphere Portal (Portal) environment.

Understanding the architecture

Before IBM Business Process Manager V7.5, setting up the Human Task widgets in Portal required that the Business Space components and widgets be installed on the same application server as WebSphere Portal. Users then saw a Business Space tab in Portal that would take them to a Business Space "island" within Portal.

This type of configuration was unable to leverage many useful WebSphere Portal features:

  • There was little or no interaction with other Portal pages or portlets.
  • Customization of themes was not supported with Business Space V7.
  • The Business Space V7 widgets could only run within the Business Space theme due to a limitation in the portal/mashup support prior to Portal V7. This meant that WebSphere Portal portlets and Business Space widgets wrapped as portlets could not be rendered on the same page.
  • Business Space and Business Process Manager widgets had to be installed locally on the WebSphere Portal profile. Rendering of remote widgets on WebSphere Portal V7 was not supported in Business Space.

With IBM Business Process Manager Advanced V7.5 (IBM BPM), including Business Space, and Portal V7, a consistent architecture and programming model for rendering portlets, widgets, and content was put in place:

  • Based on Dojo 1.4, a single, simplified theme is provided for server-side aggregation (SSA), client-side aggregation (CSA), and mashups.
  • Users can now combine iWidgets and portlets on the same page.
  • iWidgets are automatically wrapped as portlets for server-side mode.
  • iWidgets can now be installed on a product's server, such as the IBM BPM server, and then registered remotely on the WebSphere Portal server.

This article describes the integration of the Human Task Management widgets using remote registration. It covers the principal steps required to set up, register, and use the IBM BPM Task Management iWidgets on WebSphere Portal V7.0.0.1.

An overview of the configuration steps

The scenario covered in this article uses a standalone Portal V7.0.0.1 server that remotely calls the Human Task Management widgets installed in a standalone Business Process Manager Advanced V7.5 server. Portal and IBM BPM were installed on separate 64-bit Windows® machines.

The scenario covers three main areas: preparing the setup, configuring the Human Task Management widgets to work with Portal, and making the widgets available in Portal. The scenario covers three main areas: preparing the setup, configuring the Human Task Management widgets to work with Portal, and making the widgets available in Portal.

Before you begin

Before you can configure the widget set-up, you need to complete the following prerequisite steps:

Configuring the Human Task Management widgets to work with Portal

Once you have a Portal server and a BPM server with SSO and SSL established, you are ready to configure the Human Task Management widgets for remote access from Portal. This involves the following steps:

Making the widgets available in Portal

Once you've configured the Human Task Management widgets for access from Portal, you need to create a Portal page and add the widgets to Portal, wire the widgets, and optionally customize the widgets, by completing the following steps:

  • Step 10: Create a Portal page that contains the Human Task Management widgets. Once the widget configuration is completed, you're ready to start working with the widgets in Portal. For each iWidget that was successfully imported, a copy of the iWidget wrapper portlet is created. You can then locate the imported iWidgets and add them to Portal pages.
  • Step 11: Wire the widgets in Portal. Because autowiring is not supported in Portal, you need to manually wire the widgets.
  • Step 12: Configure the widgets (optional). Customize the content of the widgets to fit your needs. Figure 1 shows the main steps involved in configuring the widgets covered in this article.
    Figure 1. Configuring the Human Task Management widgets to work with Portal
    onfiguring the Human Task Management widgets to work with Portal

Prerequisites

This article is based on the following products and versions:

  • IBM WebSphere Portal V7.0.0.1 for Windows. Note: Portal must be at least at V7.0.0.1 for this example. Portal V7.0 is not supported for this type of configuration. Note that at the time this article was written, this configuration only worked with Portal cumulative fix 01 and 02. Cumulative fix 03 and later are currently not recommended.
  • IBM Business Process Manager Advanced V7.5 for Windows.

The example in this article uses a standalone Portal server and a standalone BPM server, each in its own cell. Business Space is configured on the BPM server. Before you can configure the Human Task Management widgets for remote access from Portal, you need to complete steps 1-4, to install and configure the two servers, and how to configure SSO and SSL between them.


Step 1: Install and configure a standalone Portal server

This article assumes that the reader is familiar with Portal installs, and therefore only briefly covers the installation and configuration of the Portal standalone server.

For more detailed information on installing Portal, see the IBM WebSphere Portal 7 product documentation.

Using the Portal installation wizard, select the following:

  1. For Product to install, select IBM WebSphere Portal Extend.
  2. Accept the license agreement.
  3. Select Full as the installation type.
  4. Accept the default or specify an installation directory. This configuration uses the default directory C:\IBM\WebSphere.
  5. Accept the defaults or specify a node name and host name. This configuration uses fmtc4218 as node name and fmtc4218.boeblingen.de.ibm.com as the host name.
  6. Choose an administrative ID. This configuration uses a user ID of wpadmin.
  7. Leave Create services unselected.
  8. Click Next twice to start the installation and configuration.

After successful installation and configuration, verify that the Portal server is available and running. In our example, the server is located at http://fmtc4218.boeblingen.de.ibm.com:10039/wps/portal.


Step 2: Install and configure a standalone BPM server

Different editions of IBM BPM, Advanced, Standard and Express, support different levels of business process management functionality. For example, Business Process Choreographer functionality is available only in IBM BPM Advanced. To create the standalone BPM server for this example, the installation binaries for IBM BPM Advanced are required.

When you start the installation, either via the launchpad or silently, you can choose either a typical or custom installation. For typical installations, the product's bit architecture must match the system's bit architecture. If you are on a 32-bit system, a 32-bit version of the product will be installed. If you are on a 64-bit system, a 64-bit version of the product will be installed. If you need to install a 32-bit product on a 64-bit system, you must use the custom installation option.

To choose the installation best suited for your needs, refer to the IBM Business Process Manager V7.5 Information Center install topics.

After performing a custom installation, you can create one or more standalone server profiles using the Profile Management Tool or the manageprofiles command line utility.

The example in this article uses the custom installation option to create a standalone server profile using the Profile Management Tool with the following parameters:

  1. Select the IBM BPM Advanced, Process Server standalone profile from the IBM Business Process Management Advanced : Process Server environment.
  2. Select Advanced profile creation (this enables a Business Process Choreographer sample configuration).
  3. Select Deploy the administrative console.
  4. Select Deploy the default application.
  5. Specify ProcSrv01 as the profile name.
  6. Specify C:\IBM\WebSphere\AppServer\profiles\ProcSrv01 as the profile directory.
  7. Select Development as performance tuning setting.
  8. Accept the defaults or specify the node and host names. In this example, fmtc7171 is used as the node name, and fmtc7171.boeblingen.de.ibm.com is used as the host name.
  9. Specify an administrative user. This example uses user ID bpmadmin.
  10. Accept the defaults on the Security Certificate pages.
  11. Accept the default ports or specify your own ports or port range.
  12. Deselect Run as Windows service.
  13. Deselect Create a Web server definition.
  14. Select Configure Business Space, and deselect Configure IBM Forms Server.
  15. Deselect Configure the Business Rules Manager.
  16. Specify an environment name. This example uses Portal Integration.
  17. Specify an environment type. This example uses Test.
  18. Select Use server offline.
  19. Deselect Use a database design file. This example assumes a default database configuration is sufficient for a test environment. For production environments, a database design file is recommended.
  20. Accept or modify the defaults on the Database Configuration pages. This example uses the defaults.
  21. Select Create a sample Business Process Choreographer configuration.

On 64-bit systems, the manageprofiles command line utility is used. You can either specify all required parameters with the manageprofiles command, or use the response file parameter and pass all parameters via the specified file. The following example shows the response file to create a Process Server standalone profile:

Listing 1. Listing 1. Response file for Process Server standalone profile
create
dbServerPort=50000
procSvrDbName=BPMDB
perfDWDbName=PDWDB
dbDesignEnabled=false
dbDelayConfig=false
configureBSpace=true
AdminPassword=adminpassword
cellName=fmtc7171Node01Cell
personalCertDN=cn=fmtc7171.boeblingen.de.ibm.com,ou=fmtc7171Node01Cell,
ou=fmtc7171Node01,o=IBM,c=US
configureBPC=true
signingCertDN=cn=fmtc7171.boeblingen.de.ibm.com,
ou=Root Certificate=ou=fmtc7171Node01Cell,ou=fmtc7171Node01,o=IBM,c=US
hostName=fmtc7171.boeblingen.de.ibm.com
profileName=ProcSrv01
configureBRM=false
dbType=DB2_UNIVERSAL
webFormConfig=false
omitAction=samplesInstallAndConfig
dbUserId=db2userID
dbJDBCClasspath=${WAS_INSTALL_ROOT}\db2\java
applyPerfTuningSetting=development
adminUserName=adminUserName 
dbCreateNew=true
dbName=CMNDB
ProcessCenterURL
enableAdminSecurity=true
environmentType=Test
nodeName=fmtc7171Node01
winserviceAccountType=localsystem
portsFile=C:\IBM\WebSphere\AppServer/logs/manageprofiles\
1306941554759_portdef.props
profilePath=C:\IBM\WebSphere\AppServer\profiles\ProcSrv01
serverName=server1
winserviceCheck=true
winserviceUserName=windowsusername
dbHostName=fmtc7171.boeblingen.de.ibm.com
bspaceAlreadyConfigured=false
PersonalCertValidityPeriod=1
DbPassword=********
SigningCertValidityPeriod=15
KeyStorePassword=********
environmentName=Portal Integration
winserviceStartupType=automatic
templatePath=C:\IBM\WebSphere\AppServer\profileTemplates/BPM/
default.procsvr.adv

For more information on the manageprofiles command, refer to the manageprofiles parameters topic in the IBM Business Process Manager V7.5 Information Center.

After successful installation and configuration, verify that the BPM server is available and running. In this example it is located at https://fmtc7171.boeblingen.de.ibm.com:9043/ibm/console.


Step 3: Configure single sign-on

In our example, the Portal server and the BPM server reside in separate cells, with Portal users calling Business Space widgets that reside in the BPM server. Assuming that both cells allow only authorized users access, users would need to authenticate in each cell separately. To avoid users having to do this, a single sign-on (SSO) environment is configured using Lightweight Third-Party Authentication (LTPA).

Cookies, LTPA tokens, and domains

LTPA is an WebSphere Application Server security protocol that enables web users to re-use their log-in credentials across physical WebSphere servers:

  • When a user logs on, the server prompts for a name and password. After successful authentication, a session cookie is written that contains the LTPA token. This token contains, at a minimum, the domain for which the cookie is valid, the name of the cookie, an expiration date and time, and the user identity.
  • As long as the browser session is not closed, the user can then access any server that is a member of the same domain as the first server without having to re-authenticate. In our example, when the Portal user accesses the Business Space widgets located on the BPM server, the cookie is sent in the request.
  • The BPM server extracts the LTPA token from the cookie and validates it.

To enable this, the following must be configured:

  • The user must be known in both cells. The simplest way to do this is use the same user registry in both cells.
  • The realm names on the systems in the SSO domain must be matched. The realm name is either the domain name or, if no domain is specified, the machine name. In our example, the Portal server and BPM server are located on separate machines. A domain must therefore be specified. Note that domain names are case-sensitive.
  • The Portal server and the BPM server must share LTPA keys.
  • HTTP cookies must be enabled in the browser.

Set up the user registry and users for SSO

Prerequisite for SSO in a cross-cell configuration is a user ID known in both cells. In a production environment, you would, for example, use the same central user registry, such as an LDAP server, for the Portal and the BPM environment.

This example in this article uses a simplified test configuration. It uses the built-in file-based repository in both servers. The same user ID, myAdmin, is defined in both repositories. This user ID needs to have the following rights:

  • On the BPM server, the user needs to exist, be a member of the same realm as the user on the Portal server, and have the same password. No administrative rights are required on the BPM server during runtime to use the Human Task Management widgets in Business Space.
  • On the Portal server, the user needs to have administrative rights. Later in the configuration, the REST endpoint references of the Business Space widgets located on the BPM server will be remotely registered in the Portal server. Endpoints must be defined on the WebSphere Portal server, but they are created remotely using a wsadmin session on the BPM server. This requires the user ID to exist on both servers, and have administrative rights on the Portal server.

Create the myAdmin user on the BPM server

With BPM Advanced V7.5, the default user configuration for standalone servers has changed. The user that you specify when creating a default standalone profile is not a member of the defaultWIMFileBasedRealm (the default behavior with V7). Instead, it is a member of the internal, database-based realm twinternal. Since this realm does not exist in Portal, an additional user ID needs to be specified for SSO.

In this example, the standalone BPM server profile was created with the user ID bpmadmin (with realm twinternal). Using the adminstrative console, create an additional user myAdmin (realm defaultWIMFileBasedRealm, no special group membership) for the SSO configuration, as shown in Figure 2.

Figure 2. BPM user required for single sign-on
BPM user required for single sign-on

Create the myAdmin user as a Portal administrator

The following steps describe how the myAdmin user was created for this article:

  1. Log in to Portal with the wpadmin user ID (or any other user ID that has administration privileges).
  2. Click on the Administration tab.
  3. On the left side, expand the Access section.
  4. Click Users and Groups.
  5. On the Manage Users and Groups screen, click New User.
  6. Specify myAdmin as the user ID.
  7. Click OK to create the new user.
  8. Back on the Manage Users and Groups dialog, shown in Figure 3:
    1. Select Users as search criteria
    2. Select uid to search by.
    3. Select myAdmin.
    4. Click Search to display the myAdmin user.
      Figure 3. Portal user required for single sign-on
      Portal user required for single sign-on
    5. Click Duplicate group assignments to display a list of available users.
    6. Select the administrative user ID of the Portal server (wpadmin).
    7. Click OK.

To verify the user configuration, log on to Portal as myAdmin and ensure that you can see the Administration tab.

Specify the domain

To enable SSO between the Portal server and the BPM server, ensure that both are configured as part of the same DNS domain. The realm names on each system in the DNS domain are case sensitive and must match identically. For example, if the DNS domain is specified as mycompany.com, SSO is effective with any Domino server or WebSphere Application Server on a host that is part of the mycompany.com domain, for example, a.mycompany.com and b.mycompany.com.

To specify the domain in both the Portal server and the BPM server, do the following:

  1. For each server, log in to the Integrated Solutions Console as a user with administrative rights.
  2. Select Security => Global Security.
  3. In the Authentication section, expand Web and SIP security and select Single sign-on.
  4. In the Single Sign-On dialog, select Enable and specify the domain name.
  5. Click OK and save your changes.

Note: You need to restart the server, but this will be done in a later step.

Figure 4 shows a sample domain configuration on the BPM server.

Figure 4. Specifying the domain
Specifying the domain

Share LTPA keys

When SSO is enabled, a cookie is created containing the LTPA token and inserted into the HTTP response. When the Portal user accesses the Business Space widgets located in the BPM server, the cookie is sent in the request. The LTPA token is then extracted from the cookie and validated. Since the Portal server and the BPM server reside in separate cells, the two cells not only need to share the same user registry, but also share the LTPA keys in order for SSO to work.

To share the LTPA keys, you need to export them from the Portal server and import them into the BPM server.

To export the LTPA keys from the Portal server (WebSphere_Portal):

  1. Log in to the Portal server's Integrated Solutions Console as a user with administrative rights.
  2. Select Security => Global Security.
  3. In the Authentication section, click LTPA.
  4. In the Cross-cell single sign-on section, specify and confirm a password for the export of the LTPA key. This password will be used when importing the keys on the BPM server.
  5. Specify a fully-qualified file name for the LTPA keys. This file will be imported later on the BPM server. Note that the path must exist on the Portal server machine. If you specify a file name without a path, the file is stored in the Portal server's profile root directory.
  6. Click Export to export the keys to the specified file.

To import the Portal server's LTPA keys to the BPM server:

  1. Copy the file containing the LTPA keys to the BPM machine.
  2. Log in to the BPM server's Integrated Solutions Console as a user with administrative rights.
  3. Select Security => Global Security.
  4. In the Authentication section, click LTPA.
  5. In the Cross-cell single sign-on section, specify and confirm the password you used when exporting the keys from the Portal server.
  6. Specify the fully-qualified file name on the BPM machine you used when copying the LTPA keys from the Portal server.
  7. Click Import to import the keys from the file.
  8. Click OK and save your configuration.

Figure 5 shows a sample of an import of LTPA keys from the Portal server.

Figure 5. Importing LTPA keys
Importing LTPA keys

Note: When sharing LTPA keys across cells, automatic key generation should be disabled both in the Portal server and the BPM server to prevent the imported key from being overwritten when a new key is generated.

Verify that automatic key generation is disabled as follows:

  1. For each server, log in to the Integrated Solutions Console as a user with administrative rights.
  2. Select Security => SSL certificate and key management.
  3. In the Related Items section, click Key set groups.
  4. In the Key set groups dialog, click the NodeLTPAKeySetGroup entry.
  5. In the General Properties dialog, verify that automatic key generation is not selected, as shown in Figure 6.
Figure 6. Disabling automatic key generation
Disabling automatic key generation

To verify that SSO was configured successfully, do the following:

  1. Restart all servers (the BPM server and the Portal servers server1 and WebSphere_Portal).
  2. Clear your browser cache.
  3. In a browser window, log in to the Portal server as myAdmin.
  4. After successful login (and without logging out of the Portal server), open another browser tab.
  5. Enter a BPM server URL, for example, the URL to log in to the BPM server's Integrated Solutions Console or Business Space. The console should be displayed without your having to specify a user ID and password.

Troubleshooting SSO

If you see the log-in panel of the Integrated Solutions Console or Business Space, your SSO configuration has failed. To find out what went wrong, first verify that the previous steps were successful. As a next step, use web debugging to verify that your browser receives an LtpaToken2 cookie with the domain you specified.

To check this:

  1. Clear all cookies in the browser.
  2. Log in to the Portal server. You should see a LtpaToken2 cookie like that in Figure 7.
    Figure 7. Troubleshooting cookies
    Troubleshooting cookies
  3. Clear all cookies again.
  4. Log in to Business Space.
  5. Verify that the LtpaToken2 value is the same as the first one.

Note: When specifying the URLs, make sure that you always specify fully-qualified host names. Otherwise the application server cannot associate the machine name with the SSO domain. For example, http://fmtc7171:9080/BusinessSpace will not get an SSO LTPA token for the domain, while http://fmtc7171.boeblingen.de.ibm.com:9080/BusinessSpace does.

For more information on single sign-on, refer to Single sign-on for authentication using LTPA cookies in the the WebSphere V7 Information Center, and Setting up single sign-on (SSO) between IBM WebSphere Portal and WebSphere Process Server in the WebSphere V7.0 Portal product documentation.


Step 4: Configure SSL between the Portal server and the BPM server

When SSO is configured, servers can decrypt the LTPA tokens generated by another server and get the information required to identify a user to the system. Without configuring SSL, these LTPA tokens will be communicated over unsecured channels. Whether you also need to configure the Secure Sockets Layer (SSL) depends on your security requirements.

For example, if you are planning on using HTTPS in the endpoints file, the endpoint location is on a different node than Business Space, and the SSL certificate is self-signed, you need to configure SSL between the Portal server and the BPM server.

Establishing SSL trust between the BPM server and the Portal server can be achieved in various ways, depending on your security environment. One way is to import the SSL signer certificate of the BPM server into the SSL trust store of the Portal server and vice versa.

For step-by-step instructions on exchanging certificates between Portal and BPM, refer to Enabling process integration in a cross-cell setup, Steps 4 to 6 in the WebSphere Portal information center. For more information on SSL and certificates, refer to Secure communications using Secure Sockets Layer (SSL) in the WebSphere V7 Information Center.

Once you have a Portal server and a BPM server with SSO and SSL established, you are ready to configure the Human Task Management widgets for remote access from Portal, as described in steps 5-12.


Step 5: Configure the proxy server

As shown in Figure 1, all HTTP requests between the widgets and the BPM server go through the Ajax proxy on the Portal server. The main reason for this is that browsers allow JavaScript applications to connect only to the originating server, which in our case is the Portal server. Routing the requests through the proxy hides the fact that the requests are intended for the BPM server from the browser.

Modify the Ajax proxy configuration on the Portal server

In a default Portal configuration, the proxy configuration does not allow requests to servers other than the Portal server. Therefore the proxy needs to be modified to allow the requests to go to the BPM server.

If you have multiple remote servers or URLs that need to be allowed with the proxy for the Portal server, customize the proxy configuration by using dynamic policy entries. The proxy policy will differ from one deployment to the other. Refer to the WebSphere Portal documentation for different ways to configure the WebSphere Portal server proxy.

In our example, we'll modify the original proxy configuration file as described below. The resulting integration-proxy-config.xml is attached to this article.

  1. Copy the original proxy-config.xml from C:\IBM\WebSphere\PortalServer\base\wp.proxy.config\installableApps\wp.proxy.config.ear\wp.proxy.config.war\WEB-INF to a working location, such as C:\IBM\integration-proxy-config.xml.
  2. Using your favorite editor, add the following entries to the file:
    	<proxy:policy url="<REMOTE_BPM_URL>" acf="none">
    	<proxy:actions>
    	<proxy:method>GET</proxy:method>
    	<proxy:method>HEAD</proxy:method>
    	<proxy:method>POST</proxy:method>
    	<proxy:method>DELETE</proxy:method>
    	<proxy:method>PUT</proxy:method>
    	
    	</proxy:actions>
    	<proxy:cookies>
    	<proxy:cookie>LtpaToken</proxy:cookie>
    	<proxy:cookie>LtpaToken2</proxy:cookie>
    	<proxy:cookie>JSESSIONID</proxy:cookie>
    	<proxy:cookie>CRN</proxy:cookie>
    	<proxy:cookie>caf</proxy:cookie>
    	<proxy:cookie>cam_passport</proxy:cookie>
    	<proxy:cookie>cc_session</proxy:cookie>
    	<proxy:cookie>userCapabilities</proxy:cookie>
    	<proxy:cookie>usersessionid</proxy:cookie>
    	</proxy:cookies>
    	<proxy:headers>
    	<proxy:header>User-Agent</proxy:header>
    	<proxy:header>Accept*</proxy:header>
    	<proxy:header>Content*</proxy:header>
    	<proxy:header>Authorization*</proxy:header>
    	<proxy:header>X-Method-Override</proxy:header>
    	<proxy:header>Set-Cookie</proxy:header>
    	<proxy:header>If-Modified-Since</proxy:header>
    	<proxy:header>If-None-Match</proxy:header>
    	<proxy:header>X-Server</proxy:header>
    	<proxy:header>X-Update-Nonce</proxy:header>
    	<proxy:header>X-Requested-With</proxy:header>
    	<proxy:header>com.ibm.lotus.openajax.virtualhost</proxy:header>
    	<proxy:header>com.ibm.lotus.openajax.virtualport</proxy:header>
    	<proxy:header>Slug</proxy:header>
    	<proxy:header>SOAPAction</proxy:header>
    	</proxy:headers>
    	</proxy:policy>
  3. Replace the text <REMOTE_BPM_URL> with the URL to the BPM server. In our example, the entry looks like this:
    <proxy:policy url="https://fmtc7171.boeblingen.de.ibm.com:9443/*" acf="none">
  4. Verify that your proxy-config.xml file contains the following meta data settings:
    	<proxy:meta-data>
    	<proxy:name>forward-http-errors</proxy:name>
    	<proxy:value>true</proxy:value>
    	</proxy:meta-data>
    	<proxy:meta-data>
    	<proxy:name>socket-timeout</proxy:name>
    	<proxy:value>30000</proxy:value>
    	</proxy:meta-data>
  5. If you are using self-signed SSL certificates, you need to add the following entry:
    	<proxy:meta-data>
    	<proxy:name>unsigned_ssl_certificate_support</proxy:name>
    	<proxy:value>true</proxy:value>
        </proxy:meta-data>

    Without this entry, the following error message will likely occur:
    502 BMWPX0017E: The Secure Socket Layer (SSL) certificate of the target host is not trusted.
  6. Save the file.
  7. Check the modified proxy file. Change to the Portal installation's ConfigEngine directory. In our example, this is located at C:\IBM\WebSphere\wp_profile\ConfigEngine.
  8. Run the checkin-wp-proxy-config script as follows:
    ConfigEngine.[bat|sh] checkin-wp-proxy-config 
    -DProxyConfigFileName=<dir_path/temporary_proxy_file.name>
    -DWasPassword=<application_server_password>
    -DWasUserid=<application_server_user_ID>
    -DPortalAdminId=<WebSphere_Portal_administrator_ID>
    -DPortalAdminPwd=<WebSphere_Portal_administrator_password>

    In our example, we ran the script with these parameters:
    ConfigEngine checkin-wp-proxy-config 
    -DProxyConfigFileName=C:/IBM/integration-proxy-config.xml 
    -DWasPassword=myAdmin 
    -DWasUserid=myAdmin 
    -DPortalAdminId=myAdmin 
    -DPortalAdminPwd=myAdmin
  9. Verify that the script ran successfully, which is indicated by Return Value: 0.
  10. From the Portal server's Integrated Solution Console, restart the application AJAX Proxy Configuration.

Verify the proxy configuration

After restarting the application, you can verify that the new Ajax proxy configuration has been activated. Since configuration file content is stored in a custom property of a resource environment provider named WP ConfigService, you can verify activation via the Portal server's Integrated Solutions Console as follows:

  1. Select Resources => Resource environment => Resource environment providers.
  2. Click Resource Environment Providers.
  3. Select the provider WP ConfigService.
  4. On the WP ConfigService dialog, under Additional Properties, click Custom properties.
  5. Scroll to the property proxy.config.file and verify that the changes have been incorporated.

Alternatively, you can verify the proxy configuration by accessing the hello servlet from the DefaultApplication that comes with the application server. In our example, the URL to access hello servlet via the Portal proxy is http://fmtc4218.boeblingen.de.ibm.com:10039/wps/proxy/https/fmtc7171.boeblingen.de.ibm.com%3A9443/hello.

If the proxy is configured correctly, the servlet is displayed as shown in Figure 8.

Figure 8. Verifying the proxy configuration using the hello servlet
Verifying the proxy configuration using the hello servlet

Step 6: Create endpoint references on the Portal server

Service endpoints are references to a REST API or a root URL of a web archive. They are registered as resource environment entries in the application server. During initialization, the widgets query the endpoints from the server that hosts the iWidgets. While the endpoints required by the Human Task Management widgets are registered by default on the BPM server, the Portal server does not know about them, so they need to be registered.

Identify the Human Task Management widget endpoints to register

The Human Task Management widgets require the following endpoints:

Table 1. Mandatory endpoints
Endpoint ID Defined in file
{com.ibm.bspace}HumanTaskManagementWidgetsRootId HumanTaskManagementWidgetsEndpoint.xml
{com.ibm.bpm}HTM HumanTaskManagementEndpoints.xml
{com.ibm.bpm}BFM HumanTaskManagementEndpoints.xml
{com.ibm.bpm}VirtualMemberManager wsumEndpoint.xml
{com.ibm.bspace}bspaceServerRootId bspaceEndpoints.xml
{com.ibm.bspace}bspaceWidgetHelpRootId bspaceEndpoints.xml
Table 2. Optional endpoints
Endpoint ID Defined in file
{com.ibm.bspace.htm}bspaceUserImageServiceRootId userImagesEndpoint.xml
{com.ibm.bpm}CustomExtension CustomExtensionServiceEndpoint.xml

Note: Not all widgets require all of the above endpoints. To find out which endpoints a specific widget requires, check its catalog.xml file. For the Human Task Management widgets, the file is named catalog_HumanTaskManagement.xml and is located on the BPM server in <install_root>/BusinessSpace/registryData/catalogs. In our example, this maps to C:\IBM\WebSphere\AppServer\BusinessSpace\registryData\catalogs.

Search for the widget definition, then for the following tag:

	<metadata name="com.ibm.bspace.serviceEndpointRefs">

Check for all listed endpoints that have the attribute required set to true.

You can find the above endpoint files in two locations on the BPM server:

  1. The Business Space installation folder <WAS_home>/BusinessSpace/registryData/endpoints, which in this example maps to C:\IBM\WebSphere\AppServer\BusinessSpace\registryData\endpoints contains HumanTaskManagementEndpoints.xml, userImagesEndpoint.xml and CustomExtensionServiceEndpoint.xml.
  2. The Business Space profile folder <USER_INSTALL_ROOT>/BusinessSpace/<node_name>/<server_name>/mm.runtime.prof/endpoints, which in this example maps to C:\IBM\WebSphere\AppServer\profiles\ProcSrv01\BusinessSpace\fmtc7171Node01\server1\mm.runtime.prof\endpoints, contains bspaceEndpoints.xml, HumanTaskManagementWidgetsEndpoint.xml and wsumEndpoint.xml.

Update the endpoint files to match your configuration

The registration command used to register the endpoints in Portal requires a directory as input parameter. It is therefore recommended that you copy all required endpoint files into a new separate directory and modify them there. In this example, the directory C:\IBM\endpoints is used, and only the required files listed below are used:

  • HumanTaskManagementEndpoints.xml
  • bspaceEndpoints.xml
  • HumanTaskManagementWidgetsEndpoint.xml
  • wsumEndpoint.xml

Before registering the endpoint files on the remote Portal server, the URLs they contain need to be changed from relative to fully-qualified URLs, because the Portal server will not find the appropriate endpoints in its own path. The fully qualified URL must also include the domain.

When modifying the URLs in HumanTaskManagementEndpoints.xml, you also need to check whether the URL points to the correct REST endpoint. The endpoint files listed above are templates and do not reflect the current configuration of the BPM server. Starting with IBM BPM V7.5, there are three possible values for each of the endpoints in HumanTaskManagementEndpoints.xml:

For the process services endpoint {com.ibm.bpm}BFM:

  • Business Process Choreographer REST services: /rest/bpm/bfm
  • Federated (process) REST services: /rest/bpm/federated/bfm
  • Business process definition enginge services: /rest/bpm/wle

For the task services endpoint {com.ibm.bpm}HTM:

  1. Business Process Choreographer REST services: /rest/bpm/htm
  2. Federated (process) REST services: /rest/bpm/federated/htm
  3. Business process definition enginge services: /rest/bpm/wle

In a default Business Space configuration, the federated REST services are used.

To find out which values are used by your Business Space running on the BPM server, log in to the administrative console and navigate to Application servers => server1 => Business Space Configuration => REST service endpoint registration. Check the URLs for the Process services and Task services types.

Update each <tns:url> tag in the copied files with the appropriate URL and endpoint values.

Figure 8 shows the HumanTaskManagementEndpoints.xml as a sample modified endpoint file. All of the endpoint files used are provided for download with this article.

Listing 2. Sample endpoint file with fully-qualified URL
<tns:BusinessSpaceRegistry xmlns:tns="http://com.ibm.bspace/BusinessSpaceRegistry"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://com.ibm.bspace/BusinessSpaceRegistry 
BusinessSpaceRegistry.xsd ">

  <tns:Endpoint>
    <tns:id>{com.ibm.bpm}HTM</tns:id>
    <tns:type>{com.ibm.bpm}HTM</tns:type>
    <tns:version>7.5.0.0</tns:version>
    <tns:url>https://fmtc7171.boeblingen.de.ibm.com:9443/
            rest/bpm/federated/htm/</tns:url>
    <tns:description>Location of backing services for HTM widgets</tns:description>
  </tns:Endpoint>

  <tns:Endpoint>
    <tns:id>{com.ibm.bpm}BFM</tns:id>
    <tns:type>{com.ibm.bpm}BFM</tns:type>
    <tns:version>7.5.0.0</tns:version>
    <tns:url>https://fmtc7171.boeblingen.de.ibm.com:9443/rest/bpm/federated/bfm/</tns:url>
    <tns:description>Location of backing services for BFM widgets</tns:description>
  </tns:Endpoint>

</tns:BusinessSpaceRegistry>

Register the endpoints using updateEndpointBindingsOnPortal

The endpoint files are registered on the Portal server within a wsadmin session with the updateEndpointBindingsOnPortal command. This command creates references to the REST endpoints on the WebSphere Portal application server.

The AdminTask.updateEndpointBindingsOnPortal command is part of the Business Space installation. The wsadmin session must therefore be run from the bin directory of the BPM server.

  1. On the BPM server, open a command prompt and go to the directory <install_root>/bin.
  2. Start wsadmin with the following parameters:
    wsadmin -lang jython -conntype none

    Note: At the time of writing, updateEndpointBindingsOnPortal worked only in disconnected mode.

  3. Run the updateEndpointBindingsOnPortal command with the following parameters:
    AdminTask.updateEndpointBindingsOnPortal('[
    -nodeName <Portal_server_name> 
    -endpointBindingDirectoryName <directory_containing_endpoints_files_on_local_system>
    -host <Portal_server_IP_or_host>
    -port <Portal SOAP_port_default_8879>
    -user <Portal_admin_ID>
    -password <Portal_admin_password]>')

    In this example, we used the following parameters:
    AdminTask.updateEndpointBindingsOnPortal('[
    -nodeName fmtc4218 
    -serverName WebSphere_Portal 
    -endpointBindingDirectoryName c:/IBM/endpoints 
    -host fmtc4218 
    -port 10025 
    -user wpadmin 
    -password wpadmin]')
  4. Restart the Portal server.

Verify endpoint registration

All registered endpoints are stored as custom properties of the resource environment provider WP Mashup Endpoints. To verify them in the Portal server's Integrated Solutions Console, do the following:

  1. Select Resources => Resource environment => Resource environment providers.
  2. Select Resource Environment Providers.
  3. Select the provider WP Mashup Endpoints.
  4. On the WP Mashup Endpoints dialog, under Additional Properties, click Custom properties.

Each endpoint has in three custom properties. To verify that the URLs are correct, search for the endpoint name with an additional postfix ".url" appended. For example, to verify the {com.ibm.bpm}HTM endpoint, search for the property {com.ibm.bpm}HTM.url.


Step 7: Install forms on the Portal server (optional)

Forms provided by a web archive (WAR) or enterprise archive (EAR) will only be found if they are installed on the Portal server. If you want to use the predefined tasks that come with the BPM server, you need to install the HumanTaskManagementWidgets.ear file located on the BPM server. The EAR is located under <profile_home>\ installableApps\BusinessSpace\<cellname>\<servername>. In this example, it is here: C:\IBM\WebSphere\AppServer\profiles\ProcSrv01\installableApps\BusinessSpace\fmtc7171Node01\server1\HumanTaskManagementWidgets.ear.

While the EAR is installed as usual, special attention is required to map the modules to the correct server. By default, the modules are installed on server1, but they need to be installed on the WebSphere_Portal server.

In this example, the WAR and EAR containing the forms was installed on the Portal machine as follows:

  1. Log in to the Portal administrative console.
  2. On the right side, expand Applications.
  3. Select New Application => New Enterprise Application.
  4. Specify the path to the HumanTaskManagementWidgets.ear, and click Next.
  5. Select Fast Path, and click Next.
  6. Click Next to go to Step 2 Map modules to servers.
  7. Select the WebSphere_Portal server as target server.
  8. In the table at the bottom, select all modules, and click Apply, then click Next.
  9. Click Finish.
  10. Start the application.

Step 8: Register the Human Task Management widgets on WebSphere Portal

Registration of widgets is done in bulk using the Portal ConfigEngine tool on the Portal server.

You must complete the following steps prior to widget registration:

  • Endpoint registration: The location of the iWidget.xml files is resolved using endpoint definitions. Thus you must have successfully registered the endpoints before this step.
  • Portal Ajax proxy configuration: The ConfigEngine connects via the Portal Ajax proxy. Registration will fail if your proxy configuration is incorrect.

The ConfigEngine tool connects remotely to the BPM server and downloads all required information to register the widgets. To run, the tool needs to know the catalog file name and under which URL it can be found. Then, using the contents of the catalog, the iWidget.xml file locations are determined and downloaded to the Portal server. The following sections guide you through these steps.

Identify the catalog file to use for registration

To show the widgets in the palette, the Portal server requires the catalog file of the Human Task Management widgets be in a special format. The name of the catalog file is one of the parameters that is passed to the ConfigEngine command. ConfigEngine expects the catalog in the root directory of the widgets' WAR file within the corresponding EAR file. For the Human Task Management widgets, the file is named portal_catalog.xml.

Identify the root context of the Human Task Management Widgets

The default context root for the Human Task Management is /HumanTaskManagementWidgets. The complete URL for the catalog to the BPM server would thus be http://fmtc7171.boeblingen.de.ibm.com:9080/HumanTaskManagementWidgets/portal_catalog.xml.

Since the ConfigEngine connects via the Portal Ajax proxy, this link will work only if the proxy configuration file contains a policy for this port. In our example, this is not the case.

Depending on the security requirements of your environment, you can either add a policy to your proxy configuration that allows connections to port 9080, or use the secure URL for the catalog: https://fmtc7171.boeblingen.de.ibm.com:9443/HumanTaskManagementWidgets/portal_catalog.xml

Verify that the catalog URL is accessible via the proxy

To verify that the catalog URL can pass the proxy, prefix the URL with the proxy URL and enter it into a browser address bar. In our example, the prefix for the proxy is http://fmtc4218.boeblingen.de.ibm.com:10039/wps/proxy/. The complete URL for the Human Task Management widget catalog is then: http://fmtc4218.boeblingen.de.ibm.com:10039/wps/proxy/https/fmtc7171.boeblingen.de.ibm.com%3A9443/HumanTaskManagementWidgets/portal_catalog.xml.

Register the Human Task Management widgets using bulk registration

Using the above URL, you can now register the widgets as follows:

  1. On the Portal server, open a command prompt and change to the ConfigEngine directory located at <wp_profile_root>/ConfigEngine. In this example, it is C:\IBM\WebSphere\wp_profile\ConfigEngine.
  2. Run the ConfigEngine tool with the following parameters:
    ConfigEngine.[bat|sh] register-iwidget-definition 
    -DIWidgetCatalog=<URL_to_catalog_XML_file>
    -DWasPassword=<password> 
    -DWasUserid=<ID> 
    -DPortalAdminId=<ID>
    -DPortalAdminPwd=<password>
    -DRegistrationAspects=catalogTitlesOverule,considerWidgetParam,
    considerUniqueName

    In this example, the command and parameters are as follows:

    ConfigEngine.bat register-iwidget-definition                    
    -DIWidgetCatalog=
    https://fmtc7171.boeblingen.de.ibm.com:9443/HumanTaskManagementWidgets
    /portal_catalog.xml
    -DWasPassword=wpadmin
    -DWasUserid=wpadmin
    -DPortalAdminId=wpadmin
    -DPortalAdminPwd=wpadmin
    -DRegistrationAspects=catalogTitlesOverule,considerWidgetParam,considerUniqueName
  3. Check the output of the tool. Success is indicated by Return Value: 0.

Each iWidget listed in the catalog is now registered, and a copy of the iWidget wrapper portlet is created and is available for use.


Step 9: Enable the Business Space drop-down menus

Business Space provides some extra actions (refresh, help, and send widget) on the widgets, which are not available in Portal by default. These need to be added as theme custom menu extensions. Step 4 of Configuring widgets to work with WebSphere Portal in the IBM BPM V7.5 Information Center, describes in detail how to enable the menu items that your Business Space widgets use so that they appear in WebSphere Portal.

However, these instructions don't explain which files need to be adjusted. You need to update a least two files, theme_??.html and widgetActions.json, where ?? is the language identifier of the language for which you make this update. Thus, if your site supports several languages, several versions of theme_??.html need to be updated. The files are accessible using a WebDav folder. For general information about accessing the files via WebDav, refer to Connecting to the WebDav folder to customize Business Space in the Information Center.

Note: The WebDav access as described in the Information Center works only when using the Explorer on Windows XP. On Windows Vista or Windows 7 you might use a third-party WebDav client.

In this example, we are changing the default portal theme PageBuilder2. The theme is found at: http://<Portal_hostname>:10039/wps/mycontenthandler/dav/fs-type1. For this example, it is http://fmtc4218.boeblingen.de.ibm.com:10039/wps/mycontenthandler/dav/fs-type1.

In an English-only configuration, you need to update the following files:

  • themes/PageBuilder2/menuDefinitions/widgetActions.json
  • themes/PageBuilder2/nls/theme_en.html

In a non-English configuration, you also need to update the theme_??.html. (See Figure 9.)

Download the files, create a back-up for each, and update them using the snippets from the step 4 of the Information Center topic, then upload them again.

To activate your changes, clear the browser cache and reload the Portal page.

Figure 9. Editing the custom theme
Editing the custom theme

Step 10: Create a portal page that contains the Human Task Management widgets

The next step in the configuration is to create a Portal page that contains the Human Task Management widgets. However, before creating the portal page, it is useful to create a similar space in Business Space. If something doesn't work on the Portal page, this reference space can be used for verification.

Create a reference space from the template (optional)

To create the reference space in Business Space on the BPM server, do the following:

  1. Log in to Business Space with a BPM user ID with administrative rights. In this example, we used myAdmin.
  2. Select Actions => Create space.
  3. Choose a space name. We used Portal Reference Space.
  4. Select Create a new space using a template.
  5. From the drop-down, select Interact with Processes and Task, as shown in Figure 10.
  6. Click Save to create the new space.
Figure 10. Creating a reference space on the BPM server
Creating a reference space on the BPM server

This creates a space called Portal Reference Space with two pages, Initiate and Work with Tasks and Check Status. Figure 11 shows the newly created reference space for the user myAdmin.

Figure 11. Sample BPM reference space for user myAdmin
Sample BPM reference space for user myAdmin

Create a Portal page and add widgets

The last step is to create a new Portal page that will host the Human Task Management widgets:

  1. Log in to the Portal server with a user ID that has administrative rights. We used myAdmin.
  2. At the top right of the Welcome page, click Actions, then Edit Page. This displays a new tab called New Page.

    Note: If the Edit Page menu item is not shown, it may be because the browser is not able to display it (for example, Firefox 4 cannot display it). In this case, try a different browser.

  3. Select the New Page tab.
  4. Enter a name for the page. You can specify any name. We used the same name as the BPM Business Space page, Interact with Processes and Tasks.
  5. Click Create Page.
  6. To switch the theme to Client Side Aggregation (CSA), click Actions => Edit Page properties.
  7. Select Client Side Aggregation – Rendering.
  8. Click OK to close the page properties.
  9. To switch into the page edit mode again, click Actions => Edit Page.
  10. On the tool bar, click Customize to display the widget palette. Note: Currently, the Human Task Management widgets are visible only in the All category.
  11. Click All below Browse Content.
  12. To filter the results, enter the word Task in the Search All entry field and click the search button.
  13. Drag the following widgets onto the page: Tasks, Task Definitions and Task Information.
  14. Save the page by clicking Save from the tool bar.

The widget code is now loaded for the first time, and the contents of the widgets are displayed, as shown in Figure 12.

Figure 12. Human Task Management widgets on a Portal page
Human Task Management widgets on a Portal page

Troubleshooting widget registration

If no content appears, or only the loading indicator is displayed, you should troubleshoot the problem before wiring the widgets in the last step of the configuration. Troubleshooting problems at this time (before the wiring) is recommended because you may need to re-register widgets when solving problems. Re-registered widgets receive a new instance ID, which means you would need to re-wire the widgets.

Troubleshooting load problems of a widget begins with a verification of the HTTP request that is sent by the browser. Use your favorite browser debugging tool to do this. We used Firefox as the browser, and Firebug for debugging. Internet Explorer Developer tools are suitable as well.

By default, the Portal server is set up to use mashup multipart. This is a new Mashup Center 2.0 feature that makes it possible to tunnel multiple logical requests through one single physical HTTP request. In addition, the multipart requests sent by the HTTP GET method can be cached by the HTTP server or Edge server.

While this improves browser-side performance, it makes it a bit more difficult to see what is going on when errors occur. Thus, the first step in troubleshooting is typically to switch multipart off. You do this in the Portal server Integrated Solutions Console:

  1. Navigate to Resources => Resource environment => Resource environment providers.
  2. Select the WP CommonComponentConfigService provider.
  3. On the WP CommonComponentConfigService dialog, under Additional Properties, click Custom properties.
  4. Scroll to the cc.multipart.enabled property and click its name.
  5. Change the value to false.
  6. Restart the WebSphere_Portal server and server1.

Once multipart is disabled, start your browser debugging tool and search for failing HTTP requests. After successful troubleshooting, remember to set the value of the cc.multipart.enabled property to true again.

Note: Due to the design of Dojo, there are some HTTP requests that are expected to fail. If you see failing HTTP requests that have "nls" in their paths, you can ignore them. For example, you can ignore the following: http://fmtc4218.boeblingen.de.ibm.com:10039/wps/proxy/https/fmtc7171.boeblingen.de.ibm.com %3A9443/HumanTaskManagementWidgets/com/ibm/bpc/widget/util/nls/en/ErrorMessage.js

Re-registering widgets

Widgets can be registered multiple times. At the time this article was written, widgets that were registered again did not overwrite the previously registered version, but created new instances. The older instances remained, and the palette contained the same widget multiple times. To remove the older duplicates, complete the following steps:

  1. In the Portal server, click on Administration.
  2. In the navigation area on the left, under Portlet Management, select Portlets.
  3. Search for the Human Task Management widgets. For example, search for the titles Task Information or Task List, and remove those duplicates without a unique name entry from the list.
  4. Repeat step 2 for each widget.

Step 11: Wire the widgets

In Business Space on the BPM server, widgets are automatically wired when dropped onto a page. In Portal, all widgets must currently be wired manually. There are two ways to do this:

  • In Page Edit mode, via the widgets' Display Menu. This is useful for creating the main wires, but does not provide a good view of the wires already in place.
  • On the Portal Administration page using Manage Pages under Portal User Interface.

If you don't know which wires are required, use the wiring editor in your reference space in Business Space to see which wires are between the widgets:

  1. While logged in, switch to the reference page (Interact with Processes and Tasks).
  2. Click Edit Page.
  3. From any widget, select Edit wiring from the drop-down menu for the widget.
  4. In the wiring editor, click on each widget to see which wires are used.

Wiring widgets in page edit mode

Wiring in the page edit mode is done using the Mashups wiring editor. In page edit mode, you start the wiring editor from the Display menu of a widget.

Note: If the Edit Page menu item is not shown, this may be a browser issue (for example, Firefox 4 cannot display it). In this case, try a different browser.

To wire the Tasks widget, for example, do the following:

  1. Go to the Interact with Processes and Tasks page.
  2. Under Actions, select Edit Page to edit the page.
  3. On the Tasks widget, select Edit Wiring from the widget's Display menu.
  4. On the Wiring menu, click Settings.
  5. Select Consider semantic types or payload type for matching of source and targets, as shown in Figure 13.
  6. Click Done.
  7. Under Content to send, select the wire that should be connected, for example Action Requested.
  8. Under Select a widget to receive content, select the receiving widget, for example Task Information.
  9. Under Select an action, select the desired action, for example Action Requested.
  10. If you need more actions to be wired, click on the widget listed under Select content to send and repeat steps 7 – 9.
  11. Click Done to leave the wiring editor.
  12. Repeat this for all widgets on the page. Click Save & Exit to exit the page edit mode when all widgets are wired.
Figure 13. Wiring widgets using the Edit Page
Wiring widgets using the Edit Page

Wiring widgets using Portal Administration pages

Wiring using the Portal Administration pages is done using the Manage Pages function. To wire the Tasks widget, for example, do the following:

  1. In the Portal server, click Administration.
  2. In the navigation area on the left, under Portal User Interface, select Manage Pages.
  3. On the Manage Pages dialog, search by Title starts with and enter the name of your widget page in the search field, then click Search. In this example, it is Interact with Processes and Tasks. The required page is displayed in the list.
  4. Click the Edit Page Layout icon on the right, as shown in Figure 14.
    Figure 14. Wiring widgets using Portal Administration
    Wiring widgets using Portal Administration
  5. Click the Wires tab to display the Portlet Wiring Tool.
  6. On the Portlet Wiring Tool dialog, click Consider semantic types or payload type for matching of source and targets.
  7. Select the widget you want to work with from the pull-down menu, and define the sending and receiving wires as required.
  8. Click Done when all widgets are wired.

Verifying the wires

To verify the wiring, open your Portal page by clicking Home, then select the Interact with Processes and Tasks tab and create a new task using the Task Definitions widget.

If your wires are correct, your new task should be opened in the Task Information widget.


Step 12: Configure the widgets (optional)

After wiring the widgets, you can configure the content of the widgets as you would do in the Business Space. For example, to change the view mode of the Task Definitions widget from table to list, do the following:

  • Click Edit Shared Settings from the widget's drop-down menu.
  • Click the Display tab.
  • Click List under Select a layout.
  • Click OK.

Your Portal page should now look like the reference space.


Conclusion

In this article, you extended your WebSphere Portal environment to host BPM widgets and created a Portal page so that users can start processes and perform actions on them as they would do in a Business Space page. You can now explore the possibilities of composing, wiring and configuring widgets in conjunction with portlets.


Download

DescriptionNameSize
Endpoint files and proxy configuration filesamplefiles.zip4KB

Resources

Comments

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


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Business process management, WebSphere
ArticleID=857737
ArticleTitle=Configuring IBM Business Process Management Human Task Management widgets for use in WebSphere Portal
publish-date=02132013