Hi there,
Thanks WWF team.
BaselN,
The InvokeWorkflow executes the child workflow asynchronously from the parent. If you're looking for synchronous behavior, the child workflows should be designed as custom activities instead. That way, they can be dropped directly into the parent workflow.
Ariel Schapiro has also created a sync version of the InvokeWorkflow activity:
http://staff.southworks.net/blogs/ariel/archive/2005/11/02/InvokeWorkflowSyncActivity_v_1.aspx
>Anyone got a Beta2 version of Ariel's InvokeWorkflowSync Activity they can share?
Yes, it would be most helpful if they did.
It seems very much the case that the workflow state machine is geared heavily toward asynchronous operation.
Ok, I've spent most of the afternoon migrating the InvokeWorkflowSync activity from Beta 1 --> Beta 2. It compiles fine but at runtime, the activity cannot get a reference to the runtime (null is returned), as per:
protected override ActivityExecutionStatus Execute(ActivityExecutionContext context){
runtime = context.GetService<WorkflowRuntime>();Even though the workflow is added into the services as per:
workflowRuntime.AddService(workflowRuntime);
//For the benefit of syncinvokeworkflowI have a feeling that this kind of thing was never meant to be allowed... and now in Beta 2 it has been prevented altogether. Can anyone confirm this? And if so, any ideas how I can get the invokeworkflowsync working (as the above code is critical to instantiating the new child workflow instances).
Many thanks
Frank
Since I know how many parent & child workflows are needed from the outset, I've decided to explicitly create these instances in the host. As far as I can tell, it's the best solution so far.
Regards,
Frank
