Sunday, July 13, 2008

InfoPath and ASP.NET Development Considerations

This month at the K2 user group we did a presentation on understand the differences between InfoPath and This decision has been a pretty heavily debated thing in my company, even outside the scope of K2. InfoPath 2003 was pretty good but the licensing issues around it being installed on every client machine became challenging given it was part of MS Office Enterprise. Then with InfoPath 2007 they now allow for the forms to be web enabled however there are several limitations around them.

I believe InfoPath is a very strong tool which when used for the right scenario is better than However allows for full control and more complex applications. NOTE that I say "applications". InfoPath itself is a "forms" product that when used with product like K2 blackpearl "applications" can be built. Using InfoPath and K2 blackpearl (or K2 blackpoint) now make development of InfoPath bearable. Then next challenge is to understand the user interface requirements and business rules that need to be implemented. Typically if the application is going to require tons of CRUD operations, grids and dynamic user interfaces InfoPath will fall flat. However if the application is just presenting some information, with some light weight CRUD operations using K2 SmartObjects, using SharePoint/InfoPath can make really strong solutions.

Here are the bullets from the presentation.

Selection Criteria:

  • Worker skill set
  • System integration
  • Time to production
  • User interface requirements
  • Need to integrate with SharePoint
  • Business logic & code
  • Deployment

InfoPath Pros:

  • Improvements over 2003 (browser option, actions are handled outside of the form, multiple form templates & views can be used).
  • Quick to develop and deploy, based on XML. When I say quick; we me quick. The level of effort to create InfoPath form is significantly smaller and a wider span of designers can now build them.
  • Easy to hook into most Web services.
  • Disconnected / Offline use.
  • InfoPath does force developers to write pretty decoupled applications in that much of the user interface rules will be captured in InfoPath and all business logic will be pushed to a business/service layer.

K2 InfoPath Pros:

  • K2 allows for true business processes to be built around InfoPath instead of embedding the logic in .Net managed code, script or SharePoint server events.
  • XML captured becomes part of the process and is accessible through the K2 Object/Context browsers. There is no need to build up functionality to get data and use it within the K2 process. However almost all of that has been alleviated with K2 SmartObjects.
  • K2 SmartObject integration with the InfoPath form itself.
  • InfoPath forms become part of the K2 project.
  • Can be used in server events for XML storage.

InfoPath Cons:

  • If using the InfoPath client, it must be installed on every user's computer that will participate in the workflow.
  • Browser-based forms, cannot use the full set of controls that are available in the InfoPath client application (InfoPath 2007 features that are unavailable in InfoPath Forms Services and Web browser compatibility in InfoPath Forms Services).
  • Browser-based forms require MOSS enterprise licensing. Just trying to use Form Services with WSS is not any cheaper from a cost perspective.
  • Browser-based forms are difficult to configure for non-AD authentication (FBA).
  • Browser-based forms are hard to control number of postbacks browser-based forms make to server. Things like using AJAX and Flash are not supported.
  • Fully-trusted forms, difficult barrier in some environments.
  • Debugging and troubleshooting is limited, can be difficult for web enabled forms.
  • Hard to control look and feel, and state of controls (enabled / disabled). This is even more challenging with web enabled forms. It is very hard to make it follow corporate branding requirements when published over a public internet site.
  • Event model for InfoPath is based on the XML document, not the user interface. This requires a different way of thinking when using custom code.
  • Controls bound to secondary data sources can't be easily validated (InfoPath limitation).
  • Little support for handling multiple languages via resource files.
  • Can only be used with an InfoPath Integrated process -- can't use with a SharePoint integrated process.
  • Kerberos issue still not fixed with MOSS SP1 (MS hotfix reference: KB941470 - more detail information).

K2 InfoPath Cons:

  • Highly complex browser-enabled forms (lots of data connections, code behind, larger in size) may fail to convert when deployed.
  • File attachments can make the form huge and cause the size of the K2 database to grow significantly.
  • If you have to go into code you probably should avoid InfoPath unless you're really comfortable – forms with code not officially supported in K2 (read this for help).
  • Form file left in SharePoint library (can be changed in Advanced Mode but only for client forms -- browser-enabled forms will always remain in the library).


  • Flexibility.
  • Standard ASP.Net + Workflow.Client and SmartObject.Client namespaces, typically.
  • Better control of session state for large forms or attachments.
  • No Licensing considerations other than Windows Server.
  • Standard debugging.
  • Outside of the K2 project.


  • Longer development cycles.
  • Custom code means more complex maintenance and management of projects.
  • Outside the scope of K2 project -- must be deployed separately and kept in synch with K2 project.
  • Can't be used with SharePoint integrated workflows.

InfoPath Design Considerations

  • Do you need managed code? If you have lots of it, use
  • Use ASP.NET pages for wider audience and then use InfoPath form back office business processes. It is possible in K2 to have processes that using both InfoPath and client events.
  • How many views do you need?
  • Having lots of fields in a view is not a problem unless every field has a validation and conditional logic rule.
  • Store data in the InfoPath form?
  • Do not pollute your main data source.
  • Working with required fields across views?
  • Chaining multiple InfoPath forms into a single process.
  • Understand Destination Plans and how XML is managed by K2?


Most of my K2 implementation to date has been successful InfoPath solutions. This all comes down to understanding the scope of the implementation and selecting the right tool. I know I am betraying my app dev roots when I say InfoPath is great because it is hard to get the level of control and customization you want with ASP.NET. The value proposition with InfoPath (with K2 blackpearl) is that it allows for very rapid application development and deployment with a large base of developers. Developers with a good MIS background can do this and do not require a CS background. InfoPath applications require less engineering and have a greater maintainability potential. However InfoPath forms just cannot handle complex business rules or multiple screen CRUD interfaces.

We do not that Microsoft is making a significant investment into InfoPath Forms Server in the next generation of SharePoint and MS Office. Like Excel Services, it is their first release of the technology. I am pretty confident the gap will be closed.


Anonymous said...

your site is very nice ...
this is very helpful and attractive.
visit for help help

Adeeb said...

Lastly, I was assigned to evaluate a well famous workflow engine by K2 which is BlackPearl.
I did a deep online search about and then I stopped at your blog. So I thought based in your long experience you can help me to clearly some points about K2 BP (BlackPearl):
1- In your opinion, what makes PB better than Microsoft SharePoint, in terms of:
- Can developer without any previous experience on SharePoint work on PB?
- How easy or difficult to do the following:
o Installation
o Maintenance
o Ensure system security
o Usability (How much time and effort it will takes from a developer to learn/master PB?)
2- In my organization, we are willing to provide a business solution by using a workflow. So not all parties that we will work with have SharePoint.
a. Can we use the full capability of PB without using SharePoint?
b. How deep can we go if we want to customize PB to meet our business need?
c. If we want to integrate PB with our system/solution, is that something possible in PB? Is it easy or hard to accomplish?
Please excuse me if you found that these questions are too much, but I really need help to take the right action.
Looking forward to your replay.
Best regards,

Jason Apergis said...


No problem. Here are some high level responses:

- Developers do not have to have SharePoint app dev experience to use BlackPearl. However it would be good for them to aquire them.
- Installation is for BlackPearl is much better than what it used to be. They have made huge strides in past year to help with this. Only hard part is getting Kerberos propertly configured. I have a blog on the topic which will help.
- K2 provides some tools for non-developers. As for development, even though K2 provides tons of wizards and code generation for the developer, it still takes time to master and "really" become an expert. I would give someone 4 to 6 months on solid experience.
- YES - k2 works without SharePoint. It is the only platform out there that does that when you compare to Nintex or AgilePoint. I have used it many times for doing process automation for, winforms, mainframes, SQL server, WCF services, etc.
- The code generated is completely customizable and you add in your own custom code events as you wish. I did this a lot in the past.
- Integration just takes planning. You will have challenges with any product if the systems are legacy and complex in nature.

Does that help?