AW: How can I disable the SAP office forwarding under SAP 4.6 c
Svanikier, Helena
helena.svanikier at sap.com
Tue Jun 4 16:34:09 EDT 2002
I like your approach but I must agree with Stefan and the others, that there
are situations where it can not be applied.
Let's say you want the person responsible for a certain budget (be it from
as project, a cost center or an internal order) to be the first person to
sign an invoice. As this could be practically anybody within the company you
are forced to use the general task approach and then find the responsible
agent by using a role.
As for prohibiting the workitem to be forwarded, we applied a suggestion
made a while ago within this forum. We created a field exit for the data
element 'SEARK'. Then activated the field exit for the programm SAPLRHW0 and
the dynpros 0500 and 0600. (These are the screens called, when forwarding
the workitem). Within the field exit we programmed an authority check for
the authority object 'S_WF_WI ' and the activity '25'.
This is what the coding looks like:
add these two include in the top-include of the function group:
INCLUDE RSWUINCL. "Workflow constants
INCLUDE <CNTN01>. " Workflow macros
This is the coding of the function module:
FUNCTION FIELD_EXIT_SEARK.
*"----------------------------------------------------------------------
*"*"Local interface:
*" IMPORTING
*" VALUE(INPUT)
*" EXPORTING
*" VALUE(OUTPUT)
*"----------------------------------------------------------------------
* Check whether user has the authorization to forward a workitem
* Write Entry in field back to field if everything is ok
OUTPUT = INPUT.
** Handle user actions
CASE SY-UCOMM.
WHEN 'EXIT'. "User has pressed cancel-Button
EXIT.
WHEN OTHERS.
CALL FUNCTION 'SWW_WI_AUTHORITY_CHECK'
EXPORTING
WI_TYPE = 'W'
TASK_CLASS = 'DUMMY' " Don't check
WFACTVT = ACTVT_CHANGE_USER " '25'
EXCEPTIONS
NO_AUTHORIZATION = 1
NO_PROFILE = 2
FIELD_COLLISION = 3
DESTROYED_AUTHORIZATION = 4
UNKNOWN_ERROR = 5
OTHERS = 6.
CASE SY-SUBRC.
WHEN 0.
WHEN 1 OR 2 OR 4 .
CLEAR OUTPUT.
MESSAGE E849(WL) WITH SPACE SY-UNAME.
* Work item &: User & does not have authorization for this activity
WHEN OTHERS.
CLEAR OUTPUT.
MESSAGE E012(D4) WITH SY-SUBRC.
* Error in authority check, error code &. Press F1 (HELP) for more inf
ENDCASE.
ENDCASE.
ENDFUNCTION.
Only the workflow administrators received the necessary authorisations. It
has worked well on the release 4.0. The client is now in the process of
upgrading to 4.6c and the tests show that is also continued to work under
the new release.
Best regards
Helena Svanikier
Workflow consultant sAP Switzerland
-----Original Message-----
From: Zmudzin,Tomasz,VEVEY,GL-DS/DM
To: SAP-WUG at MITVMA.MIT.EDU
Sent: 04.06.02 17:32
Subject: Re: AW: How can I disable the SAP office forwarding under SAP 4.6 c
Folks,
you already know I'm stubborn, so let me defend my proposal:
- Agreed, sometimes you need to make a compromise and make a task like
such
general.
- Still, if we talk about good design practices, going forward with jobs
to
specify Group A will do fine. That's what jobs are created for -- they
determine your responsibilities in the organization. I know it's often
hard
to push this through, especially in existing installations. But then I'd
argue that if you already have 800 jobs, a new one for a "Approver
of..."
will not hurt, but may actually bring you closer to a clean,
well-maintainable design. It's not the number that counts, but rather
the
structure of the content.
- AND HERE'S THE REAL CATCH:
I've seen some EBP workflows in which Group A has been specified by...
user
role (NOT what we maintain in PFAC, but the one used by security folks
to
define user authorizations, menus etc. -- object type 'AG'). So if you
have
an elementary security role that controls the access to your
functionality,
and assign this role to your task, all the folks who have authorizations
to
perform a task are automatically assigned to Group A. I admit I haven't
tested this kind of setup in plain old R/3, but I expect this should
work
OK. And I believe this is perfect from the maintenance point of view.
In other words I agree that we need to respect the reality and that we
cannot argue with the way a specific system is set up. Still, if we have
some options, we should at least investigate the nice ones and try to
use
the cleanest approach possible.
With my warm greetings and kind regards,
Tomasz.
-----Original Message-----
From: Thomas Maue [mailto:TMaue at sial.com]
Sent: Tuesday, June 04, 2002 4:47 PM
To: SAP-WUG at MITVMA.MIT.EDU
Subject: Re: AW: How can I disable the SAP office forwarding under SAP
4.6 c
Tomasz,
I agree with Stephan - in a lot of cases you cannot
determine all the possible agents (your group A). What if
you are using a role to derive selected agents (your group
B). For example, a simple role using document data (for a
user ID) and then finding the manager (Org Structure) of
that user. If you had 1000 possible document user ID's you
would have to resolve each one manually to find the possible
agents that need to be manually assigned to the task.
This would be a maintenance nightmare. You would have to
make 1000 assignments and continually update. Positions are
usually one to one with users so this does not help. Jobs
can save some effort but in the above example the job is not
relevant so you might only have 800 assignments.
A general task assignment is really the only way to go in a
lot of situations.
Regards,
Thomas Maue
"Becker Stephan (extern)"
<Stephan.Becker.ext at mchw. To:
SAP-WUG at MITVMA.MIT.EDU
siemens.de> cc:
Sent by: SAP Workflow Subject: AW: How
can
I disable the SAP office forwarding
<Owner-SAP-WUG at MITVMA.MIT under SAP 4.6 c
.EDU>
06/04/02 09:50 AM
Please respond to "SAP
Workflow Users' Group"
Gotcha, man, you're on the right track, the thing is just
that EVERYONE is
potentially in group A, so there's no point to make any
assignments other
than a general task assignment there..
-----Urspr|ngliche Nachricht-----
Von: Zmudzin,Tomasz,VEVEY,GL-DS/DM
[mailto:Tomasz.Zmudzin at nestle.com]
Gesendet: Dienstag, 4. Juni 2002 12:45
An: SAP-WUG at MITVMA.MIT.EDU
Betreff: FW: How can I disable the SAP office forwarding
under SAP 4.6 c
... and being so stubborn I'd just add that indeed you need
to specifically
assign all the possible Group B users as belonging to Group
A which may seem
impossible at the first look in a large installation -- but
again naming
them via jobs & positions will save the day.
Kind regards -- and I promise to stop bombing you for a
while,
Tomasz
-----Original Message-----
From: Zmudzin,Tomasz,VEVEY,GL-DS/DM
Sent: Tuesday, June 04, 2002 12:36 PM
To: 'SAP Workflow Users' Group'
Subject: RE: How can I disable the SAP office forwarding
under SAP 4.6 c
Yes -- but I think we're still talking about two different
things... From
the functional point of view the agents for a task are
determined by
checking three groups of agents:
Group A: All the allowed agents of the task. If a task is
"general", this
are all system users. If it's not, these are all the agents
assigned in to
the task in the assignment (PFTC--> Additional Data -->
Agent assignment).
This is static, cannot be changed at run-time. And this is
specified at task
level -- no matter in which workflow you use the task, it
will have the same
allowed agents.
Group B: Those specified in the "Agents" section of the task
within
workflow. This is dynamic (e.g. via role or container
element) and can be
determined / altered at runtime.
Group C: Those specified in the "Excluded" section of the
task within
workflow (dynamic)
Now finally the agents for a task are determined as those
belonging to Group
A _AND_ Group B, but _NOT_ belonging to Group C. Thus if we
talk about
authorizations, we can model them by using the agent
assignments (Group A).
This is static, shared across workflows -- just as
authorizations are. Users
that don't belong to group A will not be able to execute an
item.
In your e-mail you're probably referring to Group B -- this
can be
determined dynamically at run-time based on document content
etc., on a
per-process instance basis. So this is where you try to
determine your
agents based on config tables, responsibilities, document
content etc.
Because in the end only those belonging both to A and B will
be picked, A
still acts like authorizations. And finally Group C is
subtracted, the same
way.
So in our particular problem we can still specify our agents
dynamically for
Group B (using frequently-changing tables, responsibilities
etc.). But --
instead of making the task general (Group A = all), we
assign it to the
allowed users only. Then you set the task attributes to
"General forwarding
not allowed", and we still have the very dynamic agent
determination, but
the task can be only forwarded to those you trust.
Or did I get it wrong?
BR - Tomasz
-----Original Message-----
From: Becker Stephan (extern)
[mailto:Stephan.Becker.ext at mchw.siemens.de]
Sent: Tuesday, June 04, 2002 12:06 PM
To: SAP-WUG at MITVMA.MIT.EDU
Subject: AW: How can I disable the SAP office forwarding
under SAP 4.6 c
Thomasz, my point was that in many approval situations, you
CANNOT determine
possible agents at definition time (other than saying it's a
general task)
as the possible agents are determined at runtime, from
document data, using
tables and/or other settings that change frequently in the
production
system.
-----Urspr|ngliche Nachricht-----
Von: Zmudzin,Tomasz,VEVEY,GL-DS/DM
[mailto:Tomasz.Zmudzin at nestle.com]
Gesendet: Dienstag, 4. Juni 2002 11:52
An: SAP-WUG at MITVMA.MIT.EDU
Betreff: Re: How can I disable the SAP office forwarding
under SAP 4.6 c
But in this case you can define the allowed agents for this
task, and
restrict forwarding to these agents only. Not only will this
solve the
problem of forwarding restriction, but also will guard you
against possible
mistakes in the dynamic determination of agents...
I somehow believe that the allowed agent assignment is often
underutilized... It's just a great mechanism to implement
authorization-like
restrictions for workflow tasks.
Kind regards,
Tomasz
-----Original Message-----
From: Becker Stephan (extern)
[mailto:Stephan.Becker.ext at mchw.siemens.de]
Sent: Tuesday, June 04, 2002 11:11 AM
To: SAP-WUG at MITVMA.MIT.EDU
Subject: AW: How can I disable the SAP office forwarding
under SAP 4.6 c
For example: say there is no way to restrict agent
assignment at definition
time, because agents are determined dynamically at runtime
(e.g. for signing
of invoices), for example from movement data that changes
all the time, but
you still want to prohibit forwarding because signatory
authorisation is
linked to the person only..
-----Urspr|ngliche Nachricht-----
Von: Zmudzin,Tomasz,VEVEY,GL-DS/DM
[mailto:Tomasz.Zmudzin at nestle.com]
Gesendet: Dienstag, 4. Juni 2002 11:05
An: SAP-WUG at MITVMA.MIT.EDU
Betreff: Re: How can I disable the SAP office forwarding
under SAP 4.6 c
Out of sheer curiosity -- if a task is general (i.e. can be
performed by
anyone, even if it normally lands in specific inboxes) --
why would we want
to prohibit forwarding?
To my simple mind it looks as if it would make sense to
prohibit it only if
you have certain users allowed to perform it. Then you could
still
distinguish between allowing forwarding to allowed agents
only or to the
general user community. Or am I missing something
not-so-obvious?
Kind regards,
Tomasz
-----Original Message-----
From: Becker Stephan (extern)
[mailto:Stephan.Becker.ext at mchw.siemens.de]
Sent: Tuesday, June 04, 2002 10:37 AM
To: SAP-WUG at MITVMA.MIT.EDU
Subject: AW: How can I disable the SAP office forwarding
under SAP 4.6 c
Good question.. for some reason probably only known to SAP,
you cannot have
a general task and disallow forwarding at the same time.. if
that is no
problem for you, set "general forwarding not allowed" in the
attributes of
the agent maintenance of the TS. If it is a problem, I have
in the past
chosen the (admittedly somewhat cloodgy but effective)
approach to check in
the method if the agent before and after method execution
are the same, and
to trigger an exception that is then in the builder
evaluated in a loop that
just creates the item again for the user (with a message
beforehand
informing the user about the rule).
Hth,
Stephan
-----Urspr|ngliche Nachricht-----
Von: Vincze Arpad [mailto:Arpad.Vincze at itelligence.hu]
Gesendet: Dienstag, 4. Juni 2002 10:26
An: SAP-WUG at MITVMA.MIT.EDU
Betreff: How can I disable the SAP office forwarding under
SAP 4.6 c
Hello Workflowers,
I would like to disable the SAP office forwarding for
workitems!
How can I do it?
Is there any hint?
Regards:
Arpad
Vincze Arpad
itelligence Hungary Kft.
H-1138 Budapest, Vaci zt 141
Tel.: (+36 1) 452 3822
Fax: (+36 1) 452 3839
Mobil: (+36 20) 9 533 578
arpad.vincze at itelligence.hu
More information about the SAP-WUG
mailing list