This month at the K2 user group we did a presentation on understand the differences between InfoPath and ASP.net. 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 ASP.net. However ASP.net 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.
- Worker skill set
- System integration
- Time to production
- User interface requirements
- Need to integrate with SharePoint
- Business logic & code
- 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.
- 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).
- 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 ASP.net.
- 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 ASP.net 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.