Workitems being created under different usernames

[Mike Pokraka]

Interesting!
Well in that case I'd suggest two alternatives:

- Use a 'determine agents' step that calls RH_GET_ACTORS in background
instead of using a rule on the step.

- If you want to avoid a background step you could cde the agent
determination as a functional method that bypasses auth checks (e.g. by
doing direct table reads, possibly calling the rule thereafter) and insert
that as an agent expression on your step. If you haven't used WF-OO, don't
worry because there's no need for the any of the workflow-specific stuff
for classes/objects aren't stored in the container. Just code a static
method that returns your agent parameter and plug it into the expression.

Cheers,
Mike


On Tue, March 16, 2010 3:32 am, Rick Bakker wrote:
> Hi Mike,
>
> I made sure Advance with Dialog was turned off both for the step in
> question and the preceding step. I also turned off Advance with Dialog
> at the workflow header. And I looked at 'User context' in the classic
> view. It still says the step is being created by the actual agent of
> the previous step.
>
> I then changed the agent determination to a test fm which does nothing
> but check SY-UNAME and determine the agent based on that. Again, the
> result was as expected - the preceding actual agent is executing the
> rule. It could be that SAP is overwriting SY-UNAME but I did notice
> before that the authorization problems that certain users were having
> with the AC rule disappeared when authorizations were added, and
> reappeared when they were taken away again.
>
> So I conclude that the rule is run by the preceding actual agent, even
> without advance with dialog.
>
> cheers
> Rick Bakker
> Hanabi Technology
>
> On Tue, Mar 16, 2010 at 12:20 AM, Mike Pokraka
> <wug at workflowconnections.com> wrote:
>> 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
>>>
>>
>>
>> _______________________________________________
>> 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
>