Version question

[Mike Gambier]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/pipermail/sap-wug/attachments/20080227/710bf5dd/attachment.htm