Workflow Upgrade issues (4.6c to ECC 6)

Wed Dec 9 12:50:11 EST 2009

That Alon guy is a cowboy. No wonder he lives in Texas!
Imagine that! Reusing an SAP delivered data element. Will the horrors ever cease....

Alon Raskin
e: araskin at 3i-consulting.com<mailto:araskin at 3i-consulting.com>

From: sap-wug-bounces at mit.edu [mailto:sap-wug-bounces at mit.edu] On Behalf Of Mike Gambier
Sent: Wednesday, December 09, 2009 10:32 AM
To: sap-wug at mit.edu
Subject: RE: Workflow Upgrade issues (4.6c to ECC 6)

Andy,

The surgery was required on the Workflow Container definitions themselves, specifically where non-existent Data Dictionary types were discovered to be the root cause of some abnormal behaviour.

We found that we had live WF instances of some definitions that compiled just fine pre-upgrade that all of a sudden fell over in ECC 6 because they wanted to use some data elements/fields that had simply vanished because of the upgrade.

In our case the things that went missing were actually in SAP's namespace so we couldn't stop them from disappearing, i.e. some of our WF developers (*ahem* Alon Raskin, not mentioning any names of course!) had made use of an old SAP data type that ended up being zapped from DDIC.

So let's just say that a few 'adjustments' (direct hacks) needed to be made post-upgrade to some SAP tables like SWDSBINDEF (specifically fields REFSTRUCT & REFFIELD) to allow the errored WFs to be restarted and 'find' the correct data type to use going forward.

Regards,

Mike GT

________________________________
Subject: RE: Workflow Upgrade issues (4.6c to ECC 6)
Date: Wed, 9 Dec 2009 09:01:33 -0700
From: andy.m.catherall at cadbury.com
To: sap-wug at mit.edu
Thanks Mike

I'm still unclear on a fundamental point:

"...although we did have to perform a few surgical procedures on a few definitions to resolve the odd bug here and there. And for the record we did NOT kill all of our active instances at all. "

These two statements appear to be mutually exclusive (unless I am *really* missing something).

A typical scenario
* We have some WF_1 instances running version_1 on a 4.6c PROD machine
* We take a copy of prod (for test purposes)
* We test these running instances of WF_1 and find a bug... lets say, in the bindings.
* We make a fix to resolve this issue in our ECC6 landscape. WF_1 has been reactivated and a transport created.
* ...
* Some time later, we finally go live. The production environment is upgraded and the 'fix' transports are uploaded.
* The active instances of WF_1 at version_1 (which started just prior to the upgrade) will run into the bug. Any new instances will now start version_2, and hence be bug-free (hopefully!).

Where did the surgical procedures take place such that active instances were able to continue after the upgrade? In the 4.6c environment, in advance of the upgrade?

Thanks again
Andy

________________________________
From: sap-wug-bounces at mit.edu [mailto:sap-wug-bounces at mit.edu] On Behalf Of Mike Gambier
Sent: Wednesday 09 December 2009 14:30
To: sap-wug at mit.edu
Subject: RE: Workflow Upgrade issues (4.6c to ECC 6)
Hi Andy,

I'm glad you found the thread useful :)

Several months on from the upgrade and I'm pleased to say we've made the transition to an ECC 6 platform without too much fallout, so in the immortal words on the HG2G book "Don't Panic!".

Nothing went drastically wrong, although we did have to perform a few surgical procedures on a few definitions to resolve the odd bug here and there. And for the record we did NOT kill all of our active instances at all. Instead we had millions of them waking up and playing with the new Workflow engine code reasonable natively. The only ones that had problems 'wakng up' were typically ones that were trying to invoke standard SAP Functions that had been zapped in during the upgrade, e.g. SWW_BI_EXECUTE_S_NEW.

Probably the best thing you can do is scan through OSS Note 1068627 and prepare for some thorough testing prior to the big day.

Provided you don't intend to import Workflow definition changes from a 4.6c (or earlier) system into an ECC 6 one on a continuous basis, as we did, you should find your definitions probably only need to be looked at a couple of times before they bed down. You might want to create 'new' versions in your development environments just to be sure you can differentiate between new instances and old ones but it wasn't actually necessary in most cases. Just good practice really.

Perhaps the biggest concern we had (and continue to have) is the use of the XML container and the persistence profile at our volumes. Simply put, we have not switched to the new tables at all. Mostly because we rely heavily on being able to 'find' objects in Workflow containers for exception and monitoring processes and so need stuff to still be in SWW_CONTOB. All of which means we have religiously set our Persistence Profile to the 'Structured' setting which forces the code to use the 'old' container tables.

Having said that our PI system is merrily using ccBPM stuff (essentially that means Workflow) and is using the XML Container tables, albeit at significantly lower volumes.

Pretty soon we'll complete the holy trinity and have Workflows running in our new SAP CRM 7.0 system too. Which will mean WF-BATCH whizzing along in 3 different SAP systems and 3 different ABAP codestacks all at the same time. Oh joy... :)

Regards,

Mike GT

________________________________
Subject: RE: Workflow Upgrade issues (4.6c to ECC 6)
Date: Wed, 9 Dec 2009 05:56:13 -0700
From: andy.m.catherall at cadbury.com
To: sap-wug at mit.edu
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<mailto: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<mailto:gijs at houtzagers.com>
To: sap-wug at mit.edu<mailto: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> [mailto: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/>

_______________________________________________
SAP-WUG mailing list
SAP-WUG at mit.edu<mailto: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<mailto: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
-----------------------------------------

________________________________
Use Hotmail to send and receive mail from your different email accounts. Find out how.<http://clk.atdmt.com/UKM/go/186394592/direct/01/>
________________________________
View your other email accounts from your Hotmail inbox. Add them now.<http://clk.atdmt.com/UKM/go/186394592/direct/01/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/pipermail/sap-wug/attachments/20091209/6d4520ac/attachment.htm