It was some time back that I was totally taken back by a couple of UWL issues. The issues really took us by surprise and made us give them all the respect. The best out come of this scenario was that we came to know about the UWL more than what we had in the past. I just thought of sharing them with SAP enthusiasts because when I tried to find the same information on SDN, unfortunately I didn’t find much. May be I didn’t type the right key words for the search but the fact was that I actually could not find it on web.
The version of our portal is 7.0. Though pretty old, our old boy is taking the best of care of the requirements.
The first issue that we faced was regarding the storage of data(work items) of Universal Work list. Questions surrounded the clause that where exactly portal stores the UWL work items, how are they fetched and what is the mechanism. We have a simple UWL functionality that triggers an email, once everyday, to all those users who have open/in progress/new work items in their work list. The catch here was that not all the concerned users were receiving email notifications for their work items. According to the initial design the work item count was fetched from the portal database that stored all the work items for the users. If the work item count was more than one then an email was triggered to the concerned user. The name of the Data Base table is < SAPEPPDB.KMC_UWL_ITEMS >. You can easily find this table in the portal database. Now, the first thing that we observed was that this table is a cache table. It stores the UWL data only for those users who have already opened the UWL page in portal. To test this, we simply cleared this table in the development environment and then opened the UWL page in portal for one of the users. Nothing happened till the time the user was navigating on different screens other than UWL page. However, the moment he opened the UWL page, an entry was registered in the table <SAPEPPDB.KMC_UWL_ITEMS> against his name. This made us understand that portal DB table is of no use if we want to send the email notifications based on the work item count. Because post portal restarts or on clearing UWL cache, this table would always be wiped out of data and hence no user would receive email notifications. This also bought into question the delta pull jobs that are used to fetch data from the backend (R3 system) to the portal. Ideally there are two jobs that are responsible for data pull from the backend.
- UWL_DELTA_PULL_1 – Runs ABAP report RSWNUWLSEL in FULL mode. Scheduled once in a day, this job fetches the complete data from the R3 to the portal. When I say data I mean all the open work items for a user. In the above test scenario, we ran this job just to check if the portal DB flushes with the data for all the users. Unfortunately, it didn’t fetch anything for us.
- UWL_DELTA_PULL_2 – Runs ABAP report RSWNUWLSEL in FULL mode. Scheduled every three minutes, this job fetches only the new/edited/deleted data for a user. Even this job was unable to fill the DB with any data.
Portal with version 7.0 does not support auto refresh functionality. Hence we need to set the above two mentioned jobs and also need to set time for ‘Delta Pull mechanism’ that can be found by navigating through the following path. System Administration -> System Configuration -> Universal Work list -> Universal Work list administrator -> Select Webflow connector for a system. Two properties with the following name will get displayed.
- Delta Pull Channel Refresh Period (in Seconds): 60
- Delta Pull Channel Snapshot Refresh Period (in Minutes): 5
According to the SAP, the second property is obsolete and does not have an impact on the system. However, the first property is the one that is responsible for data refresh on the UWL page. We also noticed that once an action was taken on any work item, it got immediately updated in the DB. For example, we approved one item in the work list of one of the user and found that immediately it got wiped off from the DB table as well. However, it took some time for the same work item to get off from the UWL page. So this made us conclude that the first property mentioned above helps in updating the UWL page.
In the end, we concluded that the best place to see open/in progress/new work items for a user is SAP Business workplace. We simply created a function module that gave us a flag that indicated the presence of a work item. If the flag was true, we triggered an email to the user saying ‘You have open work item to act upon’. Finally we bought the issue to a closure and gained more insight on the UWL and its relationship with portal DB.
Regarding the display of work item count, the UWL API fails badly in it. This was another requirement to fetch the UWL count for a user and display the same on the portal masthead. The reason for the failure of UWL API here is the same. It connects with the UWL DB to get the count. So on clearing the UWL cache or on portal restart, the count will surely fluctuate and would not be accurate. So to get work item count it is better to rely on some standard SAP function modules like “SAP_WAPI_CREATE_WORKLIST”.
Though the issues/requirements were small yet it helped us in understanding the functioning of universal work list. We realized that UWL is not just about creating UWL system, assigning alias, creating webflow connector, registering the webflows etc. But there are things that work in the background and that always help to understand things better. When the day ended we were satisfied with our finding and had a sense of satisfaction. It will be a value add if the readers add their piece of observation to this blog.