TIMEOUTs with SBWP - SQL error 1013 occurred when accessing table "SWWUSERWI "

[Mike Pokraka]

Hi Mike,
Interesting scenario you have there! I have to agree with the SAP stance
on this one. SWWORGTASK only applies if you arrive at agents through the
org chart. Any other method uses only SWWUSERWI. By your suggestion, one
would have to delete agents from SWWUSERWI instead of setting NO_SEL -
even worse!

My suggestion is that a task should not go to that many people in the
first place. Use some criteria to cut it down to max 10 or 20 agents -
definitively less than 50, that's just asking for inbox performance
trouble without the SWWUSERWI problem. The shotgun approach should only be
used for exceptions where a narrower group cannot be defined.

Do some arbitrary assignments if you have to - e.g. if 300 people all do X
then add a criteria such as country, plant or whatever just to split the
load. Or, you can even do it randomly - e.g. use 10 groups SY-UZEIT+5 as
your criteria.

Besides perfomrance, less items in people's inbox is always good for
morale :) There's no point in loading it up with 1000's of items if they
are only able to get through 10/day - 100 items are plenty, and also a
good maximum of what folks should see. Also, make sure your flows complete
- dead flows that are still in status STARTED also contribute to
performance issues (and SWWUSERWI entries).

Just my ideas.
Cheers,
Mike

> Hi WUGgers :)
>
> This isn't a question as such, more an observation that some of you may
> have
> already had experience of at first hand.
>
> We have a situation with the basic design of Workflow, particularly Work
> items and agent determination and how the system takes a snapshot of
> possible agents for a Work Item using table SWWUSERWI when the WI is
> issued.
>
> Our problem is this: we are using Workflow in extremely high volumes
> (possibly higher than anywhere else in the world according to SAP) with an
> HR Org that is quite flat (numerous users assigned to a Position).
>
> Due to the high number of updates to SWWUSERWI going on in the system the
> Inbox has a nasty tendancy to crash with either TIMEOUTs or deadlocks
> trying
> to set the NO_SEL flag (i.e. reserve or cancel reservation) when a user
> resevres or replaces a WI.
>
> To give you an idea of the numbers involved we currently have millions of
> entries in SWWUSERWI, yes you read that right, millions.
>
> We have 16 App Servers, 10 terabytes of memory and are the largest IS-U
> implementation in the world, but even with this power we can't get past
> bottlenecks like this.
>
> Obviously SAP have expressed concerns about how many users we have
> assigned
> to Positions (they recommend no more than 50 usually whereas some of ours
> have 300+) which I have to say I agree with as it means for every WI we
> have
> a lot of SWWUSERWI entries to update each time.
>
> But we are petitioning SAP to consider a rethink on the way SWWUSERWI is
> used at high volumes because it really doesn't much sense to take a
> snapshot
> of possible agents like this when we don't really care about agent
> assignments and timeslices.
>
> As far as we are concerned SWWUSERWI should only ever have actual agents
> in
> it, not possible agents. In other words it suits us to rely on SWWORGTASK
> all the time for WIs that have not been selected.
>
> No idea if we'll get far with this suggstion but we're open to other
> ideas...
>
> MGT
>
>
> _______________________________________________
> SAP-WUG mailing list
> SAP-WUG at mit.edu
> http://mailman.mit.edu/mailman/listinfo/sap-wug
>