Error WL 006 without authorization S_OC_ROLE in 4.6C

Fri Jan 27 02:53:48 EST 2006

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
>