<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=US-ASCII">
<META content="MSHTML 6.00.2800.1479" name=GENERATOR></HEAD>
<BODY id=role_body style="FONT-SIZE: 10pt; COLOR: #000000; FONT-FAMILY: Arial"
bottomMargin=7 leftMargin=7 topMargin=7 rightMargin=7><FONT id=role_document
face=Arial color=#000000 size=2>
<DIV>
<DIV>
<DIV>Hmmmm..</DIV>
<DIV> </DIV>
<DIV>I had a strange situation a couple of weeks ago. On a Sunday our FI team
had suddenly decided on some special processing and requested that all
users be locked out of the production system. There was one user already in the
system before the lockout and was able to continue working most of the day and
triggered several workflows. The workflows triggered before the lockout started
but the ones triggered later did not start. SM58 list displays the "User is
locked. Please notify the person responsible" for the locked user id for
function module SWW_WI_CREATE_VIA_EVENT_IBF. Target system is
WORKFLOW_LOCAL...The WF-BATCH id was not locked. </DIV>
<DIV> </DIV>
<DIV>Why is the WF initiator id being validated for creating a WF
instance??</DIV>
<DIV> </DIV>
<DIV>
<DIV><FONT lang=0 face=Arial size=2 FAMILY="SANSSERIF"
PTSIZE="10">Regards,<BR>Ramki Maley<BR>Workflow Developer,
USCBP.<BR>248-613-1287 (C)</FONT></DIV></DIV>
<DIV> </DIV>
<DIV>In a message dated 5/12/2005 9:56:13 AM Eastern Standard Time,
keohan@ll.mit.edu writes:</DIV>
<BLOCKQUOTE style="PADDING-LEFT: 0px; MARGIN-LEFT: 0px"><FONT
style="BACKGROUND-COLOR: transparent" face=Arial color=#000000 size=2>Well,
for what is is worth, OSS has stated that:<BR>> From my understanding
BC-BMT-WFM layer<BR>> does not perform any checking in order to prevent a
Workitem being<BR>> delivered to a Agent which User is Locked: USR02-UFLAG
(User Lock<BR>> Status).<BR><BR>It seems counter-productive to me that I am
allowed to route a workitem to a user who is locked and <BR>delimited.
Is this just me ? Of course, there are work-arounds, but if anyone
else has <BR>experienced this problem, I would be interested to hear how you
dealt with it.<BR><BR>Thanks,<BR>Sue<BR><BR>Susan R. Keohan wrote:<BR><BR>>
Hi Mike,<BR>> <BR>> What's interesting is that in our Dev environment,
which is not <BR>> necessarily the best place for testing :), I've had the
following <BR>> results...<BR>> <BR>> USERID_A, name John Smith, no
PA0105 record, can be selected either by <BR>> userid or by last name in
the drop-down.<BR>> <BR>> USERID_B, name Michael Doe, with valid PA0105
record, can be chosen by <BR>> entering USERID_B in the entry screen, but
*not* by entering 'Doe' in <BR>> the drop-down.<BR>> <BR>> USERID_C,
name Mark Jones, with delimited PA0105 record, can be chosen <BR>> by
entering USERID_C in the entry screen, and also by entering 'Jones' <BR>>
in the drop-down.<BR>> <BR>> Of course, it would be nice if I had
consistent data in Dev to work <BR>> with. I suspect I need to spend
some quality time with OSS.<BR>> <BR>> Thanks!<BR>> Sue<BR>>
<BR>> Michael Pokraka wrote:<BR>> <BR>>> Hi Sue, If you manually
delimit 105, does it behave as expected? If so <BR>>> it should
become<BR>>> a query for the HR people rather than user
admin/workflow.<BR>>> I'm curious, so could you let us know the outcome?
Cheers<BR>>> Mike<BR>>><BR>>> --- "Susan R. Keohan"
<keohan@ll.mit.edu> wrote:<BR>>><BR>>>> Hello
WF'ers,<BR>>>><BR>>>> We are on 4.6c, Support Pack level
39. We have used the wizard 'Choose<BR>>>> Agent' to provide a
dialog box to certain users(Agents A) which will <BR>>>> allow
them to choose the next<BR>>>> agent(Agents B) in a subsequent
workflow step. This creates a task <BR>>>> which calls the
method<BR>>>> ALLAGENTSOFTASKGETANDDISPATCH of object WF_TASK, which,
in turn, <BR>>>> calls function module<BR>>>>
SWU_WF_TASK_DISPATCH.<BR>>>><BR>>>> However, I've discovered
that Agent A may enter, or select via the <BR>>>>
dropdown,<BR>>>> a last name or username of for Agent B, whose SAP
UserID is locked <BR>>>> and delimited (but not deleted). I've
examined the SU01D records, and <BR>>>> they are indeed locked and
delimited, the personnel records are<BR>>>> 'withdrawn' and
delimited, but the PA0105 infotype records are *not* <BR>>>>
delimited.<BR>>>><BR>>>> It's unfortunate for Agent A that
they can select people (Agent B) <BR>>>> who are no<BR>>>>
longer here. I'm about to enter an OSS message, but thought I would
<BR>>>> try our experts on the<BR>>>> SAP-WUG first.
Has anyone come across this error before ?<BR>>>> -- <BR>>>>
Susan R. Keohan<BR>>>> SAP Workflow Developer<BR>>>> MIT
Lincoln Laboratory<BR>>>> 244 Wood Street<BR>>>>
LI-200<BR>>>> Lexington, MA. 02420<BR>>>>
781-981-3561<BR>>>> keohan@ll.mit.edu<BR>>>><BR>>>>
_______________________________________________<BR>>>> SAP-WUG
mailing list<BR>>>> SAP-WUG@mit.edu<BR>>>>
http://mailman.mit.edu/mailman/listinfo/sap-wug<BR>>>><BR>>><BR>>><BR>>>
Michael Pokraka<BR>>> Workflow Connections Ltd.<BR>>> Tel.: +44
(0)7786 910 855<BR>>>
_______________________________________________<BR>>> SAP-WUG mailing
list<BR>>> SAP-WUG@mit.edu<BR>>>
http://mailman.mit.edu/mailman/listinfo/sap-wug<BR>>><BR>> <BR><BR>--
<BR>Susan R. Keohan<BR>SAP Workflow Developer<BR>MIT Lincoln Laboratory<BR>244
Wood Street<BR>LI-200<BR>Lexington, MA.
02420<BR>781-981-3561<BR>keohan@ll.mit.edu<BR>_______________________________________________<BR>SAP-WUG
mailing
list<BR>SAP-WUG@mit.edu<BR>http://mailman.mit.edu/mailman/listinfo/sap-wug<BR></FONT></BLOCKQUOTE></DIV>
<DIV></DIV></DIV>
<DIV> </DIV>
<DIV><FONT lang=0 face=Arial size=2 FAMILY="SANSSERIF"
PTSIZE="10">Regards,<BR>Ramki Maley<BR>Workflow Developer,
USCBP.<BR>248-613-1287 (C)</FONT></DIV></FONT></BODY></HTML>