<div> </div>
<div>I've seen this in SRM. Authorisation that it was failing on was a PLOG or PLOGI thing! </div>
<div> </div>
<div>Andy</div>
<div><br> </div>
<div class="gmail_quote">
<blockquote style="BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex; PADDING-LEFT: 1ex" class="gmail_quote"><br>---------- Forwarded message ----------<br>From: "Mike Pokraka" <<a href="mailto:wug@workflowconnections.com">wug@workflowconnections.com</a>><br>
To: "SAP Workflow Users' Group" <<a href="mailto:sap-wug@mit.edu">sap-wug@mit.edu</a>><br>Date: Tue, 16 Mar 2010 13:00:34 -0000 (GMT)<br>Subject: Re: Workitems being created under different usernames<br>
Interesting!<br>Well in that case I'd suggest two alternatives:<br><br>- Use a 'determine agents' step that calls RH_GET_ACTORS in background<br>instead of using a rule on the step.<br><br>- If you want to avoid a background step you could cde the agent<br>
determination as a functional method that bypasses auth checks (e.g. by<br>doing direct table reads, possibly calling the rule thereafter) and insert<br>that as an agent expression on your step. If you haven't used WF-OO, don't<br>
worry because there's no need for the any of the workflow-specific stuff<br>for classes/objects aren't stored in the container. Just code a static<br>method that returns your agent parameter and plug it into the expression.<br>
<br>Cheers,<br>Mike<br><br><br>On Tue, March 16, 2010 3:32 am, Rick Bakker wrote:<br>> Hi Mike,<br>><br>> I made sure Advance with Dialog was turned off both for the step in<br>> question and the preceding step. I also turned off Advance with Dialog<br>
> at the workflow header. And I looked at 'User context' in the classic<br>> view. It still says the step is being created by the actual agent of<br>> the previous step.<br>><br>> I then changed the agent determination to a test fm which does nothing<br>
> but check SY-UNAME and determine the agent based on that. Again, the<br>> result was as expected - the preceding actual agent is executing the<br>> rule. It could be that SAP is overwriting SY-UNAME but I did notice<br>
> before that the authorization problems that certain users were having<br>> with the AC rule disappeared when authorizations were added, and<br>> reappeared when they were taken away again.<br>><br>> So I conclude that the rule is run by the preceding actual agent, even<br>
> without advance with dialog.<br>><br>> cheers<br>> Rick Bakker<br>> Hanabi Technology<br>><br>> On Tue, Mar 16, 2010 at 12:20 AM, Mike Pokraka<br>> <<a href="mailto:wug@workflowconnections.com">wug@workflowconnections.com</a>> wrote:<br>
>> Just to state the obvious: did you switch it off for the previous step?<br>>> Failing that, try disabling it at the workflow header just to test.<br>>> I vaguely remember having problems in this area before - but that was<br>
>> some<br>>> time ago.<br>>><br>>> Another thing: Don't take the log at face value. It will show you the<br>>> user<br>>> under which it pretends to execute, even though the actual session may<br>
>> differ. Look at the technical log and switch to the old-style technical<br>>> log & expand the steps. Then scroll all the way across to the right and<br>>> the column 'User context' will show you the real user.<br>
>><br>>> To further confuse, some bits are workflow aware and will perform auth<br>>> checks according to the current workflow agent, whereas others will use<br>>> SY-UNAME, which may be different. (But don't always trust SY-UNAME<br>
>> either,<br>>> because I've seen SAP code occasionally overwrite SY-UNAME in order to<br>>> impersonate dialog users in a bacground process).<br>>><br>>><br>>><br>>> On Mon, March 15, 2010 10:59 am, Rick Bakker wrote:<br>
>>> Thanks Ramki and Mike, I admit I didn't think of that. But, it doesn't<br>>>> work!<br>>>> Workitems are still created by the actual agent of the previous<br>>>> workitem, even after SWU_OBUF.<br>
>>><br>>>> On Mon, Mar 15, 2010 at 8:40 PM, Mike Pokraka<br>>>> <<a href="mailto:wug@workflowconnections.com">wug@workflowconnections.com</a>> wrote:<br>>>>> Rick,<br>>>>><br>
>>>> Creating the next work item within the current user's context<br>>>>> facilitates<br>>>>> advance in dialog. I think switching that off for the step involved<br>>>>> should<br>
</blockquote></div>