EP: Portal – UWL Functionality, Issues, Best Practices & Performance Tips

Introduction

With the Universal Worklist our end users are provided with a centralized means of accessing all core work-items and work tasks. The purpose of such task types or work-items varies surrounding business operations and can include sales orders, travel requests, leave requests or tracking setups. The management of such tasks is of vital importance as you can imagine due to the association they share to an organizations business operations and general practices. In my experiences I have dealt with many different scenarios which deal with seeking clarification on how the UWL itself functions along with a clean cut method of achieving the best performance.

How does the UWL Work?

In basic terms the Universal Worklist is built upon two primary pull operations each of which play a vital role in delivering work-items to end-users. The first primary pull occurs in which tasks are pulled from backend systems (through UWL Connectors) into the UWL Cache. Once maintained within the cache the tasks are then pulled again (through UWL Connectors) into the Users Inbox.

These primary pull operations come together to form the UWL Destination Service Configuration which in truth is the basis that the UWL follows in terms of function. The UWL Destination Service configuration is imperative when backend systems are involved and if a discrepancy exists in such configuration subsequent error exceptions & loss of functionality may indeed be encountered.

UWL Destination Service Configuration & RFC’s 

Now as highlighted above we have now established that the UWL (Universal Worklist) functions through a baseline concept known as the UWL Destination Service Configuration. Such configurations involve a core set of Connector Types which are utilized to retrieve items from the back-end systems.

• WebFlowConnector
• AlertConnector
• GenericAbapConnector

Viewing the Connector Status

1. Log on to the portal
2. Go to your main UWL iView
3. Next to the link Hide Preview click on the dropdown
4. From within the dropdown click on Display connection status

The RFC destinations have to be maintained so that the UWL can make functional calls to the backend applications. In most cases any exceptions or errors which you may encounter will be as a result of a discrepancy in such configurations.

What Type of Errors May I encounter?

Some of the most commonly encountered error exceptions include the following:

• “Cannot connect to the Provider” when you access tabs e.g. ESS/MSS
• “Problem occurred while creating JCO client for destination: ABCXYZ”
• “User is missing credentials for connecting to system alias: ABCXYZ”

How Do I resolve these errors?

• Solution: SAP Note: 1133821 – UWL Destination Service Configuration.

By following the documentation above we can ensure that the RFC destination is missing or is not configured properly.

After the note is implemented and the WebFlowConnector re-created the cache should be cleared and the backend re-registered.

Important: Check that after applying Note 1133821 the destination names and the UWL connector names exactly match, even considering case-sensitiveness.

If your portal system alias (=UWL connector name) is for example XYZCLNT100, then the RFC destination name should be exactly XYZCLNT100$WebFlowConnector. Please correct the RFC destination accordingly.

After you have checked/prepared the RFC destination for the future use please delete that connector in the UWL config UI (Portal->System
Administration->System Configuration->Universal Worklist) with which you would like to use this RFC destination.

After that

• Restart the portal cluster
• Recreate and reregister connector

Now retest.  Are you still seeing the issue?

These steps are important for the connector to work properly.  So in the portal, there needs to be a deletion on the connector, a restart of the portal cluster, then a recreate and re register so that the new connector interacts with the RFC destination.

---

UWL Performance Overview

In the past I have also dealt with general queries on improving UWL performance in which customers may be encountering slow refresh rates or inbox retrieval wait times. In this section I will attempt to shed some clarification on what you can do to make sure the UWL in your environment is configuration in accordance to optimal performance requirements.

Firstly as we touched on above there are two primary pull operations which make up the main functionality of the UWL. Due to this architecture there is an inherent delay in the automatic refreshes of the UWL. There is no way, in the current architecture that the UWL can refresh instantaneously.

• This is upon initial load as the cache must be built first upon logon so there will always be a delay.

there are some integral parameter configurations you can check regarding the UWL and performance AND I have outlined a set of Help Documentation Links below for your convenience:

• SAP KBA number: 1577547 UWL Performance * and Considerations

Also, you may want to take a look at our sizing guide that our colleagues in development support have written in relation to the UWL.

• You will find this if you go to: You can find the document under this path: www.service.sap.com/sizing > sizing guidelines ‘ SAP NetWeaver > UWL Sizing guide

These are details that you need in order for the performance to be optimal in the Universal Worklist. Please check through the documentation to see if your parameters are set accordingly and also that you have followed the information in this document.

Slow Performance & High Number of Workitems

With UWL scenarios the requirements differ among customers due to varying workloads. High workloads and  cleaning the UWL Cache is advisable especially due to the multiple workitems being registered within the cache each time the UWL is loaded or refreshed.

“New & In Progress” tasks along with “In Process” and “Completed” workitems are loaded each time the UWL is refreshed so if there is for example 5000 workitems divided up (New/Completed/InProcess) these will all have to be loaded in hence the importance of keeping an eye on the cache.

• Steps to clear the UWL cache: please go to “System Administration” “System Configuration” -> Universal Work list & Workflow -> Universal Workflow Administration -> Click on cache administration page -> Click “Clear Cache” button.

In truth the UWL Cache should be cleared when an item, which commonly involves a Web Dynpro UI screen, has been changed (this includes status changes) or customized and the changes are not reflected.

The UWL refresh interval is governed by the parameter “Default Cache Validity” which you can find under

– Universal Worklist Service Configuration link under System Administration -> System Configuration -> Universal Worklist.

The default value is 5 minutes. However, in case you want the refresh to happen earlier, you can decrease the value of this parameter. Setting this parameter to 1 means that the UWL cache will be refreshed every minute and the tasks on which an action is performed already will be removed in shorter amount of time.

If you expect the UWL to show the most up to date workitems as soon as the user logins in the UWL without having to wait, then 0 must be informed in the following parameter.

• ** Parameter: Wait duration before calling providers on loading of UWL **
• SAP Note: 1946648 – Display work items from UWL cache on user logon

With the UWL and any type of refresh value configurations it is about striking balance.

Key UWL Parameters + Pointers

• Delta Pull:
• Default Cache Validity Period, in Minutes:
• Maximum Number of Threads Created in the Thread Pool:
• Timeout Value for the Connected Systems, in Seconds:
• Number of Users per Pull Channel:

The delta pull period should be no longer than the time that task is required to be updated in the UWL for all new items from the backend. If the items are created more frequently, the period should be shortened and the opposite. Better results for performance will be with greater values, but in this case, the items may not be always up to date. The minimal value is 60 seconds, which is also the default. This corresponds to the following parameter on the portal in the UWL Admin UI for the webflow connector – Delta Pull Channel Refresh Period (in Seconds): 60. If you are using Delta Pull, please ensure that you DO NOT maintain the snapshot pull period and the value in this field (again a parameter on the portal in the UWL Admin UI for the webflow connector) should be deleted. In other words, it should be left empty as it just creates another temp channel for the user which is not required, thus impacting performance.

The number of users per channel can be increased with caution. The default value is 40 users per channel. Increasing this number will decrease the number of the invocations to the backend. This value depends on the number of the users that are using the portal. Larger number of users should = larger number of users per pull channel. The higher the number of users per channel, the higher volume of data per invocation will be transferred. Increasing this number too high without the necessary amount of memory needed could cause OOM (Out of memory issues) on the portal.

Taking the “Page Refresh Rate” into consideration which is maintained within the xml file, if you search for the word refresh here you will see it is = 300 by default. This is in seconds, so this means every user has their page refresh rate set to 5 minutes, unless configured otherwise, through personalization, or xml file. The smallest that this value can be set to is 1 minute. So the smallest value you can set this to in the xml file is 60 seconds. If you make a change to this value please ensure when you have uploaded your new file, that you rename it, upload it with high priority, then reregister the connector and clear the UWL cache. 1 second will negatively impair performance.

One additional point:

• Make sure that the UWL is NOT on the landing page. What I mean by this is to ensure that there is at least one page before the endusers see the UWL and they have to for example, click on Home –> Work, then the UWL appears, rather than having the users log on to the portal and the UWL is the first screen that they see.
• The reason for this is for each logon, there are calls to the backend made for EVERY system that is up in the UWL ADMIN UI.