<html dir="ltr"><head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
<style>.hmmessage P {
PADDING-RIGHT: 0px; PADDING-LEFT: 0px; PADDING-BOTTOM: 0px; MARGIN: 0px; PADDING-TOP: 0px
}
BODY.hmmessage {
FONT-SIZE: 10pt; FONT-FAMILY: Tahoma
}
</style>
<meta content="MSHTML 6.00.3790.2920" name="GENERATOR">
<style title="owaParaStyle">P {
MARGIN-TOP: 0px; MARGIN-BOTTOM: 0px
}
</style>
</head>
<body class="hmmessage" ocsi="x">
<div dir="ltr"><font face="Tahoma" color="#000000" size="2">Mike,</font></div>
<div dir="ltr"><font face="tahoma"></font> </div>
<div dir="ltr"><font face="tahoma">No comment on the locking behavior as I have not played around with this. Love to hear what other have experienced.</font></div>
<font face="tahoma">
<div dir="ltr"><br>
</font><font face="tahoma">Yes from what I have heard the XML is a bit faster. Since your current client has such high volumes I would recommend that you guys do some testing to see if the improved performance warrants a re-design of your current workflows
to take advantage of the new XML persistence layer. Even a small improvement may multiply out to a significant benefit because of the volumes that you guys deal with.</font></div>
<div dir="ltr"><font face="tahoma"></font> </div>
<div dir="ltr"><font face="tahoma">Regards,</font></div>
<div>
<div><font face="Tahoma" size="2">
<p class="MsoNormal"><strong><b><font face="Calibri" color="navy" size="3"><span style="FONT-SIZE: 12pt; COLOR: navy; FONT-FAMILY: Calibri"></span></font></b></strong> </p>
<p class="MsoNormal"><strong><b><font face="Calibri" color="navy" size="3"><span style="FONT-SIZE: 12pt; COLOR: navy; FONT-FAMILY: Calibri"><strong><b><font face="Calibri" color="navy" size="3"><span style="FONT-SIZE: 12pt; COLOR: navy; FONT-FAMILY: Calibri"><strong><b><font face="Calibri" color="navy" size="3"><span style="FONT-SIZE: 12pt; COLOR: navy; FONT-FAMILY: Calibri"><strong><b><font face="Calibri" color="navy" size="3"><span style="FONT-SIZE: 12pt; COLOR: navy; FONT-FAMILY: Calibri">Alon</span></font></b></strong></span></font></b></strong></span></font></b></strong>
Raskin</span></font></b></strong></p>
<p class="MsoNormal"><strong><b><font face="Calibri" color="navy" size="3"><span style="FONT-SIZE: 12pt; COLOR: navy; FONT-FAMILY: Calibri">e:</span></font></b></strong><strong><b><font face="Calibri" color="navy"><span style="FONT-WEIGHT: normal; COLOR: navy; FONT-FAMILY: Calibri">
<b><font color="navy"><span style="FONT-WEIGHT: bold; COLOR: navy"><a title="blocked::mailto:araskin@3i-consulting.com" href="mailto:araskin@3i-consulting.com"><font face="Calibri"><span style="FONT-FAMILY: Calibri"><span title="blocked::mailto:araskin@3i-consulting.com">araskin@3i-consulting.com</span></span></font></a></span></font></b></span></font></b></strong></p>
<p class="MsoNormal"></p>
<p class="MsoNormal"><b><font face="Times New Roman" color="navy" size="3"><span style="FONT-WEIGHT: bold; FONT-SIZE: 12pt; COLOR: navy"></span></font></b></p>
<p class="MsoNormal"><b><font face="Times New Roman" color="navy" size="3"><span style="FONT-WEIGHT: bold; FONT-SIZE: 12pt; COLOR: navy"><a title="blocked::http://www.themobileworkplace.com/
http://www.themobileworkplace.com/" href="http://www.themobileworkplace.com" target="_blank"><font face="Calibri" size="2"><span style="FONT-SIZE: 11pt; FONT-FAMILY: Calibri"><span title="blocked::http://www.themobileworkplace.com/"></span></span></font></a></span></font></b></p>
</font>
<hr tabindex="-1">
<font face="Tahoma" size="2"><b>From:</b> sap-wug-bounces@mit.edu [sap-wug-bounces@mit.edu] On Behalf Of Mike Gambier [madgambler@hotmail.com]<br>
<b>Sent:</b> Wednesday, February 27, 2008 5:10 AM<br>
<b>To:</b> SAP Workflow Users' Group<br>
<b>Subject:</b> RE: Version question (extended)<br>
</font><br>
<p></p>
</div>
</div>
<div></div>
<div>Thanks Mark :)<br>
<br>
On the subject of EC 6.0 and the new version-dependent settings I have a few questions of my own.<br>
<br>
Has anyone tried the 'Locking properties' settings to see what performance benefits there are with the new values?<br>
<br>
=> Standard behaviour (default)<br>
=> Lock behaviour for Sequential Workflows<br>
=> Lock behaviour for Background Workflows<br>
<br>
I'm curious to know, because we have several complex definitions that seek to lock objects in branches that just may compete with each other. I'm secretly hoping that the last option might solve a problem we have with occasional deadlocks.<br>
<br>
Also, we're in the process of upgrading to EC 6.0, so our active Workflow instances (yes, we intend to upgrade with workflow instances still on-the-go, albeit not actually active during the upgrade process!) will be using the 'old' Structure persistence container
(so SWW_CONT and SWW_CONTOB). <br>
<br>
We don't know yet if this is going to cause us any problems; I've read the white paper on the subject and in theory we should be fine. I'd appreciate it if any of you wuggers out there could let me know if you've seen or heard of any problems with instances
waking up in their new environment and falling over or complaining because of container elements.<br>
<br>
On the same subject I've heard that the 'new' XML persistence appraoch is supposed to be a tad faster, anyone have experience of that first hand? Since we interrogate SWW_CONTOB in lots of places outside of Workflow we will probably have to stick with the old
approach for most of our Workflows, but if anyone thinks the XML container isn't that much better (or maybe worse) I'd like to know just in case we need to start to switch to it.<br>
<br>
Regards,<br>
<br>
Mike GT<br>
<br>
> Date: Wed, 27 Feb 2008 10:44:17 +0000<br>
> Subject: RE: Version question<br>
> From: wug@workflowconnections.com<br>
> To: sap-wug@mit.edu<br>
> <br>
> Mike: Great piece of info, thanks.<br>
> Mark: Also have a looky on OSS, search for "workflow version" there's a<br>
> note 1240005 or some number like that which explains the difference<br>
> between version-dependent and version-independent changes.<br>
> <br>
> On Wed, February 27, 2008 8:03 am, Mike Gambier wrote:<br>
> ><br>
> > Hi Mark,<br>
> ><br>
> > The short answer is probably 'no'. An instance that has kicked off will<br>
> > know what version of the definition it is supposed to use throughout its<br>
> > life (stored on SWP_HEADER-WFD_VERS) and normally that doesn't change,<br>
> > ever.<br>
> ><br>
> > There are good reasons for this, not least of which is that the Workflow<br>
> > definition dictates to the system not only what the expected next steps<br>
> > should be in the chain but also what table entries to create in the<br>
> > twenty-odd other dedicated Workflow tables to model it all. It's like a<br>
> > blueprint; you wouldn't want to change the design of the first floor of<br>
> > your house having already laid the foundations based on your previous plan<br>
> > now would you? What if you missed out an entire staircase?<br>
> ><br>
> > I say normally but a few things might be possible might persuade the<br>
> > Workflow to behave a little differently 'in flight':<br>
> ><br>
> > 1. Changing the current active version of a Sub-Workflow in a later step<br>
> > after the Parent Workflow has been started is OK. The Parent does not care<br>
> > what the active version of the Sub-Workflow used to be prior to reaching<br>
> > the step, it will just use whatever is the 'active' version at that point<br>
> > in time. But the actual binding used to call the Sub-Workflow (or anything<br>
> > else for that matter) is sensitive to version changes, so be careful on<br>
> > this one if the signature has changed in any way.<br>
> ><br>
> > 2. Amend the actual code behind a Business Object Attribute or Method<br>
> > prior to the Workflow reaching a step that calls the code. Again the<br>
> > Workflow will use whatever has been loaded into the active runtime buffer<br>
> > when it reaches the step. This can cause a bit of grief if the Task/Method<br>
> > binding has changed by the way, so again watch out and avoid adding new<br>
> > 'mandatory' parameters on the fly.<br>
> ><br>
> > Now I say 'normally' but I have seen a rather dirty hack (naming no names)<br>
> > performed on an instance of a Workflow whereby the 'version' value was<br>
> > changed on the fly by a direct table update to SWP_HEADER-WFD_VERS. The<br>
> > end result was surprisingly successful but only because the difference<br>
> > between the 'old' and the 'new' versions of the Workflow definition were<br>
> > relatively simple (an additional modelled outcome of an existing step) and<br>
> > were much further down the line than where the instance had successfully<br>
> > navigated to. I suspect such a hack would have had no effect on an<br>
> > instance that had already reached that step and might have actually caused<br>
> > havoc if the 'new' definition required new container elements to exist in<br>
> > the instance's container, etc etc.<br>
> ><br>
> > I'm not advocating this approach at all but in desperation (e.g. to avoid<br>
> > being sued) it is an alternative to canning the instance altogether and<br>
> > re-starting it from scratch.<br>
> ><br>
> > Rememeber that standard SAP Workflow versioning is only about 90%<br>
> > effective as well. Things like changes the Workflow container elements are<br>
> > never stored. So don't assume for a second it's anywhere near as advanced<br>
> > as ABAP program versioning where you can rollback your changes. Sometimes<br>
> > you have to manually unpick things to revert things back to how they were<br>
> > before.<br>
> ><br>
> > Oh, and forget about trying to match up the version numbers from your dev<br>
> > system to your live system. Over time these will be completely out of step<br>
> > with each other since the live system will be burning new version numbers<br>
> > every time it tries to activate a transport version (9999 in SWDSHEADER)<br>
> > and turn it into an 'active' version.<br>
> ><br>
> > If your definition has a syntax error and fails to activate AND the system<br>
> > forgets which previous version was able to be activated (can happen<br>
> > sometimes) the system will continue to try and try to activate the<br>
> > definition, merrily burning version numbers as it goes along.<br>
> ><br>
> > In one case one of our definitions jumped from version 10 to 350 in an<br>
> > afternoon in the live environment because of this.<br>
> ><br>
> > Regards,<br>
> ><br>
> > Mike GT<br>
> >> From: markdaley@westnet.com.au> To: sap-wug@mit.edu> Subject: Version<br>
> >> question> Date: Wed, 27 Feb 2008 15:59:09 +0900> > Hi folks, I have<br>
> >> existing instances of a Workflow in production that> have a bug, ie when<br>
> >> a deadline is reached the WF should terminate,> but it does not.> > I<br>
> >> know the problem and have corrected this bug in development by> adding a<br>
> >> process control step in the WF definition. > > Now my question is, is it<br>
> >> possible to transport this change to> production and have the existing<br>
> >> workflow instances ‘adopt’ this> change? When I transport to Test<br>
> >> system, a new version is created and> my changes are not picked up by<br>
> >> the running instances (presumably WF> creates a new version as there are<br>
> >> already active instances).> > Is this just the way it is?> > > ><br>
> >> _______________________________________________> SAP-WUG mailing list><br>
> >> SAP-WUG@mit.edu> http://mailman.mit.edu/mailman/listinfo/sap-wug<br>
> > _________________________________________________________________<br>
> > Who's friends with who and co-starred in what?<br>
> > http://www.searchgamesbox.com/celebrityseparation.shtml_______________________________________________<br>
> > SAP-WUG mailing list<br>
> > SAP-WUG@mit.edu<br>
> > http://mailman.mit.edu/mailman/listinfo/sap-wug<br>
> ><br>
> <br>
> <br>
> _______________________________________________<br>
> SAP-WUG mailing list<br>
> SAP-WUG@mit.edu<br>
> http://mailman.mit.edu/mailman/listinfo/sap-wug<br>
<br>
<br>
<hr>
Sounds like? How many syllables? <a href="http://www.searchcharades.com" target="_blank">
Guess and win prizes with Search Charades!</a> </div>
</body>
</html>