Universal Worklist Configuration

The Universal Worklist (UWL) gives users unified and centralized way to access their work and the relevant information in the portal. It collects tasks and notifications from multiple provider systems SAP Business Workflow, Collaboration Task, Alert Framework and Knowledge Management Recent Notifications - in one list for one-stop access. Administration and configuration for the Universal Worklist (UWL) is described in this section.

Integration
UWL is integrated with: 1. 2. 3. 4. 5. 6. SAP NeWeaver Portal Application Server Java (AS Java) SAP Business Workflow Collaboration Task Alert Management Knowledge Management Collaboration Recent Notifications

Prerequisites
GeneralPrerequisites 1. As an administrator, you have full administration rights for the Portal and the required business workflow rights in back-end system (reference roles such as SAP_BC_BMT_WFM_UWL_ADMIN and SAP_BC_UWL_ADMIN_USER). Refer to SAP note 941589. 1. Make sure that each user is known to all connected SAP systems as per role requirement (make sure that there is one-to-one mapping between the portal user and the backend user) 1. If an iView is based on a system object defined in your system landscape (see System Landscape), you must assign user permission for the relevant user, group, or role to the system object, as well. User permissions assigned to a system permits the iView to retrieve data from the respective back-end application through the system object at runtime. 2. Each connected SAP system for back-end system (below release 7.0, WP-PI plug-in 6.0) has the connection to its respective SAP Internet Transaction Server (ITS) For information on SAP Enterprise Portal plug-in, see SAP note 655941.

Authorizations needed for working with Business Workflow 1. Normally, when the corresponding back-end system user already has the correct authorization to work on the Business Workflow directly, no additional setup is required when working in UWL. However, if there are any backend function module authorization issues, see SAP note 938717.

Overview of Configuration Steps

If you want to use the UWL only for collaboration tasks and for KM notifications, no minimal configuration is required at all. For showing tasks, alerts and notifications from back-end systems in the UWL you have to complete some mandatory configuration steps: 1. 2. 3. 4. 5. 6. 7. Define your SAP system Create a system alias to uniquely identify the system Define exact settings for technical connections Define how users are mapped Test system connections Add the new system to UWL configuration Register work item types

Reference Documentation 1. 2. SAP note number 888457 for the latest UWL software updates. For information on how to use the Universal Worklist features, and definitions of key terms on the user interface, see the 3. Universal Worklist Universal Worklist End User Guide. Technical Operations Manual.

Disclaimer Any software coding and/or codelines/strings included in this documentation are only examples and are not intended to be used in a productive system environment. The code is only intended better explain and visualize the syntax and phrasing rules of certain coding. SAP does not warrant the correctness and completeness of the code given herein, and SAP shall not be liable for errors or damages caused by the usage of the code, except if such damages were caused by SAP intentionally or grossly negligent.

Single Sign-On
SAP NetWeaver offers several mechanisms for authenticating users. If you have many systems in your system landscape, then a single sign-on (SSO) environment can help to reduce the number of passwords that users have to remember. For more information, see User Authentication and Single Sign-On.

SAP NetWeaver Portal provides two variants for enabling SSO depending on security requirements and the supported external applications:
SSO with logon tickets SSO with user ID and password

In the portal environment, SSO eases user interaction with the many systems, components, and applications available to the user. Once the user is authenticated to the portal, he or she can use the portal to access the different systems without having to repeatedly enter his or her user information for authentication. For general information on SSO in the portal, see Single Sign-On.

Apart from logon tickets and user mapping, you can integrate other third-party SSO authentication methods into certain points within your landscape.

SSO in a Federated Portal Network

In a federated portal network, the following should be noted:
1. 2. 3. Communication between a producer portal and a consumer portal requires the use of logon tickets for SSO. To facilitate acceptance of the logon ticket between a producer portal and a consumer portal, you need to set up trust between the portals. For more information, see Setting Up Trust. To facilitate SSO authentication between the client and a consumer portal, you can use logon tickets or other forms of authentication, such as X.509 client certificates, SPNego, and SAML.

SSO between all portals and portal applications use logon tickets. Therefore, if you are using alternative forms of SSO authentication between clients and a consumer portal, you still need to ensure that login module stacks for SSO include login modules for ticket evaluation and creation. You do this by either adjusting the login module stacks for J2EE applications or the authentication schemes for the portal iViews that users request access to. For more information, see Authentication Mechanisms and Single Sign-On Integration. See also Configuring Authentication Mechanisms.
4. To facilitate client-to-backend and producer-to-backend SSO authentication, you can use logon tickets or other forms of SSO, such as user mapping. For more information, see related topics) and Single Sign-On (for portalDestination Service (for application-to-backend tasks).

If any applications on the producer portal retrieve data from a secure back-end system and logon tickets are used for SSO, then you need to set up trust between the following systems:

1. The producer portal and the back-end system 2. The consumer portal and the back-end system
For information about setting up trust between SAPNetWeaver Portal and a SAPsystem, see Configuring SAP Web AS ABAP to Accept Logon Tickets from the J2EE Engine.
1. Working with producers and consumers in the same domain is strongly recommended. Working across multiple domains has inherent security risks and certain applications may have problems with client eventing, since JavaScript policies restrict cross-domain scripting. Setting up a federated portal network across multiple domains requires the use of SSO with logon tickets. For more information, see:

How To Set Up the Landscape for a Federated Portal Network guide, available on SAP Developer Network at sdn.sap.com/irj/sdn/howtoguides SAP NetWeaver 7.0 User Productivity Enablement Running an Enterprise Portal. Logon Tickets for Multiple Domains
In the remote role assignment and remote delta link modes, only one logon ticket is issued by the consumer portal. The consumer portal creates the logon ticket and forwards it to the client (user). The ticket is then sent by the client browser to the producer portal.

1.

SSO with Remote Role Assignment and Remote Delta Link Logon tickets and trust configurations enable single sign-on and allow the seamless flow of data between the client browser, the consumer portal, and the producer portal at runtime. From an SSO perspective, the remote role assignment and remote delta link modes have the same requirements. Minor technical differences exist with the overall runtime flow between client, producer, and consumer. For example, in remote role assignment, the consumer portal requests the navigation structure and framework for a remote role from the producer portal. In remote delta link mode, this is not relevant. The following figure illustrates an authentication and data flow for remote role assignment:

The flow of events in the system is as follows: 1. ... 1. The client browser contacts the consumer portal.
This flow assumes the user is already logged on to the portal. Other forms of authentication that are not based on logon tickets are permitted for initial logon only. In such cases, a session-based logon ticket must be issued as well, which is required for most post-logon interactions.

2. The consumer portal requests the navigation structure and framework for the remote role from the producer portal. The trust configuration between the consumer and producer allows the same session-based logon ticket to be used for SSO authentication. 3. The navigation properties from the previous request are sent back to the consumer portal. 4. The consumer portal builds a navigation structure and creates new URLs (referencing the producer portal directly) for content assigned to the role. 5. The consumer sends the role navigation structure and redirected URLs back to the client browser. 6. The client browser requests the content directly from the producer portal. 7. The producer generates and renders the iView markup and sends it to the client browser to be displayed in the portal runtime.

In cases where an iView or application retrieves its data from a data source, such as a backend system or the Web, the iView type determines if the client accesses the data source directly (for example: SAP application iViews, URL iViews, and Web Dynpro ABAP iViews) or through the producer portal (for example: Web Dynpro Java iViews). The trust defined between the producer, the consumer, and back-end systems allows SSO authentication to succeed using the logon ticket of the client. Other means of SSO can be used to authenticate the user with secure back-end systems.

SSO with WSRP Application Sharing One of the differences WSRP application sharing and the other content is that the client browser never accesses the producer portal directly. The following figure illustrates an authentication and data flow for WSRP application sharing between two NetWeaver portals:

The flow of events in the system is as follows: 2. ... 8. The client browser contacts the consumer portal.
This flow assumes the user is already logged on to the portal. Other forms of authentication that are not based on logon tickets are permitted for initial logon only. In such cases, a session-based logon ticket must be issued as well, which is required for most post-logon interactions.

9. The consumer portal processes its local proxy-to-portlet iViews and sends requests to the producer portal for all corresponding applications rendered by iViews. The trust configuration between the consumer and producer allows the same session-based logon ticket to be used for SSO authentication. 10. Rendered iViews are sent back to the consumer portal. 11. The consumer portal generates and renders the navigation structures and iView markup. 12. The consumer portal sends the rendered markup to the client browser to be displayed in the portal runtime.

In cases where an iView or application retrieves its data from a data source, such as a backend system or the Web, the iView type determines if the client accesses the data source directly (for example: SAP application iViews, URL iViews, and Web Dynpro ABAP iViews) or through the producer portal (for example: Web Dynpro Java iViews).

The trust defined between the producer, the consumer, and back-end systems allows SSO authentication to succeed using the logon ticket of the client. Other means of SSO can be used to authenticate the user with secure back-end systems.

User Mapping in a Federated Portal Network

User mapping is a form of enabling SSO, which provides logon data per data source from the portal. The system administrator responsible for configuring the necessary systems in the portal must define for each system if a user administrator, end user, or both perform the user mapping for each system object. The delegation of tasks depends on the nature of the data source. For more information, see User Mapping. In a federated portal network, user mapping can be used to create shortcuts between a user on the consumer and a system defined on a producer portal. User mapping cannot be used to map one user on a consumer portal to another user on a producer portalthe same user must be defined per individual throughout the network.
If an administrator is responsible for setting up the user mapping, this must be done directly on the producer portal. User administrators cannot set up user mapping on the consumer portal because the systems on which the remote iViews are based are not exposed on the consumer portal. Administrators can make user mapping assignments in the portal using the User Administration Identity Management interface. Assignments can be made on the level of single users, groups, or entire roles. If business users are responsible for setting up their own user mapping to remote back-end systems, then they must do so on the consumer portal, even though the systems are located on the producer portal. Users must use the Personalization User Mapping (Remote iViews) interface in the portal (see Mapping Your User to Remote Systems).