<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">
Rick,
<div><br>
</div>
<div>Agents are assigned via a custom role function module. The workflow passes the name of the approval station to the role function module via AC_CONTAINER. Each station name is associated with a particular position within a custom table. The agents associated
with that position are returned to workflow from the role function module in ACTOR_TAB.</div>
<div><br>
</div>
<div>Carolyn <br>
<div>
<div>On Oct 29, 2013, at 3:43 PM, Rick Bakker <<a href="mailto:rbakker@gmail.com">rbakker@gmail.com</a>> wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">Hi Carolyn,<br>
<br>
Good to hear. Could you tell me though, how are the agents determined in these steps?<br>
<br>
Regards<br>
Rick<br>
<br>
On Wednesday, October 30, 2013, Carolyn A Fuller <<a href="mailto:fuller@mit.edu">fuller@mit.edu</a>> wrote:<br>
> Mike,<br>
><br>
> I have discovered it is only a problem in our development environment.<br>
><br>
> I tried to replicate the issue in the EHP7 staging environment that we would open to SAP and I couldn't reproduce it. The workflow successfully showed up in the new approver's inbox after I ran SWU_OBUF.<br>
><br>
> So I need to explore with our Basis team what the differences are between our staging and development environments.<br>
><br>
> Thank you everyone for your help. I have learned a lot.<br>
><br>
> Carolyn<br>
><br>
> On Oct 29, 2013, at 1:50 PM, Mike Pokraka <<a href="mailto:wug@workflowconnections.com">wug@workflowconnections.com</a>><br>
> wrote:<br>
><br>
>> Hi Carolyn,<br>
>><br>
>> If you can reliably reproduce it then I would suggest it needs to be<br>
>> logged with SAP. I'd be interested in the outcome.<br>
>><br>
>> Regards,<br>
>> Mike<br>
>><br>
>><br>
>> On Tue, October 29, 2013 3:27 pm, Carolyn A Fuller wrote:<br>
>>> Rick,<br>
>>><br>
>>> In the email below I meant to say I ran SWI5 not SWIA after SWU_OBUF. So<br>
>>> the answer to your question is no, the work items were not appearing in<br>
>>> the new approvers inbox until after I ran SWI1_RULE for each work item.<br>
>>><br>
>>> We just upgraded this environment to EHP7 from EHP6.<br>
>>><br>
>>> In EHP6, I can do the following successfully:<br>
>>><br>
>>> 1- Add new approver to an inbox<br>
>>> 2- Run SWU_OBUF<br>
>>> 3- Immediately create a transaction that triggers workflow that goes into<br>
>>> the inbox in question<br>
>>> 4- It is in the new approver's inbox<br>
>>><br>
>>> In EHP6, I follow the first 3 steps above but the workflow item it is not<br>
>>> in the new approver's inbox until I run SWI1_RULE on the workflow item.<br>
>>><br>
>>> Carolyn<br>
>>><br>
>>> On Oct 29, 2013, at 9:09 AM, Rick Bakker<br>
>>> <<a href="mailto:rbakker@gmail.com">rbakker@gmail.com</a><mailto:<a href="mailto:rbakker@gmail.com">rbakker@gmail.com</a>>> wrote:<br>
>>><br>
>>> Hi Carolyn,<br>
>>><br>
>>> Your situation sounds very wrong. What sort of inbox are the users using?<br>
>>> Is it a case of the UWL not being refreshed?<br>
>>><br>
>>> If you look in SWI5, is the work item being assigned to the user<br>
>>> immediately?<br>
>>><br>
>>> Regards<br>
>>> Rick Bakker<br>
>>><br>
>>> On Tuesday, October 29, 2013, Carolyn A Fuller<br>
>>> <<a href="mailto:fuller@mit.edu">fuller@mit.edu</a><mailto:<a href="mailto:fuller@mit.edu">fuller@mit.edu</a>>> wrote:<br>
>>>> Mile,<br>
>>>><br>
>>>> When we first noticed this behavior, one of the other workflow<br>
>>>> administrators set up 2 test IDs as approvers and ran SWU_OBUF. The<br>
>>>> tester who owned those 2 test IDs went back to her desk and 45 minutes<br>
>>>> later she created a transaction under one ID that triggered the workflow<br>
>>>> that should have appeared in the inbox of the other ID. It did not.<br>
>>>> Several hours later she created an identical transaction which triggered<br>
>>>> the same workflow and it did appear in the inbox of her second ID.<br>
>>>><br>
>>>> Last night after I set up another approver in that inbox, ran SWU_OBUF<br>
>>>> and SWIA, the new approver had all the workflows from April in his inbox<br>
>>>> but none of the workflows that were created yesterday. It was not until<br>
>>>> I had run SWI1_RULE on each of the workflows created yesterday that they<br>
>>>> appeared in his inbox.<br>
>>>><br>
>>>> This upgrade is the first time we are noticing this behavior. Before the<br>
>>>> 2012 upgrade I never got any complaints. This past year, after the 2012<br>
>>>> upgrade, I got possibly 3 complaints that workflows were not appearing<br>
>>>> in a new approver's inbox but these workflows were from transactions<br>
>>>> created prior to the person being set up as an approver. Since we have<br>
>>>> more than 1 approver per position, it was easy to dismiss these 3<br>
>>>> complaints.<br>
>>>><br>
>>>> This behavior from the 2013 upgrade, will not so easily be dismissed. I<br>
>>>> don't know whether our MIT community will tolerate being asked to send a<br>
>>>> list of each missing transaction so that we can run SWI1_RULE against<br>
>>>> them. By the way, we have to have a list of transactions because of the<br>
>>>> multiple people per position. We have no positions with no active<br>
>>>> agents.<br>
>>>><br>
>>>> Carolyn<br>
>>>><br>
>>>> On Oct 29, 2013, at 6:05 AM, "Mike Pokraka"<br>
>>>> <<a href="mailto:wug@workflowconnections.com">wug@workflowconnections.com</a><mailto:<a href="mailto:wug@workflowconnections.com">wug@workflowconnections.com</a>>> wrote:<br>
>>>><br>
>>>>> Hi Carolyn,<br>
>>>>><br>
>>>>> It could also be the testing method. One gotcha is if you use multiple<br>
>>>>> sessions and stay in the same transaction.<br>
>> _______________________________________________<br>
SAP-WUG mailing list<br>
<a href="mailto:SAP-WUG@mit.edu">SAP-WUG@mit.edu</a><br>
http://mailman.mit.edu/mailman/listinfo/sap-wug<br>
</blockquote>
</div>
<br>
<br>
</div>
</body>
</html>