SAP-WUG Digest, Vol 108, Issue 2
Dart, Jocelyn
jocelyn.dart at sap.com
Tue Nov 5 09:22:20 EST 2013
Ok - well that's not so bad, Sai
From: sap-wug-bounces at mit.edu [mailto:sap-wug-bounces at mit.edu] On Behalf Of sai Gopal
Sent: Tuesday, 5 November 2013 4:16 PM
To: sap-wug at mit.edu
Subject: SAP-WUG Digest, Vol 108, Issue 2
Hi Jocelyn,
Thank you very much for your feedback. Actually My basis consultant changed it. and he didn't keep all the programs for flat 2 mins, he decreased the time for all reports by 50 % ( ex: for SWWERRE from 20 mins to 10 mins) . So I afraid that doesn't cause much effect as you told. Please let me know.
And ,mainly I changed the time for running my Condition check report SWWCOND a bit frequently.
Thanks & Regards,
Sai
On Tue, Nov 5, 2013 at 9:49 AM, <sap-wug-request at mit.edu<mailto:sap-wug-request at mit.edu>> wrote:
Send SAP-WUG mailing list submissions to
sap-wug at mit.edu<mailto:sap-wug at mit.edu>
To subscribe or unsubscribe via the World Wide Web, visit
http://mailman.mit.edu/mailman/listinfo/sap-wug
or, via email, send a message with subject or body 'help' to
sap-wug-request at mit.edu<mailto:sap-wug-request at mit.edu>
You can reach the person managing the list at
sap-wug-owner at mit.edu<mailto:sap-wug-owner at mit.edu>
When replying, please edit your Subject line so it is more specific
than "Re: Contents of SAP-WUG digest..."
Today's Topics:
1. RE: SAP-WUG Digest, Vol 107, Issue 37 (Dart, Jocelyn)
---------- Forwarded message ----------
From: "Dart, Jocelyn" <jocelyn.dart at sap.com<mailto:jocelyn.dart at sap.com>>
To: "SAP Workflow Users' Group" <sap-wug at mit.edu<mailto:sap-wug at mit.edu>>
Cc:
Date: Tue, 5 Nov 2013 04:19:08 +0000
Subject: RE: SAP-WUG Digest, Vol 107, Issue 37
Hi Sai,
Be very careful about doing that... it can become a nightmare if you need to copy your client or if anything goes wrong.
Each of these programs has a specific purpose - putting them all on every 2 minutes is mostly likely going to as a minimum clog the background process queue, if not worse.
SWWERRE for instance is by default intended to run every 20 minutes, and as it performs retries of temporary errors, all running it more often is likely to do is to cause more failures more quickly (i.e. temporary errors reach maximum number of retries very quickly).
SWWCLEAR clears the job logs of other jobs, so setting that too frequently just loses your audit trail when things go pear-shaped.
I could go on but suffice to say, I really don't think that approach is a good answer, and in any case none of them act on the organizational structure which is usually the primary cause of buffering issues.
Regards,
Jocelyn
From: sap-wug-bounces at mit.edu<mailto:sap-wug-bounces at mit.edu> [mailto:sap-wug-bounces at mit.edu<mailto:sap-wug-bounces at mit.edu>] On Behalf Of sai Gopal
Sent: Tuesday, 5 November 2013 2:40 PM
To: sap-wug at mit.edu<mailto:sap-wug at mit.edu>
Subject: SAP-WUG Digest, Vol 107, Issue 37
Dear all,
I also faced this problem while adding additional agent for approval. I used SWU_OBUF , but of no immediate result. But as far as I observed, there are few background programs which take time to execute to find any updates in workflow and implement them.
SWWERRE
SWWDHEX
SWWCOND
SWWCLEAR
All I did is change the default time to 2 mins to all of them so that the changes or updates will happen in 2 mins of time span.
Regards,
Sai
SAP Workflow Consultant
Wipro
On Tue, Oct 29, 2013 at 10:53 PM, <sap-wug-request at mit.edu<mailto:sap-wug-request at mit.edu>> wrote:
Send SAP-WUG mailing list submissions to
sap-wug at mit.edu<mailto:sap-wug at mit.edu>
To subscribe or unsubscribe via the World Wide Web, visit
http://mailman.mit.edu/mailman/listinfo/sap-wug
or, via email, send a message with subject or body 'help' to
sap-wug-request at mit.edu<mailto:sap-wug-request at mit.edu>
You can reach the person managing the list at
sap-wug-owner at mit.edu<mailto:sap-wug-owner at mit.edu>
When replying, please edit your Subject line so it is more specific
than "Re: Contents of SAP-WUG digest..."
Today's Topics:
1. RE: SWU_OBUF in EHP7 (Keohan, Susan - 1140 - MITLL)
---------- Forwarded message ----------
From: "Keohan, Susan - 1140 - MITLL" <keohan at ll.mit.edu<mailto:keohan at ll.mit.edu>>
To: "SAP Workflow Users' Group" <sap-wug at mit.edu<mailto:sap-wug at mit.edu>>
Cc:
Date: Tue, 29 Oct 2013 13:22:55 -0400
Subject: RE: SWU_OBUF in EHP7
Hi Carolyn,
Can't you get a list of workitems in process, and use that as input to SWI1_Rule? That should handle everything, I'd think.
It may be time to revisit some of those old WFs.
Sue
From: sap-wug-bounces at mit.edu<mailto:sap-wug-bounces at mit.edu> [mailto:sap-wug-bounces at mit.edu<mailto:sap-wug-bounces at mit.edu>] On Behalf Of Carolyn A Fuller
Sent: Tuesday, October 29, 2013 11:28 AM
To: SAP Workflow Users' Group
Cc: Workflow Administrators
Subject: Re: SWU_OBUF in EHP7
Rick,
In the email below I meant to say I ran SWI5 not SWIA after SWU_OBUF. So the answer to your question is no, the work items were not appearing in the new approvers inbox until after I ran SWI1_RULE for each work item.
We just upgraded this environment to EHP7 from EHP6.
In EHP6, I can do the following successfully:
1- Add new approver to an inbox
2- Run SWU_OBUF
3- Immediately create a transaction that triggers workflow that goes into the inbox in question
4- It is in the new approver's inbox
In EHP6, I follow the first 3 steps above but the workflow item it is not in the new approver's inbox until I run SWI1_RULE on the workflow item.
Carolyn
On Oct 29, 2013, at 9:09 AM, Rick Bakker <rbakker at gmail.com<mailto:rbakker at gmail.com>> wrote:
Hi Carolyn,
Your situation sounds very wrong. What sort of inbox are the users using? Is it a case of the UWL not being refreshed?
If you look in SWI5, is the work item being assigned to the user immediately?
Regards
Rick Bakker
On Tuesday, October 29, 2013, Carolyn A Fuller <fuller at mit.edu<mailto:fuller at mit.edu>> wrote:
> Mile,
>
> When we first noticed this behavior, one of the other workflow administrators set up 2 test IDs as approvers and ran SWU_OBUF. The tester who owned those 2 test IDs went back to her desk and 45 minutes later she created a transaction under one ID that triggered the workflow that should have appeared in the inbox of the other ID. It did not. Several hours later she created an identical transaction which triggered the same workflow and it did appear in the inbox of her second ID.
>
> Last night after I set up another approver in that inbox, ran SWU_OBUF and SWIA, the new approver had all the workflows from April in his inbox but none of the workflows that were created yesterday. It was not until I had run SWI1_RULE on each of the workflows created yesterday that they appeared in his inbox.
>
> This upgrade is the first time we are noticing this behavior. Before the 2012 upgrade I never got any complaints. This past year, after the 2012 upgrade, I got possibly 3 complaints that workflows were not appearing in a new approver's inbox but these workflows were from transactions created prior to the person being set up as an approver. Since we have more than 1 approver per position, it was easy to dismiss these 3 complaints.
>
> This behavior from the 2013 upgrade, will not so easily be dismissed. I don't know whether our MIT community will tolerate being asked to send a list of each missing transaction so that we can run SWI1_RULE against them. By the way, we have to have a list of transactions because of the multiple people per position. We have no positions with no active agents.
>
> Carolyn
>
> On Oct 29, 2013, at 6:05 AM, "Mike Pokraka" <wug at workflowconnections.com<mailto:wug at workflowconnections.com>> wrote:
>
>> Hi Carolyn,
>>
>> It could also be the testing method. One gotcha is if you use multiple
>> sessions and stay in the same transaction.
>> e.g. one SAP window in transaction XYZ, one session in the org chart.
>> Change the org chart, SWU_OBUF, but if you don't leave XYZ, that session
>> will still keep the old data buffered. You then start a new WF from there,
>> and - even though the rest of the SAP system has been refreshed - it will
>> continue to use the old snapshot from when you first launched the
>> transaction.
>>
>> Regards,
>> Mike
>>
>>
>> On Tue, October 29, 2013 12:00 am, Carolyn A Fuller wrote:
>>> Jocelyn,
>>>
>>> I ran SWI1_RULE for the missing workflow item and executed Agent rules and
>>> the item appears in the approver's inbox.
>>>
>>> Thank you,
>>>
>>> Carolyn
>>> On Oct 28, 2013, at 7:12 PM, "Dart, Jocelyn" <jocelyn.dart at sap.com<mailto:jocelyn.dart at sap.com>>
>>> wrote:
>>>
>>>> Hi Carolyn,
>>>> If the buffer wasnâ?Tt refreshed at the time you created the transaction
>>>> in step 2 it might not automatically reassign itself if there were no
>>>> selected agents at the time.
>>>> What you can use for such situations is transaction SWI1_RULE which will
>>>> do this for you assuming the rule that finds the position is directly
>>>> associated with the workflow step itself. That will let you find any
>>>> work items without agent and then re-execute the rule to assign them, or
>>>> even use an administrator forward to redirect them while you sort out
>>>> organizational structure problems.
>>>>
>>>> You should also check that the new approver is not an excluded agent â?"
>>>> as of course then she would never be assigned to that work item.
>>>>
>>>> SWU_OBUF was always a fairly crude measure for updating buffers.
>>>> Thatâ?Ts why the additional admin tools (all the SWI1* and SWI2*
>>>> transactions) were added several years ago. Itâ?Ts worth getting
>>>> familiar with them.
>>>> Rgds,
>>>> Jocelyn
>>>>
>>>> From: sap-wug-bounces at MIT.EDU<mailto:sap-wug-bounces at MIT.EDU> [mailto:sap-wug-bounces at MIT.EDU<mailto:sap-wug-bounces at MIT.EDU>] On Behalf
>>>> Of Carolyn A Fuller
>>>> Sent: Tuesday, 29 October 2013 7:43 AM
>>>> To: SAP Workflow Users' Group
>>>> Cc: Workflow Administrators; Frank Quern
>>>> Subject: Re: SWU_OBUF in EHP7
>>>>
>>>> Ionut,
>>>>
>>>> I tested the Refresh Organizational Environment today and discovered
>>>> strange behavior under EHP7 Release 740 SP-Level 0003.
>>>>
>>>> 1. I added someone to the approver's position
>>>> 2. I created a transaction that triggered workflow that went to this
>>>> position's inbox
>>>> 3. I ran SWIA for the new approver and found workflows created on
>>>> 04/08/2013 in her inbox but not the workflow I had just triggered
>>>> 4. This new approver logged into the environment and went to her inbox.
>>>> None of the workflows were there even though she just logged in.
>>>> 5. She chose -> Settings -> Workflow Settings -> Refresh Organizational
>>>> Environment in the Business Workplace
>>>> 6. The workflows created on 04/08/2013 were in her inbox but the one
>>>> workflow that I triggered a few moments after adding her to the position
>>>> was not there.
>>>> 7. I created a new transaction about 50 minutes after adding her to the
>>>> inbox and it did show up in her inbox but the one created moments after
>>>> she was added to the position never showed up.
>>>>
>>>> Is there another method for refreshing the PDOrg that works reliably?
>>>>
>>>> Carolyn
>>>>
>>>> On Oct 28, 2013, at 7:03 AM, "Andronache, Ionut-Laurentiu"
>>>> <ionut-laurentiu.andronache at sap.com<mailto:ionut-laurentiu.andronache at sap.com>> wrote:
>>>>
>>>>
>>>> Hi Carolyn,
>>>>
>>>> From my experience SWU_OBUF is used for WFs objects (also tasks, rules,
>>>> etc) modifications. To get a refresh to the OM changes you can refresh
>>>> OM from Business Workplace -> Settings -> Workflow Settings -> Refresh
>>>> Organizational Environment (this way you should get the result that you
>>>> are looking for immediately).
>>>>
>>>>
>>>>
>>>> Ionut Andronache
>>>>
>>>> SAP ABAP Senior Consultant, SAP Romania
>>>> Specializations: SAP Workflow Consultant
>>>> SAP ABAP HCM Consultant
>>>> SAP WebDynpro/ FPM Consultant
>>>>
>>>> SAP Romania SRL
>>>> Str. Tipografilor 11-15, ClÄfdirea A1 /LA, Etajul 2, 013714,1 BucureÅYti
>>>> T + 40/ 31 225 28 73, F + 40/ 31 228 59 09, M +40/ 755 094 478
>>>> mailto:ionut-laurentiu.andronache at sap.com<mailto:ionut-laurentiu.andronache at sap.com>
>>>> www.sap.com<http://www.sap.com/>
>>>> Before printing, think about the environment
>>>> Informatia continuta in acest comunicat este confidentiala, poate fi
>>>> privilegiata si a fost conceputa spre a fi utilizata exclusiv de catre
>>>> destinatarul mentionat mai sus. In cazul in care primiti acest comunicat
>>>> din eroare, va rugam sa anuntati imediat expeditorul si sa-l stergeti,
>>>> impreuna cu toate documentele atasate. Daca nu sunteti destinatarul
>>>> caruia ii este adresat acest comunicat, va este interzisa citirea,
>>>> copierea, difuzarea sau folosirea in orice fel a oricarei informatii din
>>>> acesta fara consimtamantul dat de catre SAP Romania. Va rugam luati nota
>>>> de faptul ca email-urile nu garanteaza nici confidentialitatea si nici
>>>> receptia corecta a mesajului trimis, prin urmare SAP Romania nu se face
>>>> responsabila de nici un prejudiciu cauzat.
>>>> The information contained in this communication is confidential, may be
>>>> privileged and is intended for the exclusive use of the above named
>>>> addressee. If you receive this communication in error, please notify the
>>>> sender immediately and delete it, and all its attached documents. If you
>>>> are not the intended recipient, you are expressly prohibited from
>>>> reading, copying, distributing, disseminating or, in any other way,
>>>> using any of the information without the SAP Romania consent. Please
>>>> note that Internet e-mail guarantees neither the confidentiality nor the
>>>> proper receipt of the message sent, so that SAP Romania shall not be
>>>> liable for any damages caused.
>>>>
>>>>
>>>>
>>>> From: sap-wug-bounces at MIT.EDU<mailto:sap-wug-bounces at MIT.EDU> [mailto:sap-wug-bounces at MIT.EDU<mailto:sap-wug-bounces at MIT.EDU>] On Behalf
>>>> Of Carolyn A Fuller
>>>> Sent: 25 October 2013 22:32
>>>> To: SAP Workflow Users' Group
>>>> Cc: Workflow Administrators
>>>> Subject: SWU_OBUF in EHP7
>>>>
>>>> Hi,
>>>>
>>>> We are in the process of upgrading to EHP7 Release 740 SP-Level 0003.
>>>> This morning one of the workflow administrators added someone to one of
>>>> our approver positions, back dating the relationship and then ran
>>>> SWU_OBUF to refresh the PD Org buffers.
>>>>
>>>> Some pre-existing transactions appeared in this person's inbox after
>>>> that but not all of them. And 50 minutes after she was added to the
>>>> position, a document was created and sent to her position but did not
>>>> appear in her inbox. A couple of hours later she repeated the test and
>>>> it did appear in her inbox.
>>>>
>>>> Shouldn't SWU_OBUF have ensured that the transaction created 50 minutes
>>>> later would have appeared in her inbox? Is there workflow buffer a
>>>> problem with EHP7?
>>>>
>>>> ---
>>>> Carolyn Fuller
>>>> Senior Analyst/ Programmer
>>>> Information Services and Technology
>>>> Massachusetts Institute of Technology
>>>> Room W92-215A
>>>> Cambridge, MA 02139
>>>> (617) 253-6213
>>>> http://fuller.mit.edu/
>>>>
>>>> _______________________________________________
>>>> SAP-WUG mailing list
>>>> SAP-WUG at mit.edu<mailto:SAP-WUG at mit.edu>
>>>> http://mailman.mit.edu/mailman/listinfo/sap-wug
>>>>
>>>>
>>>> _______________________________________________
>>>> SAP-WUG mailing list
>>>> SAP-WUG at mit.edu<mailto:SAP-WUG at mit.edu>
>>>> http://mailman.mit.edu/mailman/listinfo/sap-wug
>>>
>>>
>>> ---------------------
>>> Carolyn Fuller
>>> < _______________________________________________
SAP-WUG mailing list
SAP-WUG at mit.edu<mailto:SAP-WUG at mit.edu>
http://mailman.mit.edu/mailman/listinfo/sap-wug
_______________________________________________
SAP-WUG mailing list
SAP-WUG at mit.edu<mailto:SAP-WUG at mit.edu>
http://mailman.mit.edu/mailman/listinfo/sap-wug
_______________________________________________
SAP-WUG mailing list
SAP-WUG at mit.edu<mailto:SAP-WUG at mit.edu>
http://mailman.mit.edu/mailman/listinfo/sap-wug
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/pipermail/sap-wug/attachments/20131105/6a2922a8/attachment-0001.htm
More information about the SAP-WUG
mailing list