Overview  Package  Class  Use  Tree  Deprecated  Index  Help 
SAP NetWeaver 2004S SPS 10
 PREV   NEXT FRAMES    NO FRAMES    
The Universal Worklist (UWL) gives users unified and centralized way to access their work and the relevant information in the Enterprise Portal.

See:
          Description

Packages
com.sap.netweaver.bc.uwl Contains API for main classes and interfaces used with UWL.
com.sap.netweaver.bc.uwl.admin Provides API for administering the UWL.
com.sap.netweaver.bc.uwl.config Contains UWL Configuration related classes.
com.sap.netweaver.bc.uwl.connect Contains interfaces that define the interaction with different provider systems.
com.sap.netweaver.bc.uwl.i18n  
com.sap.netweaver.bc.uwl.substitution This package contains interface and data definition for the substitution functionality presented in UWL.

 

The Universal Worklist (UWL) gives users unified and centralized way to access their work and the relevant information in the Enterprise Portal. It collects tasks and notifications from multiple provider systems - Business Workflow (WebFlow) as well as Java Ad Hoc Workflow and Alert System - in one list for one-stop access.

  Contents:  Glossary   |  Architecture   |   Service Components  | Program interfaces   |   

Glossary

Ad Hoc Workflow

Ad Hoc Workflow Wizard provides the ability for an end user to build and initiate custom workflow processes. Each workflow process potentially produces work items which are displayed in the Universal Worklist (UWL). The end user can create processes consisting of a number of tasks that persist until done, or assign individual tasks to separate users.

AWF

See Ad Hoc Workflow.

Business Workflow

You can use the WebFlow Engine (SAP Business Workflow) to define business processes that are not yet mapped in the SAP System. These may be simple release or approval procedures, or more complex business processes such as creating a material master and the associated coordination of the departments involved. The WebFlow Engine is particularly suitable for situations in which work processes have to be run through repeatedly, or situations in which the business process requires the involvement of a large number of agents in a specific sequence. Work items for agents are listed in the UWL, for which the Business Workflow is one provider.

Collaboration

Collaboration brings users, information, and applications together to ensure successful cooperation. All collaboration tools and channels are easily accessible directly from the portal. These tools include collaboration rooms, instant messaging, chat, e-mail, and calendar integration.

Collaboration Room

Collaboration Rooms are flexibly structured virtual working environments for teams or project groups, and provide a central entry point to all information, tools, and services necessary for working together (single point of access principle). The tools and services include Messaging, Tasks, Attachments, Discussions, Room functions such as calendar, and integration of groupware systems from third-parties.

Connector

The UWL interacts with (task) item providers through specific connector, how map the provider API and data into the UWL API and data model. The Connector API is defined by the UWL.

Enterprise Portal

The Enterprise Portal offers a single point of access to information, enterprise applications, and services both in and outside the organization. It provides the tools to manage this knowledge, to analyze and interrelate it, and to share and collaborate on the basis of it.  With its coherent interface, role-based content, and personalization features, the portal enables the user to focus exclusively on data relevant to his daily decision-making processes. The SAP Enterprise Portal is one of the building blocks in the SAP NetWeaverTM architecture.

KM

See Knowledge Management.

Knowledge Management

As part of the Enterprise Portal, Knowledge Management offers capabilities that everyone can use to distribute and access unstructured information within an organization through a heterogeneous repository landscape.

Provider

Provider system is the source of items for the UWL.

Architecture And Behavior         top

Over view

The Universal Worklist provides end users with a list of items to work on and with notifications regarding their work. In the Enterprise Portal, the UWL is the central place where the users find their tasks.

The work items and notifications are collected from multiple and different provider systems, e.g. SAP Business Workflow (a.k.a. WebFlow), Java Ad-Hoc Workflow, Alert system and other sources.

 Basic User Functions

The basic user functions are:

Work Item

The work items contain

  List Views

List views describe how work items are presented in a list. They define

Often, an item type or category is associated with a specific list view. List views can be personalized by the user.

A navigation model describes how the list views are structured and presented in user interface controls like navigation bar, navigation tree, dropdown or folder tabs.

Service components

The following architectural diagram describes the functional components of the UWL service.

The UWL User Interface is implemented as Enterprise Portal Java iView based on the HTMLB service. Other additional implementation may follow, in particular on WebDynpro and the KM Flexible UI. The UWL user interface communicates through a well defined interface, the UWL Service API, with the UWL View Manager and Item Manager. This Java API could be used by any client.

The View Manager manages the definition of the different list views for the item and process types and categories. It also supports personalization of the views through the end user.

The Item Manager retrieves work items including their dynamic attributes, process information and attachments from the different provider systems. It may cache data to optimize performance, and it aggregates and filters the work items for presentation in the user interface.

The Item Push API allows provider systems to push work items directly into the work list. The UWL will take ownership of those items and store them in the cache store, but it will still inform the provider of certain events in the item lifecycle.

Workflow engine like ABAP Webflow and Java Ad-Hoc Workflow do not usually push items. Those providers can be queried for work items as soon as the user goes online.
Provider Connectors know the specifics of these providers and convert work items and process information into the UWL data model. The connectors perform basic mapping of attribute values and determine the work item type and execution method. They also know how to connect to object and attachment repositories to retrieve additional custom attributes or attachments. The UWL comes with standard provider connectors and it is possible to configure their detailed behavior based on work item types.

Action Handler handles the execution of work items. Standard Handlers are available to launch application iViews, pages, SAP HTML GUI transactions and ITS MiniApps. Provider specific actions handlers implement the handling of standard actions like user decisions and item forward.

The Configuration API allows applications and administrators to define item types, list views, and other UWL specific preferences.

There is also an additional Administration API for basic maintenance functions

Service Component Collaboration               top

The service behavior is best explained by describing the collaboration scenarios for the involved components. The following diagram gives an overview about the basic data object involved in the service collaboration:

 

The following scenario step numbers refer to request channels in the architecture diagram

   Scenario A: Retrieve Work Items and render Initial Worklist

  1. In the Portal, the user navigates to a page with the Universal Worklist.

  2. The Portal Run Time initializes the UWL Portal Component and provides it with the request. The Portal Component prepares to render the UWL navigation bar and the default item list view.

  3. The UI requests the user specific navigation model and the default list view information from the View Manager through the UWL Service API.

  4. The View Manager retrieves the required information from the configuration.

  5. The UI requests the items which correspond to the list view from the item manager through the UWL Service API.

  6. The item manager retrieves configuration information required to resolve the request.

  7. There might be already items stored for the user in the service database. The item manger requests these items from the cache store.

  8. The item manger has also to retrieve the items for the user from the configured provider systems which have to be pulled. The item manager provides the user credentials to the corresponding provider connectors.

  9. The Plug-In provider connectors connect to their provider systems to retrieve the work items and notifications for the user. The provider connector determines the type of the arriving items.

  10. Depending on the item type, the provider connector might query additional custom attributes from object repositories, depending on the item type configuration. Note that the query for additional attributes for each item it an expensive operation. The provider connector might decide to return items with incomplete attributes to allow fast response times for the user. The additional attributes are still retrieved in the background and are available at subsequent requests.

  11. The completed items (as well as the one with deferred attributes) are passed to the item manager through the Item Push API.

  12. The item manager caches the new items for later requests.

Finally, the item manager responds the A3 request from the UI and returns the requested items. The UI renders navigation bar and list view.

 Scenario B: Execute Action on Item

  1. In the UWL UI, the user selects and item and clicks on an action button or link.

  2. The Portal Run Time propagates the action event to the UI component.

  3. The UWL UI notifies the item manager of the action through the UWL Service API.

  4. The item manager determines the responsible plug-in action handler and delegates the action execution.

  5. The action handler calls either the executing application or portal component (passing the defined parameters), or (b) the provider itself (e.g. the workflow engines for user decisions or item forward).

  6. Application components may notify the workflow providers of the result of the action and continue with the workflow.

Note that in other cases the action handlers are used to render execution URLs directly in the UI, in particular to launch application components for work item processing.

 Scenario C: Push Work item into the Worklist

  1. A UWL provider pushes item into the worklist using the Item Push API.

  2. The item manager stores the item in the database. If the provider has registered a listener, the item manager notifies the provider of subsequent events or queries additional item information.

Note: This is not the most used scenario. Typically items are pulled to UWL through connector on demand i.e. only if user need them.

Scenario D: Provide List View and Item Type Configuration

  1. The application component registers its specific list view, item type and navigation information with the UWL configuration through the configuration API.

  2. The configuration manager stores the received views and types in the configuration store.

Program Interfaces / Integration             top

The Program Interfaces are formed from three main APIs, depending on their function:

UWL Service API

The entire user interaction with the UWL is routed through the Service API. UWL User Interface implementations use the UWL Service API to retrieve the presentation configuration as well as the items, as well as to perform activities on the items.

The Service API covers the following use cases:

  1. Retrieve detailed information about the list view being displayed
  2. Retrieve the items for display in the list view; take sorting order and filter conditions into account
  3. Retrieve connectivity status information to item providers
  4. Retrieve the navigation model
  5. Retrieve additional item attributes (like description)
  6. Retrieve the list of attachments to an item
  7. Retrieve attachments
  8. Upload and delete attachments
  9. Retrieve process context information for an item
  10. Search for items with specific conditions
  11. Delete items (if permitted)
  12. Retrieve action URLs for items
  13. Execute item actions
  14. Mark items as read
  15. Mark items as done
  16. Personalize views

IUWLService is the entry point. It is the main interface for the UWL UI and other clients. Other UWL interfaces can be got through IUWLService.

One of the primary things a UWLService client needs to do is to initiate a session (IUWLSession) with UWLService. For all the APIs the portal relevant parameters are passed thro UWLContext object. 

Retrieval of Items

Once a session is initiated,  IUWLItemManager can be used to retrieve the items (Item) in various ways.  Items for retrieval can be restricted based upon different parameters including Views or CompoundExpressions or QueryProperty or ItemTypes. Filtering on item's attribute values can be achieved using CompoundExpression and Expression. 

The getItems() method of IUWLItemManager typically return a QueryResult structure which is composed of ItemCollection and ProviderStatus information. Further information on retreival methods is present in IUWLItemManager documentation.

In addition to standard attribute (like subject, description etc.)  present in Item object, Item may optionally contain Attributes and Attachments assigned to it.

Item Type

The item type is an important UWL concept and used to determine

  1. the default execution of an item and other valid actions
  2. custom attributes which have to be retrieved from external sources, and how these attributes are retrieved
  3. the view which represents the item and its attributes best

This information is specified in the UWL configuration. Item types are hierarchical. Item types inherit the type view from parent types.

Standard item types are

An example for an item type defined by an application scenario is

If not directly provided by the provider with the item, the item type has to be determined by the provider connector when the item is pulled or pushed.Hierarchy of item types is established by the naming convention. uwl is parent for uwl.task and uwl.task is parent for uwl.task.approval.

Actions

All operations that can be done on work items are modeled as actions. Usual actions for work items are:

View and ViewManager

A view refers to information on how to display and control the items types for the logged in user.  Views will have display attributes that can be sorted on, given desired display order, or if it is displayed at all. Other attributes of a view are the ability to define filters to restrict data and/or consolidation to allow multiple tasks to be displayed in one view.  Each view can be personalized for each user to indicate desired look. This personalized view information has the visibility scope for only the logged in user.

The UWL UI uses the view attributes to render the actual UI component, e.g. by using the HTMLB Dropdown component for the filter selection and the TableView component to set up the list view.

IUWLViewManager can be accessed by getViewManager() from the UWL Service.  View Manager contains methods for retrieval of views, personalization of views and navigations.

The class UWLView is a so-called value object or transfer object class that acts only as data container and does not have functional methods by itself. Note also that the UWLView does only contain descriptive information how the items should be displayed and what filter conditions they should meet. It does not contain the items themselves, or references to them.

Columns shown in  a view a are defined by Display Attributes. The display attribute gives information on how the item data should be represented in the UI.  Views and DisplayAttributes also contain information regarding Actions displayed in the view. Following figure shows some of Actions shown in the View.

View also contains information regarding column order and other display related styles. More information can be found in the View documentation.

UWL Connector API              top

There are basically two ways the UWL service receives work items:

  1. The providers push the items into the UWL

  2. The UWL requests or pulls the items from the provider, either
      i.      When the user is online in real time
         ii.      On scheduled intervals (not implemented in the first release)

 Other use cases for which provider connections become relevant are:

  1. The UWL calls the provider of pushed items for additional deferred information
  2. The UWL calls object repositories to retrieve additional attributes for the work item according to the work item type definition
  3. The UWL manages attachments of work items, including display, add, update, and delete.
  4. The UWL asks the provider to execute actions

There is a cookbook (UWL Custom Connector API) on how to implement a new connector. The cookbook contains an example. In addition you can find a detailed example using SAP Office Mail in another cookbook (Connecting SAP Office Mail to the Universal Worklist). The complete working code of the example with the required NetWeaver Developer Studio development components and projects is available on SDN. You can simply download the sample and quickly run it (sample code for RSS connector).

The cases mentioned above are covered by the following APIs.

Pushing of Items: IPushChannel

UWL supports other components to push items into UWL system.

It is also possible for the IProviderConnector to update or delete the already pushed items. Pushing of Items is possible through IPushChannel interface which could be got thro IUWLService's getPushChannel() method

A requirement for pushing items is to register as IProviderConnector. Only registered ProviderConnector may push items into UWL system. Registration could be done using UWL Configuration API registerProviderConnector().

Pulling of items: IProivderConnector

A Connector connects a Provider System with UWL. There exists several connector interfaces in UWL.

An IProviderConnector knows how to connect to the provider system and retrieve the items. So there is always provider connector specific configuration information present. For example R3Connector needs information on all R3 systems to connect to, their versions, user id, password for the connection (typically got from Portal landscape).

The ProviderConnector implementation could use J2EE connector framework service internally. Configuration information is stored in the KM configuration framework. In addition to retrieving items, IProviderConnector may (optional) also perform following operations on the retrieved items.

  1. Sorting
  2. Computing item type
  3. Filling different attributes

In order for performance enhancements, when getItems() is called, ProviderConnector can fill only some attributes of the Item and mark the Item as hollow by setHollow(). For all hollow items, populateHollowItem() is called  in a second step (may be in a different thread).

IAttributeAccessConnector

Attribute access connectors are used to retrieve the attributes that are defined as part of the item types custom attributes.

In the configuration for an item type, source for these custom attributes are also defined. This source could be ABAP BOR, Java Workflow BOI etc. And for each kind of these source types one Attribute Access Connector is registered.

IAttachmentConnector

Item may optionally contain attachment headers.To fetch the actual attachment content IAttachmentConnector is used.

IActionHandler

Every Action has an IActionHandler associated with it. ActionHandler can be provider specific and accessible through provider connectors getActionHandler method; but there are also standard action handlers, in particular launchers which do not require communication back to the provider.

The action methods of the item manager delegate to IActionHandler. Method getUrl() returns the URL to trigger the action. Method performAction() performs the acion by invoking the provider system.

Implementations whose name ends with Launcher do not communicate the result of execution to the provider system. They just launch an external user interface, typically in a new browser window to deal with the same. Implementations whose name ends with Handler communicate the result of execution to the provider system. Method isLauncher() is used for this determination. List of ActionHandlers shipped by UWL can be seen here.

Every Item type has a default action (that happens when the subject link is clicked).

Method performAction takes care of communicating with the provider system the action that is undertaken. It returns ProviderStatus, which contains the result as communicated by the provider after reacting to the action.

UWL Administration API        top

The Configuration and Administration API covers the following use cases:

 It is important to understand that the main objects of configuration, item types, views and navigation, can be defined and redefined on the following different levels:

  1. Standard :Provided by the UWL service itself, available with the service
  2. Application:Provided by the application scenarios and usually deployed with the applications
  3. Custom: Adapted for a specific implementation of the UWL at the customer site
  4. Personal:The end user modifies or extends the existing configuration for personal needs

The lower level can override definitions of the upper levels.

Application configuration is usually deployed in the form of XML files or importable backend configuration; customization is usually done using an administration UI (but also allows XML upload). Structure of the XML file is defined by uwl configuration DTD file. A description of this DTD file is found in the DTD documentation. Corresponding to XML tags, there are Java classes. Documentation on these are found in the  configuration package.

Configuration Information basically consists of Item Types and Views which in turn define how Items are shown , what actions could be done, what custom attributes items can have etc.. More information on ItemType can be found in the ItemType documentation. Views are documented in the View and ViewManager section.

IUWLConfigurationManager is accessed through IUWLService interface. Administration user interface could use IUWLConfigurationManager interface to access configuration related functionality. IUWLConfigurationAdmin contains methods for registering , customizing and personalizing the configuration information.

 

 

 

 Overview  Package  Class  Use  Tree  Deprecated  Index  Help 
SAP NetWeaver 2004S SPS 10
 PREV   NEXT FRAMES    NO FRAMES    
Copyright 2006 SAP AG Complete Copyright Notice