- SAP Managed Tags:
Introduction
If you are familiar with the Universal Worklist from an end-users perspective you will know that the UWL itself serves as a centralized task management platform for a wide array of processes.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.
Sample Scenario: You need to remove task types?
Lets imagine you have a workitem approval scenario for managers which revolves around different managers approving and rejecting overtime requests for employees. Now the way in which this process is configured means that when a "request" is either "approved" or "rejected" the employee will receive a confirmation.
So let us imagine
- User A (Employee) sends a request (overtime) for approval to their manager.
- User B (Manager) receives the request and approves it (meaning notification and confirmation is sent to the employee).
- However the workitem (despite being approved) remains in the end-users (employees) UWL Inbox and therefore appears active (when it should be completed).
For the reason the employee follows the obvious approach and attempts to find a means of removing the workitem since in fact it has been completed. If we add a degree of further complexity to this sample scenario we can imagine the same behavior happening for "Rejected" requests which undoubtedly means task duplication will occur and the employees & managers Inbox will be overflowing with "dormant" tasks. The status of the these overtime requests may remain as "released for approval" and if these are not approved on time financial impacts may occur.
Lets Remember: How the UWL works.
The UWL follows two primary pull operations as its baseline means of functionality. When an end-users firstly opens the UWL tasks are pulled from the backend systems (across connectors) into the UWL Cache. A second pull operation then takes place and the workitems/tasks are pulled from the cache into the UWL Interface. If you intend on removing any tasks from the setup you need to firstly remember the key question here of whether you want to remove workitems from the UWL or the actual workflow?
UWL - Task Management - Can We Really Delete Tasks?
So after some discussion you confirm that you need to remove some invalid tasks from the UWL Worklist for the manager specifically related to overtime. Firstly you may have heard that should be able to view and access the workflow overview through the following navigation path:
- Logon to the Enterprise Portal
- Navigate to Content Administration & Workflow Content
- Select Workflow Tasks & Locate the workitem
These reports are part of Collaborations and are supported by the UWL.
- However in true essence these are not documented and we do not promote & support such a deletion method.
The steps outlined above are a typical approach for the deletion of worktasks but not recommended. Outlined below is a comprehensive guidance document highlighting how to hide, remove and manage workitems accordingly.
- Removing Actions From the UWL Display: https://help.sap.com/saphelp_nw70ehp1/helpdata/en/09/6d6b17b29b4eef83a553acaa52f668/frameset.htm
- Tasks: https://help.sap.com/saphelp_nw70/helpdata/en/ef/f2aed99c414f81adacc6b897a6910a/content.htm
In relation to the deletion of tasks themselves. There is no official walkthrough documentation provided by SAP as this is not encouraged
unless there is no other means of solution. If the tasks we are dealing with are Java Workflow tasks, meaning that there is no backend system involved in the scenario for these particular items,then the "task" of interest is part of a Task List, which has have created through the "Create Task" uwl button.
If you want the UWL to manage workitems accordingly to ensure the Inbox is kept "current" the Refresh option can be used to bring the recent workitems that are generated and available in SWPR but not in the UWL itself. The workitems once processed properly will be automatically removed from the UWL and their associated status will change.
SAP KBA: 1577547 - UWL Performance Tips and Considerations
UWL Refresh & Performance Parameters:
There are many configuration options that affect the performance and in the process of creation, the sizing guide determines the hardware requirements.
- Number of users
- Total number of items per user
- Number of connectors
Performance Degradation Factors
- Sometimes specific connectors (BPMUWL) cannot fulfill the get items request. There is 30 seconds timeout defined for the connectors (configurable)
- Communication channel between UWL and providers (Network, JCo)
Performance Configuration Recommendations
- Use Delta Pull mechanism (where applicable)
- 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 higher values but the items may not be always up to date.The minimal value is 60 seconds and it is default value as well.
- Cache validity should have a longer period value than the delta pull.If cache validity has expired then a call to backend will be performed regardless of the fact that delta pull has occurred.
- Page refresh rate, that is accessible from data properties of Personalize Tasks, specifies how often UI will be refreshed with data from the cache. Note that the cache validity period takes precedence.Then the Page refresh rate should have less period value than cache validity. Last comes the Delta Pull period. In short: Cache Validity > Page refresh rate > Delta Pull period.
- The number of users per channel depends on the number of the tasks and the number of theusers. Default value is 40 users per channel. Increasing this number will decrease the number of the invocation to the backend. Note that the higher the number of users per channel, the higher volume of data per invocation will be transferred.
- The IView property “Wait duration for UI refresh while waiting for update” can be increased if UI is not responsive. If the value of this property is set to 0 then user interface will be blocked waiting for the call to the backend to complete. In this case after call is completed and cache is updated, items are read from cache displayed in the UI. Assigning value to the property allows the UI to read the last data found in cache and display it immediately, this way unblocking UI while the call to backend is performed in background. After the time defined in the property passes, presumably cache already updated with the latest items in background, UI is updated again from cache showing the latest items.
- The number of the custom attributes should be decreased.For every additional attribute an additional call to backend is performed. The setting “Retrieve custom attribute via primary pull” should be switched off.
