Skip to main content

I've created a workflow that kicks off multiple IPC events. The number of IPC events depends on the number of items in a database table. A subworkflow must be created for each row, which represents an account. The subworkflow must then be routed to the manager of that account.


The trouble is that the only way I've found so far to kick off multiple sub-workflows is to add multiple destination users. Some of these accounts will be managed by the same person, but K2 is only kicking off one sub-workflow per user even if some users are added multiple times.


I've tried this as a destination rule:


public void Main(ref DestinationRuleContext K2) {
 
 K2.ResolveQueuesToUsers = true;
 
 SourceCode.K2Utilities.DSHelper oDSH = new SourceCode.K2Utilities.DSHelper(SourceCode.K2Utilities.DSHelper.DSHelperNewOptionsEnum.DefaultLDAPDomain);
 System.DirectoryServices.DirectoryEntry oDEManager;
 string sManager;
 bool bAllTrue = true;
 CDest1 oDest1 = new CDest1();
 oDest1.Main(ref K2);
 if (oDest1.IsSuccess == true) {
 //== sendto
     int accounts= HelperDLL.GetNoOfAccounts();
     for(int i=0; i < accounts; i++) {
   K2.Destinations.Add(DestinationType.User, "User" + i);
  }
 
     if (bAllTrue == false) return;
 }
}


Which will just add User1, User2 etc, thus kicking off the number of workflows that I need. However each one of these uses up a licence and there could easily be more accounts than we have licences, therefore this isn't really an option.


The idea of using a loop occurred to me, but the next stage in the workflow (the main workflow that kicks off the subworkflows) requires that all subworkflows be completed first.


Any ideas?

Hi StevoCJ,


"The trouble is that the only way I've found so far to kick off multiple sub-workflows is to add multiple destination users. Some of these accounts will be managed by the same person, but K2 is only kicking off one sub-workflow per user even if some users are added multiple times."


This is unfortunately by design - the only way to kick off multiple workflows through an IPC event, would be to add UNIQUE users to the destination rule.


Regards,


Ockert

StevoCJ,


Another option would be to load your list of accounts into an XML datafield in your process, and then create a loop within your process, kicking off a sub-workflow for each of the accounts, i.e. looping the nodes in the XML list. This will avoid using the destination rule to accomplish the same thing.


See my example for looping a collection of documents:
http://nakedprogrammer.blogspot.com/2005_10_01_archive.html

Gabriel,


This is the kind of thing I was thinking. Thanks - this makes things clearer in my head regarding that section of it, but I still have the problem that the next step in the workflow - the "Done" activity in your workflow - must not start until all of the Update Request workflows have completed. In my case these workflows will contain client events and so will take an arbitrary length of time to complete.


Perhaps as part of the subworkflows, I could update a row in the database to say that it has been processed, then call a function in a module. The module can check if all the rows have been processed and fire off an event that K2 is listening for. Is that possible?


I've had an even better idea. The next step after the sub-workflow creation loop could just be a client event. It should be easy enough for the module to complete this client event automatically.


I'll let you know how I get on.

We’ve done something similar for a proof of concept and it seems that you may be making things a little more complex than needed. Let me explain:


It seems that the first part of the problem is that the number of IPC’s are not known at design time. What we’ve done is to use “unique names” for the child processes, based on the configuration source. In your case this will be coming from your database table, I’m guessing a unique ID. It doesn’t really matter as long as the names are unique for each child process required. Now, just use these names as destination users for the activity that holds your IPC event. K2 Server doesn’t validate the destination users, so they don’t actually have to exist as long as you don’t have client events in the activity. Just make sure that you configure the activity to "Create a slot for each destination". 


The second part of the problem (if I understand correctly) is that you need to wait for all the child processes to complete before continuing your parent. For this, you can:
Configure the IPC to fire Synchronously (wait for child to complete).




  2. Create an activity datafield on the activity hosting your IPC event, let’s call it “ChildDone”.


  3. Add a simple server event after the IPC that sets the “ChildDone” activity datafield to “Yes”.


  4. Set a succeeding rule on the activity that will evaluate to true if “All slots’ ChildDone = ‘Yes’”

This will force the parent process to wait for all child procs to complete.

It seems that my idea worked nicely.


I used the looping method suggested by Gabriel and added a Client Event assigned to the workflow administration account to make it pause before moving to the next step. It's unfortunate that subworkflows have to have a server event at the end to signal their completed state but, it would seem, this is unavoidable.


When the module determines that all subworkflows are complete, it logs on as the admin account and completes the waiting client event, allowing the next process to start.


DC, I did try that method too. The problem is that each time you assign a new user it takes a K2 licence. We have 140 licences, but may potentially need to have many more workflows than that starting. Even though those workflows may only be going to 20 actual people, kicking off 140 subworkflows via the destination rule would mean I have to invent 140 unique usernames, which would take away all my licences.

Reply


View our Community Site Map

Nintex Community Sitemap
Terms & ConditionsCookie settings