ipfswebtest Wiki & Documentation Rss Feed

New Comment on "IpfsWebtestAutoFixer"

DSF — Fri, 17 Sep 2010 05:03:10 GMT

The dll for VS2010 does not work. I get 'Operation not supported' errors when I reference the dll and attemp to open any extraction rule ?

Updated Wiki: Home

JBooze — Tue, 18 Nov 2008 23:18:10 GMT

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.

Editing Session Id is at index 2
Solution Id is at index 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:

Capture HTTP requests using Fiddler or Visual Studio
Add the ExtractAndSubstituteDynamicInfoPathData web test plugin. This plugin does all the hard work for us at runtime. It identifies which responses are for InfoPath and extracts Current Form Data to a context parameter. Then it identifies InfoPath postback requests and substitutes the dynamic pieces of data into the postback body.

Capture HTTP requests

Start Visual Studio
Create a new web test
Start capturing using Visual Studios Web Test Recorder
Open an InfoPath form in a web browser
Perform the actions you want to happen in your test
Click the stop button in the Web Test Recorder

Add ExtractAndSubstituteDynamicInfoPathData web test plugin

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 the extraction rules and plugin on the Source Code tab.)
Add ExtractAndSubstituteDynamicInfoPathData web test plugin. For the common usage of InfoPath, just leave the InvocationPath parameter blank. When InvocationPath is blank, the plugin should use _layouts/FormServer.aspx at run time. However, if your InfoPath form is in an XmlFormViewControl, you will need to specify the InvocationPath parameter to identify which requests act as an InfoPath invocation. If a request url contains the InvocationPath string, then it is identified as an InfoPath request.

The original technique for writing a web test with InfoPath involved individual extraction rules and manual steps with context parameters. The instructions for that technique can be found on Using the Individual Extraction Rules.

Updated Wiki: Home

JBooze — Thu, 24 Jul 2008 22:49:26 GMT

Writing a Visual Studio Web Test for InfoPath Forms Services 2007

InfoPath Forms Services HTTP Traffic

Invocation

Current Form Data

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

Partial Postback

Full Page Postback

Event Log

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

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:

Capture HTTP requests using Fiddler or Visual Studio
Add the ExtractAndSubstituteDynamicInfoPathData web test plugin. This plugin does all the hard work for us at runtime. It identifies which responses are for InfoPath and extracts Current Form Data to a context parameter. Then it identifies InfoPath postback requests and substitutes the dynamic pieces of data into the postback body.

Capture HTTP requests

Start Visual Studio
Create a new web test
Start capturing using Visual Studios Web Test Recorder
Open an InfoPath form in a web browser
Perform the actions you want to happen in your test
Click the stop button in the Web Test Recorder

Add ExtractAndSubstituteDynamicInfoPathData web test plugin

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 the extraction rules and plugin on the Source Code tab.)
Add ExtractAndSubstituteDynamicInfoPathData web test plugin. If your InfoPath form is in an XmlFormViewControl, use the InvocationPath parameter to identify which requests are for InfoPath. If a request url contains the InvocationPath string, then it is identified as an InfoPath request.

Updated Wiki: Home

JBooze — Thu, 24 Jul 2008 22:41:37 GMT

Writing a Visual Studio Web Test for InfoPath Forms Services 2007

InfoPath Forms Services HTTP Traffic

Invocation

Current Form Data

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

Partial Postback

Full Page Postback

Event Log

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

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:

Capture HTTP requests using Fiddler or Visual Studio
Add the ExtractAndSubstituteDynamicInfoPathData web test plugin. This plugin does all the hard work for us at runtime. It identifies which responses are for InfoPath and extracts Current Form Data to a context parameter. Then it identifies InfoPath postback requests and substitutes the dynamic pieces of data into the postback body.

Capture HTTP requests

Start Visual Studio
Create a new web test
Start capturing using Visual Studios Web Test Recorder
Open an InfoPath form in a web browser
Perform the actions you want to happen in your test
Click the stop button

Add ExtractAndSubstituteDynamicInfoPathData web test plugin

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 the extraction rules and plugin on the Source Code tab.)
Add ExtractAndSubstituteDynamicInfoPathData web test plugin. If your InfoPath form is in an XmlFormViewControl, use the InvocationPath parameter to identify which requests are for InfoPath. If a request url contains the InvocationPath string, then it is identified as an InfoPath request.

Updated Wiki: Using the Individual Extraction Rules

JBooze — Thu, 24 Jul 2008 20:39:45 GMT

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:

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

Use Fiddler to capture HTTP requests

Start Fiddler Cannot resolve link: [image:start fiddler.jpg]
Start capturing
Open an InfoPath form in a web browser Cannot resolve link: [image:open form.jpg]
Perform the actions you want to happen in your test Cannot resolve link: [image:perform actions in browser.jpg]

Use the captured information to define requests in a web test

Start Visual Studio
Create a new web test
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.)
From the fiddler capture, find the GET request for /_layouts/FormServer.aspx Cannot resolve link: [image:fiddler invocation selected.jpg]
Add that request to the web test Cannot resolve link: [image:create invocation request.jpg]
Find the postbacks which are POST requests for /_layouts/Postback.FormServer.aspx or /_layouts/FormServer.aspx Cannot resolve link: [image:fiddler postback selected.jpg]
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. Cannot resolve link: [image:create postback request.jpg]

Add Extraction Rules to the invocation request

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

Substitute context variables in the postback bodys

In the web test, find the postback requests
In its string body, find the event log

For partial postbacks, the event log will be the only data in the string body
For full page postbacks, the text __EventLog should precede the section containing the event log

Edit the EventLogInfo of the postback body as follows:

Replace the 3rd item with {{editingSessionId}}
Replace the 4th item with {{solutionId}}
Replace the 19th item with {{canary}}

Cannot resolve link: [image:postback substitute.jpg]

Add an Extraction Rule to the postback requests

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

Once you have followed these steps, your web test should resemble the following picture.
Cannot resolve link: [image:complete webtest.jpg]

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.

Updated Wiki: Home

JBooze — Thu, 24 Jul 2008 20:39:20 GMT

Writing a Visual Studio Web Test for InfoPath Forms Services 2007

InfoPath Forms Services HTTP Traffic

Invocation

Current Form Data

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

Partial Postback

Full Page Postback

Event Log

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

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:

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

Use Fiddler to capture HTTP requests

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

Use the captured information to define requests in a web test

Start Visual Studio
Create a new web test
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.)
From the fiddler capture, find the GET request for /_layouts/FormServer.aspx
Add that request to the web test
Find the postbacks which are POST requests for /_layouts/Postback.FormServer.aspx or /_layouts/FormServer.aspx
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

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

Substitute context variables in the postback bodys

In the web test, find the postback requests
In its string body, find the event log

For partial postbacks, the event log will be the only data in the string body
For full page postbacks, the text __EventLog should precede the section containing the event log

Edit the EventLogInfo of the postback body as follows:

Replace the 3rd item with {{editingSessionId}}
Replace the 4th item with {{solutionId}}
Replace the 19th item with {{canary}}

Add an Extraction Rule to the postback requests

In the web test, find the postback requests
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

UPDATED WIKI: IpfsWebtestAutoFixer

JBooze — Wed, 04 Jun 2008 18:22:06 GMT

Using the IpfsWebtestAutoFixer Tool

IpfsWebtestAutoFixer is a console application that can be run on a webtest saved from Fiddler. It automatically adds the appropriate extraction rules to the invocation request and postback requests. It also automatically substitutes context parameters in postback bodys. This tool requires that a version of Visual Studio 2008 with webtesting capabilities is installed on your machine.

Steps to write an InfoPath web test with the IpfsWebtestAutoFixer Tool

Use Fiddler to capture HTTP requests
Save the session as Visual Studio Web Test
Use IpfsWebtestAutoFixer tool on the .webtest file

Use Fiddler to capture HTTP requests

Use the same process described on the Home page.

Save the session as Visual Studio web test

Select the requests you want in your webtest
File | Save | Session(s) | as Visual Studio Web Test...

Use IpfsWebtestAutoFixer tool on the .webtest file

The syntax is as follows:
IpfsWebtestAutoFixer.exe [webTest] [fixedWebTest] [invocationPath]

Arguments	Description
webTest	Path to the web test file to fix up. In this example, the web test that was saved from Fiddler.
fixedWebTest	File path for the fixed up web test to save. Overwrites an existing file or creates a new file.
invocationPath	Optional. String used to identify the invocation request of an InfoPath form. A request matches if its URL contains invocationPath. The default value is "/_layouts/FormServer.aspx" You will need to use this argument when the InfoPath form is in an XmlFormView control.

A file selection dialog for webTest and fixedWebTest will appear if no arguments are given. However, the only way to use the invocationPath option is by using its command line argument.

Examples

A session of fiddler was saved to webTestSavedFromFiddler.webtest. Fix the webtest and save it to myFixedWebTest.webtest.
IpfsWebtestAutoFixer.exe webTestSavedFromFiddler.webtest myFixedWebTest.webtest

A session of fiddler was saved to webTestSavedFromFiddler.webtest. Fix the webtest and save it to myFixedWebTest.webtest. The InfoPath form was in an XmlFormView control which was on the page MyPageWithFormViewControl.aspx.
IpfsWebtestAutoFixer.exe webTestSavedFromFiddler.webtest myFixedWebTest.webtest MyPageWithFormViewControl.aspx

UPDATED WIKI: IpfsWebtestAutoFixer

JBooze — Wed, 04 Jun 2008 18:15:23 GMT

Using the IpfsWebtestAutoFixer Tool

Steps to write an InfoPath web test with the IpfsWebtestAutoFixer Tool

Use Fiddler to capture HTTP requests
Save the session as Visual Studio Web Test
Use IpfsWebtestAutoFixer tool on the .webtest file

Use Fiddler to capture HTTP requests

Use the same process described on the Home page.

Save the session as Visual Studio web test

Select the requests you want in your webtest
File | Save | Session(s) | as Visual Studio Web Test...

Use IpfsWebtestAutoFixer tool on the .webtest file

The syntax is as follows:
IpfsWebtestAutoFixer.exe [webTest] [fixedWebTest] [invocationPath]

Arguments	Description
webTest	Path to the web test file to fix up. In this example, the web test that was saved from Fiddler.
fixedWebTest	File path for the fixed up web test to save. Overwrites an existing file or creates a new file.
invocationPath	Optional. String used to identify the invocation request of an InfoPath form. A request matches if its URL contains invocationPath. The default value is "/_layouts/FormServer.aspx" You will need to use this option when the InfoPath form is in an XmlFormView control.

A file selection dialog for webTest and fixedWebTest will appear if no arguments are given. However, the only way to use the invocationPath option is by using its command line argument.

Examples

UPDATED WIKI: Home

JBooze — Wed, 04 Jun 2008 16:40:31 GMT

Writing a Visual Studio Web Test for InfoPath Forms Services 2007

InfoPath Forms Services HTTP Traffic

Invocation

Current Form Data

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

Partial Postback

Full Page Postback

Event Log

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

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:

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

Use Fiddler to capture HTTP requests

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

Use the captured information to define requests in a web test

Start Visual Studio
Create a new web test
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.)
From the fiddler capture, find the GET request for /_layouts/FormServer.aspx
Add that request to the web test
Find the postbacks which are POST requests for /_layouts/Postback.FormServer.aspx or /_layouts/FormServer.aspx
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

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

Substitute context variables in the postback bodys

In the web test, find the postback requests
In its string body, find the event log

For partial postbacks, the event log will be the only data in the string body
For full page postbacks, the text __EventLog should precede the section containing the event log

Edit the EventLogInfo of the postback body as follows:

Replace the 3rd item with {{editingSessionId}}
Replace the 4th item with {{solutionId}}
Replace the 19th item with {{canary}}

Add an Extraction Rule to the postback requests

In the web test, find the postback requests
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

UPDATED WIKI: Home

JBooze — Fri, 16 May 2008 23:50:54 GMT

Writing a Visual Studio Web Test for InfoPath Forms Services 2007

InfoPath Forms Services HTTP Traffic

Invocation

Current Form Data

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

Partial Postback

Full Page Postback

Event Log

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

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:

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

Use Fiddler to capture HTTP requests

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

Use the captured information to define requests in a web test

Start Visual Studio
Create a new web test
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.)
From the fiddler capture, find the GET request for /_layouts/FormServer.aspx
Add that request to the web test
Find the postbacks which are POST requests for /_layouts/Postback.FormServer.aspx or /_layouts/FormServer.aspx
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

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

Substitute context variables in the postback bodys

In the web test, find the postback requests
In its string body, find the event log

For partial postbacks, the event log will be the only data in the string body
For full page postbacks, the text __EventLog should precede the section containing the event log

Edit the EventLogInfo of the postback body as follows:

Replace the 3rd item with {{editingSessionId}}
Replace the 4th item with {{solutionId}}
Replace the 19th item with {{canary}}

Add an Extraction Rule to the postback requests

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

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

UPDATED WIKI: Home

JBooze — Wed, 14 May 2008 22:51:41 GMT

Writing a Visual Studio Web Test for InfoPath Forms Services 2007

InfoPath Forms Services HTTP Traffic

Invocation

Current Form Data

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. If you are using a pre-SP1 version the Canary will be at index 24. This project currently has a bug because of this difference and only works with SP1.)

Postback

Partial Postback

Full Page Postback

Event Log

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

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:

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

Use Fiddler to capture HTTP requests

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

Use the captured information to define requests in a web test

Start Visual Studio
Create a new web test
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.)
From the fiddler capture, find the GET request for /_layouts/FormServer.aspx
Add that request to the web test
Find the postbacks which are POST requests for /_layouts/Postback.FormServer.aspx or /_layouts/FormServer.aspx
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

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

Substitute context variables in the postback bodys

In the web test, find the postback requests
In its string body, find the event log

For partial postbacks, the event log will be the only data in the string body
For full page postbacks, the text __EventLog should precede the section containing the event log

Edit the EventLogInfo of the postback body as follows:

Replace the 3rd item with {{editingSessionId}}
Replace the 4th item with {{solutionId}}
Replace the 19th item with {{canary}}

Add an Extraction Rule to the postback requests

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

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

UPDATED WIKI: Home

JBooze — Wed, 14 May 2008 15:53:23 GMT

Writing a Visual Studio Web Test for InfoPath Forms Services 2007

InfoPath Forms Services HTTP Traffic

Invocation

Current Form Data

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

Postback

Partial Postback

Full Page Postback

Event Log

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

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:

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

Use Fiddler to capture HTTP requests

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

Use the captured information to define requests in a web test

Start Visual Studio
Create a new web test
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.)
From the fiddler capture, find the GET request for /_layouts/FormServer.aspx
Add that request to the web test
Find the postbacks which are POST requests for /_layouts/Postback.FormServer.aspx or /_layouts/FormServer.aspx
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

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

Substitute context variables in the postback bodys

In the web test, find the postback requests
In its string body, find the event log

For partial postbacks, the event log will be the only data in the string body
For full page postbacks, the text __EventLog should precede the section containing the event log

Edit the EventLogInfo of the postback body as follows:

Replace the 3rd item with {{editingSessionId}}
Replace the 4th item with {{solutionId}}
Replace the 19th item with {{canary}}

Add an Extraction Rule to the postback requests

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

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

UPDATED WIKI: Home

JBooze — Tue, 29 Apr 2008 01:07:39 GMT

Writing a Visual Studio Web Test for InfoPath Forms Services 2007

InfoPath Forms Services HTTP Traffic

Invocation

Current Form Data

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

Postback

Partial Postback

Full Page Postback

Event Log

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

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:

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

Use Fiddler to capture HTTP requests

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

Use the captured information to define requests in a web test

Start Visual Studio
Create a new web test
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.)
From the fiddler capture, find the GET request for /_layouts/FormServer.aspx
Add that request to the web test
Find the postbacks which are POST requests for /_layouts/Postback.FormServer.aspx or /_layouts/FormServer.aspx
Add those requests to the web test. Be sure to copy the postback body. Note that these will be web service requests.

Add Extraction Rules to the invocation request

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

Substitute context variables in the postback bodys

In the web test, find the postback requests
In its string body, find the event log

For partial postbacks, the event log will be the only data in the string body
For full page postbacks, the text __EventLog should precede the section containing the event log

Edit the EventLogInfo of the postback body as follows:

Replace the 3rd item with {{editingSessionId}}
Replace the 4th item with {{solutionId}}
Replace the 19th item with {{canary}}

Add an Extraction Rule to the postback requests

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

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

UPDATED WIKI: Home

JBooze — Fri, 25 Apr 2008 18:06:49 GMT

Writing a Visual Studio Web Test for InfoPath Forms Services 2007

InfoPath Forms Services HTTP Traffic

Invocation

Current Form Data

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

Postback

Partial Postback

Full Page Postback

Event Log

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

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:

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

Use Fiddler to capture HTTP requests

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

Use the captured information to define requests in a web test

Start Visual Studio
Create a new web test
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.)
From the fiddler capture, find the request for /_layouts/FormServer.aspx
Add that request to the web test
Find requests for /_layouts/Postback.FormServer.aspx
Add those requests to the web test. Be sure to copy the postback body. Note that these will be web service requests.

Add Extraction Rules to the invocation request

In the web test, find the request for /_layouts/FormServer.aspx
Add ExtractEditingSessionId, ExtractSolutionId, and ExtractInitialCanary extraction rules
Substitute context variables in the postback body
In the web test, find requests for /_layouts/Postback.FormServer.aspx
Edit the EventLogInfo of the postback body as follows:

Replace the 3rd item with {{editingSessionId}}
Replace the 4th item with {{solutionId}}
Replace the 19th item with {{canary}}

Add an Extraction Rule to the postback requests

In the web test, find requests for /_layouts/Postback.FormServer.aspx
Add ExtractPostbackCanary extraction rule to each of these requests

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

UPDATED WIKI: Home

JBooze — Thu, 24 Apr 2008 21:27:55 GMT

Writing a Visual Studio Web Test for InfoPath Forms Services 2007

InfoPath Forms Services HTTP Traffic

Invocation

Current Form Data

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

Postback

Event Log

When a postback occurs, the event log is sent to the server using a POST request to Postback.FormServices.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.

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> “;” <Data1> “;” <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.

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

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:

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

Use Fiddler to capture HTTP requests

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

Use the captured information to define requests in a web test

Start Visual Studio
Create a new web test
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.)
From the fiddler capture, find the request for /_layouts/FormServer.aspx
Add that request to the web test
Find requests for /_layouts/Postback.FormServer.aspx
Add those requests to the web test. Be sure to copy the postback body. Note that these will be web service requests.

Add Extraction Rules to the invocation request

In the web test, find the request for /_layouts/FormServer.aspx
Add ExtractEditingSessionId, ExtractSolutionId, and ExtractInitialCanary extraction rules
Substitute context variables in the postback body
In the web test, find requests for /_layouts/Postback.FormServer.aspx
Edit the EventLogInfo of the postback body as follows:

Replace the 3rd item with {{editingSessionId}}
Replace the 4th item with {{solutionId}}
Replace the 19th item with {{canary}}

Add an Extraction Rule to the postback requests

In the web test, find requests for /_layouts/Postback.FormServer.aspx
Add ExtractPostbackCanary extraction rule to each of these requests

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

UPDATED WIKI: Home

JBooze — Wed, 23 Apr 2008 04:55:12 GMT

Writing a Visual Studio Web Test for InfoPath Forms Services 2007

InfoPath Forms Services HTTP Traffic

Invocation

Current Form Data

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

Postback

Event Log

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

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:

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

Use Fiddler to capture HTTP requests

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

Use the captured information to define requests in a web test

Start Visual Studio
Create a new web test
Add an InfoPathExtractionRules reference to the test project
From the fiddler capture, find the request for /_layouts/FormServer.aspx
Add that request to the web test
Find requests for /_layouts/Postback.FormServer.aspx
Add those requests to the web test. Be sure to copy the postback body. Note that these will be web service requests.

Add Extraction Rules to the invocation request

In the web test, find the request for /_layouts/FormServer.aspx
Add ExtractEditingSessionId, ExtractSolutionId, and ExtractInitialCanary extraction rules
Substitute context variables in the postback body
In the web test, find requests for /_layouts/Postback.FormServer.aspx
Edit the EventLogInfo of the postback body as follows:

Replace the 3rd item with {{editingSessionId}}
Replace the 4th item with {{solutionId}}
Replace the 19th item with {{canary}}

Add an Extraction Rule to the postback requests

In the web test, find requests for /_layouts/Postback.FormServer.aspx
Add ExtractPostbackCanary extraction rule to each of these requests

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

UPDATED WIKI: Home

JBooze — Wed, 23 Apr 2008 04:44:37 GMT

Writing a Visual Studio Web Test for InfoPath Forms Services 2007

InfoPath Forms Services HTTP Traffic

Invocation

Current Form Data

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

Postback

Event Log

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

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:

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

Use Fiddler to capture HTTP requests

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

Use the captured information to define requests in a web test

Start Visual Studio
Create a new web test
Add an InfoPathExtractionRules reference to the test project
From the fiddler capture, find the request for /_layouts/FormServer.aspx
Add that request to the web test
Find requests for /_layouts/Postback.FormServer.aspx
Add those requests to the web test. Be sure to copy the postback body. Note that these will be web service requests.

Add Extraction Rules to the invocation request

In the web test, find the request for /_layouts/FormServer.aspx
Add ExtractEditingSessionId, ExtractSolutionId, and ExtractInitialCanary extraction rules
Substitute context variables in the postback body
In the web test, find requests for /_layouts/Postback.FormServer.aspx
Edit the EventLogInfo of the postback body as follows:

Replace the 3rd item with {{editingSessionId}}
Replace the 4th item with {{solutionId}}
Replace the 19th item with {{canary}}

Add an Extraction Rule to the postback requests

In the web test, find requests for /_layouts/Postback.FormServer.aspx
Add ExtractPostbackCanary extraction rule to each of these requests

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

UPDATED WIKI: Home

JBooze — Wed, 23 Apr 2008 04:30:15 GMT

Writing a Visual Studio Web Test for InfoPath Forms Services 2007

InfoPath Forms Services HTTP Traffic

Invocation

Current Form Data

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

Postback

Event Log

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

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:

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

Use Fiddler to capture HTTP requests

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

Use the captured information to define requests in a web test

Start Visual Studio
Create a new web test
Add an InfoPathExtractionRules reference to the test project
From the fiddler capture, find the request for /_layouts/FormServer.aspx
Add that request to the web test
Find requests for /_layouts/Postback.FormServer.aspx
Add those requests to the web test. Be sure to copy the postback body. Note that these will be web service requests.

Add Extraction Rules to the invocation request

In the web test, find the request for /_layouts/FormServer.aspx
Add ExtractEditingSessionId, ExtractSolutionId, and ExtractInitialCanary extraction rules
Substitute context variables in the postback body
In the web test, find requests for /_layouts/Postback.FormServer.aspx
Edit the EventLogInfo of the postback body as follows:

Replace the 3rd item with {{editingSessionId}}
Replace the 4th item with {{solutionId}}
Replace the 19th item with {{canary}}

Add an Extraction Rule to the postback requests

In the web test, find requests for /_layouts/Postback.FormServer.aspx
Add ExtractPostbackCanary extraction rule to each of these requests

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

UPDATED WIKI: Home

JBooze — Sat, 12 Apr 2008 02:15:36 GMT

Writing a Visual Studio Web Test for InfoPath Forms Services 2007

InfoPath Forms Services HTTP Traffic

Invocation

Current Form Data

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

Postback

Event Log

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

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:

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

Use Fiddler to capture HTTP requests

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

Use the captured information to define requests in a web test

Start Visual Studio
Create a new web test
Add an InfoPathExtractionRules reference to the test project
From the fiddler capture, find the request for /_layouts/FormServer.aspx
Add that request to the web test
Find requests for /_layouts/Postback.FormServer.aspx
Add those requests to the web test. Be sure to copy the postback body. Note that these will be web service requests.

Add Extraction Rules to the invocation request

In the web test, find the request for /_layouts/FormServer.aspx
Add ExtractEditingSessionId, ExtractSolutionId, and ExtractInitialCanary extraction rules
Substitute context variables in the postback body
In the web test, find requests for /_layouts/Postback.FormServer.aspx
Edit the EventLogInfo of the postback body as follows:

Replace the 3rd item with {{editingSessionId}}
Replace the 4th item with {{solutionId}}
Replace the 19th item with {{canary}}

Add an Extraction Rule to the postback requests

In the web test, find requests for /_layouts/Postback.FormServer.aspx
Add ExtractPostbackCanary extraction rule to each of these requests

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

UPDATED WIKI: Home

JBooze — Sat, 12 Apr 2008 01:47:45 GMT

Writing a Visual Studio Web Test for InfoPath Forms Services 2007

InfoPath Forms Services HTTP Traffic

Invocation

Current Form Data

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

Postback

Event Log

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

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:

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

Use Fiddler to capture HTTP requests

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

Use the captured information to define requests in a web test

Start Visual Studio
Create a new web test
Add an InfoPathExtractionRules reference to the test project
From the fiddler capture, find the request for /_layouts/FormServer.aspx
Add that request to the web test
Find requests for /_layouts/Postback.FormServer.aspx
Add those requests to the web test. Be sure to copy the postback body. Note that these will be web service requests.

Add Extraction Rules to the invocation request

In the web test, find the request for /_layouts/FormServer.aspx
Add ExtractEditingSessionId, ExtractSolutionId, and ExtractInitialCanary extraction rules
Substitute context variables in the postback body
In the web test, find requests for /_layouts/Postback.FormServer.aspx
Edit the EventLogInfo of the postback body as follows:

Replace the 3rd item with editingSessionId
Replace the 4th item with solutionId
Replace the 19th item with canary

Add an Extraction Rule to the postback requests

In the web test, find requests for /_layouts/Postback.FormServer.aspx
Add ExtractPostbackCanary extraction rule to each of these requests

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