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 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
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
be important when writing the web test:
||Index of g_objCurrentFormData
||When does it change?
|Editing Session Id
||Identifies your session with the server
||When invoking a form
||Uniquely identifies the form template
||When the form template has been updated
||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.)
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.
its view of the data.
Full Page Postback
The event log follows a specific format which is described below in
. 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
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
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