Version question

[Mike Pokraka]

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
>