Workflow Upgrade issues (4.6c to ECC 6)

Thu Jul 31 06:58:32 EDT 2008

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 +1000From: paul.batey at presenceofit.com.auTo: sap-wug at mit.eduSubject: 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.comTo: sap-wug at mit.eduSubject: 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

------------------------------------------------------
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 GambierSent: dinsdag 17 juni 2008 17:12To: SAP Workflow Users' GroupSubject: 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! 

Get 5GB of online storage for free! Get it Now! _______________________________________________SAP-WUG mailing listSAP-WUG at mit.eduhttp://mailman.mit.edu/mailman/listinfo/sap-wug
_________________________________________________________________
The John Lewis Clearance - save up to 50% with FREE delivery
http://clk.atdmt.com/UKM/go/101719806/direct/01/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/pipermail/sap-wug/attachments/20080731/43547236/attachment.htm