Reduce UWL items in Portal

[Former Member]

SCN,

Has anyone been able to restrict the number of items UWL brings into the Portal?

Possible restrictions identified at provider and connector (see postscript for more info):  

Provider (SRM & ECC):  filters can be configured to reduce the number of items in SWWIHEAD. 

Connector:  core modifications made to methods in QueryProperties. 

Any luck with the above or anything else?

Thanks,

Sawyer

Issue:

UWL and JCo are causing OOM errors in Portal.  Heap dump analyses has identified UWL and JCo as primary leak suspects every time.

System Info:

Portal:  SAP NW 7.3EhP1 SP11 PL9; UWLJWF 1000.7.31.11.2.20140329130900.

SRM & ECC: SAPKB70108

Connector/Query restrictions:

QueryProperties

Provider restrictions:

1951140 - Filter old ABAP work items not to be fetched by Universal Worklist

1941307 - WebFlow Notifications, universal worklist: Consideration of delta pull filters for full in...

1825104 - UWL: Provision of filters for API inbox for the UWL

1908061 - WF Notifications, UWL delta pull: filters affecting runtime

[Former Member]

Hi Lawrence,

Thanks for your reply.  I suspect the root cause of our scenario is excessive UWL items (over 100 users have over 1000 workflows being pulled in over the webflowconnector), which leads to aggressive consumption of heap, and eventually OOM errors if many snapshot pulls are happening in parallel.  And/or the duration of the snapshot pull exceeds the cache validity period, in which case a second snapshot is triggered before the first can update the Portal UWL cache, which eventually exhausts threads and leads to OOM.

Can you expand on your comment "blocking start pages and increase the load"?

I did open an incident with SAP, although it hasn't been very productive yet.  Please see below for heap analysis details.

Thanks,
Sawyer

Leak suspect 1 details:

Leak suspect 2 details:

[Former Member]

Mmhh, this looks bad. I would assume EP tryes to push all items in this 2d array, according to the stack and fails. Looks like char[][] blows the stack blows your VM factual away. 70000 items are way to much, on the other side SAP doesnt provide any official limitations on the number of items as far I know. 700 MB is indeed not much, how much RAM did you gave the portal? Did you check 723909? I know you are on 7.3, but it looks similar... I would try following: increase your RAM to 12-16 GB, reconfigure the VM appropriate and reproduce. I know its a dumb idea to push the stack apart in case of OOM problems, but on this way you will find out if its a leak (it will crash again) or regular behaviour (EP could probably survive the error reproducing in that case probably)

cheers

[pokrakam]

Hi Hans,

It's not going to solve your immediate problem, but if your UWL inboxes are that big I would suggest it points to a fundamental business issue. UWL work items represent an action that should be done by a user.

Therefore ask the questions: How many items do people have in their inboxes, and can they realistically work on all of them? The answer to the second question is probably no, therefore look to the source of the large number of items. Your users will be much happier for it.

Regards,

Mike

[Former Member]

Mike Pokraka wrote:

Hi Hans,

It's not going to solve your immediate problem, but if your UWL inboxes are that big I would suggest it points to a fundamental business issue. UWL work items represent an action that should be done by a user.
Therefore ask the questions: How many items do people have in their inboxes, and can they realistically work on all of them? The answer to the second question is probably no, therefore look to the source of the large number of items. Your users will be much happier for it.

Regards,
Mike

Sir I have to disagree I was enlightened very clear and more than more time by several people this is a possible scenario in a real business world. There are not many of such employees in a company, who are affected by such problems in generally, but its not uncommon. To arrange their work a bit easier, people asked us to provide staff like mass approval etc, but this dont change anything on the number of items. Unfortunately such people are in very high management positions and have all possibilities to insist on solution of such problems However, as I mentioned this shouldnt end in OOM errors

cheers

[Former Member]

Hi Mike,

You are absolutely right.  The size of the UWL inboxes do present a fundamental business issue.  On average, each user has 421 items with one user having over 70,000...  We've suggested the business take a look here.  However preventing OOM errors in the Portal is my concern, and that needs to happen regardless of backend item counts.  Unfortunately, SAP has not prepared for this very likely scenario in their code, so I need advice from SCN on preventative measures.

I appreciate your reply.

Thank you,

Sawyer

[Former Member]

I guess you can do by writing an own UWL component and filtering using the Java API for UWL, it would be clever to do asynchronous calls probably. I faced already similar problems for managers in big companies, who are getting countless approval requests etc, its your scenario? However, this shouldnt cause OOM, rather blocking start pages and increase the load. Your case sounds like a memory leak, could you post detailed results of the heap analysis Sir? Did you open an OSS?

cheers