Sub-workflow version problems

[Rick Bakker]

An update:
I was wrong about the change in binding (between the workflow and
the sub-workflow) causing the error. It was actually the fact that
one of the first steps in the sub-workflow was making use of the
attribute of a null object in a binding which caused the error.

The error doesn't occur if you use the attribute in a container
operation step instead, but then you end up with NULL values
where you may not expect them.

It is exactly as Kjetil wrote:

"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"

In the end I think we would have chosen to do what we already did - fix
the workflows in error by hand. Not a problem if there aren't too many
and you have a willing workflow administrator.

The fact remains: think carefully about how a change to the binding
of a sub-workflow will affect workflows that are already running
and haven't yet called that sub-workflow.

regards
Rick Bakker / hanabi technology

On Tue, Mar 20, 2012 at 2:22 PM, Rick Bakker <rbakker at gmail.com> wrote:

> 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/20120417/431a678c/attachment.htm