Conclusions On Forms Services Development

Using InfoPath 2007 and InfoPath Forms Services within a SharePoint environment is a powerful option to take legacy paper-based form processes and convert them to powerful electronic data entry mechanisms that streamline overall business process while easing overall development efforts. Although there are methods to generate forms for use within SharePoint by developing custom WebParts that contain the relevant .NET controls for data capture and event handling to fetch or submit data to a variety of a data sources, the inherent InfoPath development capabilities make it a lucrative option for form development tasks.

Forms Services solves one of the largest issues that was present in environments trying to leverage a hybrid InfoPath and SharePoint solution, where users attempting to access InfoPath forms required the InfoPath Smart Client to be installed on the requesting machine in order to input relevant data. The introduction of the XmlFormView control provided by InfoPath Forms Services allows HTML rendering of InfoPath forms either within SharePoint WebPart pages or using a custom SharePoint WebPart, allowing InfoPath forms to be accessed from any machine, regardless of available form software.

Using Design Once programming principles split object models aren’t necessary for developing forms that will render in both the InfoPath Smart Client as well as casting the form to a browser, programming intuitive forms that are environment agnostic is a straightforward task. Benefiting from integration with the System.Xml namespace, integration with powerful IDE’s such as VSTA, many familiar programming concepts and semantics are available when developing tailored, impressive electronic forms targeting the Forms Services platform.

Several types of data sources can be assimilated into the InfoPath Forms environment when using InfoPath 2007, such as Web Services or Databases, all of which can be customized further through the use of managed code. Using the inherent Data Connection Libraries that SharePoint provides allows the option to store UDC’s that are being used throughout a Forms environment to be managed in one central location and called by forms at run-time, allowing the backend connection plumbing to be hidden from users that are consuming various connection types from InfoPath.

Using the Events Manager allows the capturing of three types of events, Form events, Xml events, and Control events. Using custom code to manage these events allows the granular options which allow you to heavily control user interaction with the form in regards to event trapping and management. Calling these events can be done through the design surface control menu in the InfoPath Forms Designer, or by registering the event capturing the InternalStartup() method.

Using InfoPath Forms Services requires some consideration in the terms of security and deployment. There are three main security settings for forms, full-trust, domain, and restricted, each with their own implications that must be considered. Most importantly, administrators must approve forms that are tapping into backend business logic since they require full-trust. When deploying forms, there are certain steps that must be followed to successfully deploy a form, from initial publishing of the form to activating the form to make it available to various site collections.

Forms Services is one of the most powerful features that has been released based off the SharePoint platform. Because forms build the interface to enterprise data operations, automating forms through electronics process greatly increases overall organizational operations efficiency and procures an environment that can highlight end-user interaction into how the forms development process should develop and grow.