Workitems being created under different usernames

[Mike Pokraka]

Just to state the obvious: did you switch it off for the previous step?
Failing that, try disabling it at the workflow header just to test.
I vaguely remember having problems in this area before - but that was some
time ago.

Another thing: Don't take the log at face value. It will show you the user
under which it pretends to execute, even though the actual session may
differ. Look at the technical log and switch to the old-style technical
log & expand the steps. Then scroll all the way across to the right and
the column 'User context' will show you the real user.

To further confuse, some bits are workflow aware and will perform auth
checks according to the current workflow agent, whereas others will use
SY-UNAME, which may be different. (But don't always trust SY-UNAME either,
because I've seen SAP code occasionally overwrite SY-UNAME in order to
impersonate dialog users in a bacground process).



On Mon, March 15, 2010 10:59 am, Rick Bakker wrote:
> Thanks Ramki and Mike, I admit I didn't think of that. But, it doesn't
> work!
> Workitems are still created by the actual agent of the previous
> workitem, even after SWU_OBUF.
>
> On Mon, Mar 15, 2010 at 8:40 PM, Mike Pokraka
> <wug at workflowconnections.com> wrote:
>> Rick,
>>
>> Creating the next work item within the current user's context
>> facilitates
>> advance in dialog. I think switching that off for the step involved
>> should
>> do the job.
>>
>> Cheers,
>> Mike
>>
>>
>> On Mon, March 15, 2010 5:49 am, Rick Bakker wrote:
>>> Dear WUGgers,
>>>
>>> A custom-made workflow was sometimes failing to find an agent for a
>>> Decision step via an AC rule when testing.
>>>
>>> Eventually the cause was tracked down and it became 100% reproducible.
>>> It was only when certain users had executed the previous step, and an
>>> attribute had been changed in the underlying object during the
>>> workflow. It turned out to be an authorization problem.
>>>
>>> I have always viewed workflow logs with concern when I see which
>>> usernames some of the steps or workitems have been created by. They
>>> could be any old agent, usually the actual agent of the preceding
>>> step. But, this was the first time I had seen it cause a problem.
>>>
>>> So what do I do now? Try to find every authorization that could
>>> possibly be needed in every situation with this workflow (and all
>>> other workflows) and request they be given to all possible users, or
>>> do I insert a dummy background step after each dialog step
>>> in order to pass control back to WF-BATCH? I tried the latter. It's
>>> simple, quick, effective and ugly.
>>>
>>> Has anybody else encountered this problem?
>>>
>>> By the way, I tried putting in a 1-minute wait step after the step
>>> where the underlying  object gets changed, it didn't make any
>>> difference. In any case, there could be other situations  in which
>>> agents don't have sufficient privileges to do whatever a step needs to
>>> be created properly.
>>>
>>> We're on ECC 6.0.
>>>
>>> regards
>>> Rick Bakker
>>> Hanabi Technology
>>> _______________________________________________
>>> 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
>