You are on page 1of 7

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.

Technical Operations Manual. and definitions of key terms on the user interface. 2. see SAP note 938717. Universal Worklist Universal Worklist End User Guide. 4.Authorizations needed for working with Business Workflow 1. 3. 7. 6. The code is only intended better explain and visualize the syntax and phrasing rules of certain coding. 2. 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. no additional setup is required when working in UWL. However. 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. 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. if there are any backend function module authorization issues. when the corresponding back-end system user already has the correct authorization to work on the Business Workflow directly. 5. alerts and notifications from back-end systems in the UWL you have to complete some mandatory configuration steps: 1. For showing tasks. SAP does not warrant the correctness and completeness of the code given herein. For information on how to use the Universal Worklist features. 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. . SAP note number 888457 for the latest UWL software updates. Normally. see the 3.

To facilitate acceptance of the logon ticket between a producer portal and a consumer portal. see related topics) and Single Sign-On (for portalDestination Service (for application-to-backend tasks). 3. If any applications on the producer portal retrieve data from a secure back-end system and logon tickets are used for SSO. you need to set up trust between the portals. For more information. SSO between all portals and portal applications use logon tickets. see Authentication Mechanisms and Single Sign-On Integration. 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. and applications available to the user. Once the user is authenticated to the portal. To facilitate client-to-backend and producer-to-backend SSO authentication. such as user mapping. For more information. you can use logon tickets or other forms of SSO. SSO eases user interaction with the many systems. and SAML. then you need to set up trust between the following systems: . For more information. see User Authentication and Single Sign-On. such as X. SSO in a Federated Portal Network In a federated portal network. he or she can use the portal to access the different systems without having to repeatedly enter his or her user information for authentication. 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. Communication between a producer portal and a consumer portal requires the use of logon tickets for SSO.Single Sign-On SAP NetWeaver offers several mechanisms for authenticating users. Apart from logon tickets and user mapping. Therefore. see Setting Up Trust.509 client certificates. see Single Sign-On. 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. if you are using alternative forms of SSO authentication between clients and a consumer portal. you can integrate other third-party SSO authentication methods into certain points within your landscape. 2. To facilitate SSO authentication between the client and a consumer portal. SPNego. you can use logon tickets or other forms of authentication. you still need to ensure that login module stacks for SSO include login modules for ticket evaluation and creation. the following should be noted: 1. 4. See also Configuring Authentication Mechanisms. For more information. components. For general information on SSO in the portal.

The producer portal and the back-end system 2. Working with producers and consumers in the same domain is strongly recommended. see Configuring SAP Web AS ABAP to Accept Logon Tickets from the J2EE Engine. 1. and the producer portal at runtime. 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. Working across multiple domains has inherent security risks and certain applications may have problems with client eventing. producer. Minor technical differences exist with the overall runtime flow between client. In remote delta link mode. the remote role assignment and remote delta link modes have the same requirements. The ticket is then sent by the client browser to the producer portal. only one logon ticket is issued by the consumer portal. The consumer portal creates the logon ticket and forwards it to the client (user). For more information. the consumer portal requests the navigation structure and framework for a remote role from the producer portal. since JavaScript policies restrict cross-domain scripting.0  User Productivity Enablement  Running an Enterprise Portal. the consumer portal. The consumer portal and the back-end system For information about setting up trust between SAPNetWeaver Portal and a SAPsystem. and consumer. From an SSO perspective. this is not relevant. For example. see:  How To Set Up the Landscape for a Federated Portal Network guide.com/irj/sdn/howtoguides  SAP NetWeaver 7.sap. available on SAP Developer Network at sdn. Setting up a federated portal network across multiple domains requires the use of SSO with logon tickets.1. in remote role assignment.  1. Logon Tickets for Multiple Domains In the remote role assignment and remote delta link modes. The following figure illustrates an authentication and data flow for remote role assignment: .

The producer generates and renders the iView markup and sends it to the client browser to be displayed in the portal runtime. and back-end systems allows SSO authentication to succeed using the logon ticket of the client. and Web Dynpro ABAP iViews) or through the producer portal (for example: Web Dynpro Java iViews). The client browser requests the content directly from the producer portal. . a session-based logon ticket must be issued as well. such as a backend system or the Web. 2.The flow of events in the system is as follows: 1. In cases where an iView or application retrieves its data from a data source. 1. The consumer portal requests the navigation structure and framework for the remote role from the producer portal. . The trust defined between the producer. 5.. The navigation properties from the previous request are sent back to the consumer portal. The consumer sends the role navigation structure and redirected URLs back to the client browser. 6. In such cases. URL iViews. 3. This flow assumes the user is already logged on to the portal. 4. The trust configuration between the consumer and producer allows the same session-based logon ticket to be used for SSO authentication. The consumer portal builds a navigation structure and creates new URLs (referencing the producer portal directly) for content assigned to the role. Other means of SSO can be used to authenticate the user with secure back-end systems. the iView type determines if the client accesses the data source directly (for example: SAP application iViews. Other forms of authentication that are not based on logon tickets are permitted for initial logon only. The client browser contacts the consumer portal. the consumer. 7.. which is required for most post-logon interactions.

a session-based logon ticket must be issued as well. and Web Dynpro ABAP iViews) or through the producer portal (for example: Web Dynpro Java iViews). 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 client browser contacts the consumer portal. 12.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. 9. 11. the iView type determines if the client accesses the data source directly (for example: SAP application iViews. which is required for most post-logon interactions.. The consumer portal generates and renders the navigation structures and iView markup. such as a backend system or the Web. URL iViews.. 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. In cases where an iView or application retrieves its data from a data source. Rendered iViews are sent back to the consumer portal. . 8. The consumer portal sends the rendered markup to the client browser to be displayed in the portal runtime. In such cases. This flow assumes the user is already logged on to the portal. 10. The trust configuration between the consumer and producer allows the same session-based logon ticket to be used for SSO authentication. . Other forms of authentication that are not based on logon tickets are permitted for initial logon only.

then they must do so on the consumer portal. Other means of SSO can be used to authenticate the user with secure back-end systems. end user. the consumer. this must be done directly on the producer portal. . For more information. groups. even though the systems are located on the producer portal. User Mapping in a Federated Portal Network User mapping is a form of enabling SSO. or both perform the user mapping for each system object. User mapping cannot be used to map one user on a consumer portal to another user on a producer portal—the same user must be defined per individual throughout the network. If business users are responsible for setting up their own user mapping to remote back-end systems. Administrators can make user mapping assignments in the portal using the User Administration  Identity Management interface. user mapping can be used to create shortcuts between a user on the consumer and a system defined on a 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. The system administrator responsible for configuring the necessary systems in the portal must define for each system if a user administrator. In a federated portal network. see User Mapping. Assignments can be made on the level of single users.The trust defined between the producer. Users must use the Personalization  User Mapping (Remote iViews) interface in the portal (see Mapping Your User to Remote Systems). which provides logon data per data source from the portal. and back-end systems allows SSO authentication to succeed using the logon ticket of the client. or entire roles. If an administrator is responsible for setting up the user mapping. The delegation of tasks depends on the nature of the data source.