<div>An update:</div><div>I was wrong about the change in binding (between the workflow and</div><div>the sub-workflow) causing the error. It was actually the fact that</div><div>one of the first steps in the sub-workflow was making use of the </div>
<div>attribute of a null object in a binding which caused the error.</div><div><br></div><div>The error doesn't occur if you use the attribute in a container </div><div>operation step instead, but then you end up with NULL values</div>
<div>where you may not expect them.</div><div><br></div><div>It is exactly as Kjetil wrote:</div><div><br></div><div>"I've had a similar problem once where we had to</div><div>introduce code in the business object to check whether a specific container</div>
<div>element existed in the container in order to control the behaviour"</div><div><br></div><div>In the end I think we would have chosen to do what we already did - fix</div><div>the workflows in error by hand. Not a problem if there aren't too many </div>
<div>and you have a willing workflow administrator.</div><div><br></div><div>The fact remains: think carefully about how a change to the binding</div><div>of a sub-workflow will affect workflows that are already running</div>
<div>and haven't yet called that sub-workflow.</div><div><br></div><div>regards</div><div>Rick Bakker / hanabi technology</div><br><div class="gmail_quote">On Tue, Mar 20, 2012 at 2:22 PM, Rick Bakker <span dir="ltr"><<a href="mailto:rbakker@gmail.com">rbakker@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>Hi Mike and Kjetil,</div><div><br></div><div>Thanks for your remarks.</div><div><br></div><div>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.</div>
<div><br></div><div>Definitely one to watch out for; when in doubt create a new sub-workflow template.</div><div><br></div><div>The addition of new parameters in the binding makes existing workflow instances go into error even if they aren't mandatory!</div>
<div><br></div><div>I can't say I've ever used local workflows, I'll have to look into that.</div><div class="im HOEnZb"><div><br></div><div>regards</div><div>Rick Bakker</div><div>hanabi technology</div><br>
</div><div class="HOEnZb"><div class="h5"><div class="gmail_quote">
On Mon, Mar 19, 2012 at 7:56 PM, Kjetil Kilhavn <span dir="ltr"><<a href="mailto:kjetil.kilhavn@bluec.no" target="_blank">kjetil.kilhavn@bluec.no</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
It's a bit late and will definitely not solve your current problem Rick, but<br>
perhaps a local workflow would be the solution to this. Our 'holy book' states<br>
that the recommendation is to use local workflows for subworkflows if the<br>
"subworkflow" is not called by other workflows.<br>
I haven't actually tried it, but since a local workflow is not callable outside<br>
its main workflow and not stored as a separate template I am sure it would<br>
share the runtime version with main workflow.<br>
<br>
A proper subworkflow is an independent workflow template, so you would usually<br>
not want it to be tied to the version of the calling workflow. Such a binding<br>
would for instance mean that error corrections wouldn't become effective for<br>
running instances. It would probably also make the runtime engine more<br>
complicated with multiple runtime versions of a workflow active at the same<br>
time.<br>
<br>
I see your problem though, and I've had a similar problem once where we had to<br>
introduce code in the business object to check whether a specific container<br>
element existed in the container in order to control the behaviour. It's not a<br>
good design, but at the time it was the only solution possible for us.<br>
<br>
I suppose changing the binding of a subworkflow must be considered as important<br>
as changing the binding of a published BAPI, and SAP's solution to that is to<br>
create a new BAPI function module. That's one solution, and the other is to<br>
ensure that the new version is able to handle the old binding as well, so you<br>
can't introduce a new mandatory element.<br>
<br>
Onsdag 14. mars <a href="tel:2012%2012.38.36" value="+12012123836" target="_blank">2012 12.38.36</a> skrev Mike Pokraka:<br>
<div><div>> Hi Rick,<br>
><br>
> That's how it would work. A subwf is a completely new instance of a WF.<br>
><br>
> There may be a way to call a WF with a specific version, perhaps someone<br>
> else has hacked this. But for incompatible changes to a subWF it's usually<br>
> far easier to make a copy and include that in your new version of the main<br>
> WF. For reporting purposes it's usually not a biggie.<br>
><br>
> Regards,<br>
> Mike<br>
><br>
> On Wed, March 14, 2012 12:42 am, Rick Bakker wrote:<br>
> > Hello,<br>
> ><br>
> > Could someone confirm/deny:<br>
> ><br>
> > 1. Workflow A calls sub-workflow B.<br>
> > 2. If you change sub-workflow B then existing instances of A will call<br>
> ><br>
> > the new version of B.<br>
> ><br>
> > I didn't expect this and it can cause some big problems, e.g. if you<br>
> > change<br>
> > the binding between A and B then A can even go into error when it tries<br>
> > to call B.<br>
> ><br>
> > Does anyone know a way to get A to call the version of B that was live<br>
> > when<br>
> > the instance of A was created?<br>
> ><br>
> > Be careful when changing sub-workflows!<br>
> ><br>
> > (I knew of this problem with Tasks but that's fair enough, they don't have<br>
> > versions)<br>
> ><br>
> > regards<br>
> > Rick Bakker<br>
> > hanabi technology<br>
<br>
</div></div><span><font color="#888888">--<br>
Kjetil Kilhavn <a href="tel:%28%2B47%2040220607" value="+4740220607" target="_blank">(+47 40220607</a>) - Blue Consulting AS (<a href="http://www.bluec.no" target="_blank">http://www.bluec.no</a>)<br>
</font></span><div><div>_______________________________________________<br>
SAP-WUG mailing list<br>
<a href="mailto:SAP-WUG@mit.edu" target="_blank">SAP-WUG@mit.edu</a><br>
<a href="http://mailman.mit.edu/mailman/listinfo/sap-wug" target="_blank">http://mailman.mit.edu/mailman/listinfo/sap-wug</a><br>
</div></div></blockquote></div><br>
</div></div></blockquote></div><br>