I haven't tried this yet myself (though I will, as I am in the same boat as you) but if you specify all of your IPC events to be Synchronous, does it have the desired effect?  I'm not sure if it will wait for the first one to finish before starting the second, etc.  I'll give it a try tomorrow, but if you get to it sooner let me know what happens.  Thanks!

Hi

I only have the 1 IPC event in my parent process and that calls multiple instances of a child process. This IPC event is set to synchronous and therefore I assumed it would wait for all the child instances to finish before it continues to the next step of the parent process but this is not the case, as soon as the first child finishes the parent continues.

As for the child processes running at the same time - I am currently setting off 2 child instances that as part of their job send out an email requesting that they are approved and then wait until they have been approved before completing. By looking at the console I can see that process 1 runs and sends the email but has not completed and is awaiting approval when process 2 starts until it gets to the same point. Then as soon as I approve instance 1 it completes and the parent annoyingly moves on.

So they do run asynchronously and unfortunately completely independent of each other.

Let me know if you find anything - Or if anyone else knows, there's now 2 of us wondering!

In K2 2003 you had to set a succeeding rule on the parent activity. Blackpearl is probably similar. Here's the code I use in 2003:

public void Main(ref SucceedingRuleContext K2) {
    bool result = true;
    foreach(ActivityInstanceDestination dest in K2.ActivityInstance.Destinations) {
        if(dest.Status.ToString() != "Complete") {
            result = false;
        }
    }
    K2.SucceedingRule = result;
}
 

StevoCJ is on the right track in using suceeding rules.  Here's an approach I use in blackpearl without writing any custom code.

First, I create a process-level variable in the sub-process to contain the result.  Let's call it something like "SubProcessResult".  When the sub process is done, I'll put a value in this field, say "Done".

Next, I'll create an activity-level data field on the activity in the calling workflow that contains the IPC event.  We could also call this one "SubProcessResult" or whatever works for you.  Then in the IPC event, I map a return value from the sub process field to the activity level field in the IPC activity.  In this example, from SubProcessResult in the sub process to SubProcessResult in the IPC activity. 

Finally I create a suceeding rule for the activity containing the IPC Event.  The suceeding rule looks something like "All Slots of SubProcessResult = Done". 

Using a combination of suceeding rules and line rules, I could actually have the sub process return one of several results, then take the appropriate path in the main workflow.

Hello All

Thanks for the help. I have used a suceeding rule to make this work but I have done it in a slightly different way to above.

It's a PO approval system and the child instances represent the lines in the PO and the parent process represents the main PO approval hence it needing to wait for all lines to be approved. All these lines are stored in a SmartObject and therefore I have access through SQL to the table they are stored in.

So I added a 'Default Server Event (Code)'  just below the IPC Event in the same Activity box. 

Then I set up a data field in my parent called 'LinesWaiting' and used the Server event to send this data field to a stored procedure.

The stored procedure does a count of the lines in the SmartObject table that have a status of 'Waiting'. The 'LinesWaiting' variable is set with the count value and returned to k2.

The suceeding rule for the activity box is then set to: LinesWaiting = 0.

Thanks again

Rich