<br><font size=2 face="sans-serif">Zack,</font>
<br>
<br><font size=2 face="sans-serif">Having similar issues in regard to review
of workflow logs for pre-upgrade workitems.</font>
<br>
<br><font size=2 face="sans-serif">Your comment of '</font><tt><font size=2>We
fixed these by correcting the container definitions to reference the appropriate<br>
data dictionary elements/object types.'</font></tt>
<br>
<br><font size=2 face="Default San Serif">When the pre-upgrade incorrect
versions of the workflow templates were corrected, did this not generate
'new versions' of the templates? If so, then how are the pre-upgrade
workitems going to be linked to the new corrected versions. Or can
the templates be corrected and given the same version numbers via generation
so that they then linked back up properly?</font>
<br>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td width=40%><font size=1 face="sans-serif"><b>Zack P <sapedi2000@yahoo.com></b>
</font>
<br><font size=1 face="sans-serif">Sent by: sap-wug-bounces@mit.edu</font>
<p><font size=1 face="sans-serif">03/05/2008 02:03 PM</font>
<table border>
<tr valign=top>
<td bgcolor=white>
<div align=center><font size=1 face="sans-serif">Please respond to<br>
"SAP Workflow Users' Group" <sap-wug@mit.edu></font></div></table>
<br>
<td width=59%>
<table width=100%>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">To</font></div>
<td><font size=1 face="sans-serif">"SAP Workflow Users' Group"
<sap-wug@mit.edu></font>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">cc</font></div>
<td>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">Subject</font></div>
<td><font size=1 face="sans-serif">RE: ECC 6.0 Upgrade - Processing work
items from old environment</font></table>
<br>
<table>
<tr valign=top>
<td>
<td></table>
<br></table>
<br>
<br>
<br><tt><font size=2>Hi Mike,<br>
<br>
The errors that showed up in ECC 6.0 environment were<br>
related to binding definitions that did not cause<br>
problems in 46C. Doing a syntax check in SWDD shows<br>
these errors. We fixed these by correcting the<br>
container definitions to reference the appropriate<br>
data dictionary elements/object types. <br>
<br>
Regards,<br>
Zack<br>
<br>
<br>
--- Mike Gambier <madgambler@hotmail.com> wrote:<br>
<br>
> <br>
> Ouch. That's not good news. We will going through<br>
> the same pain in a few months time, again with<br>
> millions.<br>
> <br>
> I presume the binding problems are a result of the<br>
> version-dependent settings (of whatever Workflow<br>
> definition the Work Items belong to) not matching<br>
> the stricter rules imposed by the new Workflow<br>
> environment in ECC 6.0?<br>
> <br>
> Have you checked that the DDIC data element or<br>
> structure involved is actually active? We've noticed<br>
> that several large tables that we know have been<br>
> changed were not activated properly and present in<br>
> the runtime environemnt in their new format, despite<br>
> DDIC saying they were active. It took us a few<br>
> manual bumps and a couple of SWU_OBUFs to actually<br>
> persuade one particular step to accept that a<br>
> parameter it was using was the correct length.<br>
> <br>
> If you tried to display the definition now using<br>
> SWDD or SWUD does the builder highlight the<br>
> problematic elements or binding issues?<br>
> <br>
> Have you considered checking the binding settings in<br>
> SWD_BINDEF for the version of the Workflow<br>
> definition that is causing the problem? Perhaps by<br>
> 'adjusting' the values in the table to point to a<br>
> valid/active DDIC structure the runtime syntax error<br>
> could be avoided?<br>
> <br>
> By the way, we noticed that several 'old' 4.6c<br>
> condition steps (e.g. date constants like<br>
> '31.12.9999' as a characeter string for example)<br>
> would have to be re-entered again in SWDD before<br>
> they would be deemed acceptable by the builder.<br>
> Presumably because the new builder does something a<br>
> little bit more/differently than the old one,<br>
> allowing the 'old' value to pass whatever validation<br>
> it failed before.<br>
> <br>
> Regards,<br>
> <br>
> Mike GT> Date: Wed, 5 Mar 2008 08:30:14 -0800> From:<br>
> sapedi2000@yahoo.com> Subject: ECC 6.0 Upgrade -<br>
> Processing work items from old environment> To:<br>
> sap-wug@mit.edu> > Hello,> > Upgarding to ECC 6.0<br>
> from 4.6C. In the development> box, we found that<br>
> some workflow templates failed> syntax check due to<br>
> stricter enforcement of data types> bindings. We<br>
> fixed these issues in the development> environment.><br>
> > Question 1) What happens to work items created in<br>
> 46C> after the upgrade? Should they continue to<br>
> process in> ECC6.0 without issues?> > Question 2)<br>
> What happens to work items created in 46C> for the<br>
> WF templates which failed the syntax check in> ECC<br>
> 6.0 (we have millions) when we go live? I><br>
> understand that a workflow instance always refers<br>
> to> the version of the WF template that it was<br>
> created in> and not to the latest version. Does that<br>
> mean that> when we go-live, the work items that<br>
> exist that were> created in 4.6C would be referring<br>
> to the older (46C)> version of the workflow<br>
> templates rather than the> newest version (ECC6.0)<br>
> where the syntax issue was> fixed. Do they then<br>
> fail?> > Any input into how to fix this potential<br>
> issue would> be helpful!> > Thanks,> Zack><br>
> _______________________________________________><br>
> SAP-WUG mailing list> SAP-WUG@mit.edu><br>
> http://mailman.mit.edu/mailman/listinfo/sap-wug<br>
><br>
_________________________________________________________________<br>
> Free games, great prizes - get gaming at Gamesbox. <br>
> http://www.searchgamesbox.com><br>
_______________________________________________<br>
> SAP-WUG mailing list<br>
> SAP-WUG@mit.edu<br>
> http://mailman.mit.edu/mailman/listinfo/sap-wug<br>
> <br>
<br>
_______________________________________________<br>
SAP-WUG mailing list<br>
SAP-WUG@mit.edu<br>
http://mailman.mit.edu/mailman/listinfo/sap-wug<br>
</font></tt>
<br>