Error WL 006 without authorization S_OC_ROLE in 4.6C

Wed Jan 25 16:47:29 EST 2006

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 