Forwarding work items and possible agents
Soady, Phil
phil.soady at sap.com
Wed Jan 19 05:48:16 EST 2005
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/20050119/3e277f03/attachment.htm
More information about the SAP-WUG
mailing list