Sub-workflow version problems

[Rick Bakker]

Hi Mike and Kjetil,

Thanks for your remarks.

I'm starting to get more used to the idea of existing workflows calling
only the latest version of a sub-workflow. It seemed counter-intuitive at
first but now I can't think of a better way SAP could've handled it.

Definitely one to watch out for; when in doubt create a new sub-workflow
template.

The addition of new parameters in the binding makes existing workflow
instances go into error even if they aren't mandatory!

I can't say I've ever used local workflows, I'll have to look into that.

regards
Rick Bakker
hanabi technology

On Mon, Mar 19, 2012 at 7:56 PM, Kjetil Kilhavn <kjetil.kilhavn at bluec.no>wrote:

> It's a bit late and will definitely not solve your current problem Rick,
> but
> perhaps a local workflow would be the solution to this. Our 'holy book'
> states
> that the recommendation is to use local workflows for subworkflows if the
> "subworkflow" is not called by other workflows.
> I haven't actually tried it, but since a local workflow is not callable
> outside
> its main workflow and not stored as a separate template I am sure it would
> share the runtime version with main workflow.
>
> A proper subworkflow is an independent workflow template, so you would
> usually
> not want it to be tied to the version of the calling workflow. Such a
> binding
> would for instance mean that error corrections wouldn't become effective
> for
> running instances. It would probably also make the runtime engine more
> complicated with multiple runtime versions of a workflow active at the same
> time.
>
> I see your problem though, and I've had a similar problem once where we
> had to
> introduce code in the business object to check whether a specific container
> element existed in the container in order to control the behaviour. It's
> not a
> good design, but at the time it was the only solution possible for us.
>
> I suppose changing the binding of a subworkflow must be considered as
> important
> as changing the binding of a published BAPI, and SAP's solution to that is
> to
> create a new BAPI function module. That's one solution, and the other is to
> ensure that the new version is able to handle the old binding as well, so
> you
> can't introduce a new mandatory element.
>
> Onsdag 14. mars 2012 12.38.36 skrev Mike Pokraka:
> > Hi Rick,
> >
> > That's how it would work. A subwf is a completely new instance of a WF.
> >
> > There may be a way to call a WF with a specific version, perhaps someone
> > else has hacked this. But for incompatible changes to a subWF it's
> usually
> > far easier to make a copy and include that in your new version of the
> main
> > WF. For reporting purposes it's usually not a biggie.
> >
> > Regards,
> > Mike
> >
> > On Wed, March 14, 2012 12:42 am, Rick Bakker wrote:
> > > Hello,
> > >
> > > Could someone confirm/deny:
> > >
> > > 1. Workflow A calls sub-workflow B.
> > > 2. If you change sub-workflow B then existing instances of A will call
> > >
> > >    the new version of B.
> > >
> > > I didn't expect this and it can cause some big problems, e.g. if you
> > > change
> > > the binding between A and B then A can even go into error when it tries
> > > to call B.
> > >
> > > Does anyone know a way to get A to call the version of B that was live
> > > when
> > > the instance of A was created?
> > >
> > > Be careful when changing sub-workflows!
> > >
> > > (I knew of this problem with Tasks but that's fair enough, they don't
> have
> > > versions)
> > >
> > > regards
> > > Rick Bakker
> > > hanabi technology
>
> --
> Kjetil Kilhavn (+47 40220607) - Blue Consulting AS (http://www.bluec.no)
> _______________________________________________
> 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/20120320/46682aff/attachment.htm