Workflow -> Task Bindings and user authorizations

[Mike Pokraka]

Michael,

This is normal, though the results seem a little counterintuitive. A
workflow step is created in the context of the preceding step. This
includes binding and agent determination (necessary to support advance in
dialog). Then, when all the binding and agent determination is done, the
workflow engine will switch context by calling an RFC to start the actual
task processing (in case of a background step).

Not sure if it still does this if you switch advance in dialog off at the
header level. Never tried as you often want this feature elsewhere in the
WF.

If you use the old technical log (thanks SAP for bringing this back as
"Classic Technical View" in the personal workflow settings!), the very
last column shows the context under which each bit is executing.

Cheers,
Mike

On Thu, February 10, 2011 10:23 pm, michael.mcley at daimler.com wrote:
> Rick,
>
> Interesting thing is that I thought these tasks were running as WF_BATCH.
> I changed them to background processing in one of our test systems, but
> still the authorizations failed (at least the containers were not written
> until I changed the auths of the agent in the previous steps)
>
> The only thing necessary to have a step run as WF_BATCH is to execute the
> work item in background, correct?
>
> Sorry to bother you, but no good deed should go unpunished...;-)
>
> Michael McLey
> MBUSI - IT Parts & Administration
> Mercedes-Benz US International, Inc.
> 1 Mercedes Drive
> Vance, AL 35490
> PHONE:  (205) 462 - 5239
> EMAIL:   michael.mcley at daimler.com
>
>
>
> rbakker at gmail.com
> Sent by: sap-wug-bounces at MIT.EDU
> 02/10/2011 04:18 PM
> Please respond to
> sap-wug at MIT.EDU
>
>
> To
> sap-wug at MIT.EDU
> cc
>
> Subject
> Re: Workflow -> Task Bindings and user authorizations
>
>
>
>
>
>
> Hi Michael,
>
> Surprising to me as well but then I try to run as much as possible as
> WF-BATCH, even putting in dummy wait steps to achieve this.
> I've encountered similar authorization problems before.
>
> regards
> Rick Bakker
> hanabi technology
>
> On Fri, Feb 11, 2011 at 8:28 AM, <michael.mcley at daimler.com> wrote:
>
> Thanks Rick,
>
> This is just a follow-up.
>
> I bit the bullet and started testing to see if I could reproduce this
> problem.  As it turns out, bindings can be affected by user
> authorizations.  In this case it was a problem with the approvers reading
> infotype 0105 in the HR records for the trip requestor.
>
> Without even read permissions, the binding will not pass the workflow
> container value into the task container and the method fails.  Maybe it is
> because the source container value was an attribute of a BOR object and
> these container objects are subject to authorizations, dunno...
>
> This was a suprise to me, maybe it helps someone else with debugging.
> Michael McLey
> MBUSI - IT Parts & Administration
> Mercedes-Benz US International, Inc.
> 1 Mercedes Drive
> Vance, AL 35490
> PHONE:  (205) 462 - 5239
> EMAIL:   michael.mcley at daimler.com
>
>
>
> rbakker at gmail.com
> Sent by: sap-wug-bounces at mit.edu
> 02/09/2011 04:13 PM
>
> Please respond to
> sap-wug at mit.edu
>
>
>
> To
> sap-wug at mit.edu
> cc
>
> Subject
> Re: Workflow -> Task Bindings and user authorizations
>
>
>
>
>
>
>
>
>
> Hi Michael,
>
> This probably has nothing to do with your problem but so many keywords
> match that I can't resist.
>
> I was very surprised to find that including a position (S ....) which
> is empty in the list of recipients of a SendMail step causes the
> workflow to go into error.
> Maybe your problem is somehow related.
>
> regards
> Rick Bakker
> hanabi technology
>
> On Thu, Feb 10, 2011 at 4:20 AM,  <michael.mcley at daimler.com> wrote:
>>
>> Hello Wuggers,
>>
>> I'm stumped.
>>
>> Background:
>> We are using a workflow for the approvals of travel requests.  One of
> the
>> steps is that if an approver rejects a travel request, an SAP mail is
> sent
>> to the requestor with some text explaining why.
>>
>> Issue:
>> The SAP Mail reciepient is the user ID of the requestor, which is
> contained
>> in a WORKFLOW container element at the start of the workflow.  This
> WORKFLOW
>> container element is passed into the TASK container through a standard
>> binding.  So far a no-brainer.
>>
>> As of about August last year, most of these send mail tasks started
> going
>> into error (most - not all).  A review of the logs of successful and
>> error-ed tasks (and the task program, etc...) shows the reason for the
> error
>> is that the task container element which is used in the task to
> determine
>> the reciepient of the mail is not being populated, although the source
>> element in the workflow container has a value.
>>
>> Some Hints:
>> At about exactly the same time, we underwent a complete overhaul of our
> user
>> authorization scheme.  Additionally, the send mail task (for some
> strange
>> reason) is not a background task, although there is no user interface.
>>
>> ----------------------------
>> It seems to me that our authorization project has somehow caused this
>> binding to break in most (but not all) instances, but up to this point,
> I
>> did not think that user auths had any effect on workflow -> task
> bindings,
>> even if the step is not background.  Am I wrong to assume this?
>>
>> Any help or hints would be appreciated.  Thx.
>>
>>
>> Michael McLey
>> MBUSI - IT Parts & Administration
>> Mercedes-Benz US International, Inc.
>> 1 Mercedes Drive
>> Vance, AL 35490
>> PHONE:  (205) 462 - 5239
>> EMAIL:   michael.mcley at daimler.com
>> If you are not the intended addressee, please inform us immediately that
> you
>> have received this e-mail in error, and delete it. We thank you for your
>> cooperation.
>>
>> _______________________________________________
>> 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
>
>
> If you are not the intended addressee, please inform us immediately that
> you have received this e-mail in error, and delete it. We thank you for
> your cooperation.
>
> _______________________________________________
> 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
>
>
>
> If you are not the intended addressee, please inform us immediately that
> you have received this e-mail in error, and delete it. We thank you for
> your cooperation.  _______________________________________________
> SAP-WUG mailing list
> SAP-WUG at mit.edu
> http://mailman.mit.edu/mailman/listinfo/sap-wug
>