Skip to main content

I have successfully proved in a test workflow that a process can be restarted - and it's worklist items farmed back out to the activities they were originally sat at, but we have one more issue that I thought might be worth asking about here.

 
Normally when you fire an IPC event, and make the calling worklistitem wait until the child process finishes before continuing, how is that relationship configured?

I'm wondering about this because if you allow a process to be restarted, you may be restarting both a parent and a child process - and in that case the parent process instance may be waiting for the child to finish.

If we do a GotoActivity on the parent, it will fire the IPC event again. If however we base the IPC code on a flag - i.e. "Do not fire the IPC event if this is a restart", we still face the headache - how does the child tell the parent it has finished, and how is the parent instructed (behind the scenes) to wait for that child?


 

I realised on the way home last night that you don't need to "attach" IPC parents and children... you just have the same start mechanism on child workflows, and let the parent fire the children.

 This all sounds a LOT worse than it really is. If I could post diagrams in here easily, it would make a lot more sense :)
 


Reply