Impact of WF Versions on Transports during Upgrade from 4.6 C to ECC 6
Morris, Eddie
eddie.morris at sap.com
Fri Nov 5 06:44:37 EDT 2010
Hi Sandy,
In answer to your questions.
[1] Versions do not have to be the same across all your systems. When you make a change DEV and transport to QAS it will check if there are active work items for that workflow. If there are then it will create a new version so the active work items can complete with the current version and the new work items will use the newly transported version. (Same applies when you transport to PRD).
[2] Pushing users to complete work items before the upgrade is only a suggestion and does not have to completed at all. You should not have many issues with your work items but some points to look out for are:
· Container elements based on table fields that no longer exist. When you try to execute these work items they will go into error. After you upgrade and before your users start executing work items I would suggest you look at note 1058159 and run report RSWDVERCNT. This identifies any issues in your workflow templates and gives you the option to change the container definition. Note 939489 also deals with this issue.
· If you use structures in your workflow definitions/containers and they have been changed (e.g. the index of the fields in the structure moves) then note 910573 can help here. You need to run report RSWF_MIG_CONTAINER_STRUCTS. The note details how and when to use it.
[3] If nothing is imported after transporting initially and you have refreshed the buffers in the target system then it sounds like there was a problem activating the new workflow version in the target system. There are some notes related to this but I guess you will be upgrading to the latest support pack so you should have all of these notes. It can also happen if you have failed to transport a new object to the target system first. E.g. if you create a new task and insert it into your workflow and then transport the workflow to the target system it will not activate because the task does not yet exist in the target system. Please transport all new objects (Tasks, custom reference structures/tables, object attributes/methods) to the target system before you transport the workflow definition.
I hope this helps.
Regards,
Eddie
From: sap-wug-bounces at mit.edu [mailto:sap-wug-bounces at mit.edu] On Behalf Of Sandy
Sent: 05 November 2010 02:38
To: sap-wug at mit.edu
Subject: Impact of WF Versions on Transports during Upgrade from 4.6 C to ECC 6
Thanks a lot Susan & Micheal for your suggestions regarding WF Cutover upgrade activities.
Much appreciated
I have some further queries regarding Impact of WF Versions on Transports during Upgrade from 4.6 C to ECC 6
1. What if changes are made to WF definition in current DEV system and Imported to PRD system, then WF in PRD system would have one version (Plus) higher than the version of the WF definition in Current DEV upgrade system (Since DEV upgrade system is a Copy of PRD system). So when Transports would be imported to PRD from DEV->Quality - >PRD, is there any possibilty of conflict due to difference in Versions? Or transport would simpley overwrite the current version in PRD from one imported from DEV->QAS->. If there is a conflict? How could we resolve it?
2. If the client is not able to push the users to complete all the work item generated from 4.6 C workflow definition before Upgrading the PRD to ECC 6, what could be the impact? I mean ?What sort of errors could be experienced while executing the old Work items in ECC6 environment if there is not much Change in container or definition change.There are about 100 Custom Workflow and heaps of Work items in Client system. I dont think they can actually process all the work items.
3. Also, I have read in many threads that " No changes were imported in QAS from DEV when transports were imported the FIRST time" Then REIMPORTING the transports again second time brought in the changes to QAS. Did anyone knows a reason for this?
Thanks a lot for your valuable suggestions
Regards
Sandy
On 3 November 2010 03:29, <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: Workflow Upgrade 4.6C to ECC6 - manual settings during
Cutover & Version (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>>
Date: Tue, 2 Nov 2010 12:29:01 -0400
Subject: RE: Workflow Upgrade 4.6C to ECC6 - manual settings during Cutover & Version
Hi Michael, Sandy,
Excellent questions, excellent points.
1) I run SWU3 in each environment as it becomes available to schedule the background jobs, assign the WF Admin, etc. Takes less than 10 minutes – should be done in Dev,QA,PRD after the upgrade, when Basis allows you in.
2) Sure, run SWU_Obuf – or wait for the Cinderella Effect (past midnight, everything gets refreshed)
3) I do generate each BOR object after the upgrade as I go from Dev – QA – PRD, after Checking them first!
4) SWUD on each workflow – test environment – Consistency check for components (including subworkflows) should help you sort the wheat from the chaff as well.
5) Agent assignments for General Tasks are transportable, I believe, but my Basis friends let me do it ‘the workflow way’. Then they shut me out.
Michael, I sympathize! I had heard from another organization about WF Train Wrecks – and in our case, we were fortunate that we were able to encourage our users to complete almost all workitems prior to the upgrade. Since we had upgraded from EBP 3.5 to SRM 5.0 Extended Classic just 1.5 years prior, our users were sympathetic to this, and weekly reports provided them with insight as to how many outstanding workflows they had. However, we are a relatively small shop – although our workflow footprint is quite large. We have no SAP-delivered workflows running, but plenty of custom ones.
You do need to:
1 The first bullet in the SAP document does say ‘Complete all running workflow instances’ - So really try to convince your business people of this. You can, if necessary, report on workflows in process at the time of the upgrade, and perhaps kill them, and manually start new workflows after the upgrade? As I said, it depends on your business.
2 Check each custom workflow – you will probably need to do ‘Block Correction’ on each one. You will probably have more DDIC and binding corrections too – which goes right back to #1.
3) Absolutely test previously started (if you must) and freshly-started (after upgrade) workflows as you move thru Dev and QA. This will help you prepare for the oncoming train ☺. You will probably be able to form a plan for addressing any workflows that look as though they are going south – and this will almost certainly be the ones that were running prior to upgrade. It’s also helpful to document each test - which workflow acted flukey, what the resolution was, so you can refer back to it, and share it with your other WF folks.
If you do read and use the document (upgrading SAP Business Workflow from SAP 4.6c to SAP ERP 6.0) please do rate it – it is only when people see that e-learnings are used and helpful that they are encouraged to create more. Which is a good thing for all of us!
http://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/103b1a61-294f-2a10-6491-9827479d0bf1
----
Susan R. Keohan
SAP Workflow Specialist
Enterprise Applications
Information Services Department
MIT Lincoln Laboratory
244 Wood Street, LI-200
Lexington, MA. 02420
781-981-3561
keohan at LL.MIT.EDU<mailto:keohan at LL.MIT.EDU>
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 michael.mcley at daimler.com<mailto:michael.mcley at daimler.com>
Sent: Tuesday, November 02, 2010 10:20 AM
To: sap-wug at mit.edu<mailto:sap-wug at mit.edu>
Subject: Re: Workflow Upgrade 4.6C to ECC6 - manual settings during Cutover & Version
Sandy,
I'm sorry I cannot answer your specific questions below (I only have intermediate WF skillz). However, each of your points sounds reasonable and shouldn't take too long to check and see if it is necessary once you have an upgraded test system to work with. The real experts here can probably provide you with better feedback.
I only wanted to make the point that we upgraded to ECC 6.0 roughly 1.5 years ago, and many of our workflows were trainwrecks afterward. In fact it was at that point that I really learned workflow as just about every custom workflow we use broke after the upgrade. Granted I work in a heavily customized environment (the land of 'Z'...) so I don't think this was so much a problem with SAP products, but of our own making. Incidentally, we didn't seem to have any problems with pure out-of-the-box SAP supplied workflows (which we mostly use in HR).
In any case, from my own experience (if I ever had to do this again), I would:
1. Pay particular attention to agent determination, especially if you are using custom agent determination rules and techniques
2. Seperate testing for new workflow instances versus existing instances (those workflow instances that already are running at the time of the upgrade). Most of the problems we experienced were with already-running workflows - of which there were hundreds.
The 2 areas where we experienced the most problems were with travel approval and incoming invoice processing, which for us, are almost entirely custom everything (objects, events, programs, you name it...).
Just a friendly FYI, nothing more.
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<mailto:michael.mcley at daimler.com>
sandysydney at gmail.com<mailto:sandysydney at gmail.com>
Sent by: sap-wug-bounces at mit.edu<mailto:sap-wug-bounces at mit.edu>
11/01/2010 07:20 PM
Please respond to
sap-wug at mit.edu<mailto:sap-wug at mit.edu>
To
sap-wug at mit.edu<mailto:sap-wug at mit.edu>
cc
Subject
Workflow Upgrade 4.6C to ECC6 - manual settings during Cutover & Version
Hello Guys,
We are upgrading to ECC 6 from 4.6C and we are on release 701 & support pack SAPKB70106.
I would like to know which are the "Manual activities" that needs to done during cutover and WHEN should these should be done (eg. before ECC6 upgade, or after ECC6 upgrade but before config/dev transports, or after config/dev transports).
I have looked on few threads and found the following info. Please correct me or add extra info if i have missed something:
1. Configure RFC destination & other mandatory options in Transaction SWU3.
2. Run Transaction SWU_OBUF to clear the runtime buffers before users start Testing.
I assume rest of changes would be imported with transports, but i have read through lot of SDN threads that all custom Workflow definitions needs to be ACTIVATED in each system (DEV - QAS- PRD) and custom BOR objects needs be REGENERATED in each system (DEV - QAS- PRD). Also, do I have manually set the agent assignement for Customer Task as GENERAL TASK in each system? Are above stated 3 steps needs to be manually done in each system or transports take care of them ? I am bit confused. Could anybody please advise me regarding the Manual Task/activities that needs to done in each system during cutover during WF upgrade from 4.6 C to ECC6.
Thanks for posting excellent stuff regarding the Workflow Upgrades on this mailing list. It really helped me in resolving most of my issues.
Thanks in advance
Kind Regards
Regards
Sandy
_______________________________________________
SAP-WUG mailing list
SAP-WUG at mit.edu<mailto: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<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/20101105/f22f464b/attachment.htm
More information about the SAP-WUG
mailing list