Writing a Visual Studio Web Test for InfoPath Forms Services 2007

To write a Visual Studio web test for InfoPath Forms Services (IPFS), you must first understand some of IPFS’s architecture. Before continuing, read the Forms Services Architecture article on MSDN. Pay close attention to the “Runtime Architecture” and “Rendering and Query Parameters” sections.

InfoPath Forms Services HTTP Traffic

When using an InfoPath form in the browser, a conversation between the browser and server occurs over HTTP. This conversation consists of two kinds of transactions: Invocation and Postback. Invocation occurs once when first opening the form. After the form has been invoked, one or more postbacks to the server can occur.

Invocation

Invocation is the first transaction that occurs. It loads all the resources that allow you to edit the form in the browser. Invocation is started by making a GET request to FormServer.aspx. (See How to: Use Query Parameters to Invoke Browser-Enabled InfoPath Forms for more information on the format of this request). The response includes the HTML of the form and some javascript for the form. This request also causes requests for other dependent resources. One of these dependent resources is core.js, which defines the core logic for form editing in the browser.

Current Form Data

In the browser, there is javascript running which defines several pieces of data. In particular, there is an array named g_objCurrentFormData. Data in this array will later be used to create a postback request. There are three pieces of dynamic data that will be important when writing the web test:

Data	Index of g_objCurrentFormData	Description	When does it change?
Editing Session Id	3	Identifies your session with the server	When invoking a form
Solution Id	4	Uniquely identifies the form template	When the form template has been updated
Canary	25	Used for security mitigation	With every request/postback

(The indicies above assume you have installed Service Pack 1 on your server. If you are using a pre-SP1 version the Canary will be at index 24.)

Postback

While you are interacting with a form in the browser, you may perform various actions such as typing in a text box or clicking a button. These actions are recorded in an event log, using javascript. When the form is submitted, or when logic must be performed on the server, the browser sends the event log to the server. The server plays back the actions in the event log to recreate the state of the form. Finally, the updated state of the form is returned to the browser and the browser refreshes its view of the data. This transaction is known as a postback. InfoPath has two types of postbacks - partial postback and full page postback. A partial postback is a more efficent transaction because less data is transmitted. However, some actions like view switching must use a full page postback.

Partial Postback

When a partial postback occurs, the event log is sent to the server using a POST request to Postback.FormServer.aspx. The body of the POST request contains the event log. The response from the server contains javascript to evaluate on the browser, which updates its view of the data.

Full Page Postback

When a full page postback occurs, the event log, along with some other data, is sent to the server using a POST request to FormServer.aspx. The response from the server contains HTML and javascript to render the updated view of the data.

Event Log

The event log follows a specific format which is described below in BNF. Note that the location of spaces is important.

<EventLog> ::= <EventLogInfo> ” “ <Events>

<EventLogInfo> ::= <Data0> “;” <PostbackCounter> “;” <EditingSessionId> “;” <SolutionId> “;” <Data4> “;” <Data5> “;” <Data6> “;” <Data7> “;” <Data8> “;” <Data9> “;” <Data10> “;” <Data11> “;” <Data12> “;” <Data13> “;” <Data14> “;” <Data15> “;” <Data16> “;” <Data17> “;” <Canary>

<Events> ::= <Events> “ “ <Event> | <Event> “ “

The event log consists of two main parts: EventLogInfo and Events. EventLogInfo is simply a list of items separated by semicolons. Events is a list of items separated by spaces. Each item of Events represents an action that occurred while interacting with the form.
As you can see, the three important pieces of information from g_objCurrentFormData are used in EventLogInfo.

1. Editing Session Id is at index 2
2. Solution Id is at index 3
3. Canary is at index 18

There is another piece of EventLogInfo to point out. At index 1 is the PostbackCounter. This is an integer that starts at 0 and increments with each postback.

An example event log follows.
Editing Session Id is bolded
Solution Id is italicized
Canary is underlined

8;0;3a41917c-bc1d-409b-904a-32fb82ce565b;I:5fdfe5d2-fe2b-446f-9c70-504a30b3b40f:9285a025-812e-4c2f-a194-39edbec6c50a:633415556920000000;0;;http%3A%2F%2Fmyserver%2Fexample%2FForms%2Ftemplate.xsn;http%3A%2F%2Fmyserver%2Fexample%2FForms%2Ftemplate.xsn;http%3A%2F%2Fmyserver%2Fexample%2F;http%3A%2F%2Fmyserver;http%3A%2F%2Fmyserver%2Fexample%2FForms%2FAllItems.aspx;1;1;0;10;0;633415558731245000;;xKQi13p2GSqnFUzaSU7oMSRrhdC5spPCSnMbGWAd/kp95egDGTpq2vhVf/vz4ASFTrsYvuWQIj4G68gTruRruQ==|633415558731244855 0;V1_I1_T1;0;Type%20some%20text 14;;false;false

Putting the Pieces together in Visual Studio

Now that we have a general idea how IPFS generates HTTP traffic, we can write a web test in Visual Studio. Let’s recap the relevant IPFS architecture information:

• IPFS has two main transactions when interacting with a form: Invocation and Postback
• Editing Session Id, Solution Id, and Canary are dynamic. They will need to be extracted from responses.
• Editing Session Id, Solution Id, and Canary are used in the postback request. Their values will need to be substituted in the postback body.
• Editing Session Id and Solution Id do not change between postbacks. They will only need to be extracted for the invocation request.
• Canary changes after every postback. It needs to be extracted for every request.

We have all the required knowledge; we just need to put the pieces together. The basic steps to write a web test for IPFS are:

1. Use Fiddler to capture HTTP requests
2. Use the captured information to define requests in a web test
3. Add Extraction Rules to the invocation request
4. Substitute context variables in the postback bodys
5. Add an Extraction Rule to the postback requests

Use Fiddler to capture HTTP requests

1. Start Fiddler
2. Start capturing
3. Open an InfoPath form in a web browser
4. Perform the actions you want to happen in your test

Use the captured information to define requests in a web test

1. Start Visual Studio
2. Create a new web test
3. Add an InfoPathExtractionRules reference to the test project. (You can download a dll for InfoPathExtractionRules from the Releases tab of this project. Or you can download the source code for those rules on the Source Code tab.)
4. From the fiddler capture, find the GET request for /_layouts/FormServer.aspx
5. Add that request to the web test
6. Find the postbacks which are POST requests for /_layouts/Postback.FormServer.aspx or /_layouts/FormServer.aspx
7. Add those postback requests to the web test as web service requests. Be sure to copy the postback body. The eventlog string should end with a single space. Double check that the event log you copied to the webtest ends with a single space as this is a common mistake.

Add Extraction Rules to the invocation request

1. In the web test, find the first request for /_layouts/FormServer.aspx
2. Add ExtractEditingSessionId, ExtractSolutionId, and ExtractInitialCanary extraction rules

Substitute context variables in the postback bodys

1. In the web test, find the postback requests
2. In its string body, find the event log
1. For partial postbacks, the event log will be the only data in the string body
2. For full page postbacks, the text __EventLog should precede the section containing the event log
3. Edit the EventLogInfo of the postback body as follows:
1. Replace the 3rd item with {{editingSessionId}}
2. Replace the 4th item with {{solutionId}}
3. Replace the 19th item with {{canary}}

Add an Extraction Rule to the postback requests

1. In the web test, find the postback requests
2. Add ExtractPostbackCanary extraction rule to each of these requests

Once you have followed these steps, your web test should resemble the following picture.

IpfsWebtestAutoFixer Tool

IpfsWebtestAutoFixer is tool which makes creating an InfoPath web test much easier. It automatically adds the appropriate extraction rules to the invocation request and postback requests. It also automatically substitutes context parameters in postback bodys.