COM/DCOM application architecture versus VuGen recording
1. In order for VuGen to trap all necessary COM/DCOM communication between the front-end client application and the backend server, there is a need for the recorder to know about the architecture of the application in terms of COM/DCOM object communication. In general, this information can be gathered with the help of the developer.
2. A general application architecture may look like the following:
On the Client side,
· You might have your own custom data access object.
· You might have different objects talking to the backend server objects and any custom data access object.
On the Server side,
· All DCOM objects created by the client request and communicate with the database for data access.
· In return, these DCOM objects might pass back necessary data to fulfill the client request for data retrieval/update.
3. To let VuGen COM/DCOM recorder know about what objects you are interested in recording, you need to configure the recording option. The purpose of listing all necessary objects here in the filtering option is to enable the recorder to read the type information about the object, so that it would monitor the creation of such objects and all activities done by the objects. Finally, after the recording, the recorder could generate appropriate script for all the activities trapped.
Recording options for COM/DCOM
Scripting Language and Option
There are four code generation modes
· C Language – Generate Vuser scripts using C. No additional component is required. This mode of code generation is useful for recording applications that use complex COM construct and C++ objects. It is also recommended for users familiar with C programming language.
· Visual Basic for application – Generate Vuser scripts using Visual Basic. Need to have Visual Basic Application installed. This mode of code uses the full capabilities of VB and is ideal for VB based application. It is also recommended for users familiar with Visual Basic.
· Visual Basic Scripting – For VBscript-based applications, such as ASP.
1. Basic Options – The Basic script options apply to all of the languages and Vuser types. These options allow you to control the level of detail in the generated script.
a. Close all AUT processes when recording stops: Automatically closes all of the application under test’s (AUT) processes when VuGen stops recording. (disabled by default)
b. Generate fixed think time after end transaction: Add a fixed think time, in seconds, after the end of each transaction. When you enable this option, you can specify a value for the think time. The default is 3 seconds. (disabled by default)
c. Generate recorded events log: Generate a log of all events that take place during recording. (disabled by default)
d. Generate think time greater than threshold: Use a threshold value for think time. If the recorded think time is less than the threshold, VuGen does not generate a think time statement. You also specify the threshold value. The default values is 3—if the think time is less than 3 seconds, VuGen does not generate think time statements. If you disable this option, VuGen will not generate any think times. (enabled by default)
e. Track processes created as COM local servers: Track the activity of the recorded application if one of its sub-processes was created as a COM local server. (disabled by default)
2. Correlation Options – The Correlation options does not apply to C Language scripting. These settings let you configure the extent of automatic correlation performed by VuGen while recording. All correlation options are disabled by default.
a. Correlate small numbers – Correlate short data types such as bytes, characters, and short integers. (disabled by default)
b. Correlate large numbers – Correlate long data types such as integers, long integers, 64-bit characters, float, and double. (disabled by default)
c. Correlate simple strings – Correlate simple, non-array strings and phrases. (enabled by default)
d. Correlate arrays – Track and correlate arrays of all data types, such as string, structures, numbers, etc. (disabled by default)
e. Correlate structures – Track and correlate complex structures. (disabled by default)
1. Default Filter: The filter to be used as the default when recording a COM Vuser script.
2. New Filter: A clean filter based on the default environment settings. Note that you must specify a name for this filter before you can record with its settings.
In the tree hierarchy of type libraries, you can expand the tree to show all of the available classes in the type library. You can expand the class tree to show all of the interfaces supported by that class.
To exclude a type library, clear the checkbox next to the library name. This excludes all of its classes in that type library. By expanding the tree, you can exclude individual classes or interfaces by clearing the checkbox next to the item.
Various classes can implement an interface differently. When you exclude an interface that is implemented by other classes that have not been excluded, a dialog box opens asking you if you also want to exclude the interface in all classes that implement it this interface.
Note that when you clear the checkbox adjacent to an interface, it is equivalent to selecting it in the Excluded Interfaces dialog box.
1. Environment: The environments to record: ADO objects, RDS Objects, and Remote Objects. Clear the objects you do not want to record.
2. Type Libraries: A type library .tlb file represents the COM object to record. All COM objects have a type library that represents them. You can choose a type library from the Registry, Microsoft Transaction Server, or file system. After adding the Type Libraries, VuGen will display the following information on the lower section of the dialog box:
· TypLib: The name of the type library (the .tlb file).
· Path: The path of the type library.
· Guid: The Global Unique Identifier of the type library.
Add: Click to add another COM object. To add a type library from the Registry, select “Browse Registry.” To add a type library from the file system (.tlb, .dll, and so forth.), select “Browse File System.” To add a component from the Microsoft Transaction Server, select “Browse MTS.” To use components from the Microsoft Transaction Server, the computer must have an MTS client installed.
Exclude: Enables you to exclude specific interfaces during recording.
DCOM scripting options apply to all programming languages. These settings let you configure the scripting options for DCOM methods and interface handling.
1. ADO Recordset filtering: Condense multiple recordset operations into a single-line fetch statement. (enabled by default)
2. Save Recordset content: Stores Recordset content as grids, to allow viewing of recordset in VuGen. (enabled by default)
3. Generate COM exceptions: Generate COM functions and methods that raised exceptions during recording. (enabled by default)
4. Release COM Objects: Record the releasing of COM objects when they are no longer in use. (disabled by default)
5. Limit size of SafeArray log: Limit the number of elements printed in the safearray log per COM call, to 16. (enabled by default)
6. Generate COM statistics: Generate recording time performance statistics and summary information. (disabled by default)
7. Declare Temporary VARIANTs as Globals: Define temporary VARIANT types as Globals, not as local variables. (disabled by default)
Sample recording against Mercury Interactive’s Flight application
The following is an example of Flight Reservation System (COM sample application that comes with the sample installation).
3. As laid out in the diagram, the GUI (graphical user interface) objects talk to the FRS, which is a COM object that communicates with ADO (Microsoft ActiveX Data Object). ADO as a lower level COM object does all the data access with the backend database and returns Recordset to the FRS object. Then, the GUI objects pick up all actual data from the FRS object for data presentation.
4. In terms of VuGen COM/DCOM recording, there are two approaches.
- The first approach is to trap the COM activities generated by the FRS.
- The second approach is to trap ALL the ADO activities including the following:
i. Connection to the database
ii. Performing SQL query
iii. Retrieving data via Recordset
Why use ADO
· Considering ADO as a low-level object for data access, it contains all business logic to access the backend database when recording at this level.
· Since Microsoft creates ADO as a standard data access object, VuGen COM/DCom recorder contains extensive support for it because more is known about this object than any others.
· ADO is a thread safe object. The recorded script could be run as a thread.
Why not ADO
· With ADO recording, the recorded script might be lengthy based on the amount of Recordset created and used by the application.
· Extensive correlation might be required to avoid database unique constrain violation when doing update/insert process. A higher-level object might already contain logic to avoid this.
· Very importantly, there might be some other client-side objects that communicate with server-side objects.
1. Start VuGen and bring up a new COM/DCOM script.
2. On the “Programs to record” field, navigate to the executable of the application. For the sample, please select frsui.exe that is in <Installation >samplesbin.
3. Click on the “Options” button in the lower left-hand corner to set the recording options.
4. Go to the DCOM tab.
i. Select the ADO objects under Environment.
ii. Click on “Add” then on “Browse file system.”
iii. Navigate to “frs.dll” and click OK.
5. After step 4, you should see the “FRS” is automatically added to the type libraries.
6. You can expend “FRS” to select the interface you want to record.
7. Click “OK” to quite the recording options
8. Start recording
NOTE: You will need to correlate the dynamic values so that the script replay will be successful.