Version question (extended)

Wed Feb 27 08:43:43 EST 2008

Mike,

No comment on the locking behavior as I have not played around with this. Love to hear what other have experienced.

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.

Regards,

Alon Raskin
e: araskin at 3i-consulting.com<mailto:araskin at 3i-consulting.com>
<http://www.themobileworkplace.com>
________________________________
From: sap-wug-bounces at mit.edu [sap-wug-bounces at mit.edu] On Behalf Of Mike Gambier [madgambler at hotmail.com]
Sent: Wednesday, February 27, 2008 5:10 AM
To: SAP Workflow Users' Group
Subject: RE: Version question (extended)

Thanks Mark :)

On the subject of EC 6.0 and the new version-dependent settings I have a few questions of my own.

Has anyone tried the 'Locking properties' settings to see what performance benefits there are with the new values?

   => Standard behaviour (default)
   => Lock behaviour for Sequential Workflows
   => Lock behaviour for Background Workflows

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.

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

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.

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.

Regards,

Mike GT

> Date: Wed, 27 Feb 2008 10:44:17 +0000
> Subject: RE: Version question
> From: wug at workflowconnections.com
> To: sap-wug at mit.edu
>
> Mike: Great piece of info, thanks.
> Mark: Also have a looky on OSS, search for "workflow version" there's a
> note 1240005 or some number like that which explains the difference
> between version-dependent and version-independent changes.
>
> On Wed, February 27, 2008 8:03 am, Mike Gambier wrote:
> >
> > Hi Mark,
> >
> > The short answer is probably 'no'. An instance that has kicked off will
> > know what version of the definition it is supposed to use throughout its
> > life (stored on SWP_HEADER-WFD_VERS) and normally that doesn't change,
> > ever.
> >
> > There are good reasons for this, not least of which is that the Workflow
> > definition dictates to the system not only what the expected next steps
> > should be in the chain but also what table entries to create in the
> > twenty-odd other dedicated Workflow tables to model it all. It's like a
> > blueprint; you wouldn't want to change the design of the first floor of
> > your house having already laid the foundations based on your previous plan
> > now would you? What if you missed out an entire staircase?
> >
> > I say normally but a few things might be possible might persuade the
> > Workflow to behave a little differently 'in flight':
> >
> > 1. Changing the current active version of a Sub-Workflow in a later step
> > after the Parent Workflow has been started is OK. The Parent does not care
> > what the active version of the Sub-Workflow used to be prior to reaching
> > the step, it will just use whatever is the 'active' version at that point
> > in time. But the actual binding used to call the Sub-Workflow (or anything
> > else for that matter) is sensitive to version changes, so be careful on
> > this one if the signature has changed in any way.
> >
> > 2. Amend the actual code behind a Business Object Attribute or Method
> > prior to the Workflow reaching a step that calls the code. Again the
> > Workflow will use whatever has been loaded into the active runtime buffer
> > when it reaches the step. This can cause a bit of grief if the Task/Method
> > binding has changed by the way, so again watch out and avoid adding new
> > 'mandatory' parameters on the fly.
> >
> > Now I say 'normally' but I have seen a rather dirty hack (naming no names)
> > performed on an instance of a Workflow whereby the 'version' value was
> > changed on the fly by a direct table update to SWP_HEADER-WFD_VERS. The
> > end result was surprisingly successful but only because the difference
> > between the 'old' and the 'new' versions of the Workflow definition were
> > relatively simple (an additional modelled outcome of an existing step) and
> > were much further down the line than where the instance had successfully
> > navigated to. I suspect such a hack would have had no effect on an
> > instance that had already reached that step and might have actually caused
> > havoc if the 'new' definition required new container elements to exist in
> > the instance's container, etc etc.
> >
> > I'm not advocating this approach at all but in desperation (e.g. to avoid
> > being sued) it is an alternative to canning the instance altogether and
> > re-starting it from scratch.
> >
> > Rememeber that standard SAP Workflow versioning is only about 90%
> > effective as well. Things like changes the Workflow container elements are
> > never stored. So don't assume for a second it's anywhere near as advanced
> > as ABAP program versioning where you can rollback your changes. Sometimes
> > you have to manually unpick things to revert things back to how they were
> > before.
> >
> > Oh, and forget about trying to match up the version numbers from your dev
> > system to your live system. Over time these will be completely out of step
> > with each other since the live system will be burning new version numbers
> > every time it tries to activate a transport version (9999 in SWDSHEADER)
> > and turn it into an 'active' version.
> >
> > If your definition has a syntax error and fails to activate AND the system
> > forgets which previous version was able to be activated (can happen
> > sometimes) the system will continue to try and try to activate the
> > definition, merrily burning version numbers as it goes along.
> >
> > In one case one of our definitions jumped from version 10 to 350 in an
> > afternoon in the live environment because of this.
> >
> > Regards,
> >
> > Mike GT
> >> From: markdaley at westnet.com.au> To: sap-wug at mit.edu> Subject: Version
> >> question> Date: Wed, 27 Feb 2008 15:59:09 +0900> > Hi folks, I have
> >> existing instances of a Workflow in production that> have a bug, ie when
> >> a deadline is reached the WF should terminate,> but it does not.> > I
> >> know the problem and have corrected this bug in development by> adding a
> >> process control step in the WF definition. > > Now my question is, is it
> >> possible to transport this change to> production and have the existing
> >> workflow instances ‘adopt’ this> change? When I transport to Test
> >> system, a new version is created and> my changes are not picked up by
> >> the running instances (presumably WF> creates a new version as there are
> >> already active instances).> > Is this just the way it is?> > > >
> >> _______________________________________________> SAP-WUG mailing list>
> >> SAP-WUG at mit.edu> http://mailman.mit.edu/mailman/listinfo/sap-wug
> > _________________________________________________________________
> > Who's friends with who and co-starred in what?
> > http://www.searchgamesbox.com/celebrityseparation.shtml_______________________________________________
> > SAP-WUG mailing list
> > SAP-WUG at mit.edu
> > http://mailman.mit.edu/mailman/listinfo/sap-wug
> >
>
>
> _______________________________________________
> SAP-WUG mailing list
> SAP-WUG at mit.edu
> http://mailman.mit.edu/mailman/listinfo/sap-wug

________________________________
Sounds like? How many syllables? Guess and win prizes with Search Charades!<http://www.searchcharades.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/pipermail/sap-wug/attachments/20080227/d1c24bd6/attachment.htm