Workflow Upgrade issues (4.6c to ECC 6)

Wed Dec 9 09:18:17 EST 2009

Thanks for that, Koenraad. All warnings of dragons ahead gratefully received!

________________________________

From: sap-wug-bounces at mit.edu [mailto:sap-wug-bounces at mit.edu] On Behalf Of JANSSENS Koenraad
Sent: Wednesday 09 December 2009 13:18
To: SAP Workflow Users' Group
Subject: RE: Workflow Upgrade issues (4.6c to ECC 6)

Totally not on topic but I recently ran into the issue corrected with note 1383979 which is also +- an upgrade issue and will pop up when you create your first new wf with parallel execution of subwf's starting from a multiline container element. (dynamic parallel processing)  Might be of use to you too.

Best Regards

Koenraad Janssens

Keneos S.A.

From: sap-wug-bounces at mit.edu [mailto:sap-wug-bounces at mit.edu] On Behalf Of Catherall, Andy
Sent: Wednesday, December 09, 2009 1:56 PM
To: SAP Workflow Users' Group
Subject: RE: Workflow Upgrade issues (4.6c to ECC 6)

Hi all

Apologies for resurrecting an old thread... I'm working my way through all the upgrade-lesson posts, as we are now finally moving from 4.6c to ECC6. I too have recognised this "Do I *really* have to end all my workflow instances/business processes!?!" dilemma, and am trying to understand the subtleties behind it. This thread seemed a very pertinent place to ask my questions.

I really appreciate all the lessons which have been put on this forum with respect to WF upgrades... from this, I get the strong impression that there may be a multitude of bugs, issues and associated corrections to workflow definitions, bindings, the 'block structure' etc, in support of ECC6. I am witnessing a number of these issues in our test environment, and they are impacted both in-flight instances & new instances.

Many of these fixes will result in new versions of the workflow design: So, for example, if I identify & fix a binding issue in my ECC6 test environment, I will have to re-activate the workflow and promote the change into production at cut-over. This instantly means that any workflows might be in-progress during the cut-over weekend will be not be 'valid' in the new environment, because they will not be running the corrected version. Further, we may have to change an object or method such that old versions of the workflow cannot successfully call it... Again, in-flight workflow instances are the living-dead; we know they will not continue after the upgrade.

That all made sense to me and my little understanding of the universe... and I can foresee having to forewarn the business of this. They will by very impressed, I'm sure!

However, there are hints in this thread - and other similar ones - of people somehow managing to cajole their workflow instances into continuing across the upgrade boundary...

So, my questions:

Where are all the fixes made such that 'old' versions of the workflows were still functional even after the upgrade? Can they all be made in the 4.6c system, in advance of the upgrade?

How are all the fixes made? If they cannot all be made in the 4.6c environment (e.g. the corrected block-structure issue only manifests in ECC6), how are new versions avoided?

Many thanks for this information.

Andy

________________________________

From: sap-wug-bounces at mit.edu [mailto:sap-wug-bounces at mit.edu] On Behalf Of Mike Gambier
Sent: Thursday 31 July 2008 11:59
To: SAP Workflow Users' Group
Subject: RE: Workflow Upgrade issues (4.6c to ECC 6)

Hi,

Just a follow-up on my earlier post. Feel free to ignore if you're not bothered about upgrading from 4.x to 700+.

After a welcome visit from the SAP Gods of Workflow (Ralf Goetzinger and Peter Amrhein) we now have a couple of freshly issued OSS Notes to help us along with our quest:

1. 1234971 - Workflow Builder: Changing the ParForEach expression syntax (essentially tweaks the SAP Upgrade FM SWD_UPGRADE_3XX_TO_4XX) which should fix our Multiline binding issues. Yay :)

2. 1228836 - Compatibility of conditions with date/time constants (provides an alternative binding solution for active instances of 'old' definitions at runtime). Does not actually fix the WF Definition and add the new required {TYPE=...} syntax, but could be a life-saver during an upgrade if dates and time bindings are used a lot. Also provides a rather useful ABAP Report utility to scrutinise your WF Definitions and sniff out date/time bindings (RSWDCLRBUF) which, if you copy and clone, you can adjust to examine other binding types as well :)

Anybody else going through an upgrade should find these two notes particularly useful.

These can also be found attached to the composite Upgrade Note 1068627 which is starting to read a bit like a bible...

Ralf and Peter, if you're reading this, thanks again!

Regards,

Mike GT 

________________________________

Date: Fri, 20 Jun 2008 10:09:04 +1000
From: paul.batey at presenceofit.com.au
To: sap-wug at mit.edu
Subject: Re: Workflow Upgrade issues (4.6c to ECC 6)

Hi Mike,

A client of mine just went from 46B to ECC6, and we found the following workflow problems:

1) Every workflow had to have a block correction done in workflow builder (this may fix your par for each error).  Run SWU7 and if you get loads of invalid node type errors, a block correction will fix it.

2) Old FORMHTML.PROCESS steps short dumped, so we replaced them with the shiny new form step.

3) Workflow versions were completely butchered when transported from the first upgraded box to the next in the sequence.  This was fixed by running FM SWD_WFD_REPLICATE_FROM_9999 and putting the WSXXXXXXXX number into the IM_TASK field.

4) We used customised versions of RSWUWFML to send email notifications of workitems.  This and any other custom program that put entries into the SOST queue (email, fax etc) did not properly commit (if memory serves me an SO_OFFICE_SEND exception 1 error in SOST).  A simple explicit COMMIT WORK statement at the appropriate place in each program sorted that one out.

Apart from that, there were minimal issues with workflows starting before the upgrade and finishing afterwards (unless they hit the short dumping form step)

On 6/18/08, Mike Gambier <madgambler at hotmail.com> wrote: 

Gijs,

We will have millions of active instances running when we bring the system down to upgrade it. There's no way we will be able to shut them down and restart, despite the SAP white paper suggesting that we really should. We have about 100 WF definitions to check...

Consequently we're having to test how well they perform in an upgraded environment before we do it for real. Which means testing lots of areas: triggering events event queued or otherwise & binding (which works differently in ECC 6), deadlines (different again in ECC 6), event listeners (which are shifted to a completely different table), complex alternate bindings, dialog work items being executed & terminating events, forks, loops, dynamic steps and, of course, general tRFC/ARFCSSTATE/feedback errors.

Whilst it's always nice to see new OO stuff coming through as part of the upgrade, the new versions of the Workflow service jobs are proving to be a bit hard to predict in how they do things. So we're waiting to see how they cope at volume too.

By the time we go live we'll have gone through several full blown upgrade simulations. All of which means a lot of effort. Hence the pain...

That and 4 High Priority OSS Messages already and you can see where I'm coming from. Still, it's educational and quite fun to dig around in the new stuff :)

MGT

________________________________

From: gijs at houtzagers.com
To: sap-wug at mit.edu
Subject: RE: Workflow Upgrade issues (4.6c to ECC 6)
Date: Tue, 17 Jun 2008 18:46:25 +0200 

Hi Mike,
Could you elaborate on the painful stuff you were confronted by?
Regards

Gijs Houtzagers
Principal Consultant

Kirkman Company B.V.
Amsterdamsestraatweg 40
3743 DT  Baarn
The Netherlands

T +31 (0)88 40 40 400
F +31 (0)88 40 40 499
www.kirkmancompany.com <http://www.kirkmancompany.com/> 

------------------------------------------------------
The information contained in this message 
may be confidential and is intended to be 
exclusively for the addressee. Should you 
receive this message unintentionally, you are 
kindly requested not to make any use 
whatsoever of the contents. Please notify
the sender by return e-mail and delete 
the material from any computer.
---------------------------------------------------- 

________________________________

From: sap-wug-bounces at mit.edu [mailto:sap-wug-bounces at mit.edu] On Behalf Of Mike Gambier
Sent: dinsdag 17 juni 2008 17:12
To: SAP Workflow Users' Group
Subject: Workflow Upgrade issues (4.6c to ECC 6)

Hi,

We're currently struggling through a rather painful upgrade process from 4.6c to ECC 6 and we've hit a few Workflow mines.

Despite several high priority OSS Messages the end result from SAP so far as been a fairly poor acknowledgement of issues that need to be addressed manually, culminating in OSS Note 1175535.

Basically we have 4 known faults at the moment. Two relating to changes not coming across from 4.6c into ECC 6 based around Workflow Container Elements and Event Linkages, which I can quite understand as the target tables ahve shifted in ECC 6. But the other two point to problems in SAP's 'mapping' process where they convert 4.6c (or older) definitions into ECC 6 syntax (Kernel 700+).

These issues are:

1. Multiline Table handling - to use these properly in loops and dynamic steps it seems you now have to use a new &WF_PARFOREACH_INDEX& element that only becomes available after 4.6c

They did suggest trying a dodgy binding switch as implemented by OSS Message 1083317, which mostly works for active instances but only as long as the 'Change Release' value on the WF version remains equal to or lower than '46C'. Not all that useful if the instances are on the current active version and that definition is then activated in the ECC 6 environment. But that doesn't actually fix the definition syntax going forward anyway.

2. Condition binding after 4.6c introduces a {TYPE=...} additional statement in SWDSCONDEF so that, for example, a hard-coded string like '31.12.9999' can be converted into a date variable at runtime to compare against an object date property. Prior to 4.6c this statement did not exist. Now it is required or else the binding is considered to be erroneous and a syntax error will result.

Has anyone esle come across upgrade-related issues other than these?

Regards,

Mike GT

________________________________

Get 5GB of online storage for free! Get it Now! <http://clk.atdmt.com/UKM/go/msnnkmgl0010000005ukm/direct/01/> 

________________________________

Get 5GB of online storage for free! Get it Now! <http://clk.atdmt.com/UKM/go/msnnkmgl0010000005ukm/direct/01/> 

_______________________________________________
SAP-WUG mailing list
SAP-WUG at mit.edu
http://mailman.mit.edu/mailman/listinfo/sap-wug

________________________________

Win £3000 to spend on whatever you want at Uni! Click here to WIN! <http://clk.atdmt.com/UKM/go/101719803/direct/01/>  

The Cadbury Cocoa Partnership is working to secure the future of cocoa farming around the world. Cadbury Dairy Milk bars are now Fairtrade certified in the UK and Ireland. Visit www.cadbury.com <http://www.cadbury.com/>  to learn more.

Be part of our "Purple Goes Green" commitments and don't print this email.

-----------------------------------------

This email (including any attachment) is confidential and may contain privileged information and is intended for the use of the individual(s) to whom it is addressed. If you are not the intended recipient or receive it in error, you may not use, distribute, disclose or copy any of the information contained within it and it may be unlawful to do so. If you are not the intended recipient please notify us immediately by returning this email to us at mailerror at cadbury.com and destroy all copies.

Any views expressed by individuals within this email do not necessarily reflect the views of Cadbury Holdings Ltd or any of its subsidiaries or affiliates. This email does not constitute a binding offer, acceptance, amendment, waiver or other agreement, or create any obligation whatsoever, unless such intention is clearly stated in the body of the email. Whilst we have taken reasonable steps to ensure that this email and any attachments are free from viruses, recipients are advised to subject this email to their own virus checking, in keeping with good computing practice. We accept no liability for any damage sustained as a result of any viruses. Please note that email received by Cadbury Holdings Ltd or its subsidiaries or affiliates may be monitored in accordance with applicable law. 

This email originates from Cadbury Holdings Ltd ("Cadbury") or Cadbury UK ("Cadbury UK") as the case may be.

Cadbury Holdings Ltd: registered in England and Wales, registered no. 52457
Registered office address: Cadbury House, Sanderson Road, Uxbridge, Middlesex, UB8 1DH United Kingdom. Telephone: +44 (0)1895 615000  Fax:+44 (0)1895 615001  

Cadbury UK: a partnership of Cadbury UK Ltd, Trebor Bassett Ltd and The Old Leo Company Ltd. Ltd each of which is registered in England and Wales. 

Principal trading address: Cadbury House, Sanderson Road, Uxbridge, Middlesex, UB8 1DH United Kingdom. Telephone: +44 (0)1895 615000  Fax:+44 (0)1895 615001  

-----------------------------------------

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/pipermail/sap-wug/attachments/20091209/4e17d60e/attachment.htm