Forwarding work items and possible agents
Dart, Jocelyn
jocelyn.dart at sap.com
Thu Jan 20 19:39:43 EST 2005
P.S. The below is not a flame to Phil - just a reminder to all of the
new options.
Phil, I've used the new event and it's great stuff! And yes it
definitely achieves the sort of change you made in 4.6. And yes I
absolutely agree that its a better approach than just forwarding to a
new agent.
E.g. put your agents in a multiline container element, on deadline
reached, append your new agents to the container element then fire the
event. Magic stuff!
Also helps to send a mail at the same time telling the original agents
that they have now been "dobbed in" to the next level above.
Jocelyn.
________________________________
From: Dart, Jocelyn
Sent: Friday,21 January 2005 11:27 AM
To: 'SAP Workflow Users' Group'
Subject: RE: Forwarding work items and possible agents
By the way everyone...
As of 6.20/6.40 you should no longer use SWW_WI_AGENTS_CHANGE,
but use the special workflow header level event(Outcome) "Reevaluate
rules on active work items or the "Redo rules" option in the workflow
administrator transactions or the equivalent SAP_WAPI function modules
instead.
Much better and much much easier to use - especially the header
level event.
Regards,
Jocelyn
________________________________
From: sap-wug-bounces at mit.edu
[mailto:sap-wug-bounces at mit.edu] On Behalf Of Soady, Phil
Sent: Wednesday,19 January 2005 9:48 PM
To: SAP Workflow Users' Group
Subject: RE: Forwarding work items and possible agents
Hi WUGers
I watch this one with interest.
Perhaps I made an assumption in the past how this works.
But I have used SWW_WI_AGENTS_CHANGE
to add people to a workflow so they COULD execute. In
fact because an ALL actual agents can execute.
I saw this as a desirable feature. Delegation in
real-time.
The weren't NOT originally on a possible agent. But
someone passes to them.
Just like with paperwork.
My understanding was the fact that someone becomes a
CURRENT agent.
Either by adding them programmatically or via
forwarding, there are now 2 agent actuals.
Not yet reserved, but 2 agents with the task in the
inbox ready to go.
Perhaps under 6.x with the re-evaluate rule, this might
catch this.
I haven't tried that.
A test of possible agent still correctly shows one not
as a possible agent.
All New WFlows don't go to one of the users. AS
expected.
But once a workflow was delivered to a user by someone
who did have originally have access
they have effectively delegated. Hence the warning. The
user is a possible agent. Are you sure
you want to pass this.
Hence also the general agents forwarding. Switch.
I remember looking as some code way back when....
But maybe I made a mistake. But that this the way I
thought it worked.
Heres the code we used (4.6) back in 2001.
Please no flames because I didn't use the SAP_WAPIs ;-)
If someone with a system with suitable test users etc
can test the Re-evaluate rule aspect I
would be interested in the result.
1 *
2 function z_ess_change_absence_approver .
3
*"----------------------------------------------------------------------
4 *"*"Local interface:
5 *" IMPORTING
6 *" VALUE(DOCSY) LIKE ZESSLEAVEWI_ID-DOCSY
7 *" VALUE(DOCNR) LIKE ZESSLEAVEWI_ID-DOCNR
8 *" TABLES
9 *" AGENTS STRUCTURE SWHACTOR OPTIONAL
10 *" DEPENDENT_WIS STRUCTURE SWWWIHEAD
OPTIONAL
11 *" EXCEPTIONS
12 *" BAD_CONTROL_CONFIG
13 *" BAD_TASK_CONFIG
14 *" BAD_DOCSY_DOCNR
15 *" UPDATE_FAILED
16
*"----------------------------------------------------------------------
17
18
19 data: wi_id like zessleavewi_id-wi_id,
20 l_task_control like
zesscontrol-ar_app_task_id.
21
22
23 * Read ZESS control information:
24 select single ar_app_task_id into
l_task_control from zesscontrol
25 where sysid = sy-sysid.
26
27 if sy-subrc <> 0.
28 raise bad_control_config.
29 endif.
30
31 if l_task_control is initial.
32 raise bad_task_config.
33 endif.
34
35
36 * Read Doc - WF link table:
37 select single wi_id into wi_id from
zessleavewi_id
38 where docsy = docsy
39 and docnr = docnr.
40
41 if sy-subrc <> 0.
42 raise bad_docsy_docnr.
43 endif.
44
45
46 refresh dependent_wis.
47 clear dependent_wis.
48
49 call function 'SWI_GET_DEPENDENT_WORKITEMS'
50 exporting
51 wi_id = wi_id
52 tables
53 dependent_wis = dependent_wis.
54
55 loop at dependent_wis where wi_rh_task =
l_task_control.
56
57 call function 'SWW_WI_AGENTS_CHANGE'
58 exporting
59 * NOTIFICATION_AGENTS_APPEND = ' '
60 * DEADLINE_AGENTS_APPEND = ' '
61 * DESIRED_END_AGENTS_APPEND = ' '
62 * LATEST_START_AGENTS_APPEND = ' '
63 * EXCLUDED_AGENTS_APPEND = ' '
64 agents_append = ' '
65 wi_id =
dependent_wis-wi_id
66 * DO_COMMIT = 'X'
67 * AUTHORIZATION_CHECKED = ' '
68 tables
69 agents = agents
70 * DEADLINE_AGENTS =
71 * DESIRED_END_AGENTS =
72 * LATEST_START_AGENTS =
73 * EXCLUDED_AGENTS =
74 * NOTIFICATION_AGENTS =
75 exceptions
76 no_authorization = 1
77 update_failed = 2
78 invalid_type = 3
79 others = 4
80 .
81 if sy-subrc <> 0.
82 raise update_failed.
83 endif.
84
85 exit.
86 endloop.
87
88
89 endfunction.
Phil Soady
Senior Consultant
Business Technologies
SAP Australia
M +61 (0) 412 213 079
E phil.soady at sap.com <mailto:phil.soady at sap.com>
________________________________
From: sap-wug-bounces at mit.edu
[mailto:sap-wug-bounces at mit.edu] On Behalf Of Cristiana D'Agosto
Sent: Wednesday,19 January 2005 3:17 PM
To: SAP Workflow Users' Group
Subject: RE: Forwarding work items and possible
agents
Hi Jocelyn,
but my issue is that the user is NOT a possible
agent and can execute the work item! I am puzzled because I know that
this should not have happened!
Any other ideas on why the user is being able to
execute the work item that has been forwarded to him even thought he
doesn't have the required authorization role assigned to his user id??
Its driving me crazy! This user id has not been
changed recently, so it is not buffer-related.
Thanks
Cheers
Cristiana
"Dart, Jocelyn" <jocelyn.dart at sap.com>
Sent by: sap-wug-bounces at mit.edu
19/01/2005 03:01 PM
Please respond to
"SAP Workflow Users' Group"
To
"SAP Workflow Users' Group" <sap-wug at mit.edu>
cc
Subject
RE: Forwarding work items and possible agents
Yes that's right Cristiana - sending it to
someone who is not a possible agent means they can't execute it, but
they can view it and forward it to a 3rd party.
Not something you would usually want - hence the
warning - but occasionally handy if:
* You want to forward to a help desk or shared
services desk who is responsible for finding an alternative agent
* The person you are forwarding to is the
correct agent but doesn't have the security to execute it yet, it can
then sit in their inbox until their security is sorted out.
Mark the task as "Forwarding not allowed" (4.6D
or above) to prevent forwarding to anyone. Mark the task as "General
Forwarding not allowed" to prevent forwarding to agents who are not
possible agents.
Regards,
Jocelyn
________________________________
From: sap-wug-bounces at mit.edu
[mailto:sap-wug-bounces at mit.edu] On Behalf Of Cristiana D'Agosto
Sent: Wednesday,19 January 2005 12:31 PM
To: SAP Workflow Users' Group
Subject: Re: Forwarding work items and possible
agents
Hi Paul,
I understand that ideally the 'General
Forwarding Not Allowed' should be set.
But I don't understand why the user was able to
execute the work item if he was not a possible agent??
Any other ideas?
Regards
Cristiana
Paul.Bakker at osr.treasury.qld.gov.au
Sent by: sap-wug-bounces at mit.edu
19/01/2005 10:38 AM
Please respond to
"SAP Workflow Users' Group"
To
"SAP Workflow Users' Group" <sap-wug at mit.edu>
cc
Subject
Re: Forwarding work items and possible agents
Cristiana,
Is the 'General Forwarding Not Allowed'
attribute set on your task?
If it is set, you should only be able to forward
to a possible agent (who
hasn't been excluded by the workflow).
hope this helps,
Paul
(Brisbane)
"Cristiana D'Agosto"
<cristiana.dagosto at a
To: sap-wug at mit.edu
u1.ibm.com>
cc:
Sent by:
Subject: Forwarding work items and possible agents
sap-wug-bounces at mit.
edu
19/01/2005 08:41
Please respond to
"SAP Workflow Users'
Group"
G'day,
we are in version 4.7
If a work item is forwarded to an user that is
NOT a possible agent, a
message is displayed but you can still forward
it.
In my scenario I'm using one security role
assigned to the task to
determine the possible agents.
In my testing, the user that I forwarded the
work item to is NOT a possible
agent. I accepted to forward the work item
anyway; log on as the user and
could execute the work item?
I thought that if the user is not a possible
agent of the work item, he/she
cannot execute it?
It seems rather a silly question but I am
puzzled. I must have missed
something, but what?
Much thanks and regards,
Cristiana
_________________________________
Cristiana d'Agosto
IBM Business Consulting Services
Direct: +61 2 9478 8926
Mobile: +61 417 927 224
cristiana.dagosto at au1.ibm.com
_______________________________________________
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/20050121/e3ed4109/attachment.htm
More information about the SAP-WUG
mailing list