Evaluation path for Inbox (SBWP)...

Mon May 9 08:41:33 EDT 2011

Glad it worked out.

Subject: RE: Evaluation path for Inbox (SBWP)...
Date: Mon, 9 May 2011 13:42:25 +0200
From: Michael.Klika at ids-scheer.com
To: sap-wug at mit.edu

Thanks to Ed an Jocelyn,  Yes, that solved my Problem and I’m aware of the performance implications L I will test this with some 10k WI and keep you informed, if you like. And I do agree that a proper role is the better solution, but that would mean changing existing workflows because some get their agents upfront from the calling application and we wanted to change agent determination based on that… Thank you very much again!Michael From: sap-wug-bounces at mit.edu [mailto:sap-wug-bounces at mit.edu] On Behalf Of Edward Diehl
Sent: Friday, April 08, 2011 2:43 PM
To: sap-wug at mit.edu
Subject: RE: Evaluation path for Inbox (SBWP)... Jocelyn makes an excellent point and I think there is a better way to do what you want to do.

Instead of using the Org Unit as the runtime agent rule, create your own rule (PFAC) based on your own eval path (OOAW).  The rule will be of type F - Agent determination: function to be executed.  The function  you will specify is SWX_GET_STRUCTURE.  When you enter this FM,  a field will appear for your eval path.  One tricky thing about this is how you specify the container element to be passed to the rule:   You MUST call your element OBJECT, no matter how you data type it.  Mine is WFSYST-AGENT.  You can give in any description you want, but the Expression must say OBJECT.

When you test the rule in PFAC the input value will be one of your org units with a preceding OTYPE, such as O 40001221.  You will then see all of the object types you have defined in your eval path.

Here is one of the custom paths I created.

10    O    B    002    Is line supervisor of    *    O  SKIP
20    O    B    003    Incorporates    *    S            SKIP
30    S    A    008    Holder    *    P                     SKIP
40    P    B    208    Is identical to    *    US

NOTE:   SKIP means that I only want to see the US (user id) elements.

This one would return a list of user ids based on all of the of the persons in all of the positions in all of the org units under 40001221.

This is more work, but it is an excellent technique to learn - quite handy when your workflowing in a system with a good org structure.

Good Luck,
EdFrom: jocelyn.dart at sap.com
To: sap-wug at mit.edu
Date: Fri, 8 Apr 2011 04:02:00 +0200
Subject: RE: Evaluation path for Inbox (SBWP)...HI Michael, Ed’s correct  - but just be careful to watch for performance implications and unintended side effects – as changing the evaluation path SAP_TAGT will affect EVERY workflow/work item. Might be worth asking the group if anyone else has tried this before… and what their experiences were. RegardsJocelyn From: sap-wug-bounces at mit.edu [mailto:sap-wug-bounces at mit.edu] On Behalf Of Edward Diehl
Sent: Friday, 8 April 2011 12:31 AM
To: sap-wug at mit.edu
Subject: RE: Evaluation path for Inbox (SBWP)... Hi Michael,
We've just been through something like this with regard to including substitutes (A210) in the eval path.  The eval path you want is SAP_TAGT.  In order to include lower level org units and their position you need to insert a line just before line 100:    90 O B 002 * O.  This will get you all of the lower org units and their positions.

Best wishes,
EdSubject: RE: Evaluation path for Inbox (SBWP)...
Date: Thu, 7 Apr 2011 15:58:56 +0200
From: Michael.Klika at ids-scheer.com
To: sap-wug at mit.eduHi Nat Thank you very much for your reply.  I think (no, I’m sure) my question wasn’t understandable: The Inbox as well as several other tools (e.g. “display agents in workflow log”, standard transactions) derive users for a given workitem. My scenario is as follows: -          I’ve got a hierarchy of Orgunits-          User is connected via User – Personnel Number – Position – Orgunit-          My rule for a certain task produces a top orgunit-          Only those users belonging to the top-orgunit will receive that workitem, NOT the users belonging to orgunits underneath  Is it possible to change this behavior? Is there a standard evaluation path that handles that an could be modified? Thanks again and best regards, Michael   From: sap-wug-bounces at mit.edu [mailto:sap-wug-bounces at mit.edu] On Behalf Of Nat 4 Govender
Sent: Thursday, April 07, 2011 3:13 PM
To: SAP Workflow Users' Group
Cc: sap-wug at mit.edu; sap-wug-bounces at mit.edu
Subject: Re: Evaluation path for Inbox (SBWP)... 
There are two transaction that I know of that can use 
1        SWI5                -        which will show you all work items for that specific User / Position. 
2        SWI2_ADM1        -        Work item without agents 

Regards
Nat Govender
Toyota South Africa
IT - SAP Workflow Specialist
Internal Ext.   :  32645
Direct Line    :  +27 031 910 2645
Fax               :  086 607 0414
E-mail           :  ngovender4 at toyota.co.za

If you tell the truth, you don't have to remember anything. "Klika, Michael" <Michael.Klika at ids-scheer.com> 
Sent by: sap-wug-bounces at mit.edu 2011/04/07 02:56 PM Please respond to
"SAP Workflow Users' Group" <sap-wug at mit.edu>To<sap-wug at mit.edu> cc
SubjectEvaluation path for Inbox (SBWP)... 

Hello workflow experts 

I’m wondering what evaluation path exactly is used to determine for which workitems I am an agent if I’m part of an orgstructure hierarchy with orgunits, positions, personnel numbers and users. The rule I use determines orgunits only! 

Or is there a different mechanism used? If I check table SWWORGTASK (storing orgobjects for a particular workitem) I can see orgunits and no evaluated users, so something must happen in between… 

Is there any way to change the evaluation (even if this obviously doesn’t make too much sense…) 

Thanks in advance, 
Michael 
 _______________________________________________
SAP-WUG mailing list
SAP-WUG at mit.edu
http://mailman.mit.edu/mailman/listinfo/sap-wug

***** This e-mail is a privileged and private communication and may be read, copied and used only by the intended recipient(s). If you are not an intended recipient, please inform the sender by return e-mail with the subject heading "Received in error". Please then delete the e-mail; destroy any copies of it and do not disclose its contents to any person or entity. If you are not the intended recipient, note that any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is strictly prohibited and may be unlawful. Neither the sender nor Toyota South Africa Motors (Pty) Ltd accepts any liability whatsoever as a result of the further dissemination of this e-mail. Toyota South Africa Motors (Pty) Ltd does not guarantee that e-mail communications are secure or error-free, as information could be intercepted, corrupted, amended, lost, destroyed, arrive late or incomplete, or contain viruses. *****
_______________________________________________ SAP-WUG mailing list SAP-WUG at mit.edu http://mailman.mit.edu/mailman/listinfo/sap-wug 
_______________________________________________ SAP-WUG mailing list SAP-WUG at mit.edu http://mailman.mit.edu/mailman/listinfo/sap-wug 
_______________________________________________
SAP-WUG mailing list
SAP-WUG at mit.edu
http://mailman.mit.edu/mailman/listinfo/sap-wug 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/pipermail/sap-wug/attachments/20110509/942e7aeb/attachment.htm