Version problem after workflow transport

[Mike Nickson]

We also had the scenario Mike G describes in his last paragraph, where an
object transported but did not activate correctly. What happened then was
every time the workflow was selected via PFTC it started to generate more
versions as it struggled to resolve a missing object attribute, but never
gave us a meaningfull message.
SAP fixed this for us be generating the object again in the receiving
system.

Mike

On 27/12/06, Mike Gambier <madgambler at hotmail.com> wrote:
>
> Amit,
>
> In some very rare circumstances the transport of your WF defintiion can
> fail, leaving none of your versions active. Hope this hasn't happened to
> you, but it can be fixed if you know the tables to 'adjust' if it has.
>
> In my experience it is worth everybody keeping a close eye on the
> following
> tables and make sure your WF versions are consistent from time to time:
>
> HRS1205 (current active version)
>
> SWDSHEADER (all versions of the WF definition, active or inactive) - note
> that version '9999' is always the latest 'Transport' version of the
> definition and should have generated a 'new' version with a lower number
> if
> it has been activated properly.
>
> In theory, the most recent active version (but not the '9999' Transport
> version) listed in SWDSHEADER _should_ match up to the current active
> version listed in HRS1205. If these two tables disagree you have a version
> issue that will need to be fixed.
>
> We run a program to compare these tables and flag up any WF definitions
> that
> are inconsistent after major releases and fixes. It can adjust the tables
> if
> need be ; )
>
> WF activation isn't always immediate by the way. Indeed, in some of our
> test
> systems we have WF definitions that have never been activated and so are
> still sitting there in there 9999 versions waiting to be activated. The
> activation code can sometimes encounter problems activating the right
> version in target systems that are future-dated where the most recent
> active
> version in the target system appears to be 'younger' than the transport
> version. SAP came back on that one and said they didn't support this kind
> of
> situation so we had to resort to table updates post-transport to keep
> things
> in line.
>
> In many cases WF activiation needs a triggering event to be raised or
> someone to check the WF using SWQUD/SWDD to kick off the 'activate new
> version' subroutines to convert version 9999 into a proper version.
> Sometimes just by executing these transactions on your WF definitions is
> enough to retrigger the 'generate active version' code and finish the job
> if
> the transport hung up halfway through. Sometimes it isn't enough though,
> often because something's up with the WF definition's syntax.
>
> SWDD can also help if there's a dodgy dialog Task complaining about agent
> determination errors. These can also hold up WF activation.
>
> Sometimes for General Tasks we find that the table entry from HRP1217 can
> sometimes go astray too. If that happens try selecting the Agent
> Assignment
> menu option inside the task and choose the attributes button to select the
> 'General Task' radio button in your target system. Even if the system is
> 'locked' for edit' this will still create the HRP1217 entry, which is a
> handy trick : )
>
> Of course Business Object changes can also cause issues. Make sure any
> objects that have been changed to support the new WF version also syntax
> check. Generate them from SWO1 if you can just to be sure. Then drop the
> WF
> buffers using SWU_OBUF before trying SWUD or SWDD again.
>
> MGT
>
> >From: "Mike Pokraka" <asap at workflowconnections.com>
> >Reply-To: "SAP Workflow Users' Group" <sap-wug at mit.edu>
> >To: "SAP Workflow Users' Group" <sap-wug at mit.edu>
> >Subject: Re: Version problem after workflow transport
> >Date: Wed, 27 Dec 2006 10:21:09 -0000 (UTC)
> >
> >Hi Amit,
> >This recently came up on SDN
> >https://forums.sdn.sap.com/click.jspa?searchID=535469&messageID=2315432
> >
> >Basically do a consistency check using SWUD.
> >Cheers,
> >Mike
> >
> >
> >On Mon, December 25, 2006 11:52 am, amit wrote:
> > > Dear All,
> > >
> > > We have just transported all our ESS related workflows to the Testing
> > > system
> > > and are facing a highly peculiar problem .
> > >
> > > During first transport, the workflows had an error saying : Workflow
> > > definition 'WS91000015' not in version '0001'.
> > > Therefore we retransported the workflows and these workflows were
> >opening
> > > fine. However, the versions of these workflow keep on increasing !!
> > > some of the workflows have generated atleast 50 versions now and i
> dont
> > > know
> > > why this is happening !!
> > >  The workflow versions of all workflows except one are increasing .
> > > we are on ECC5.0 WAS 6.4 .
> > >
> > > Could somebody please help me understand and correct why this is
> > > happening,
> > > as this is one problem ive never encountered??
> > >
> > >  Thanks and Regards,
> > > Amit Erande
> > > _______________________________________________
> > > SAP-WUG mailing list
> > > SAP-WUG at mit.edu
> > > http://mailman.mit.edu/mailman/listinfo/sap-wug
> > >
> >
> >
> >--
> >Mike Pokraka
> >Senior Consultant
> >Workflow Connections
> >Mobile: +44(0)7786 910855
> >
> >_______________________________________________
> >SAP-WUG mailing list
> >SAP-WUG at mit.edu
> >http://mailman.mit.edu/mailman/listinfo/sap-wug
>
> _________________________________________________________________
> Get FREE Web site and company branded e-mail from Microsoft Office Live
> http://clk.atdmt.com/MRT/go/mcrssaub0050001411mrt/direct/01/
>
> _______________________________________________
> SAP-WUG mailing list
> SAP-WUG at mit.edu
> http://mailman.mit.edu/mailman/listinfo/sap-wug
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/pipermail/sap-wug/attachments/20061227/b7c90dba/attachment.htm