Role Error in Workflow

[Dart, Jocelyn]

That's great Louise!
 
Suggest you double-check the settings in T77UA anyway -
WF-BATCH may be picking up super user authority by default.
As this is now a requirement of your workflow you need to make sure
you document and communicate to the HR folks that WF-BATCH absolutely
MUST be a superuser no matter what changes they make to HR structural
authorisations in future.
Kind regards,
Jocelyn
 
-----Original Message-----
From: Louise Morgan [mailto:Louise.Morgan at Xansa.com]
Sent: Monday, 15 April 2002 8:42 PM
To: SAP-WUG at MITVMA.MIT.EDU
Subject: FW: Role Error in Workflow
 
 
Thanks Jocelyn, putting a dummy background step between the two user
decisions did resolve the problem without having to put a new entry in
T77UA.
 
Kind Regards,
 
Louise
 
> -----Original Message-----
>> From: "Dart, Jocelyn" <jocelyn.dart at sap.com>@GLOBAL
> Sent: Monday, April 15, 2002 8:20 AM
> To:   Louise Morgan
> Subject:      RE: Role Error in Workflow
>
> Hi Louise,
> Yep that's exactly it.  HR structural authorisations can drive you balmy
> but this seems to be the quickest and most effective way around it.
> Make sure that the workflow system user does have super user authority for
> HR struc auth - i.e. they are entered in table T77UA as having full HR
> authority.
> Regards,
>       Jocelyn Dart
> Consultant (EBP, BBP, Ecommerce, Internet Transaction Server, Workflow)
> SAP Australia
> Email jocelyn.dart at sap.com <mailto:jocelyn.dart at sap.com>
> Tel: +61 412 390 267
> Fax: +61 2 9935 4880
>
>
> -----Original Message-----
>> From: Louise Morgan [mailto:Louise.Morgan at Xansa.com]
> Sent: Friday, 12 April 2002 6:35 PM
> To: Dart, Jocelyn
> Subject: FW: Role Error in Workflow
>
>
> Hi Jocelyn,
>
> This is interesting!
>
> I just wanted to double check I understood what you're saying...
>
> We have a condition step that evaluates if the WF_Initiator = Trip Creator
> (ie &TRIP.EMPLOYEE.USERID&)
> If this is true, the expenses need an admin check.  If false, the expenses
> go straight to the approving manager (in this scenario, the Workflow does
> not error).
> Once the administrator has provided the check (ie approved via a user
> decision), the workflow moves straight on get approval from the manager
> (which is then where the Workflow fails).
>
> I can see from the technical log that where the Workflow has gone through
> the administrator's step, the workflow then tries to execute the function
> SW_WI_STATUS_CHANGE using the administrator's id for the manager approval
> step and is showing an error.  So from what you have said, is this where
> the
> Workflow is trying to resolve the manager approval step using the
> administrator's id to see if this dialogue step is for them aswell and
> it's
> failing because of some HR issue?  (I'm still a bit confused about what
> this
> HR authorisation issue is)
>
> Following this through then, if I simply put a dummy background step in
> between these two user decision steps, this will effectively flip the
> Workflow back to using the WF Manager/WF-BATCH user to resolve the next
> dialogue step?
>
> Thanks for your response,
>
> Kind Regards,
>
> Louise
>
> > -----Original Message-----
> > From:       SAP Workflow <Owner-SAP-WUG at MITVMA.MIT.EDU>@GLOBAL  On
> Behalf Of
> > "Dart, Jocelyn" <jocelyn.dart at sap.com>
> > Sent:       Friday, April 12, 2002 2:46 AM
> > To: SAP-WUG at MITVMA.MIT.EDU
> > Subject:    Re: Role Error in Workflow
> >
> > Hi Louise,
> >
> > Expense approvals? Hmmm.... I guess that means the workflow is using HR
> > infotypes
> > underneath the business objects?
> > Then it is likely that you are being hit with HR structural
> authorisation
> > errors.
> >
> > E.g. The person who raises the event starts the workflow. Under normal
> > workflow
> > behaviour that person's userid is used to evaluate and execute the
> > following
> > few
> > steps in case the next dialog work item belongs to them. This means that
> > if
> > your
> > condition step uses HR infotype data, and HR structural authorisation is
> > on
> > the infotypes
> > are being retrieved under the dialog user's authority. When you restart
> > with
> > SWPR you
> > are using a different userid that does have the authority to retrieve
> the
> > infotype data.
> > The technical view of the workflow log shows you whose userid is being
> > used
> > to evaluate the workflow step.
> >
> > I've just been working on something similar so this is very fresh in my
> > mind.
> > The main thing is you want the workflow system user to have superuser
> > authority
> > to HR structural authorization (e.g. via table T77UA) and to ensure the
> > condition step
> > is evaluated by the workflow system user.
> >
> > There are a couple of ways you could do this - e.g. playing with the
> > advance
> > with dialog
> > options, or including a background step prior to your condition step
> (e.g.
> > you could set
> > up a background task linked to an empty background method to explicitly
> > "swaptobackgrounduser").
> >
> > Regards,
> >         Jocelyn Dart
> > Consultant (EBP, BBP, Ecommerce, Internet Transaction Server, Workflow)
> > SAP Australia
> > Email jocelyn.dart at sap.com <mailto:jocelyn.dart at sap.com>
> > Tel: +61 412 390 267
> > Fax: +61 2 9935 4880
> >
> >
> >
> > -----Original Message-----
> > From: THOMAS MAUE JR [mailto:tommjr at worldnet.att.net]
> > Sent: Friday, 12 April 2002 10:54 AM
> > To: SAP-WUG at MITVMA.MIT.EDU
> > Subject: Re: Role Error in Workflow
> >
> >
> > Louise,
> >
> > Sounds like it could be an authorization problem (only happening in
> > production).  Do a trace and look for a problem.  When you restart
> > manually or test the role - you are using your profiles which can
> > account for the resolution working.
> >
> > Regards,
> >
> > Thomas Maue
> > Workflow Consultant
> >
> > -----Original Message-----
> > From: Louise Morgan <Louise.Morgan at Xansa.com>
> > To: SAP-WUG at MITVMA.MIT.EDU <SAP-WUG at MITVMA.MIT.EDU>
> > Date: Thursday, April 11, 2002 12:03 PM
> > Subject: Re: Role Error in Workflow
> >
> >
> > Thanks for the suggestion Stephen but there isn't anything in the branch
> > following the administrator user decision (if a positive decision is
> made,
> > which it has been) and the approval step.  The administrator check is
> just
> > a
> > standard user decision, and the variables passed into the subsequent
> > approval role are based on attributes directly from the object so I
> can't
> > see how these would be overwritten.
> >
> > It's very strange especially as the problem only occurs on one client;
> the
> > Workflow is fine on DEV and QA clients.
> >
> > > -----Original Message-----
> > > From: SAP Workflow <Owner-SAP-WUG at MITVMA.MIT.EDU>@GLOBAL  On Behalf Of
> > > "Becker Stephan (extern)" <Stephan.Becker.ext at mchw.siemens.de>
> > > Sent: Thursday, April 11, 2002 12:35 PM
> > > To:   SAP-WUG at MITVMA.MIT.EDU
> > > Subject:      AW: Role Error in Workflow
> > >
> > > I would think that this is a variable error. My guess would be that in
> > the
> > > branch with the user decision, a variable that is needed later in the
> > > role,
> > > is changed or otherwise overwritten, so that the role errors. A
> careful
> > > look
> > > at the bindings and containers will probably reveal what the cause is.
> > >
> > > Hth,
> > > Stephan
> > >
> > > -----Urspr|ngliche Nachricht-----
> > > Von: Louise Morgan [mailto:Louise.Morgan at Xansa.com]
> > > Gesendet: Donnerstag, 11. April 2002 13:14
> > > An: SAP-WUG at MITVMA.MIT.EDU
> > > Betreff: Role Error in Workflow
> > >
> > >
> > > We're working on 4.6B of Connect and Go and have an issue with a
> > Workflow
> > > to
> > > support Expense Approvals on the Production client.
> > >
> > > The Workflow starts correctly but when it gets the approval step which
> > has
> > > a
> > > Role (based on a function module) it errors.  The error log shows that
> > no
> > > agent is found and Role AC9xxxxx cannot be resolved.  However, when
> the
> > > Workflow is manually restarted from transaction SWPR, the role
> resolves
> > > correctly and the user decision task is routed to the right agent
> > without
> > > any problems.
> > >
> > > Prior to the approval step, there is a condition step that evaluates
> > > whether
> > > the expenses must first be checked by an administrator.  If it doesn't
> > > have
> > > to be checked by the administrator the Workflow moves straight on to
> the
> > > approval step otherwise a user decision task is routed to the
> > > administrator.
> > > It is only when the Workflow takes the branch via the administrator
> that
> > > it
> > > errors on the approval role following completion of the check.  Going
> > > directly from the condition step to the approval step does not result
> in
> > > an
> > > error.
> > >
> > > The approval Role always resolves correctly when it is tested via PFAC
> > so
> > > I
> > > do not believe there is an Organisational issue.
> > > The Workflow is correctly passing in the container elements the Role
> > > requires.
> > > We have tried creating a new Workflow definition and re-transporting
> > which
> > > has not resolved the problem.
> > > The Workflow was fully tested in DEV & QA clients without issue.
> > >
> > > Can anyone shed any light on what the problem might be?