Transporting workflows from 4.6c to ECC6?

Thu Jan 14 08:24:34 EST 2010

Andy,

The short answer is mostly 'yes', but sometimes (typically where ECC 6 wants to deal with new tables) also 'no'.

The longer answer is probably more like this:

RE: ECC Upgrade - WF Transport Issues?‏
From:  sap-wug-bounces at mit.edu on behalf of Keohan, Susan (keohan at ll.mit.edu)  
Sent: 06 November 2008 15:54:52 
To:  SAP Workflow Users' Group (sap-wug at mit.edu) 
  5 attachments | Download all attachments (115.9 KB)  
 image001.jpg (22.6 KB), image002.jpg (16.8 KB), image003.jpg (42.3 KB), image004.jpg (34.1 KB), ATT00001 (0.1 KB)  

Hi Mike,  All potential upgraders!

Well, I did find this helpful – 

https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/103b1a61-294f-2a10-6491-9827479d0bf1

In particular, there is one OSS Note (1068627) which is good because it lists a lot of notes that may be helpful.

We are on Basis Support Pack 15, so a lot of them did not apply to us.

I’ve filled out an OSS Message.  SAP did respond advising me to check: 

* 1175535 - Cross-release transport of workflows

If you look at section [5] of note 1098805 there are some points
I would like you to check. They are:

Troubleshoot versions & activation

- Do the Source and Target systems have the same system date &
time?

- If you created any new container elements in your workflow can
you make sure that the their data references also exist in the
QA system.

- Did you create any new tasks and add them to the workflow in
the development system. If so please make sure that you also
transported the task to the quality system.

- Have you checked transaction SWDM -> Extras -> Transported
workflows in the target system? It will show up in red if
there are any issues.

* 1098805 - Troubleshooting Tips & Tricks for workflow issues

Additionally, table SWDSHEADER, for version 9999 of the workflow, should have the exact date and time stamp as the same entry in your Dev Box.

Many thanks to Eddie Morris for helping me get this far.

So far, no other resolution.  I’ve deleted offending container elements in Dev, re-added them, checked binding, re-transported, all to no avail.

I’ll keep you posted.

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

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

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

Subject: Transporting workflows from 4.6c to ECC6?
Date: Thu, 14 Jan 2010 06:03:44 -0700
From: andy.m.catherall at cadbury.com
To: sap-wug at mit.edu

Hi

Is it possible to [successfully] transport 4.6c workflow developments (esp. WS objects) to ECC6? 

We still have our 4.6c path-to-production, and we have our parallel ECC6 project landscape for the upgrade. Some urgent changes/fixes have been made to a few of our production workflows, and these transports have been cloned back into our ECC6 Dev & Sandbox systems.

That has not gone well... :o(

We have noticed two key features:
1) In most cases, the WS objects are not activating. There is no error, nor any clear warning explaining why not.
2) In most cases, we have seen warnings along the following lines:

    different nametabs for table HRS1212
    different nametabs for table SWBRULECOU
    etc.
Clearly, the 'new' tables are of a different size to the 4.6c tables, hence the offsets are incorrect. 

However, in at least one example - involving two WS templates - the activations did occur despite the warnings.

So, is there evidence/experience of successful transports of this nature out there, and I just need to find the appropriate correction or fix? Or, is this approach impossible?

I further note that we are only on SAPKB70103 - 4,5 & 6 exist, so I am working my way through these notes to see if there are any solutions. For example, note 1276795 may help, though it does not sound ideal. 

Thanks again, guys!
Andy Catherall 
Technical Analyst - SAP Workflow, IXOS & DMS 

Int: 751 0556 
Ext: +44 (0)121 486 0556 
Mobile: +44 (0)7813 025481 

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

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

_________________________________________________________________
Got a cool Hotmail story? Tell us now
http://clk.atdmt.com/UKM/go/195013117/direct/01/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/pipermail/sap-wug/attachments/20100114/cdee6387/attachment.htm
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cadburylogoEmail.gif
Type: image/gif
Size: 772 bytes
Desc: not available
Url : http://mailman.mit.edu/pipermail/sap-wug/attachments/20100114/cdee6387/attachment.gif