Evaluation path for Inbox (SBWP)...

Klika, Michael Michael.Klika at ids-scheer.com
Mon May 9 07:42:25 EDT 2011


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,
Ed

________________________________

From: 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. 

Regards

Jocelyn

 

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,
Ed

________________________________

Subject: 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.edu

Hi 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

	
Subject

Evaluation 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 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/pipermail/sap-wug/attachments/20110509/72c8c074/attachment.htm


More information about the SAP-WUG mailing list