Limiting Forwarding on Decision Tasks

[Michael Pokraka]

Hi Mark, 
If I can be just as vague as Alon, there was also a thread on the WUG where
someone wanted to do something with authorizations on decision tasks... or
something like that. I think it may even have been to do with limiting
forwarding as well, and there may have been a userexit involved. 

<shrug> Not sure if that's any help, but might be worth a stab into the murky
depths of the archives.
Cheers
Mike

--- Alon Raskin <araskin at 3i-consulting.com> wrote:

> Hi Mark,
> 
> I don't remember too much. I just think I remember (could I be any more
> vague?) someone mentioned that there was a BADI that was not available in
> 4.6.
> 
> Mark G, did you and I discuss this at all when I was in Chertsey? Perhaps
> you remember the name of the BADI?
> 
> Alon Raskin
> e: araskin at 3i-consulting.com
> w: http://www.3i-consulting.com
> 
> -----Original Message-----
> From: sap-wug-bounces at mit.edu [mailto:sap-wug-bounces at mit.edu] On Behalf Of
> Mark Pyc
> Sent: Friday, February 11, 2005 7:22 AM
> To: sap-wug at mit.edu
> Subject: RE: Limiting Forwarding on Decision Tasks
> 
> Mark, Mike, I had contemplated something along the lines of what you're both
> basically describing. When wrapped in a subflow it doesn't cause anymore
> impact on the main flow than the proceedure I was suggesting in the post and
> it does get rid of the maintenance of tasks. Assuming the loop is necessary
> I'd be inclined to favour the extra decision choice rather than subtyped
> button simply because there really isn't a functional difference and one is
> completely standard.
> 
> However has anyone taken the subtyped dialog a step further and incorporated
> WAPI logic (or equiv) such that the new button really is a forward. That is,
> rather than being in a loop (which generates multiple WIs for each
> iteration) the current decision would be forwarded, but forwarded in a
> custom controlled manner?
> 
> Alon, I've done some digging of the BADIs searching on WF, Forwarding,
> Agents but can't see anything likely. Does anyone know the details of the
> BADI or an alternative??
> 
> Thanks for input. The current thinking on site is to go with the multi WS/TS
> solution I originally described simlpy because it uses entirely standard
> techniques and will ultimately allow reporting flexibility. The maintenance
> effort is understood and accepted.
> 
> I'm still interested in any suggestions for future reference.
> 
> Thanks again,
> Mark
> 
> From: "Griffiths, Mark" <mark.griffiths at sap.com>
> Reply-To: "SAP Workflow Users' Group" <sap-wug at MIT.EDU>
> To: "SAP Workflow Users' Group" <sap-wug at MIT.EDU>
> Subject: RE: Limiting Forwarding on Decision Tasks
> Date: Fri, 11 Feb 2005 12:21:15 +0100
> 
> Mark,
> 
> Did you think about using a copy of the user decision task which has the
> option 'no forwarding', but then on your decision screen you include a
> 'forward' button. This doesn't really forward but instead gives a pop up box
> to select an alternative approver from a list you generate.  You could
> include all this in a loop and do your selected agent assignment with an
> expression.  I used this approach at a few customers over the years.
> 
> What do you reckon?
> 
> Cheers,
> 
> Mark
> 
> -----Original Message-----
> From: sap-wug-bounces at MIT.EDU [mailto:sap-wug-bounces at MIT.EDU] On Behalf Of
> Mark Pyc
> Sent: 11 February 2005 10:50
> To: SAP-WUG at MIT.EDU
> Subject: Limiting Forwarding on Decision Tasks T  on
> 
> G'day Wuggers,
> 
> It's amazing how seemingly straight forward requirements can tie you up in
> knots.
> 
> What I require is the ability to limit the forwarding of a Decision workitem
> to only those people within the same organisation unit. In this case the
> 
> Responsible Agents will be based on a combination of Plant and Company Code,
> and forwarding should be limited to those within the same Company.
> 
> The standard options for controlling forwarding are:
> * General Task (therefore general forwarding)
> * General Forwarding (the initially selected agent(s) will be limited to
> 
> Possible, but then general forwarding)
> * General Forwarding not allowed (initial agents and forwarding choices
> limited to Possible)
> * No Forwarding (the ultimate in control)
> 
> With these as the only techniques the solution then becomes to build a Task
> per Company Code with appropriate Possible Agents. OK so far. With over 800
> Company Codes however, alarm bells start ringing - the smallest of text
> changes will require extensive maintenance (unless a standard text can be
> included - yet to be tested, esp for multilingual issues).
> 
> The next issue is that you want to have a maintenance table identifying
> which TS task exists for which company code and use the dynamic Task binding
> within the Workflow step. This is a great idea, but you can't dynamically
> bind Decision tasks!?! This is frustrating because it's the uncontrolled
> 
> nature of decision tasks (i.e. no data related security checks) that makes
> this limited forwarding so desireable.
> 
> OK, so we can leep that hurdle by dynamically including a sub-WF which
> basically just wraps a static call to a standard decision task. So now we
> have a TS and a WS per company code. Workable, but it doesn't seem very
> elegant.
> 
> Now for the usual bit - Shirely some of you have faced this before...?
> 
> The programmer in me wants an alternative to all this maintenance of TS and
> WS objects. Is there anything like a user exit which can control the
> possibilities of forwarding?
> 
> In terms of how would I know the list of Possibles without refering to Task
> level possible agents - the solution in this case is a custom Authorization
> Object included in security roles (Thanks for the tips Joc, it's a nice
> technique). I can programmatically determine who has access to a given
> Company Code or Company Code/Plant combo for each logical WF Agent type (PO
> approver level 1/2, Invoice Reviewer ...etc).
> 
> Any suggestions or insights greatly appreciated. Hopefully I've just missed
> a completely obvious technique.
> 
> Have fun,
> Mark
> 
> PS - SAP Enterprise 4.7 / 620
> 
> 
> _______________________________________________
> 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
> 
> _______________________________________________
> SAP-WUG mailing list
> SAP-WUG at mit.edu
> http://mailman.mit.edu/mailman/listinfo/sap-wug
> 
>