InfoPath data store – XML vs SmartObjects

03 May

K2’s recommended approach for using InfoPath integration is to use SmartObjects as the data store as opposed to the standard XML store. Speaking from experience I don’t necessarily agree with this approach for all instances.

Using the SmartBox does give you certain advantages, the main one being that your data is in a database, which simplifies reporting and makes it available to systems without needing to parse XML. It also makes parallel activities simpler by minimising data concurrency issues. However, there are disadvantages. In our case here we had no choice but to use SmartObjects since there was a requirement to be able to view and edit the data outside of the process. If you have to decide between SmartObjects and XML, here are some reasons to consider not using SmartObjects (This is just off the top of my head, I’ll add more as I think of them):

  1. Performance. If you’re using SmartObjects you’re making back end database calls and you will have a less responsive UI (particularly if you’re using forms services).
  2. Validation Rules cannot be added to controls bound to a SmartObject property.
  3. You cannot have a drop down with manually entered options to choose from if the control is bound to a SmartObject data source. For example if I have a property ‘DayOfTheWeek’ and I want the user to choose from Monday, Wednesday or Friday then I need to create an XML field, drag that on to the form as a drop down list box, enter in the values, then remap the binding to the SmartObject control. This is because if it’s bound to a SmartObject property then you can’t set a default value in InfoPath which means you can’t click ‘Ok’.
  4. Editing SmartObjects is very painful because every field needs to be manually copied from the Load data source to the Save data source.
  5. You can’t have nested lists. For example if you have an XML structure of repeating properties (a list of departments each with a list of members) you cannot display them all with SmartObject data sources. This is because to get a list of members you need to enter in the department id and then look up the members, and then when you get to the next department and look up the members for that department the results of the previous lookup are overwritten. The workaround for this is to create a custom List SmartObejct method which flattens the department and members list, but it’s ugly and clunky.
  6. Deployment is necessarily more complicated since you’re deploying SmartObjects.
  7. Data is more difficult to get to from K2 processes – you need to load SmartObjects as opposed to using the XML data fields.


1 Comment

Posted by on May 3, 2010 in InfoPath, SmartObjects


One Response to InfoPath data store – XML vs SmartObjects

Leave a Reply

Your email address will not be published. Required fields are marked *