Error WL 006 without authorization S_OC_ROLE in 4.6C
Trant, David
David.Trant at andrew.com
Thu Jan 26 16:27:27 EST 2006
Again, thanks for all the tips. Unfortunately, the "advance with
dialog" flag setting didn't help. It is true that the flag had been
originally set for the first work item, but even after un-checking it,
the second work item was still being launched by the userID executing
the first work item. Also, note that the second work item is not a
background task, but rather another dialog task. Here are some screen
shots to show the progression.
Step one: approval task is sent to user PLM Planner, who approves it
The next step in the workflow is a condition branch, and then this
dialog step:
Since the PLM Planner does not have authorization to resolve the role
for the subsequent step, the workflow fails:
Whereas if the first work item is sent to user Yan Guan, who does have
the S_OC_ROLE authorization, then it works fine:
Again, the workaround we know of is to insert a dummy background task
between the two dialog tasks, which forces the workflow system to start
the second dialog task with WF-BATCH's authorizations, but I still feel
like there should be a better way. Maybe this is something for OSS, but
surely other customers have encountered this before. I could have sworn
I saw chatter on this way back when, but alas I can't find anything in
the archives and my own mental archives are too fuzzy!
Thanks again for all the ideas.
David
-----Original Message-----
From: sap-wug-bounces at mit.edu [mailto:sap-wug-bounces at mit.edu] On Behalf
Of Mike Pokraka
Sent: Thursday, January 26, 2006 12:49 AM
To: SAP Workflow Users' Group
Subject: RE: Error WL 006 without authorization S_OC_ROLE in 4.6C
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
>
_______________________________________________
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]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/pipermail/sap-wug/attachments/20060126/809486cd/attachment.htm
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 36525 bytes
Desc: image001.jpg
Url : http://mailman.mit.edu/pipermail/sap-wug/attachments/20060126/809486cd/attachment.jpg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 37862 bytes
Desc: image002.jpg
Url : http://mailman.mit.edu/pipermail/sap-wug/attachments/20060126/809486cd/attachment-0001.jpg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 116640 bytes
Desc: image006.jpg
Url : http://mailman.mit.edu/pipermail/sap-wug/attachments/20060126/809486cd/attachment-0002.jpg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 38151 bytes
Desc: image007.jpg
Url : http://mailman.mit.edu/pipermail/sap-wug/attachments/20060126/809486cd/attachment-0003.jpg
More information about the SAP-WUG
mailing list