In the SharePoint Central Administration console, in the General Application Settings area, you will find important settings that control various facets of IPFS across the entire SharePoint farm. Unless you are managing a very large SharePoint environment (or a multi-tenant hosting service), these are not settings that you will need to adjust very often, but it is important to know what modifications are possible at the SharePoint farm level.

To ensure that you have a basic understanding of the IPFS administrative options for your SharePoint environment, the following exercise walks you through the primary IPFS configuration settings in SharePoint Central Administration.

One of the most common challenges with browser-based forms (aside from performance) is related to the security and authentication process. Sometimes, form designers are surprised when their forms work just fine in the InfoPath client but fail anytime someone attempts to use the same form in the browser. This often happens because (unlike the InfoPath client) a browser form communicates with the server via the XMLHTTP protocol, which is stateless. In other words, the browser form cannot pass on the user credentials to remote data sources the same way a regular InfoPath client form can (via NT LAN Manager [NTLM]). This more complex submission process can introduce authentication problems in scenarios for which the data connections are in different domains (other servers). This is generally referred to as a double-hop problem, and it is a very common challenge for IPFS administrators.

Occasionally, you will have scenarios in which you want to connect a browser-based form to a web services data source that resides outside the domain of your SharePoint environment. In these cases, user authentication can become very complex because the browser-based forms do not have the ability to forward the user credentials to the remote server. Conveniently though, SharePoint provides the web proxy service for IPFS, which will essentially act as a proxy between the form and the third-tier data source. The web proxy service provides a facility for SharePoint to pass on the user’s authentication credentials to the remote web service, ensuring that the user can fill out the form and retrieve data from the web service, as expected. Notice in the following screenshot that you are given the option to enable the web proxy for user forms. This option controls whether or not the web service proxy is available to forms uploaded by users. If the Enable check box is left cleared, only forms uploaded by administrators can use the web service proxy.

We are all familiar with the frustrating experience of using slow websites on the Internet. Because IPFS is an HTTP-based system, you can encounter some of the same performance challenges as slow Internet sites—if you don’t have a solid plan in place to mitigate the potential issues. Aside from a poorly designed SharePoint environment (a discussion of which is beyond the scope of this book), several conditions can negatively impact the performance of browser-enabled forms. The following are the most common factors that you are likely to encounter:

Many of these potential performance inhibitors can be easily eliminated by making one or more design changes within your browser form. The challenge when chasing down an IPFS performance issue is to narrow down the potential candidate pool of problems; that can be a difficult task without sufficient information. Therefore, a deeper understanding of how IPFS actually communicates with a SharePoint server and obtaining a snapshot of the underlying web traffic that your form is generating is sometimes a necessary task.

To facilitate this information gathering, you need to install one additional software utility on your system. This free tool is called Fiddler, and its primary purpose is to log all HTTP activity between your computer and a website (in this case, the server hosting the browser form). Even if you’ve never done any network traffic analysis, Fiddler makes it very easy to see all the details of what your form is doing at load and submission time.

In the following three exercises, you will use Fiddler to help you understand how to do basic performance analysis of IPFS forms.

You can see from the preceding exercise that monitoring the details of IPFS HTTP traffic is easy to do with a web analysis program such as Fiddler and that such a program can be an invaluable addition to your toolkit when troubleshooting performance problems.

As mentioned earlier in the chapter, there are many possible reasons why your IPFS forms are not performing as well as you’d like. One of the most obvious is a form that generates a lot of traffic because of the size of the HTML that the form is generating. Among the many ways that you can end up with large, unwieldy forms, one of the most common is giving users the ability to add attachments. When a user embeds a file or picture in a browser-based form, the attachments must be saved with the form to the SharePoint form library.

We’re not encouraging you to disallow all attachments; this is merely one example of how a form can quickly grow into a performance challenge. Therefore, the point of the following exercise is not to pick on any certain controls but to illustrate how to use Fiddler to monitor a form that has an attachment. In the exercise, you’ll use the picture control because it’s easy to work with.

Aside from the overall size of the HTML generated for a form (which we looked at in the previous two exercises), probably the most common of all the potential factors that might affect IPFS performance are postbacks. Some form controls, actions, and features require a user’s browser to communicate with the server while in the process of a form-filling session. The interchange of data during a session is called a postback, and it usually occurs when a form needs to send data from the user’s browser back to the server for processing and then has to wait for a response to update and re-render the form. This can make postbacks a particularly expensive performance problem because they can quickly increase the required network traffic for a form each time a postback occurs.

Because IPFS forms are so reliant on the server, postbacks will sometimes be unavoidably necessary. Fortunately, the challenges that postbacks pose can be mitigated by a forms designer who has the knowledge and techniques to minimize them. Sometimes the difference between creating a poor performing form and a good one is not to eliminate postbacks but rather to minimize them by giving thought to the problems postbacks can cause if the form user interface is built without appropriate consideration of performance. When designing a browser form, most controls have an option on the control properties for forcing postbacks (see the following illustration). This would be a rare exception though; generally, best practice is to leave this option at the default setting.

Armed with the proper knowledge of postbacks—why they occur and how to monitor your forms to identify potential problems—you can design a form to minimize the situations that cause them, usually without losing important functionality.

A few of the most common scenarios that cause postbacks are as follows:

If you watch activity in Fiddler while making the selection indicated above in the Flight Delay form, you’ll see a postback event that looks similar to the following illustration, triggered by the selection of a different option in the choice group.

In the following exercise, you will use Fiddler to monitor a form-load process and then capture a postback event during the form-filling experience. The form is one you’re already familiar with if you completed the exercises in Chapter 9.

The event generated by the preceding exercise did not cause a large amount of network traffic. However, in a real world scenario, where the button is connected to a larger data source such as a database, the postback events could become very unwieldy. Some designers will set the data to load when the form is first loaded. This strategy can be problematic because the initial form load has a great deal of impact on users’ perception of overall performance of the form. In some circumstances, a better approach is to give users a button in the interface that loads data (similar to the Event Registration form). This approach sets the expectation that a delay will occur so that users are not surprised when the form takes a few seconds to fetch data.

Now you know how to monitor a form and watch for postbacks. This is a useful skill for any IPFS forms designer. Postbacks are a necessary evil with browser forms; it is simply the nature of the way any HTTP-based form application must work. So the goal isn’t to eliminate them—that’s not really possible. However, now that you know when, where, and why they occur, you can design your forms to minimize the impact on performance and usability that postbacks will cause for your users.