ECC 6.0 Upgrade Question
Shai Eyal
shai.eyal at yahoo.com
Thu Feb 22 03:13:38 EST 2007
Yes.
There's a standard report to do so - let me know if you can't find it and I'll look for it & send it to you.
Regards,
Shai Eyal
SAP Logistics consultant
SAP Workflow specialist
Mobile: 972-52-5816633
----- Original Message ----
From: "sap-wug-request at mit.edu" <sap-wug-request at mit.edu>
To: sap-wug at mit.edu
Sent: Wednesday, 21 February, 2007 12:03:36 PM
Subject: SAP-WUG Digest, Vol 27, Issue 46
Send SAP-WUG mailing list submissions to
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
You can reach the person managing the list at
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. ECC 6.0 Upgrade Question (workflow at insightbb.com)
2. RE: ECC 6.0 Upgrade Question (Munday,Sherie J.)
3. Re: ECC 6.0 Upgrade Question (Shalini Sabnani)
4. Re: Upgrade for ECC 6.0 (Paul.Bakker at osr.treasury.qld.gov.au)
5. Deadline setting (Guenther, Annegret)
6. Re: Parallel processing of Workflow Deadline Monitoing in
4.6C (Mike Gambier)
----------------------------------------------------------------------
Message: 1
Date: Tue, 20 Feb 2007 12:22:22 -0500
From: workflow at insightbb.com
Subject: ECC 6.0 Upgrade Question
To: sap-wug at mit.edu
Message-ID: <f64987e517e7a.45dae7fe at insightbb.com>
Content-Type: text/plain; charset="us-ascii"
To All:
Has anyone been involved in an ECC 6.0 Upgrade? If yes, was it necessary to convert all related ABAP for methods to unicode?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/pipermail/sap-wug/attachments/20070220/c99bf563/attachment-0001.htm
------------------------------
Message: 2
Date: Tue, 20 Feb 2007 13:34:41 -0500
From: "Munday,Sherie J." <MUNDAYSJ at airproducts.com>
Subject: RE: ECC 6.0 Upgrade Question
To: "SAP Workflow Users' Group" <sap-wug at mit.edu>
Message-ID:
<B3D052C7FA25934B94BA33FC2080CA16D11A21 at us0355exmp.america.apci.com>
Content-Type: text/plain; charset="us-ascii"
We did not upgrade to unicode with our technical ECC6.0 upgrade. We are
however upgrading now to unicode in conjunction with our Asia language
project.
Best Wishes,
Sherie
Sherie Munday
Workflow Developer/ Analyst
Air Products & Chemicals, Inc.
________________________________
From: sap-wug-bounces at mit.edu [mailto:sap-wug-bounces at mit.edu] On Behalf
Of workflow at insightbb.com
Sent: Tuesday, February 20, 2007 12:22 PM
To: sap-wug at mit.edu
Subject: ECC 6.0 Upgrade Question
To All:
Has anyone been involved in an ECC 6.0 Upgrade? If yes, was it necessary
to convert all related ABAP for methods to unicode?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/pipermail/sap-wug/attachments/20070220/9d4c6bdc/attachment-0001.htm
------------------------------
Message: 3
Date: Tue, 20 Feb 2007 13:57:56 -0500
From: "Shalini Sabnani" <workflow.mail at gmail.com>
Subject: Re: ECC 6.0 Upgrade Question
To: "SAP Workflow Users' Group" <sap-wug at mit.edu>
Message-ID:
<53c024f70702201057q63de0738ocfae06a851a5ad38 at mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
We were required to be Unicode compliant but since we only use Englinsh and
French for the Client we did not convert out ABAP code to Unicode.
Hope this helps
Shalini
On 2/20/07, workflow at insightbb.com <workflow at insightbb.com> wrote:
>
> To All:
>
> Has anyone been involved in an ECC 6.0 Upgrade? If yes, was it necessary
> to convert all related ABAP for methods to unicode?
>
> _______________________________________________
> SAP-WUG mailing list
> 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/20070220/a8b749a3/attachment-0001.htm
------------------------------
Message: 4
Date: Wed, 21 Feb 2007 09:15:06 +1000
From: Paul.Bakker at osr.treasury.qld.gov.au
Subject: Re: Upgrade for ECC 6.0
To: SAP-WUG at mit.edu
Cc: "Levy, Greg" <greg_levy at cinfin.com>
Message-ID:
<OFCC7C7D12.62FA753E-ON4A257288.007DA266-4A257288.007FB6B7 at treasury.qld.gov.au>
Content-Type: text/plain; charset="us-ascii"
Greg / WUGgers,
Our upgrade from 46C to ECC6.0 went surprisingly smoothly - for both
standard and custom workflows. The only issues we encountered were the
following:
Problem: 'Old' workitems (created before the upgrade) can trigger a "Error
at point of synchronization" when they are processed
Solution: Implement OSS note 991585 before users are allowed onto the
system
Problem: Workorder workflows were not being triggered
Solution: the BADI 'WORKORDER_UPDATE' required manual adjustment and
reactivation.
Note: There is a new 'enhancement point' concept for BADIs.
Problem: workflows that use the obsolete BOR object 'ABSENCE' no longer
work
Solution: Implement OSS note 731260
Problem: a workflow doesn't trigger because a (custom) function group has a
syntax error.
ECC60 complains that executable statements in the TOP INCLUDE are 'NOT
ACCESSIBLE'.
Solution: Improve the custom code
Note: It seems that some syntax issues that were considered 'warnings' in
46C are now 'errors' in 60.
Problem: the new workflow log is hard to use
Solution: you can still revert back to the old one!
I'm sure there may be more - does anyone else have some war stories to
share?
cheers
Paul B
|---------+---------------------------->
| | "Levy, Greg" |
| | <Greg_Levy at CINFIN|
| | .com> |
| | |
| | 21/02/2007 04:17 |
| | |
|---------+---------------------------->
>--------------------------------------------------------------------------------------------------------------------------|
| |
| To: <paul.bakker at osr.treasury.qld.gov.au> |
| cc: "Neumann, Marcia" <Marcia_Neumann at CINFIN.com> |
| Subject: Upgrade for ECC 6.0 |
>--------------------------------------------------------------------------------------------------------------------------|
Paul,
Read your email about applying OSS note 991585 after upgrading to ECC 6.0.
Thanks for that info. Also, did you have any existing custom workflows that
you had to deal with after the upgrade? Did you experience any other issues
with either new or old workflows after the upgrade?
Thanks!
Gregory Levy
SAP Senior Technical Consultant
The G Levy Group, Inc
O 513 870-2300 X-4298
C 502 386-4788
******************************************************************************************************************************************************
Only an individual or entity who is intended to be a recipient of this e-mail may access or use the information contained in this e-mail or any of its attachments. Opinions contained in this e-mail or any of its attachments do not necessarily reflect the opinions of Queensland Treasury.
The contents of this e-mail and any attachments are confidential and may be legally privileged and the subject of copyright. If you have received this e-mail in error, please notify Queensland Treasury immediately and erase all copies of the e-mail and the attachments. Queensland Treasury uses virus scanning software. However, it is not liable for viruses present in this e-mail or in any attachment.
******************************************************************************************************************************************************
------------------------------
Message: 5
Date: Wed, 21 Feb 2007 11:01:30 +0100
From: "Guenther, Annegret" <annegret.guenther at eds.com>
Subject: Deadline setting
To: "SAP Workflow Users' Group" <sap-wug at mit.edu>
Message-ID:
<94CEEA0AE0E18B47BAF07AABFD8976BA2EE64B at derum200.emea.corp.eds.com>
Content-Type: text/plain; charset="iso-8859-1"
Hi,
Hope anyone can help me. My costumer would like that the deadline handling will start after 2 working days. But in the Workflow customizing I can only select days and other stuff. Has anyone experiences with this and can give me an advice??
Thanks in advance!!
Best regards
Anne G?nther
Phone: +49(0)3461 814 138
Fax: +49(0)3461 814 202
e-mail: annegret.guenther at eds.com
------------------------------
Message: 6
Date: Wed, 21 Feb 2007 10:03:21 +0000
From: "Mike Gambier" <madgambler at hotmail.com>
Subject: Re: Parallel processing of Workflow Deadline Monitoing in
4.6C
To: sap-wug at mit.edu
Message-ID: <BAY117-F707A26743CAC4F4C80FECD5880 at phx.gbl>
Content-Type: text/plain; format=flowed
Hi all,
Well SAP's Oracle DBA, Stefan Kuhlmann (thanks Stefan if you're reading
this!), worked his magic on our Workflow data on Sunday. In just over five
and a half hours our live Production tables for Workflow were trimmed right
down to 200Gb from just over 1.6Tb.
I don't know the figures for the indexes and how much space we clawed back
from them, but overall everyone seems to be happy. Our previous run on a
snapshot of Production showed a 2Tb gain in total so I suspect we were
pretty close to that overall.
To give you an idea of what we were up against here are some table sizes and
record counts from tables you'll probably all know:
Table Size (Kb) Rows
SRRELROLES 16,588,160
SWEINSTCOU 1,330,176 9,212,962
SWELOG 1,114,112 6,376,382
SWELTS 303,104
SWEQUEUE 293,824
SWPNODELOG 71,023,616 502,301,486
SWPSTEPLOG 140,800,000 395,628,934
SWP_ADM_US 1,918,976
SWP_HEADER 8,227,840
SWP_JOIN 4,669,440
SWP_NODEWI 25,812,992
SWWBINDEF 129,307,264 1,251,610,755
SWWEI 2,655,232
SWWLOGHIST 90,001,408
SWWORGTASK 434,176
SWWRUNMETH 27,454,464
SWWSWPRET 13,524,992
SWWUSERWI 37,192,960 653,628,051
SWWWIDEADL 14,109,696
SWWWIHEAD 174,683,584 421031224
SWWWIRET 37,329,536
SWW_CONT 125,770,880 1,834,208,289
SWW_CONTOB 92,498,944 955,142,364
I don't recall ever seeing a single table with 1.8 BILLION records before!
^^
Apparently these tables alone when combined are much larger than some entire
systems that SAP normally work with.
We now have just over 70 MILLION entries in SWWWIHEAD (only!) and things are
running much more smoothly.
No problems yet reported.
MGT
>From: "Mike Gambier" <madgambler at hotmail.com>
>Reply-To: "SAP Workflow Users' Group" <sap-wug at mit.edu>
>To: sap-wug at mit.edu
>Subject: Re: Parallel processing of Workflow Deadline Monitoing in 4.6C
>Date: Tue, 06 Feb 2007 09:44:49 +0000
>
>Hi all,
>
>Progress update on our open heart surgery for Worklflow : )
>
>SAP's Oracle DBA people got hold of a snapshot of our system over the
>weekend, copied the 25 Workflow tables they wanted to hack to pieces and
>proceeded to slice and dice all Workflow entries where the parent WF had
>terminated.
>
>They then swapped the new copies of the tables with the system down,
>renaming the original ones as a backup, and brought the system back up.
>
>The whole procedure took about 7 hours and our WF tablespaces dropped from
>2 Terabytes to 560 Megabytes at a stroke.
>
>We are currently running integrity tests to see if anything has been broken
>but so far so good.
>
>Considering our estimates show that we would have to run archiving
>agressively for 6 months to achieve the same result, this seems like an
>acceptable alternative.
>
>The current plan is to do this for real in Production some time soon.
>
>We're still not sure if our current archiving strategy can keep tabs with
>our net growth though, perhaps we'll have a better idea when we reduce the
>overall size of our WF tables.
>
>MGT
>
>>From: Susan Keohan <keohan at ll.mit.edu>
>>Reply-To: "SAP Workflow Users' Group" <sap-wug at mit.edu>
>>To: "SAP Workflow Users' Group" <sap-wug at mit.edu>
>>Subject: Re: Parallel processing of Workflow Deadline Monitoing in 4.6C
>>Date: Wed, 24 Jan 2007 06:35:08 -0500
>>
>>Hi Mike,
>>
>>Thanks for the update.... Please keep us posted.
>>
>>I am dealing with WF Table sizes and access time as well, but not on the
>>scale that you describe. We have not yet implemented archiving on our
>>workitems, but our SRM 5.0 system spends a *lot* of time accessing
>>SWWWIHEAD in certain business objects (Bids, BUS2200).
>>
>>Still, I might learn a lesson from your experience.
>>
>>Mike Gambier wrote:
>> > Hi,
>> >
>> > For anyone who was interested we have implemented the RFC Q option 2 on
>> > my previous mail and things look to be working well.
>> >
>> > We have on average 60,000 RFC entries in ARFCSSTATE for our 'new'
>> > WORKFLOW_DEADLINE_100 queue and our version of SWWDHEX is churning
>> > thorugh our deadlines pretty well. Load balancing seems to be working
>>as
>> > well as it can with WF-BATCH dominating 2 dedicated servers most of the
>> > time. Our 'normal' event RFCs seem to be stable too which is good news.
>> >
>> > Now for our next problem to tackle: we have 2 terabytes (!!) of data in
>> > our Workflow tables and only need about 300 gig of it to remain
>>availablle.
>> >
>> > We've been trying to get rid of our Workflow data using the SAP
>> > archiving objects but our net growth rate is such that we can only seem
>> > to keep up with new data coming in.
>> >
>> > SAP have suggested a radical 'heart surgery' approach involving an
>> > Oracle DBA getting his/her hands dirty to clone the 25 WF tables, slice
>> > and dice them and then reinstate the trimmed versions back in the
>> > system. All a bit scary to be honest...
>> >
>> > Will post the results here as to how we progress as someone else might
>> > find this useful.
>> >
>> > MGT
>> >
>> >> From: "Mike Gambier" <madgambler at hotmail.com>
>> >> Reply-To: "SAP Workflow Users' Group" <sap-wug at mit.edu>
>> >> To: sap-wug at mit.edu
>> >> Subject: Parallel processing of Workflow Deadline Monitoing in 4.6C
>> >> Date: Fri, 24 Nov 2006 16:11:53 +0000
>> >>
>> >> Hello fellow WUGgers,
>> >>
>> >> We are faced with a bit of a new dilemma regarding WF Deadlines and
>> >> seem to
>> >> be faced with some difficult choices.
>> >>
>> >> Our old dilemma was this: we used to run RSWWDHEX every 15 minutes to
>> >> pick
>> >> up our steps that had passed their deadline entries (SWWWIDH /
>> >> SWWWIDEADL)
>> >> until this started to time out during the SELECT statement pulled too
>> >> many
>> >> entries back (simply because we have so many Workflows running). We
>> >> also had
>> >> an issue with the standard program respawning itself whilst its
>> >> predecessor
>> >> job was still running which caused us a bit of grief. This last bit
>> >> has been
>> >> resolved since we hear in later SAP versions.
>> >>
>> >> So, to fix these issues we cloned the program and built in a MAX HITS
>> >> parameter to reduce the number of deadlines it processed per run and
>> >> added a
>> >> self-terminate subroutine to ensure no two jobs ran concurrently.
>> >>
>> >> But, even after these changes we are faced with a NEW dilemma with WF
>> >> Deadline Monitoring. Namely it has a nasty habit of loading up
>>whatever
>> >> server the job is run on to progress the deadline! This manifests
>> >> itself in
>> >> dailog process 'hogging' or excessive local tRFC entries in ARFCSSTATE
>> >> where
>> >> it can't get hold of a dialog process to use on that particular server
>> >> (which can happen a lot if we have other heavy jobs running there).
>> >> The load
>> >> then shifts to RSARFCEX which then struggles with the load as
>> >> everything is
>> >> processed locally on whatever server it is run on.
>> >>
>> >> Unlike the Event Queue there is no standard ready made Parallel
>> >> processing
>> >> option for Deadlines that we know of, at least not in 4.6C. So we're
>> >> thinking of choosing one of these options:
>> >>
>> >> 1. Amend our Deadline Monitoring program (will require a mod to SAP
>> >> code as
>> >> well) to redirect the first RFC with a new custom destination that can
>>be
>> >> processed seperately to 'normal' Workflow tRFCs, e.g.
>>'WORKFLOW_DL_0100'
>> >> instead of 'WORKFLOW_LOCAL_0100'. The new destination would be set up
>>to
>> >> point to a completely different server than the one the Deadline
>> >> Monitor job
>> >> is currently running on. This won't diminish the load on the server
>>where
>> >> dialog processes are available but at least it will shift the load on
>> >> RSARFCEX when it runs. Obviously we would have to schedule a new run
>>for
>> >> RSARCFEX with this new destination into our schedule.
>> >>
>> >> 2. Same as 1 (mod required) but the new destination will point to a
>> >> server
>> >> group destination (rather than a single server) to spread the load
>>across
>> >> mutltiple servers when the tRFCs are converted into qRFCs. Has the
>>added
>> >> benefit of reusing the qRFC queue (and its standard config settings
>>and
>> >> transactions) to buffer the start of each new deadline being
>> >> processed. Once
>> >> a deadline step is executed, any tRFCs that result will be appended as
>> >> WORKFLOW_LOCAL_0100 as normal because they will result from subsequent
>> >> calls
>> >> that will not affected by our mod setting. End result should be the
>> >> START of
>> >> each deadline process chain is distributed across multiple servers
>>(and
>> >> therefore will spread the demand for dialog processes accordingly),
>> >> but any
>> >> tRFCs that result will end up being chucked back into the 'local' pot.
>> >> Unfortunately this would mean that our version of SWWDHEX would pass
>>the
>> >> baton on to RSQOWKEX (the outbound queue batch job) to actually
>> >> progress the
>> >> deadline, i.e do any real work. We would therefore have two batch jobs
>>to
>> >> watch and have a noticeable delay between deadlines being selected and
>> >> deadlines actually being progressed. Whether we can live with this we
>> >> just
>> >> don't know. The issue of different deadlines for the same Workflow
>>being
>> >> progressed on different servers is also a concern but since we limit
>>the
>> >> number of deadlines we process per run anyway that is currently
>> >> something we
>> >> suffer from at the moment.
>> >>
>> >> 3. Dynamic destination determination (OSS Note 888279) applied to all
>> >> Workflow steps, not just deadlines. Scary stuff. Breaks the concept of
>>a
>> >> single server 'owning' a deadline process chain in its entirety.
>> >> Considering
>> >> the volumes of Workflow we have, we're uncertain as to what impact
>> >> this will
>> >> have system-wide.
>> >>
>> >> 4. Redesign Deadline Monitoring to use the same persistence approach
>>as
>> >> Event Delivery and have a deadline queue. Complete overhaul using
>> >> SWEQUEUE
>> >> etc as a guide. Would be a lovely project to do but honestly we can't
>> >> really
>> >> justify the database costs, code changes and testing.
>> >>
>> >> We are currently favouring option 2 as a realistic way forward as it
>> >> seems
>> >> to offer the simplest way of shifting the load around to prevent a
>>single
>> >> server from being hammered. It has risks and would require careful
>> >> monitoring or the qRFC queues, but it seems a safer bet than
>>overloading
>> >> another single server (option 1), splitting up a single deadline chain
>> >> across multiple servers (option 3) or costing the earth and becoming
>> >> unsupportable (option 4).
>> >>
>> >> Has anyone out there implemented option 3, the OSS Note? We'd love to
>> >> know...
>> >>
>> >> Or, if you have any alternative suggestions we'd be interested to hear
>> >> them
>> >> :)
>> >>
>> >> Regards,
>> >>
>> >> Mike GT
>> >>
>> >> _________________________________________________________________
>> >> Stay up-to-date with your friends through the Windows Live Spaces
>>friends
>> >> list.
>> >>
>>http://clk.atdmt.com/MSN/go/msnnkwsp0070000001msn/direct/01/?href=http://spaces.live.com/spacesapi.aspx?wx_action=create&wx_url=/friends.aspx&mk
>> >>
>> >>
>> >> _______________________________________________
>> >> SAP-WUG mailing list
>> >> SAP-WUG at mit.edu
>> >> http://mailman.mit.edu/mailman/listinfo/sap-wug
>> >
>> > _________________________________________________________________
>> >> From predictions to trailers, check out the MSN Entertainment Guide to
>> >> the
>> > Academy Awards®
>> > http://movies.msn.com/movies/oscars2007/?icid=ncoscartagline1
>> >
>> >
>> >
>>------------------------------------------------------------------------
>> >
>> > _______________________________________________
>> > SAP-WUG mailing list
>> > SAP-WUG at mit.edu
>> > http://mailman.mit.edu/mailman/listinfo/sap-wug
>>
>>--
>>Susan R. Keohan
>>SAP Workflow Developer
>>MIT Lincoln Laboratory
>>244 Wood Street
>>LI-200
>>Lexington, MA. 02420
>>781-981-3561
>>keohan at ll.mit.edu
>>_______________________________________________
>>SAP-WUG mailing list
>>SAP-WUG at mit.edu
>>http://mailman.mit.edu/mailman/listinfo/sap-wug
>
>_________________________________________________________________
>Turn searches into helpful donations. Make your search count.
>http://click4thecause.live.com/search/charity/default.aspx?source=hmemtagline_donation&FORM=WLMTAG
>
>_______________________________________________
>SAP-WUG mailing list
>SAP-WUG at mit.edu
>http://mailman.mit.edu/mailman/listinfo/sap-wug
_________________________________________________________________
Play Flexicon: the crossword game that feeds your brain. PLAY now for FREE.
http://zone.msn.com/en/flexicon/default.htm?icid=flexicon_hmtagline
------------------------------
_______________________________________________
SAP-WUG mailing list
SAP-WUG at mit.edu
http://mailman.mit.edu/mailman/listinfo/sap-wug
End of SAP-WUG Digest, Vol 27, Issue 46
***************************************
___________________________________________________________
All New Yahoo! Mail – Tired of unwanted email come-ons? Let our SpamGuard protect you. http://uk.docs.yahoo.com/nowyoucan.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/pipermail/sap-wug/attachments/20070222/bbd233d5/attachment.htm
More information about the SAP-WUG
mailing list