Need help with Dynamic Destinations

  • 24 July 2007
  • 6 replies
  • 0 views
B
Badge +3

I'm new to K2 and I'm trying to decide on the right approach for dynamic assignment of destinations in my workflow. 


Here's the situation:  I have work that needs to be reviewed by different users based on the state(s) (i.e. Illinois, Ohio) that the work relates to.  Multiple people are responsible for multiple states (i.e. Jim handles Illinois and Texas and John handles Ohio and also helps with Illinois) and these assignments may change over time. 


This leads me toward using Queues and defining groups that map states to users. However it doesn't seem clean to create 50 Active Directory Groups.  I've researched creating our own version of the SQL User Manager, but it seems like you then lose the nice integrated security which scares me if we want to integrate easily with Sharepoint.  So I'm left thinking that I need to write custom code in the event for the action to look up groups from my own tables and add destinations.


I'd appreciate any feedback on the best approach to this problem. 


Thanks.

6 replies

P
Badge +13

So you only need 1 slot per state approval and you have multiple destinations for each state (Jim, John).   Depends on how many users you have, you could probably get away of using String Tables to store the members if you don't want to deal with external table & lookup.

Name string value   NJ_USER1 with value JIM's domain/ID (if you have multiple domains), then NJ_USER2 with value John's ID.   In the destination rule you could use try catch and NJ_USER & iloop to increment one by one.  

This method doesn't give you the best view on how many states a specific person is handling, but you could query the K2 table on string table to sort it if you needed to. 

P
Badge +13

You don't need to create 50 active directory groups if you assign the person explicitly. (but you do lose the dynamic changes, which I don't think happens often in your case?)

My previous method of using string table allows you to update the users w/o having to export the process again.

S
Badge +8

Hi,


With respect: I don't think StringTables are the best option in this case, StringTables should only be used to store Process Configuration parameters.


Your best bet would be to store the State to User assignments in your own SQL table(s) and then write a web service which takes a state as input and returns an XML string of users for that state, this will even work if you have more than one responsible user per state.


Use Code in the destination rule to call the web service and iterate through the repeating nodes, adding a K2 destination on each iteration. Here is an example:


 if (oDest2.IsSuccess == true)
 {
 //== sendto ALL Regional Approvers
     System.Xml.XmlDocument myXApprovers = new System.Xml.XmlDocument();
       System.Xml.XmlNode myXNode;
       myXApprovers.LoadXml(K2.ProcessInstance.XmlFields["Approvers"].Value);
       myXNode = myXApprovers.SelectSingleNode("approvers");
       if (myXNode.HasChildNodes)
       {
          foreach (System.Xml.XmlNode myXChild in myXNode.ChildNodes)
          {
    K2.Destinations.Add(DestinationType.User, myXChild.SelectSingleNode("SAMAccount").InnerXml);             
          }
       }
  else
  {
   K2.Destinations.Add(DestinationType.Queue, "FallBackRole");
  }
     if (bAllTrue == false) return;
 }


 


Regards


 Deon

B
Badge +3

Yeah - storing the user/groups in our own sql tables and using our own component to retrieve the appropriate users is the route we were thinking of going.  I should be able to create my own assembly and reference it in the code, right?


 


Thanks for the help.

S
Badge +8

Sure, you can call any assembly or web service directly from the Destination Rule Code.


-D

G
Badge +4

Hi bdoc7k2,


 


It’s always a interesting question on what is 'clean' approach to business logic. The answer is party based on opinion and partly based on other non-functional requirements. Some things to consider are:



  • maintainability (how easy should it be and by whom)


  • maintenance interface (where should the maintenance take place)


  • complexity of you code and how much time you have :-)


As for using anything other than AD for security, yes, you'll lose more than you'll gain. I don't think its uncommon to create a group for each state you have users in, as a matter of fact I would expect for your AD to already cater for this physical structure of your organisation. My preference would be AD.


 


Your other option is to implement this in a separate DB and then access the information using a code call from your destination rule. If you do go this route, keep common pitfalls in mind like performance (you'd like it to be fast and possibly implement caching), maintainability (from a network admin perspective somebody would need to maintain this information via some user interface), maintainability (from a code perspective avoid dropping lots of code into your process as this would make future maintenance of your code *very* difficult, consider putting it behind a web service in order to keep your process 'light' and allow you to change logic in the service without impacting dependant processes).


 


A last option would be to build this physical structure of your company in SharePoint by adding a 'location' property to your users list in SharePoint and then accessing this information using custom code in a web service and then calling the web service from your destination rule or loading the property from a SharePoint list event into a datafield and then using the datafield as a destination rule...


 


Have fun!

 

Reply


View our Community Site Map

Nintex Community Sitemap
Terms & ConditionsCookie settings