ECC Upgrade - WF Transport Issues?

Wed Nov 5 12:41:06 EST 2008

Hi Mike,

Thank you for your thoughtful and thorough answer.  I probably neglected to specify that although these WF Definitions were originally created in 4.6c, they've been changed after our Dev box was upgraded to ECC 6.0.   Which is why this is so frustrating - these definitions are fine in our Dev box which is ECC 6; they run and everything.  Then we transport them to QA and get errors (which I would have expected to get in Dev).

I am still plowing through OSS notes though.

It would be one thing if I was concerned about running instances of the old workflows, but I have gotten lucky (I think) in that the business seems to have bought off on clearing out all our 'old' 4.6c workflow instances.

But thank you for enlightening all of us!

----
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

________________________________
From: sap-wug-bounces at mit.edu [mailto:sap-wug-bounces at mit.edu] On Behalf Of Mike Gambier
Sent: Wednesday, November 05, 2008 12:27 PM
To: sap-wug at mit.edu
Subject: RE: ECC Upgrade - WF Transport Issues?

Hi Sue,

We're at the tail-end of a long protracted code merge between 4.6c and ECC 6 and our experiences of the whole WF Transport area are these:

1. SAP categorically does NOT support transporting 4.6c changes to ECC 6 definitions. And from what we've been told they never will either, despite our complaints that they need to consider they're existing customers who can't just upgrade overnight.

2. SAP expects clients to upgrade their definitions once and once only. And therefore their migration tools and programs are written to update the new tables from the 'old' tables once and once only.

3. Basically speaking you have to assume that most changes to containers and container elements will NOT be Transportable and will have to be manually applied directly in ECC 6. Thankfully, binding changes seem to be unaffected for the most part although there too some things have crept in that might catch you because of unicode parsing (there's new syntax added by SWDD for type definitions that you can't add in 4.6c).

4. Some brand new WF Definition features have to be defaulted but these values may not be ideal for you. For instance we have chosen to stick to the 'old' STRUCTURE PERSISTENCE conatiner tables (SWW_CONTOB) but we need to explicitly state this in the WF Definition header settings otherwise furture versions may decide to switch to the new tables (Compatiblity setting). And we've found that on occasion 4.6c Transports have a nasty habit of re-initialising some of these defaults...

5. Dummy nodes in ECC 6 cause havoc until a Block Correction is carried out, as you have found out. These go away but come back if you re-import from 4.6c iof course. Nice! The fault is deep down in the new logic for determining step types and the fact that ECC 6 adds an extra piece of data somewhere to define a dummy block that you can't transport.

6. Multi-line tables now have to be handled with a brand new container element that 4.6c can't deal with. That was a fun one to work out. You actually have to hack your binding in text editor mode to insert the new syntax  if you want to pacth this kind of thing up (WFParForEach).

The Transport mechanism in 4.6c can only succeed in delivering changes where the tables in ECC 6 have remained in place and are still in use. Thankfully this means that in most cases the changes to actual step logic and binding does make it through, but be careful where the new logic being added is based on new container elements (see 3).

To be fair I appreciate SAP's dilemma a bit because the jump from 4.6c to ECC 6 in terms of Workflow is subtle but huge. The addition of XI/PI/BPM (whatever they call it now) and the whole revamp of the Workflow engine in ABAP Classes has meant a complete rethink in a lot of key areas.

But I think clients are currently faced with a painful choice at the moment which leaves a sour taste in my mouth to be honest. They either send Transports through and patch things up manually (as we have had to do) or they carry out parallel changes and keep their development codestreams apart (at the risk of missing stuff). Either way the upgrade becomes quite a pain if you use Workflow a lot.

By the way, be aware that the tables for Event Linkages have also changed, so SWETYPV is based on a completely different table view and hence Transports from 4.6c are utterly useless.

Regards,

Mike GT
________________________________

From: keohan at ll.mit.edu
To: sap-wug at mit.edu
Date: Wed, 5 Nov 2008 11:35:41 -0500
Subject: ECC Upgrade - WF Transport Issues?

Hi All,

We are upgrading from 4.6c to ECC 6.
Some workflow definitions that were originally built in 4.6c have trouble when a corrected version is transported to QA.
I am talking only about definitions - not instances.
Here's the long version...

WF Definition (originally built in 4.6c) in Development system (ECC 6) then transports to QA (ECC 6)
1)      Had errors in block structure, corrected via WF Builder (Extras> Special Functions> Block Correction
2)      Tranported to QA
3)      WF Definition was not updated in QA with first transport, header data did not reflect change version from date of first transport
4)      Transport logs ineffective (although they do report error 8)
5)      Generated new version in Dev.  Transported to QA.  No Transport errors
6)      New version 'appears' to be in QA

7)      Check on WF - SWUD In Dev:
[cid:image001.jpg at 01C93F43.C55EE8A0]
But in QA:  (Workflow Definition does not exist????)
:[cid:image002.jpg at 01C93F43.C55EE8A0]

8) PFTC_DIS In Dev (OK, warnings, but so what):
[cid:image003.jpg at 01C93F43.C55EE8A0]

In QA:
[cid:image004.jpg at 01C93F43.C55EE8A0]

I am scouring OSS Notes.  We do get the warnings in QA when entering PFTC_DIS with various container elements ('Container element TYPEID is not used', Message No. WD315).   So far notes seem to address elements *missing* from the workflow containers (related to workflow instances, not definitions), Container elements missing (RSWF_CNT_BOR_ELEM_REPLACE), but this workflow was fine in Dev and the elements referred to do exist in QA...

Any tips would be appreciated.
Thanks
Sue
----
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

________________________________
Read amazing stories to your kids on Messenger Try it Now!<http://clk.atdmt.com/UKM/go/117588488/direct/01/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/pipermail/sap-wug/attachments/20081105/36a42258/attachment.htm
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 23144 bytes
Desc: image001.jpg
Url : http://mailman.mit.edu/pipermail/sap-wug/attachments/20081105/36a42258/attachment.jpg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 17208 bytes
Desc: image002.jpg
Url : http://mailman.mit.edu/pipermail/sap-wug/attachments/20081105/36a42258/attachment-0001.jpg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.jpg
Type: image/jpeg
Size: 43300 bytes
Desc: image003.jpg
Url : http://mailman.mit.edu/pipermail/sap-wug/attachments/20081105/36a42258/attachment-0002.jpg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image004.jpg
Type: image/jpeg
Size: 34876 bytes
Desc: image004.jpg
Url : http://mailman.mit.edu/pipermail/sap-wug/attachments/20081105/36a42258/attachment-0003.jpg