Dynamic human task UI mapper
Original Publication Date: 2009-Feb-23
Included in the Prior Art Database: 2009-Feb-23
Our invention contains two key ideas: 1. a Dynamic human task UI mapper in task list application for portal administrators to define the mapping between a human task and a human task processing page at runtime. This allows: - Clear role separation between portal administrator and process designer. - Portal page management does not depend on process designs. - No manual communication required between portal administrator and process designer. - Process designer does not need to worry about the portal UI aspect during the process design time. 2. a Rule-based dynamic human task UI mapper for the portal administrators to dynamically map one human task type to many task processing portal pages. For each mapping, portal administrators can define a rule. This allows: - more granular task processing portlet designs - richer portal user experience - flexible portal page management
Dynamic human task UI mapper
Portals can be the user interface for the human component of business processes. The portal displays a list of human tasks of business processes to notify users when they are assigned a new task. Each task is part of the larger business process, that can include many different types of human activities with automated services, creating a complete end-to-end workflow solution. Through this human task list, portal users can view, claim, and launch tasks on a new portal page, which contains a portlet to display the task specific user interface and to process the task in a certain way using Task APIs. Since the task list can contain many different types of human tasks, it is crucial for the task list portal to know which task processing page to launch when a portal user selects a task to work on it.
Typically, this is how current solution works. The steps highlighted in red indicate the limitations of the current solution.
Business process designer use the process development tool to create business processes.
identifier field of each human task using the process development tools during the process design phase.
Portal administrator creates the portal pages and assign them the agreed-upon unique portal
page names. (This step is possible only if Portal server exists in the system at the time of process design.)
Business process is complete and Process server administrator deploys it.
Portal administrator deploys a task processing portlet on the portal page.
Portal administrator deploys the task list portlet on a portal page that is configured to be a
dynamic extention node.
Business user logs into portal to see his/her task list.
Business user claims a task and launches the task.
The task list portlet retrieves the unique portal page name for the selected task from the human
task running within the business process on Process Server.
The task list portlet uses Dynamic Portal UI APIs to open the portal page referenced by the
unique portal page name dynamically.
Business process designer and portal administrator communicate with each other to agree on a
unique portal page name for each human task. (This step is possible only if Portal server exists in the system at the time of process design.)
Business process designer defines the agreed-upon unique portal page name in the Client UI
Details on how to enable business process for portal can be found at WebSphere Portal Server InfoCenter today. http://publib.boulder.ibm.com/infocenter/wpdoc/v6r0/topic/com.ibm.wp.ent.doc/wps/bpi
As described in step 2 ~ 4 above, the current solution requires the portal administrator to be involved in the process design phase to agree on the unique portal page name so that the process...