Workitems being created under different usernames

[JANSSENS Koenraad]

Binding?  Config?

>-----Original Message-----
>From: sap-wug-bounces at mit.edu [mailto:sap-wug-bounces at mit.edu] On Behalf Of Rick Bakker
>Sent: Monday, March 15, 2010 11:59 AM
>To: SAP Workflow Users' Group
>Subject: Re: Workitems being created under different usernames
>
>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