Version question (extended)

Wed Feb 27 08:49:51 EST 2008

Who's Mark? :)

You asked for subjective experience: A 4.7 client had a pretty well
performing system that slowed to a crawl whenever workflow got involved.
SWI2_ADM1 would timeout when querying more than one day. All this despite
being a low-volume workflow environment.

One of issues I discovered was that the developers had jammed everything
possible into the container (60+ elements for PO approval, bound to each
step) and set it to compatibility mode. Heaven knows why. I think SWWCONT
was one of the top 5 biggest tables in the entire system.

I redid the WF to reduce container elements and use XML, but unfortunately
the old junk was still around so could not tell any improvements and I
left a short while after go live.

Cheers,
Mike

On Wed, February 27, 2008 11:10 am, Mike Gambier wrote:
>
> 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
> _________________________________________________________________
> 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
>