cancel
Showing results for 
Search instead for 
Did you mean: 

Automatic Claim of UWL tasks no longer working

Former Member
0 Kudos

Hi All,

We are on IE11 and 7.31 sp16.

I am not sure if this issue is a side effect from a recent SAP upgrade or the upgrade to IE11 but we have noticed that our custom UWL tasks are no longer being automatically claimed.  That is to say when a user clicks on the task in their UWL, it is no longer removing that task from other user's UWL.  So in essence we could have a number of users all working on the same process.. not good..

We have made no change to this application/UWL config.  It has been working fine for the last 8 years.

I'm wondering if additional UWL config is required for our tasks since the upgrade?  Anyone experienced this before?

Many thanks in advance,

Liz.

Accepted Solutions (0)

Answers (2)

Answers (2)

troy_cronin2
Active Contributor
0 Kudos

Hi Liz

I hope you are keeping well and many thanks for using the SAP Discussion Forums .

Based upon the scenario that you have described let us break it down together and review the details:

  • IE11 and 7.31 SP16 & custom UWL tasks are no longer being automatically claimed. When a user clicks on the task in their UWL, it is no longer removing that task from other user's UWL.  No change to this application/UWL config.  It has been working fine for the last 8 years.

Ok firstly from a high level perspective could you kindly provide clarification on the following:

  • What happens if you perform a manual refresh in the UWL ('selecting the refresh button')?
  • What is the XML Priority of this this task 'TS99500171'?

Now regarding the UWL itself you mentioned that "when the user clicks on the tasks in their UWL, it is not removed subsequently from the other user" therefore this is obviously causing confusion. The UWL functions using two primary pull operations (at logon) firstly tasks are pulled from the backend into the UWL Cache and then a second pull takes place from the Cache into the Interface.

  • Is real-time-refresh configured?

The reason I'm asking here is that due to the architecture of the UWL itself as mentioned above there is an inherent delay in the automatic refreshes of the UWL. If you perform a "Manual Refresh" or wait for a duration of 5 minutes do the tasks dissappear from one users inbox?


  • With issues such as these Real Time Refresh can be enabled to update the UWL in a more real-time aspect.

Real Time Refresh (RTR) mechanism of UWL enables automatic update of the UWL task and alerts list. Thus, when items are set to status Complete, they are removed from the New and In Progress view in the UWL.


  • If you are noticing that the workitems are clearing after 5 or so minutes.
  • If so, then check the following parameters on your portal: and bear this in mind:
  • Cache Validity >  Page Refresh Rate > Delta Pull Refresh Period

This is the value setup they should follow i.e. each of the above is a separate parameter:

  • You can check the Cache Validity Period through System Admin, system config, uwl and workflow, Universal worklist administration,
  • Scroll halfway down the page and open the tray for Optional Universal Worklist Service Configuration.
  • Check the default cache validity period 5 minutes. It should not be less than 1 minute.

Page Refresh Rate

  • Finally check the main UWL iview: Click on the dropdown which has the option to personalize. Select Personalize view.
  • Click on the page refresh rate time. The Page Refresh Rate specifies how often UI will be refreshed with data from the cache.


Delta Pull Refresh Period

  • System Admin, system config, select the system, click edit, what is the delta pull refresh period, it should not be less than 1 minute.

Checking the parameters outlined above might seem tedious but it will give us a better idea of how the UWL is configured and the pull operations are taking place. If the item never leaves then we need to delve deeper although if the item eventually changes status then we can focus on parameters.

Let me know how you get on and I will respond once time permits.

Kind Regards & Talk Soon

Troy Cronin - Enterprise Portal Support Engineer

Former Member
0 Kudos

Hey Troy,

Hope all is well with you my friend.  100,000 thanks for all of the above!  

I will check out and come back to you in a bit.

All the best,

Liz.

troy_cronin2
Active Contributor
0 Kudos

Hey Liz

No problem at all, my pleasure to help out.

Let me know how you get on and talk soon.

Kind Regards

Troy

Former Member
0 Kudos

Ok so here we go!

What happens when you perform a manual refresh - nothing! task remains in all approvers inbox

XML priority of task  TS99500171 - High.  Xml priority is high for all our custom stuff.

Cache validity period  = 5 minutes

Main UWL iview page refresh rate = 5 minutes

Data Pull Refresh Period = no value defined - aha! could this be it!?!?

Many thanks again for your help with this.  You are a true gentleman and scholar

All the best,

Liz.

troy_cronin2
Active Contributor
0 Kudos

Hey Liz

Truly my pleasure !

Ok now regarding your analysis findings you mentioned that there is no change after performing a manual refresh which is quite peculiar in true essence. One point to checkout here on your side is the default trace on the UWL if you can take a look at it on your side and see if there are any EP-BC-UWL exceptions being thrown.

For guidance you can use the KBA outlined below to capture the trace. If you are able to reproduce the issue at hand, try doing so and then subsequently have a look at the trace. If you see any EP-BC-UWL references you can send them onto me and I will take a look.

Based on whats reveled in the trace this will let us rule out potential errors as contributing factors in the scenario and issue.

Now onto the observations you made:

  • Cache validity period  = 5 minutes
  • Main UWL iview page refresh rate = 5 minutes
  • Data Pull Refresh Period = no value defined

Now regarding these parameter settings they are all about striking balance and are dependent on specific system requirements and loads i.e. they will differ among customers.

In terms of the most optimal and recommend setup the baseline point of reference is that of:

  • SAP KBA: 1577547 UWL Performance Tips and Considerations

Lastly let us cover the "Delta Pull Refresh Period".

In terms of the Delta Pull itself its configuration and the underlying baseline operations there are a few important points to highlight.

The Delta Pull mechanism of UWL enables new items to be fetched from the back end SAP systems every minute by default every 60 seconds, and every 30 seconds for alerts.

However, this can be configured. The user does not need to use the refresh function to update the inbox. Once items are retrieved, timestamps are updated for the users whose items are successfully retrieved.

  • These retrieved items are updated in the UWL cache.

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 user and is not required, thus impacting performance.

Let me know how you get on and if you need anymore clarifications here.

Always happy to help out 

Kind Regards & Talk Soon

Troy

Former Member
0 Kudos

Hey Troy,

So I got the trace files from Basis and could not believe the amount of these exceptions!  See below

a snapshot from the time and my name is all over that! (I'm hoping the quality of this image will be good enough, if not tell me..)

Now oh learned one..  Perchance can you explain to me what it means?  How could I possibly not be mapped to a portal user?  I've worked here years and portal admin is part of my job.. The mind boggles!

Thanks in advance,

Liz.

troy_cronin2
Active Contributor
0 Kudos

Hey Liz

Many thanks for taking the time to gather the traces from your colleague and the image size is fine no problem at all .

So lets us take the error exceptions from the perspective of the UWL and have a look:

  • External user [USLOLEARY] of external system [SAP_R3] not mapped to a portal user
  • Item with external id@ <000002959897> and system id: <SAP_R3>: No object instance key available for attributes lookup

Now this would appear to be thrown and highlighted due to a small discrepancy and there are a few little checks you can make here:

  • Check if your UME & user e.g. USLOLEARY is pointing to the correct system
  • Review the UserMapping setup, by checking that the the correct user (backend) is being "mapped" to the Portal user. Then try to reactivate and re-register the connector.

Secondly I have come across a few instances with the UWL in which a "Backend User" being mapped to "multiple Portal Users" has caused completed items i.e. those taken action on to remain in the inbox i.e. they are not removed.

The reason for this behavior is that the workflow system is using user mapping for authentication and multiple portal users have been mapped to the same R/3 backend user in User Management.

Due to the fact that multiple portal users have been mapped to a single R/3 backend user, an incorrect portal user is notified about item refresh.

  1. Go to User Administration -> Identity Management
  2. Make sure your R3 backend user has been mapped to only to one portal user.

Lastly let me know if you came across anything interesting in the parameters (for performance) we discussed earlier and if anymore UWL Exceptions have been noted.

Kind Regards & Talk Soon

Troy

Former Member
0 Kudos

Hey Troy,

So I had a look at the user mapping and lo and behold we have, in fact, no user mapping!  When I went to the tab user mapping for system access on my user, it says this:

"There are no systems available for user mapping for the selected principle"

If there is no user mapping and then therefore no authentication by the workflow, is this the cause of our issue?

Yours in awe of your knowledge ,

Liz.

troy_cronin2
Active Contributor
0 Kudos

Hey Liz

Many thanks for the respond and update regarding your findings, greatly appreciated

Ok now in relation to the User Mapping let us tie back to what we discussed earlier surrounding the UWL and its underlying operations i.e. how it functions.

The UWL functions using two primary pull operations (at logon) firstly tasks are pulled from the backend into the UWL Cache and then a second pull takes place from the Cache into the Interface.


So it layman's terms we have the UWL UI retrieving items from backend systems e.g. SRM PLM etc.


Now back to User Mapping and why its important I would recommend reviewing the link outlined below:


https://help.sap.com/saphelp_nw73/helpdata/en/4a/fe5bcbf0ca4f78e10000000a421937/content.htm?frameset...


There is also the additional guidance documentation on provider systems


https://help.sap.com/saphelp_nw73/helpdata/en/4b/0497c463c12b5fe10000000a42189c/content.htm?frameset...


It could be indeed playing a role here dependent on how your workflow is configured.


Regarding the highlight noted: "There are no systems available for user mapping for the selected principle" in theory you should be able to confirm via User Administration --> User Mapping. Here you just need to search the name/group/role to which you wish to assign username and password for a given system and set the username and password.


  • With SSO however User Mapping is not required.

Could you kindly follow the steps below and let me know the connector status(s) in the right hand column.

  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
  5. Please send me a screenshot of this information.


Thanks for your patience and understanding thus far and talk soon my friend.

Kind Regards & All The Best

Troy

Former Member
0 Kudos

Hey Troy,

Hope all is well with you.  Thanks again for all your help with this.  Very kind of you to be going to such trouble!

Anyway, I was reading your message with bated breath, thinking yes this user mapping is the issue until I go to the part about SSO, we do have SSO implemented on our system. Boo, thought that was gonna be it!

You said that it could play a role depending on how my workflow is  configured.  What did you mean by that? 

Anyway, see below, the connection status you requested:

I look forward to hearing from you,

Liz.

troy_cronin2
Active Contributor
0 Kudos

Hey Liz

No problem what so ever now as we see here all UWL Connectors operate successfully which is good news this is what by referring to "how your workflow is configured" in association to the UWL setup and the backend calls.

  • However everything appears to be fine here which is perfect.

Now lets go back to what you mentioned (SSO is configured however): you went to the tab user mapping for system access on my user, it says this:

  • "There are no systems available for user mapping for the selected principle"

The most likely reason for the system not being shown on the "User Mapping for System Access" tab is that the group being edited in "Identity Management" doesn't have "enduser" permissions for the system. Since we are speaking about portal groups is possible that these are PCD permissions that can be configured either in the system Landscape editor or the Permissions editor of the Portal.

Please see page 8 in the below document and make sure that the aliases are set:

This should in theory remove this error exception highlight from the trace and then we can see where we are at.

Thanks for your patience and understanding thus far and talk soon.

Kind Regards & All The Best

Troy

Former Member
0 Kudos

Troy!!  I was just thinking I hadn't heard from you in a while and imagine my embarrassment when I went and checked and realised I had not replied to your last mail.

Apologies, had something big going live and totally forgot..

I will check out what you have suggested and come back to you.

Thanks!

Liz.

troy_cronin2
Active Contributor
0 Kudos

Hey Liz

Absolutely no problem at all update me at your convenience, I'm always here

Talk Soon

All The Best

Troy

Former Member
0 Kudos

So I've been doing some more testing and I've made a discovery.  Automatic claim of the tasks is still occurring on our system, if the method linked to the task is asynchronous i.e. has a terminating event.

Tasks with methods that are synchronous with no terminating event, the status is returned to ready once you cancel out of it.  Once you click on the task, the status does change to started.  once you x out of it, the status returns to ready.

I have done some digging and a lot of documentation is saying that you expressly have to configure the task status returning to ready (table sww_taskcust) but we have not done that.  (see sap note 1708610).  but yet this is what's happening..

I'm beginning to think that this is now the standard behaviour of synchronous methods.  When you right click on the task,  you can select an option to assign the task to yourself. 

I'm thinking that now I will find a function module where I can set the status of the task and set it to reserved myself when the user selects a processing option.

What are your thoughts on above?

All the best,

Liz.

troy_cronin2
Active Contributor
0 Kudos

Hi Liz

Many thanks for the feedback.

In relation to the task conconfigurationd the setup itself as per SAP Note: 1708610 this in true essence is workflow based configuration rather than UWL e.g. it would belong to the component area of BC-BMT-WFM-WLC.

Could you kindly let me know if the refresh mechanism is setup as per Note: 1710171 - SBWP Automatic Refresh?


In terms of the function module itself just to revert back to our earlier discussions and from a workflow standpoint the SAP_WAPI_EXECUTE_WORKITEM will invoke the workitem "processing" i.e. its start.

  • Depending on the exact nature of the workitem, the behaviour could be different.

http://help.sap.com/erp2005_ehp_04/helpdata/EN/8d/25f384454311d189430000e829fbbd/frameset.htm


From the workflow side I would recommend following this documentation note very closely SAP Note: 1098805 - Troubleshooting Tips & Tricks for Workflow Issues.

Thanks for your patience and understanding thus far and talk soon.

Kind Regards & All The Best

Troy

Former Member
0 Kudos

Hi Liz,

It could be related to workflow.

can you please explain UWL work item/scenario so that we can understand better.

Regards,

Deepa.

Former Member
0 Kudos

Hi Deepa,

Firstly many thanks for taking an interest in my problem.  Much appreciated!

We have a webforms inbox on a role on portal.  This is custom development and the only change is the upgrade.  Code and workflows remain as is.

Users use the webforms inbox to fill out an electronic form say for a new customer and then send for further processing.  Hitting the send for further processing button triggers a BO event which is linked to a workflow.  We have a number of different forms, all with different workflows, all custom.

Each workflow has various approval steps and will eventually go on to create the customer in the back end.  Approvers are determined by workflow rules.  Each approval step has UWL configuration which launches a custom BSP, which displays the various options for processing this task i.e. approve, reject, display, update.  See below for UWL config of one of our custom tasks:

Up to now, if a user clicked on the task, that task would then be removed from all other approvers inbox.  This now no longer happens for any of our forms, of which there are many!  We have never had to explicitly claim any task before.  Not sure what has changed but something has.

If you need more information, please let me know.

Thanks in advance,

Liz.

Former Member
0 Kudos

Hi Liz,

we see you are using some custom tasks and not the standard one as we are.

Please let us know if this is a user decision task or something else.

Could you also let us know the reason why you used custom task in your scenario.

Thank you

Regards,

Deepa.

Former Member
0 Kudos

Hi Deepa,

Many thanks for the response.  We have used a custom task so we could have a variable text body on the approval task.  It is a user decision task, which is a copy of the standard generic task one, but with a textbody table parameter.

Thanks again,

Liz.