In a business process solution with human tasks, there is always the requirement to have a frontend for users to find, claim, and work on their tasks. There are several possibilities for the task handling frontend integration. When choosing a solution, the business and technical requirements should be considered. One task handling option is to integrate a solution to a WebSphere Portal environment. For example, the main portal server functionalities are content integration, social platforms, and smarter work. With the mentioned process integration, WebSphere Portal Server can be augmented to a business process portal.
The concepts and technical details on how to create a business process portal integration solution, using WebSphere Portal Server V7.0 (hereafter called Portal Server) and WebSphere Process Server V7.0 (hereafter called Process Server) are documented in this article (see Figure 1). This article is based on concrete project experiences and the solution is online in a 24x7 environment. The focus of this article is specific to Process Server. Note that the main parts of this article are also valid for IBM Business Process Manager (BPM) and WebSphere Portal integration.
Figure 1. Integrate Portal Server with Process Server
When it comes to the implementation options for the task handling in a Portal Server environment, there are also the options to use the "My Tasks Portlet", Business Space human task widgets, custom portlet implementation, or to extend the functionality of the Unified Task List portlet with the Business Process Accelerator package. You can use the Business Process Accelerator package to create business processing portlets to process the human tasks surfaced in the Unified Task List.
For more details on integration options, see Integrating WebSphere Portal with IBM Business Process Manager.
In our project, we evaluated the previously mentioned integration options to find the best solution for the human task handling integration. Requirements and constraints for the integration solution came from the business users and also from the technical team. One technical requirement was, for example, to deploy and configure the fully automated solution by using scripts.
A good integration in Portal Server and the "look and feel" has been an important subject for business users. This was to provide a seamless extension of the existing Portal Server environment. From the technical side, one of the requirements was to have the integration based on loosely coupled components and protocols.
The existing portal site makes comprehensive use of virtual portals, which brought up additional requirements for the business process portal solution. It was important that human tasks are virtual portal aware. The virtual portals are used in the project environment to provide country-specific portal sites. The virtual portal awareness mandates that the task list solution must only show human tasks specific to a virtual portal, respectively, for the user country environment.
Figure 2 shows the virtual portal (country) task dependency. The task list in the headquarter (HQ) must only show human tasks defined for HQ, and vice versa, human tasks for Germany (DE) must only be shown in the DE virtual portal.
Figure 2. Human task dependencies in a virtual portal environment
Mainly based on the mentioned requirements, the project evaluation result was to use the Unified Task List Version 5.0 for the business process integration.
This article shows how to get started with the Unified Task List and how to set up the Unified Task List with manual tasks as well as an automated procedure (scripted). You will also learn how set up an integration solution in virtual portal environments.
Getting started with the Unified Task List
Integrating Process Server is one of the features of the Unified Task List. You can also use the Unified Task List to integrate WebSphere Lombardi Edition and IBM Business Process Manager. The features shipped with the Unified Task List meet integration and frontend requirements for the most of the common solutions. You can also use the Unified Task List developer package to further customize and extend the Unified Task List features.
Prerequisites and scope of this article
This article does not cover the installation and basic setup for Portal Server and Process Server. When installing Portal Server and Process Server in separate cells, which is the recommended setup, a Cross-Cell-Single Sign On (SSO) configuration is required. How to set up a Cross-Cell-SSO configuration is found in the product documentation.
The Unified Task List portlet provides the integration and selection for human tasks. When users work on (open) a task via the Unified Task List, a page is required to show the task specific data and available actions (for example, approve or reject a task). Such task pages are called task page definitions and contain task processing portlets. A task processing portlet is human task specific. Task page definitions use the Portal Server concept of dynamic pages. Another option to work with human task is the property broker eventing, which can be used for inter-portlet communication. For more information, see the Dynamic user interfaces page.
You can create dynamic pages and task handling portlets by using standard Portal Server development tools like Rational® Application Developer, or using the Web Experience Factory. The Unified Task List includes builders to do this. For more information about creating task processing portlets that interact with dynamic pages, see the Unified Task List developer pack documentation.
The creation and deployment of dynamic pages and task handling portlets are beyond the scope of this article. Documentation about these is found in the Portal Server product documentation and the article Developing business process portal applications using WebSphere tooling.
In this article, we show examples of XMLAccess and wsadmin scripts, but we do not provide details about how to use the tools. For more information, see XMLAccess (XML Configuration Interface) and wsadmin.
The Unified Task List setup
Let's start with the definition of the activities and sequence to install and configure the Unified Task List. Figure 3 shows the setup actions in the sequence, which proved to be successful in our project. We will talk in detail about each activity in the following sections.
Figure 3. Unified Task List setup actions
Deploy and place the Unified Task List
To get started, download the Unified Task List package and unzip the UnifiedTaskList_V5.0.zip file. This file contains the Unified Task list documentation (UnifiedTaskList.pdf) and the "Portal Application Archive" file (unifiedtasklist.paa), which can be used with the Portal Solution Installer.
The recommended approach to install Unified Task List is to use the Portal Solution Installer. If you can use the Portal Solution Installer in your Portal Server environment, we recommend that you follow the setup instructions in the Unified Task List documentation.
Actually, using the Portal Solution Installer in our project was not an option because existing automated deployment procedures were already in place. It was a requirement to use the established deployment process, which is based on wsadmin and XML Access.
To integrate the Unified Task List in the automated deployment process, we used the following steps:
- Extract the Unified Task List PAA (Portal Application Archive) file. Using your favorite zip tool, unzip the Unified Task List PAA file to a temporary directory.
- From the unzipped directory, copy the file tpir.jar
to the following Portal Server Profile
You can find the file tpir.jar in the unzipped directory at:
Portal Server as
<PortalServer_ProfileDirectory>/ConfigEngine.sh stop-server start-server
- Deploy and start the Unified Task List using the wsadmin
script. The Unified Task List Web Archive file (WAR) is located
in the unzipped directory
can use the sample wsadmin command script shown in Listing 1 to
install the WAR file. For additional information about how to start
and use wsadmin, see the Information Center.
Listing 1. Sample wsadmin script to install and start the Unified Task List application
##Sample wsadmin jython script to install the UTL war file # # Define UTL specific deployment parameters # # !Set/check the following parameters ! utl_war_file="E:/1UTL/unifiedtasklist.war" nodeName="punk-wp7-node02" serverName="WebSphere_Portal" appName="unifiedtasklist_war" ############ print "-> Starting Unified Task List installation." # Install the UTL war file cellName=AdminControl.getCell() AdminApp.install(utl_war_file, '[ -nopreCompileJSPs -distributeApp -nouseMetaDataFromBinary -nodeployejb -appname '+appName+' -createMBeansForResources -noreloadEnabled -nodeployws -validateinstall warn -noprocessEmbeddedConfig -filepermission .*\.dll=755#.*\.so=755#.*\.a=755#.*\.sl=755 -noallowDispatchRemoteInclude -noallowServiceRemoteInclude -asyncRequestDispatchType DISABLED -nouseAutoLink -contextroot /wps/unifiedtasklist -MapModulesToServers [[ WPF unifiedtasklist.war,WEB-INF/web.xml WebSphere:cell='+cellName+', node='+nodeName+',server='+serverName+' ]] -MapWebModToVH [[ WPF unifiedtasklist.war,WEB-INF/web.xml default_host ]]]' ) print " - Application installed." # Save the configuration AdminConfig.save() print " - Configuration saved - Starting application." # Start the UTL application # Get the WebSphere AppServer Application Manager Object appManager = AdminControl.queryNames('cell='+cellName+',node='+nodeName+', type=ApplicationManager,process='+serverName+',*') AdminControl.invoke(appManager, 'startApplication', appName) print " - Application Unified Task List started" print "-> Installation done." ####DONE###
- Now register the deployed Unified Task List application in Portal
Server. The registration of pre-deployed portlets in Portal Server is
done via an XMLAccess script.
Listing 2 shows an XMLAccess example to register the pre-deployed Unified Task List Portlet.
Listing 2. XMLAccess to register the pre-deployed Unified Task List application in Portal Server
<?xml version="1.0" encoding="UTF-8"?> <request xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="PortalConfig_7.0.0.xsd" type="update" create-oids="true"> <portal action="locate"> <web-app action="update" predeployed="true" active="true" uid="com.bowstreet.portlet.WebAppRunner2_unifiedtasklist.webmod"> <url>file:<WP_Profile_Dir>\installedApps\<NodeName>\ unifiedtasklist_war.ear\unifiedtasklist.war</url> <context-root>/wps/unifiedtasklist</context-root> <display-name>unifiedtasklist</display-name> <servlet action="update" active="true" objectid="Unified Task List Portlet" referenceid="Unified Task List Portlet.servlet" /> <portlet-app action="update" active="true" uid="Unified Task List Portlet"> <portlet action="update" active="true" uniquename="UTL_Portlet" name="Unified Task List Portlet" servletref="Unified Task List Portlet.servlet"> </portlet> </portlet-app> </web-app> </portal> </request>
- Create a portal page and place the Unified Task List using
Listing 3 shows the XMLAccess script to create a "HumanTasks" Portal Server page and place the Unified Task List portlet on that page. This is just an example, as you want to place this page in a more appropriate place in your Portal Server page structure.
Listing 3. XMLAccess to create a Portal Server page and place the Unified Task List portlet
<request build="wp7001CF03_001_15" type="update" version="184.108.40.206" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation= "PortalConfig_7.0.0.xsd"> <portal action="locate"> <web-app action="locate" domain="rel" uid="com.bowstreet.portlet. WebAppRunner2_unifiedtasklist.webmod"> <servlet action="locate" domain="rel" name="Unified Task List Portlet"/> <portlet-app action="locate" domain="rel" name="com.bowstreet.portlet.WebAppRunner2_unifiedtasklist" uid="com.bowstreet.portlet.WebAppRunner2_unifiedtasklist"> <portlet action="locate" domain="rel" uniquename="UTL_Portlet" objectid="utlPortletID"/> </portlet-app> </web-app> <content-node action="locate" domain="rel" uniquename= "wps.content.root"/> <content-node action="locate" domain="rel" uniquename= "ibm.portal.Home"/> <content-node action="update" active="true" allportletsallowed="true" content-parentref="ibm.portal.Home" create-type="explicit" domain="rel" ordinal="300" type="page" uniquename="Task"> <supported-markup markup="html" update="set"/> <localedata locale="de"> <title>Meine Aufgaben</title> </localedata> <localedata locale="en"> <title>My Tasks</title> </localedata> <component action="update" active="true" deletable="undefined" domain="rel" modifiable="undefined" ordinal="100" orientation="V" skinref="undefined" type="container" width="undefined"> <component action="update" active="true" deletable="undefined" domain="rel" modifiable="undefined" ordinal="100" skinref="undefined" type="control" width="undefined"> <portletinstance action="update" domain="rel" portletref="utlPortletID"> <preferences name="wpf_edit_defaults.com.ibm.accelerators.utl.VisibleFilters:VisibleFilters" update="set"> <!-- Define the Visible Filters for -this- Virtual Portal : HQ--> <value><![CDATA[ <FilterSettings xmlns="http://www.ibm.com/wps/utl/VisibleFiltersSchema"> <DefaultFilter>Headquarter_Tasks</DefaultFilter> <VisibleFilters> <FilterID>Headquarter_Tasks</FilterID> <FilterID>Headquarter_ClaimedTaks</FilterID> <FilterID>Headquarter_UnClaimedTasks</FilterID> </VisibleFilters> </FilterSettings>]]> </value> </preferences> </portletinstance> </component> </component> </content-node> </portal> </request>
After successful completion of the deployment and placement steps, the Unified Task List portlet is available in the Portal Server and you can make further configurations.
- To access the Unified Task List, login to Portal Server and select the
My Tasks page. The page name "My Tasks" was set via
the placement XMLAccess script. In case you are using a non-English locale
set in your browser, the page name is translated to the appropriate
language. For German locales, the page name is "Meine Aufgaben".
There is only one Unified Task List portlet instance for all country portals (virtual portals). This single instance is shared and placed on separate pages in the virtual portals.
Configure the Unified Task List Portlet
You have now deployed and placed the Unified Task List. The next steps are the integration and environment specific configurations. To access the Unified Task List configuration, open the page where the Unified Task List was placed, hover with the mouse over the upper right corner of the portlet (portlet menu), and select Configure to open the portlet configuration view, as shown in Figure 4.
Figure 4. Open the configuration view for the Unified Task List Portlet
Configure task provider instances
- Open the Unified Task List configuration and click on Task
When configuring a Task Provider Instance, you have to choose a provider. For Process Server, the options "IBM WebSphere Process Server" and "IBM WebSphere Process Server 7 (Task Query Table API)" are available. To clarify which provider to use, discuss with your business process developers, and ask if the business process implementation uses task query tables. In our project, we did not use task query tables, and so the provider IBM WebSphere Process Server was chosen as shown in Figure 5.
Figure 5. Task Provider Instance configuration
- Set a Name for the task provider, select Enabled to activate it, and click Next.
- To configure the Process Server Task Provider Instance, the Human Task
Manager Web Service SOAP Endpoint from the Process Server system is
There are two options to get the Process Server TaskContainer SOAP endpoint.
- "Construct" the SOAP Endpoint.
Replace the Process Server system
parameters in the following URL to get the right SOAP endpoint
http://<WPS_HOST>:<WPS_HTTP_PORT>/HT MIF_<WPS_Node>_<WPS_Server>/sca/com/ibm/task/ api/sca/HTMWS
Here is an example:
- Export the Human Task Manager WSDL files using the WebSphere
Application Server Admin Console – this is the recommended
- Open the IBM Solution Console on the Process Server system. Navigate to Applications > Application Types > WebSphere enterprise applications TaskContainer_<WPS_Node>_<WPS_Server> > Publish WSDL files.
- Open the zip file
and navigate to the following
- Open the HTMWS.wsdl file. The SOAP endpoint is
defined at the end of the
When you use a Load-Balancer or an HTTP Server in front of the Process Server system, then
<WPS_HTTP_PORT>have to be set to the HTTP Server with the Load-Balancer values.
The tasks returned from a Task Provider Instance are defined by the Where Clause of Task Query (see Figure 6). A where clause is based on the Human Task Query syntax. Details about Process Server where clause queries are found in the Process Server Information Center.
You can completely type in a custom task query string, or use one of the sample clauses. In our project, we started with a sample clause and extended those with the query for the virtual portal custom property.
Figure 6. Configure a task provider endpoint and task query
Following is an example for a query clause that shows all the "Ready Tasks" for the virtual portal "Headquarter". The virtual portal is identified by the value "hq" for the custom task property "vp.selector.prop". Task custom properties are described in more detail in the next section.
(TASK.TKTID = TASK_TEMPL_DESC.TKTID) AND (TASK.STATE = TASK.STATE.STATE_READY) AND (TASK.KIND = TASK.KIND.KIND_PARTICIPATING) AND (WORK_ITEM.REASON = WORK_ITEM.REASON. REASON_POTENTIAL_OWNER) AND TASK_CPROP1.NAME='vp.selector.prop' AND TASK_CPROP1.STRING_VALUE='hq'
- TASK_CPROP1.NAME: This parameter must be available at the human task.
- TASK_CPROP1.STRING_VALUE: This parameter value is checked in the query.
Task provider details
Within the Unified Task List configuration, you can define multiple task providers. This may be necessary if there are multiple backend servers. Or, as in our case, the requirement is that the Unified Task List presents a customized menu with the task list display options "All Tasks", "Claimed Tasks", and "Ready Tasks" (unclaimed tasks).
We defined one Task Provider Instance for each of the task states (All, Claimed, Ready). The distinction between the different tasks state happens via the "TASK.STATE" parameter in the Human Task query statement.
To recap, another project requirement was to present the users only virtual portal (country) specific tasks. For this to happen, we used a custom property at the human tasks level with the name of "vp.selector.prop". Custom property definitions have to take place during human task development in WebSphere Integration Developer. Further details about human task custom properties are described in Selecting a human task with custom properties using WebSphere Process Server.
To select tasks based on the custom property values, the Task Provider human task queries are extended to find only tasks matching the custom property value. Based on that, we created three Task Instance Provider instances for each existing virtual portal. For this example, there are only two virtual portals, but this can be further extended.
This results in six Task Provider instances as shown in Table 1.
Table 1. Task provider to custom property mapping
|Task Provider Name||Custom Property Value (vp.selector.prop)|
|All Tasks for German Portal||de|
|Claimed Task for German Portal||de|
|Ready Tasks for German Portal||de|
|All Tasks for Headquarter Portal||hq|
|Claimed Task for Headquarter Portal||hq|
|Ready Tasks for Headquarter Portal||hq|
With all the task providers defined, the Unified Task List configuration for our project looks similar to Figure 7.
Figure 7. List of defined task providers
Combine task providers using task filters
Using filters, the human tasks from more than one Task Provider Instance can be combined in one menu item for business users. Even if there is only one Task Provider Instance, you must define a filter for this instance configuration.
We had to define one filter for each Task Provider Instance, so we ended up with six filters.
- In the Unified Task List configuration, select Filters (see Figure 8) and click Add to define a new filter.
- Set a name for the filter and to define a resource key. We will talk about the resource key later.
- In the drop down box, select the Task Instance
Provider to create a filter, and click the
+ icon to add the provider to the filter
configuration. Click Submit to complete the filter
Figure 8. Filter configuration
The filter is now available in the Filters configuration view as shown in Figure 9.
Figure 9. Defined filters list
Task handling configuration of the Unified Task List
There are three options for the task handling connection method: Dynamic Portal Page, External URL, and Property Broker Event. Mainly based on the project team's project experiences, the Dynamic Portal Page method was used in the referenced project. This section will focus on the setup for using Dynamic Portal Pages for task handling.
When a business user claims a task, the next step is to open and work with that task. This means that the task data must be presented to the user in the frontend with features to execute the possible task actions. Such functionality is provided by the task handling pages and task handling portlets. The creation of task handling pages and portlets is not covered in this article.
Beside the task pages and task handling portlets, one further portal page is required. This additional page is called extension node. The extension node page is a plain portal page, which must be enabled as an extension node. Details about this task are found in the Portal Server product documentation, Developing a dynamic UI configuration. The task handling pages and one extension node have to be defined for each virtual portal.
The focus of this section is the task handling configuration of the Unified Task List.
Each distinct human task type requires a separate task handling page. And for each task handling page, one task handling definition has to be configured in the Unified Task List. For example, in our project we had five human task types so we created five task handling configurations, one for each task handling page.
To configure a Unified Task List Task Handler, you need the unique name of the task handling page for the specific task type. Think about a naming concept for unique names when creating the task pages in Portal Server.
Open the Unified Task List configuration, and select Task Handling (see Figure 10), click Add to open the task handling configuration.
When opening the Task Handling configuration, the Unified Task List connects to the defined Process Server (task provider instances). That is, all options shown in the drop down boxes represent the actual running modules from the Process Server system.
Working with the task handling configuration is actually the first test to see if the task provider configuration and the cross-cell communication is correct.
If you do not see any modules, check your configuration and the Portal Server log files for possible errors messages.
Apart from the text input field for the Unique ID of Portal Page, all other parameters can be selected from the drop down boxes.
Figure 10. Task handling configuration
Assign the correct task handling page to an application and task type, and click Submit to create the task handler. Remember, you have to create a task handler for each task type.
Configure visible filters to present the task list to users
With the configuration done so far, you can connect to the Process Server. You have created filters and defined the task handling. This section shows how to configure the Unified Task List menu items presented to business users. The menu items are defined as visible filters.
As mentioned, Process Server and Portal users must only see and work on
human tasks specific to their country. This is distinct by the virtual
portal identifier the user is logged into, for example
To achieve this, define the custom property named "vp.selector.prop" on the human tasks. This custom property is used as the filter criteria in the where clause in our task provider instances. In addition, the Unified Task List visible filters are used to further filter and group how tasks are displayed to the user.
Using the visible filter configuration, you can define which filters are shown in a country specific virtual portal. The visible filter configuration is different for each virtual portal where the Unified Task List portlet is used.
In our project experience, we did not start with the visible filter configuration before finalizing the localization configuration. First, create and change the localization files (see Using localization with filters), and then start with the visual filter configuration. This way, you see the localized text for the filters in the visible filter configuration.
To access the Visual Filter configuration, click on Edit Shared Settings in the Unified Task List portlet menu. To add filters to the visible filters list in the shared settings, select a filter from the list and add it by clicking the add icon. You can add multiple filters to the visible filters list. In our case, we added the visible filters for claimed tasks, unclaimed tasks, and all tasks. This way, the user can select between three views in the Unified Task List.
With three defined visible filters and the adjusted resource bundle files, the Unified Task List menu looks like either Figure 11 or Figure 12.
Figure 11. Unified Task List menu for the German locale
Figure 12. Unified Task List menu for the English locale
After the visible filter configuration, the Unified Task List is ready to be tested.
Using localization with filters and visible filters
The Unified Task List provides localization functionalities, which are based on the Portal Server locale features. Depending on the users locale settings (browser language, Portal profile), all pages and portlets are translated to the user's language.
As you saw in the Combine task providers using task filters section, each filter has an associated resource key defined. You use resource bundle files to set and translate the text for the defined filter resource keys.
Resource bundle files are located in a configurable directory below this path:
The name of the "Bundle_Directory" is configured as a custom property on the Portal Server Config Service Resource environment provider. Use the following steps to configure the directory and bundle file names.
- Open the "Integrated Solutions Console" for the Portal Server cell.
- Go to Resource environment providers > WP ConfigService> Custom properties.
- Click New (or edit the existing property).
processintegration.filtersetresourcebundlein the Name field.
- For the Value field, you enter a package definition for the bundle
director and the bundle file name, such as
For example, if the bundle files are stored as this:
You enter the following package name as
- Click Apply and OK.
The bundle files are named
_<Locale>.properties. If no bundle file for the user's locale is found, the default localization file,
.properties, is used.
You can edit the existing localization files, or just add further localization files to the directory to meet the language requirements. In a clustered WebSphere ND environment with multiple nodes, you have to distribute the bundle files to all Portal nodes.
You can also create the resource bundle files using a text editor, and place the files in a response file directory structure on a shared file system.
Configure the Unified Task List using a scripted procedure
In a real world project, we always recommend to script and automate all setup and configuration steps. With a scripted configuration, you can minimize failures caused by manual actions and provide a fast, reliable, and repeatable setup process.
In the last sections, we used the Unified Task List web interface to do the configuration. Using this approach, the effort to set up a project environment with several stages, such as development, stage, and production systems, is very high and error prone.
To automate the Unified Task List configuration, you can set up a procedure based on some configuration scripts. The scripts are mainly based on the Portal Server XML Configuration Interface, XMLAccess.
As you saw during the manual configuration, the Unified Task List has two configuration sections:
- The common configuration for all virtual portals (such as task provider instance, filters, task handling, and localization).
- The shared configuration, which is virtual portal specific (visible filters).
The common Unified Task List configuration is saved as preference data at the portlet level. To view the configuration, open the Configure Portlet (see Figure 13) in the Portal Server manage portlets administration for the Unified Task List portlet.
Figure 13. Open the Unified Task List configuration
Figure 14 shows a sample configuration preference and values. As you see, the preference names are matched to the Unified Task List options we configured in the web interface configuration.
Figure 14. Unified Task List Portlet preference page
The settings are represented as one string in the Value fields, and are not meant to be changed here, nor would it be easy to do this. To edit and change the portlet configuration, a good approach is to export the data to an XML file. This can be done in the Portal administration, or using XMLAccess.
To export the required configurations using XMLAccess, the Unified Task List Web Module has to be exported. This can be done using the script shown in Listing 4.
Listing 4. XMLAccess to export the Unified Task List configuration
<?xml version="1.0" encoding="UTF-8"?> <request build="wp7001CF03_001_15" type="export" version="220.127.116.11" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="PortalConfig_7.0.0.xsd"> <portal action="locate"> <web-app action="export" domain="rel" uid="com.bowstreet.portlet. WebAppRunner2_unifiedtasklist.webmod"> </web-app> </portal> </request>
The resulting XMLAccess XML file contains all the common data that you can adjust for another environment. The XML file is comprehensive and too large to be shown here. You can find a sample file in the Download section of this article.
You can use the exported Unified Task List XML file to import the
configuration into another environment. For example, if you successfully
tested the configuration in the stage environment, you can set up the
Unified Task List, identical in the production environment, using this
XMLAccess XML file. Actually, you will have to at least change the Process
Server connection data to target the task provider to the production
Process Server system. For this, you have to change all
<ID>SoapEndpoint</ID> entries, then
use XMLAccess to import the configuration into Portal Server.
Also, a prerequisite for this to work is that you have successfully completed the steps described in the Deploy and place the Unified Task List section for the target environment. If you made changes to the resource bundle file, remember to also transfer those files to the other system.
Scripting the shared configuration
The virtual portal specific configuration for visible filters is defined at the portlet instance level. You can set this data by using an XMLAccess script. Listing 5 shows the visible filter configuration for a specific virtual portal (Germany: de).
Listing 5. XMLAccess to set the shared configuration used for visible filters
<request build="wp7001CF03_001_15" type="update" version="18.104.22.168" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="PortalConfig_7.0.0.xsd"> <portal action="locate"> <web-app action="locate" domain="rel" uid="com.bowstreet.portlet. WebAppRunner2_unifiedtasklist.webmod"> <servlet action="locate" domain="rel" name="Unified Task List Portlet"/> <portlet-app action="locate" domain="rel" name="com.bowstreet.portlet.WebAppRunner2_unifiedtasklist" uid="com.bowstreet.portlet.WebAppRunner2_unifiedtasklist"> <portlet action="locate" domain="rel" name="Unified Task List Portlet" objectid="utlPortletID"/> </portlet-app> </web-app> <content-node action="update" active="true" allportletsallowed="true" content-parentref="ibm.portal.Home" create-type="explicit" domain="rel" ordinal="300" type="page" uniquename="Task"> <component action="update" active="true" deletable="undefined" domain="rel" modifiable="undefined" ordinal="100" orientation="V" skinref="undefined" type="container" width="undefined"> <component action="update" active="true" deletable="undefined" domain="rel" modifiable="undefined" ordinal="100" skinref="undefined" type="control" width="undefined"> <portletinstance action="update" domain="rel" portletref="utlPortletID"> <preferences name="wpf_edit_defaults.com.ibm.accelerators.utl. VisibleFilters:VisibleFilters" update="set"> <!-- Define the Visible Filters for Virtual Portal : DE--> <value><![CDATA[ <FilterSettings xmlns="http://www.ibm.com/wps/utl/VisibleFiltersSchema"> <DefaultFilter>Germany_Tasks</DefaultFilter> <VisibleFilters> <FilterID>Germany_AllTasks</FilterID> <FilterID>Germany_ClaimedTasks</FilterID> <FilterID>Germany_UnclaimedTasks</FilterID> </VisibleFilters> </FilterSettings>]]> </value> </preferences> </portletinstance> </component> </component> </content-node> </portal> </request>
Using the provided sample scripts provided with this article, you not need to manually configure the Unified Task List. You just need to run XMLAccess to import the common and the shared configuration to a Portal Server environment. This minimizes the manual effort and ensures identical configurations in different environments.
If the environment fulfilled all the prerequisites and you followed the steps in this article, the Unified Task List portlet should show the available tasks.
If not, here are some points to check:
- Does SSO really work?
See this technote on how to validate SSO.
- Does the Portal user really have tasks on Process
You can check this for example with the "Business Process Explorer" (BPC Explorer) on the Process Server site.
- Check that the user is assigned as a potential owner for the tasks.
- Login to BPC Exporer with the user and click on My To-dos.
- If the setup is correct, and the user has tasks, then tracing
will help to further analyze the situation.
To see what's going on in the Unified Task List, enable the following trace string on Portal Server:
com.ibm.accelerators.utl.*=all. In addition, to see more details on the Process Server site, enable the following trace details:
com.ibm.bpe.*=all: com.ibm.task.*=all:com.ibm.ws.security. *=all:com.ibm.ws.staffsupport.*=all
Analyzing the trace data can be complex, but the data can provide a hint to the cause and why the Unfied Task List does not show the expected tasks.
The Unified Task List is one option to extend a WebSphere Portal Server environment to a business process portal. Using examples taken from a real customer project, this article showed the sequence and detailed actions to get up and running with the Unified Task List. Based on this, you learned how to integrate in a virtual portal environment and how to use scripts for the configuration.
The author would like to thank Paul Thomas and David Rockett for their technical review of this article. In addition, thanks to Thomas Reske who provided support and guidance in the creation of this article.
|Code sample file||UTL-Scripts.zip||9KB|
- Download the Unified Task List portlet from the "IBM Lotus and WebSphere Portal Business Solutions Catalog" (Greenhouse).
- The IBM WebSphere Portal Unified Task List Portlet Developer Pack includes a jump start example that covers the processing of a sample business process from start to finish in WebSphere Portal.
- Unified Task List Developer Pack documentation
- WebSphere Portal Server V7 product documentation
- WebSphere Portal V7 Solution Installer
- Integration in WebSphere Portal V7
- WebSphere Application Server scripting interface (wsadmin)
- WebSphere Portal Server XML configuration interface XMLAccess
- Comparison of the programming interfaces for retrieving process and task data