Error WL 006 without authorization S_OC_ROLE in 4.6C
Mike Pokraka
wug.replies at workflowconnections.com
Thu Jan 26 01:48:51 EST 2006
Not on this here 620 system. The only way is as I just explained - setting
a background step to dialog and having it thus execute under the previous
step's user.
Cheers
Mike
Rick Sample wrote:
> Also, from my understanding (and correct me if I am wrong) in versions
> greater than 4.6c, we will be able to use background step (WF-BATCH)
> but pass in any user ID as user who executed the task.
> (Saw this while lurking so terminology may not be correct. Still on
> 4.6c.)
>
> i.e. logs will display a User verses WF-BATCH. So, when someone looks
> at a change log, they don't see WF-BATCH. Which is meaningless at
> times.
> Yes?
>
>
> Rick
>
>
>
>>>> wug.replies at workflowconnections.com 1/25/2006 15:25 >>>
> Hi David,
> Yes it does make sense in many for a user to begin executing the
> successor
> step. This is what "advance with dialog" is all about. Sometimes you
> want
> two steps in succession and you don't want the user to go back to
> their
> inbox. Think "reject" decision followed by an "enter reason" step.
>
> Untick "Advance with Dialog" in your workflow builder and the system
> will
> create each step. This can also be turned off by default - though I
> only
> switch it off for a few very specific scenarios.
>
> In your case, all that is irrelevant however. If your step shouldn't
> be
> executed by a user it should be a background task. In your task
> definition, tick "Background Processing". This is automatically set
> when
> your method is not flagged as dialog. Perhaps slightly misleading is
> the
> term 'dialog' - it does not mean 'on screen interaction', but 'dialog
> user'. In other words that tickbox is the entire "algorithm" you were
> wondering about :-)
>
> Sometimes I use a dialog task for non-interactive steps when I want a
> "background" update to happen under a specific userid. Other times I
> may
> want the update to be by WF-BATCH for security purposes... It all
> depends
> on the specific requirements.
>
> Have fun,
> Mike
>
> Trant, David wrote:
>> Thanks, and please do keep us posted with your OSS progress, but we
> are
>> still on 4.6C and are not using portals. I remember in some other
>> recent posts that the UWL treats work items a bit differently in
> later
>> releases, and maybe this is one reason why. If you think about it,
> it
>> doesn't make much sense for the user executing a predecessor step to
> be
>> listed as the user who begins executing a subsequent step. Really,
> the
>> workflow system should always be the one to initiate a step, sending
> it
>> to the appropriate agent(s). In the following example (forgive the
> text
>> -- my print screen application is acting up), work item 33635636
> gets
>> created by WF-BATCH (whose name field is populated in SU01 with "AC3
> SAP
>> Mail (Do Not Reply)"). Work item 33634785 shows being created by
> Yan
>> Guan, the user who was the agent for 33635636. Since Yan has
>> authorization for S_OC_ROLE, this works. If he did not, the work
> item
>> would not get created, and error WL 006 would be raised instead.
>>
>> Work Item
>> ---------
>> 33635636 147 ECH: Approve ECR
>> AC3 SAP Mail (Do Not RepX Dialog work item created <== WF-BATCH
>> creates
>> Yan Guan Work item reserved
>> Yan Guan Execution started
>> Yan Guan Work item processing complete <= user
>> executes
>> 329 End of parallel
>> 234 Change request a
>> 288 Branch
>> 307 Container operat
>> 33634785 284 EC: &EC_MASTER.C
>> Yan Guan Dialog work item created <== user
> creates
>>
>> So far, I've yet to discover the algorithm for determining whether
> the
>> agent involved in certain operations is going to be the last agent
> in
>> the buffer, WF-BATCH, or something called "WF Manager." One would
> think
>> that all entries other than real dialog work items should have WF
>> Manager as the agent, but again perhaps that changes in future
> releases.
>>
>> By inserting a dummy background task between the above two work
> items,
>> the system seems to always start the second task using WF-BATCH
> rather
>> than the last user in memory.
>>
>> I was just hoping perhaps someone was aware of a fix or other
> solution
>> as this seems quite inelegant. Maybe the answer is to do this until
> we
>> upgrade someday!
>>
>> Thanks,
>> David
>>
>> -----Original Message-----
>> From: sap-wug-bounces at mit.edu [mailto:sap-wug-bounces at mit.edu] On
> Behalf
>> Of Rick Sample
>> Sent: Wednesday, January 25, 2006 11:18 AM
>> To: sap-wug at mit.edu
>> Subject: Re: Error WL 006 without authorization S_OC_ROLE in 4.6C
>>
>> May or may not be related, but we started getting these messages
>> after a Portals upgrade. And, we only get this message when users
>> attempt to execute a decision step task via the UWL. Otherwise,
>> if the user execute via SAP GUI inbox it works fine.
>>
>> If this sounds like the same issue, let me know. We have an OSS note
>> opened and in progress.
>>
>> Rick
>>
>>
>>>>> David.Trant at andrew.com 1/25/2006 10:29 >>>
>> My apologies for probably re-posting an old question, but
>> google-searching the archives only turned up one posting on the
>> subject,
>> with no responses. I thought I had seen this addressed in the past,
>> so
>> hopefully someone can just help me find an already-documented
>> solution.
>>
>> When a user executes a work item in 4.6C, and that userID then tries
>> to
>> start the next work item, we sometimes get error WL 006:
>>
>> The following error occurred in the workflow above:
>> ROLLBACK WORK executed (SWP_CONTINUE_WITH_NEXT_NODES item 1)
>> Please repair the suspended workflow
>>
>> Press 'Execute' to display the workflow that has errors.
>>
>> This happens when a user executes a work item, and then the system
>> tries
>> to start the next work item using the current userID rather than
>> WF-BATCH. The action fails a check on authorization S_OC_ROLE value
>> ADMINISTRATOR. Since we won't be handing out that authorization to
>> our
>> users, one possible solution is to insert a dummy background step
> that
>> forces "focus" to change from the previous step's userID to WF-BATCH
>> prior to the subsequent step being started. Surely there is a
> better
>> work-around, but I can't seem to find it in the archives or in OSS.
>>
>>
>>
>> Does anyone recall the solution to this?
>>
>>
>>
>> Thanks,
>>
>> David
>>
>>
> ------------------------------------------------------------------------
>> ------------------------
>> This message is for the designated recipient only and may
>> contain privileged, proprietary, or otherwise private information.
>> If you have received it in error, please notify the sender
>> immediately and delete the original. Any unauthorized use of
>> this email is prohibited.
>>
> ------------------------------------------------------------------------
>> ------------------------
>> [mf2]
>>
>> _______________________________________________
>> SAP-WUG mailing list
>> SAP-WUG at mit.edu
>> http://mailman.mit.edu/mailman/listinfo/sap-wug
>>
>>
> ------------------------------------------------------------------------------------------------
>> This message is for the designated recipient only and may
>> contain privileged, proprietary, or otherwise private information.
>> If you have received it in error, please notify the sender
>> immediately and delete the original. Any unauthorized use of
>> this email is prohibited.
>>
> ------------------------------------------------------------------------------------------------
>> [mf2]
>>
>> _______________________________________________
>> 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
>
More information about the SAP-WUG
mailing list