Workitems being created under different usernames

Mon Mar 15 18:55:07 EDT 2010

Hi Florin,

Thanks for your thoughts!

> Solution 1) - Add the missing authorizations

It certainly is possible, but quite a pain and not really something
I'd want to do
as a matter of course for every workflow. You'd also have to make sure
that any future
users get the same authorizations, something I don't have much control
over. Making sure
everything is run as WF-BATCH completely circumvents these problems,
as far as I can see.

>When using rule resolution, I personally tend to omit additional authorization checks, to avoid these symptoms.

I didn't add any additional authorization checks, it's standard SAP.

> Solution 2) - Enforce WF-BATCH

I'm using WFTS method EMPTY_BACKGROUND which is definitely a
background step and is therefore
always run as WF-BATCH. Best of all, it doesn't involve an actual
wait. Unless someone tells
me otherwise, I'm assuming this is guaranteed to switch control back
to WF-BATCH.

>Solution 3) - Recode rule resolution
>Change the rule resolution to avoid authorization checks

Not possible in this case. I have to access the object and SAP
determines it has to be via the buffer and that's when I get problems.

>Solution 4) - Flag Asynchronous rule resolution
Interesting, I'll try it out.

cheers
Rick Bakker
Hanabi Technology

On Mon, Mar 15, 2010 at 11:23 PM, Florin Wach <florin.wach at gmx.net> wrote:
> Hello Rick,
>
> I have observed the same behaviour: The next work item is created by the previously acting user: The role-resolution is executed (usually synchronously) and the work item is also being created under that user id.
>
> Where the second step (work item creation) is not authority checked, the rule resolution might be, e.g. when reading object attributes such as LFA1 etc.
>
> Solution 1) - Add the missing authorizations
>
> And - believe it or not - we tracked each needed authorization object required to execute the workflow and put that into a role, which is assigned to each involved user.
> When using rule resolution, I personally tend to omit additional authorization checks, to avoid these symptoms.
>
> Solution 2) - Enforce WF-BATCH
>
> If you want to enforce the WF-BATCH-User, you'll need to throw a /real/ background step in between. A wait step will not be sufficient, which is executed by the current user. Deflag the "Dialog" check box, and if it's still a problem, mark the task as asynchronous and send the terminating event within the object method's coding (however, this should not be neccessary).
>
> Solution 3) - Recode rule resolution
>
> Change the rule resolution to avoid authorization checks
>
> Solution 4) - Flag Asynchronous rule resolution
>
> I havend worked with it yet, but under version ECC 6.00 there's a flag at the workflow definition step that the rule is to be executed asynchronously. This created an interal RFC call and the result of the rule is then put back into the workitem, which then will continue. I suspect that the user WF-BATCH is also used for that internal tRFC call.
>
>
> Best wishes,
> Florin
>
>
>
> -------- Original-Nachricht --------
>> Datum: Mon, 15 Mar 2010 21:41:06 +1000
>> Von: Rick Bakker <rbakker at gmail.com>
>> An: "SAP Workflow Users\' Group" <sap-wug at mit.edu>
>> Betreff: Re: Workitems being created under different usernames
>
>> Interesting.... Could there be a config setting which controls this
>> behaviour?
>>
>> On Mon, Mar 15, 2010 at 9:09 PM, JANSSENS Koenraad
>> <Koenraad.JANSSENS at swift.com> wrote:
>> > Binding?  Config?
>> >
>> >>-----Original Message-----
>> >>From: sap-wug-bounces at mit.edu [mailto:sap-wug-bounces at mit.edu] On Behalf
>> Of Rick Bakker
>> >>Sent: Monday, March 15, 2010 11:59 AM
>> >>To: SAP Workflow Users' Group
>> >>Subject: Re: Workitems being created under different usernames
>> >>
>> >>Thanks Ramki and Mike, I admit I didn't think of that. But, it doesn't
>> work!
>> >>Workitems are still created by the actual agent of the previous
>> >>workitem, even after SWU_OBUF.
>> >>
>> >>On Mon, Mar 15, 2010 at 8:40 PM, Mike Pokraka
>> >><wug at workflowconnections.com> wrote:
>> >>> Rick,
>> >>>
>> >>> Creating the next work item within the current user's context
>> facilitates
>> >>> advance in dialog. I think switching that off for the step involved
>> should
>> >>> do the job.
>> >>>
>> >>> Cheers,
>> >>> Mike
>> >>>
>> >>>
>> >>> On Mon, March 15, 2010 5:49 am, Rick Bakker wrote:
>> >>>> Dear WUGgers,
>> >>>>
>> >>>> A custom-made workflow was sometimes failing to find an agent for a
>> >>>> Decision step via an AC rule when testing.
>> >>>>
>> >>>> Eventually the cause was tracked down and it became 100%
>> reproducible.
>> >>>> It was only when certain users had executed the previous step, and an
>> >>>> attribute had been changed in the underlying object during the
>> >>>> workflow. It turned out to be an authorization problem.
>> >>>>
>> >>>> I have always viewed workflow logs with concern when I see which
>> >>>> usernames some of the steps or workitems have been created by. They
>> >>>> could be any old agent, usually the actual agent of the preceding
>> >>>> step. But, this was the first time I had seen it cause a problem.
>> >>>>
>> >>>> So what do I do now? Try to find every authorization that could
>> >>>> possibly be needed in every situation with this workflow (and all
>> >>>> other workflows) and request they be given to all possible users, or
>> >>>> do I insert a dummy background step after each dialog step
>> >>>> in order to pass control back to WF-BATCH? I tried the latter. It's
>> >>>> simple, quick, effective and ugly.
>> >>>>
>> >>>> Has anybody else encountered this problem?
>> >>>>
>> >>>> By the way, I tried putting in a 1-minute wait step after the step
>> >>>> where the underlying  object gets changed, it didn't make any
>> >>>> difference. In any case, there could be other situations  in which
>> >>>> agents don't have sufficient privileges to do whatever a step needs
>> to
>> >>>> be created properly.
>> >>>>
>> >>>> We're on ECC 6.0.
>> >>>>
>> >>>> regards
>> >>>> Rick Bakker
>> >>>> Hanabi Technology
>> >>>> _______________________________________________
>> >>>> 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
>> >
>>
>> _______________________________________________
>> 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
>