InfoPath Forms Services 2007 Web Testing Toolkit

New Post: Visual Studio 2008 Professional Edition

JBooze — Thu, 28 Aug 2008 00:45:13 GMT

According to the Visual Studio 2008 Product Comparison page under the Code Quality Tools section, to get Web Test functionality you need Visual Studio Team System 2008 Test Edition or Visual Studio Team System 2008 Team Suite.

New Post: Visual Studio 2008 Professional Edition

michaellotter — Wed, 27 Aug 2008 15:43:57 GMT

Hi,

I'm currently using Visual Studio 2008 Professional Edition and I'm not able to create a Web Test per the instructions from MSDN. When I was reading through the article I noticed that it said I needed Visual Studio Team addition. Is this correct or can it work with Visual Studio 2008 Professional?

Thank you for doing this project and I'm really looking forward to using it because I do a lot of InfoPath 2007 web based forms and never had a good way for testing.

Cheers,
Michael

Updated Wiki: Home

JBooze — Thu, 24 Jul 2008 22:49:26 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. 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.

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: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

Created Release: IPFS Web Test Toolkit 20080724 for VS2008 (Jul 24, 2008)

Thu, 24 Jul 2008 20:33:09 GMT

IPFS Web Test Toolkit includes InfoPathExtractionRules and the IpfsWebtestAutoFixer tool.

Add a reference to InfoPathExtractionRules.dll in your test project to get the following extraction rules and web test plugin:

ExtractAndSubstituteDynamicInfoPathData
ExtractSolutionId
ExtractEditingSessionId
ExtractInitialCanary
ExtractPostBackCanary

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.

Updates:

Added ExtractAndSubstituteDynamicInfoPathData web test plugin. This plugin greatly simplifies the process for writing a web test for InfoPath. To use it, simply add the plugin to your web test. It automatically recognizes the infopath requests then extracts/substitutes the dynamic InfoPath data. If your InfoPath form is in an XmlFormViewControl, use the InvocationPath parameter to identify which requests are for InfoPath.

Released: IPFS Web Test Toolkit 20080724 for VS2008 (Jul 24, 2008)

Thu, 24 Jul 2008 20:33:09 GMT

ExtractAndSubstituteDynamicInfoPathData
ExtractSolutionId
ExtractEditingSessionId
ExtractInitialCanary
ExtractPostBackCanary

Added ExtractAndSubstituteDynamicInfoPathData web test plugin. This plugin greatly simplifies the process for writing a web test for InfoPath. To use it, simply add the plugin to your web test. It automatically recognizes the infopath requests then extracts/substitutes the dynamic InfoPath data. If your InfoPath form is in an XmlFormViewControl, use the InvocationPath parameter to identify which requests are for InfoPath.

Closed Feature: Create a Webtest plugin to automatically call appropriate extraction rules

JBooze — Tue, 22 Jul 2008 01:56:14 GMT

This plugin would automatically add the appropriate extraction rules to invocation and postback requests. It potententially could dynamically substitute context parameters into the postback request string bodys.

Source code checked in, #12141

JBooze — Tue, 22 Jul 2008 01:56:12 GMT

Factor out some logic from IPExtractionUtil to EventLog and CurrentFormData. Add ExtractAndSubstituteDynamicInfoPathData webtest plugin. Writing a web test for InfoPath Forms Server is even easier with this plugin. To use it, simply add the plugin to your web test. If your InfoPath form is in an XmlFormViewControl, use an InvocationPath parameter to identify which requests are for InfoPath.

New Post: Constructing Postback Requests: what is the variable at index

SylviaS — Fri, 18 Jul 2008 03:32:07 GMT

Hello, thank you very much for your response :-)

Just to give you an update. I left the value as they were as per your response and I did not experience any issue.

Cheers,
SylviaS

New Post: Constructing Postback Requests: what is the variable at index

JBooze — Wed, 09 Jul 2008 22:07:45 GMT

It is CreationTime and is represented in ticks. The value comes from the item at index 18 in g_objCurrentFormData.

When I run my tests, I've just left that value as the one that was originally captured. Have you run into problems running webtests that you think are related to this variable?

New Post: Constructing Postback Requests: what is the variable at index

SylviaS — Tue, 08 Jul 2008 01:27:17 GMT

Thank you for your response so far :-) Look forward to your next response!

New Post: Constructing Postback Requests: what is the variable at index

JBooze — Mon, 07 Jul 2008 16:27:45 GMT

I think your guess of a timestamp is correct and it may represents ticks. I'm on vacation right now, so I don't have access to resources to confirm these answers right now. I'll get back to you in a couple days with a more complete and confident answer.

New Post: Constructing Postback Requests: what is the variable at index

SylviaS — Mon, 07 Jul 2008 05:29:24 GMT

Hello,

I have been recording Postback Requests and found that there is another dynamic variables apart from Event Session, Solution ID and Canary.

I found that the variable at index 17 (boldfaced below using your example) keeps changing for each postback request. Can you please tell me what it represents, it looks to be relate to Canary (is it timestamp of some sort). How is it generated?

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

Cheers,
SylviaS

New Post: Can't Trigger the Event for submitting the data to DB

JBooze — Thu, 12 Jun 2008 01:17:52 GMT

Using the default submit button should cause a postback and trigger InfoPath's SharePoint submit data connection. Adding that postback to your webtest should be the same as adding any other InfoPath postback. Take a look at the instructions on this project's wiki if you haven't already.

However, one of the important details of a SharePoint submit data connection is the file name of the submitted form. How is the SharePoint submit data connection defined in your form template? What are you using to determine the name of the submitted file? Is "Allow overwrite if file exists" checked?

Think about what you do when you manually use the form in the browser. Does a value typed in one of the form's fields determine the name of the submitted form? If so, I would recommend binding that value to context parameter. The action of typing a value gets written to the event log. If this is the case, I can walk you through the steps to find out where to put the context parameter in the event log.

Are you trying to use the web test in a load test? If so, you likely want the submitted file names to be unique. Again, I can give you more details if that is the case.

New Post: Can't Trigger the Event for submitting the data to DB

travlos7 — Wed, 11 Jun 2008 14:20:48 GMT

What happens if we do not use a custom button for submit like you do in your example but rather use the default submit button of sharepoint?
The requests that i get from to /_layouts/Postback.FormServer.aspx when i hit the submit button is the following.
So the form is not submited at the library.

8;5;5e1f8646-ee77-4fde-b867-6851d3da9300;677291e9-0976-49e3-a287-29aeafd309fa:ver:1.0.0.1694;0;;http%3A%2F%2Fspsupgrade%2FFormServerTemplates%2FExpenseReport.xsn;http%3A%2F%2Fspsupgrade%2FFormServerTemplates%2FExpenseReport.xsn;http%3A%2F%2Fspsupgrade%2FExpenseListHQ%2F;http%3A%2F%2Fspsupgrade;http%3A%2F%2Fspsupgrade%2FGlassExpenseListHQ%2FForms%2FAllItems.aspx;1;1;0;9;0;633487873928904000;;4vGF1XsXCT7TVpAlQsDf0MPXHVainRLLIVoevEsA74b1qBQojSbOJ+dmW8R/AhBKZbuUD2Jm6Onrz7k/k0p9sQ==|633487874962087402 9;;;
How can i make it work?
Thanks a lot..

UPDATED WIKI: IpfsWebtestAutoFixer

JBooze — Wed, 04 Jun 2008 18:22:06 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 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.