Error WL 006 without authorization S_OC_ROLE in 4.6C
Mike Pokraka
wug.replies at workflowconnections.com
Fri Jan 27 03:49:26 EST 2006
Sorry, I just re-read you post and realized what you meant.
When you said "The action fails a check on authorization..." I assumed
you're talking about a user not authorized to perform the *task* of the
step, not to *determine the agents*. A completely different thing.
I am not sure why special authorizations sould be required. (Hence this is
a slightly unusual problem), normally people should have the necessary
auth to look around the org chart and evaluate rules. Does your rule do
anything special that it required 'ADMINISTRATOR' values in the auths?
Auth checks can sometimes give red herrings, and the real auth/problem
might be something else that's causing it to look at S_OC_ROLE.
In that case you are right, and I have used the 'background step'
technique you mention before, but only very rarely. I was mistaken in
thinkint that unticking 'advance w. dialog' uses the system user to create
the next step (just goes to show how often I use it). I think that's
exactly what it *should* do.
If this is a special kind of rule looking at restricted data, then I would
put the rule into it's own background method which calls RH_GET_ACTORS and
returns agents into a container element. This helps to distinguish this
rule a little and enforces its evaluation in background.
Cheers
Mike
Mike Pokraka wrote:
> David,
>
> I have given you the answers, please re-read my last post, particularly
> the bit that stats with "In your case, all that is irrelevant however..."
>
> You need a background task, it has nothing to do with advance with dialog.
>
> Cheers
> Mike
>
> Trant, David wrote:
>> 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]_______________________________________________
>> 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