Share this page
Deploying and Running the Custom Toolkit Support
The final stage of extending UFT One support for a custom toolkit is deployment. This means placing all of the files you created in the correct locations, so that the custom toolkit support is available to UFT One.
You can also deploy the toolkit support during the development stages, to test how it affects UFT One and debug the custom toolkit support set that you are creating.
About Deploying the Custom Toolkit Support
From the UFT One user's perspective, after you deploy the toolkit support set on a computer on which UFT One is installed, the toolkit support set can be used as a UFT One add-in.
When UFT One opens, it displays the custom toolkit name in the Add-in Manager, as a child node under the Java Add-in node. Select the check box for your custom toolkit to instruct UFT One to load support for the toolkit using the toolkit support set that you developed.
Note: Only applications that are opened after loading or unloading support for the custom toolkit are affected.
If you do not load the support for your custom toolkit, the code that you designed in your toolkit support set does not run.
If you load support for your custom toolkit:
UFT One recognizes the controls in your custom toolkit and can run test steps on them.
UFT One displays the name of your custom toolkit in the Environment list in all of the dialog boxes that display lists of add-ins or supported environments.
UFT One displays the list of test object classes defined by your toolkit support set in dialog boxes that display the list of test object classes available for each add-in or environment. (For example: Define New Test Object dialog box, Object Identification dialog box.)
Note: Test object classes defined in a toolkit support set that was developed using a Java Add-in Extensibility SDK version earlier than 10.00 are displayed in the UFT One dialog boxes as Java test object classes. To cause UFT One to display these test object classes under the correct environment name, change the PackageName attribute in the test object configuration file to the name of the custom toolkit, as it appears in the Add-in Manager. Additionally, if an index identification property is implemented for any test object classes in the toolkit support set, remove this implementation to enable the use of the Generate Scripts button in the Object Identification dialog box.
Deploying the Custom Toolkit Support
The following table describes the appropriate location for each of the toolkit support files:
File Name | Location |
|---|---|
<Custom Toolkit Name>.xml | <UFT_One_installdir>\bin\java\classes\extension |
<Custom Toolkit Name>TestObjects.xml Note: This file name convention is used by the Java Add-in Extensibility wizard. You can have more than one test object configuration file, and name them as you wish. |
|
<Custom Toolkit Name>Support.class | All of the compiled Java support classes can be packaged in class folders or Java archives on the computer on which UFT One is installed, or in an accessible network location. Specify the location in <Custom Toolkit Name>.xml. |
<CustomClass>CS.class | |
Icon files for new test object classes (optional) | The file can be a .dll or .ico file, located on the computer on which UFT One is installed, or in an accessible network location. Specify the location in <Custom Toolkit Name>TestObjects.xml. |
Deploying Custom Support During the Development StageDuring the design stages of the custom toolkit support, the support class files can remain in your workspace. You deploy the custom toolkit support by placing the toolkit configuration files (including the test object configuration file) in the correct locations, and by specifying the location of the compiled support classes in the toolkit configuration (XML) file. In addition, if your new test object classes use specific icons, specify their locations in the test object configuration file.
Note: Compile the support classes before deploying and check for compilation errors, to avoid run-time failure.
If you modify attributes of Identification Property elements in the test object configuration file, it is recommended to keep the DevelopmentMode attribute of the TypeInformation element set to true during the design stages of the custom toolkit support. For more information, see Modifying Identification Property Attributes in a Test Object Configuration File.
If you develop custom toolkit support using the UFT One Java Add-in Extensibility plug-in in Eclipse, and UFT One is installed on your computer, you deploy toolkit support by clicking the Deploy Toolkit Support
Eclipse toolbar button, or by choosing UFT > Deploy Toolkit Support. The XML configuration files are copied to the correct UFT One locations, while the Java class files remain in the Eclipse workspace. (The actual locations of the toolkit support class and the custom support classes are listed in the toolkit configuration file.) For details on deploying support using the Eclipse plug-in, see Deploy Toolkit Support .
If you do not use the UFT One Java Add-in Extensibility plug-in in Eclipse, or if UFT One is installed on another computer, you must perform the deployment manually, according to the information in the table.
To deploy custom support manually during the development stages:
Make sure that the compiled support classes (toolkit support class and custom support classes) are in a location that can be accessed by UFT One.
Update the configuration files with the correct locations of the compiled support classes and icon files (if relevant).
Copy the configuration files to the appropriate folders, as described in the table.
Deploying Custom Support After the Design is CompletedWhen the custom toolkit support is fully designed, you can deploy it to any computer on which UFT One is installed.
If you set the DevelopmentMode attribute of the TypeInformation element in the test object configuration file to true while developing the custom toolkit support, make sure to remove this attribute (or set it to false) before deploying the custom support for regular use. For more information, see Modifying Identification Property Attributes in a Test Object Configuration File.
To deploy custom support after the design is completed:
Place the compiled support classes (toolkit support class and custom support classes) in their permanent location. The classes can be in class folders or in a Java archive, in a location that can be accessed by UFT One.
In addition, if you have new test object classes using specific icons, place the icon files in a location that can be accessed by UFT One.
Update the toolkit configuration file with the correct location of the compiled support classes.
If necessary, update the test object configuration file with the correct location of the icon files.
Copy the configuration files to the appropriate folders, as described in the table.
Running an Application with Supported Custom ControlsAfter you deploy the custom toolkit support, you can perform UFT One operations on an application that contains the supported custom controls to test the effects of the support.
You can run the application in any way you choose.
If you run an SWT application from Eclipse using a version earlier than 3.3, Eclipse overrides the Java library path to add the SWT dll. Therefore, you must add the jvmhook.dll path (required by the Java Add-in) to the library path manually.
To add the jvmhook.dll path to the library path (when working with Eclipse versions earlier than 3.3):
Right-click the application file in the Eclipse Package Explorer. Select Run As > SWT Application.
In the Eclipse toolbar, select Run > Run. The Run dialog box opens.
Select the SWT application in the Configurations list.
Click the Arguments tab.
In the VM arguments area, enter:
-Djava.library.path=<System Folder>\system32(For example:
-Djava.library.path=c:\WINNT\system32)Close the application and run the application again. (Right-click the application file in the Eclipse Package Explorer and select Run As > SWT Application).
Modifying Deployed Support
If you modify a toolkit support set that was previously deployed to UFT One, the actions you must perform depend on the type of change you make, as follows:
If you modify the toolkit configuration file or a test object configuration file, you must deploy the support.
If you modify a test object configuration file, you must reopen UFT One after deploying the support.
Whether you modify the configuration files or only the Java support classes, you must re-run the Java application for the changes to take effect.
If you change the identification property definitions that specify the functionalities for which the properties are used in UFT One, see Modifying Identification Property Attributes in a Test Object Configuration File.
Removing Deployed Support
When opening UFT One, the UFT One user can use the Add-in Manager to instruct UFT One whether to load the support provided for any particular toolkit. If the support for your custom toolkit is not loaded, the code that you designed in your toolkit support set does not run, and the test object classes that you defined in the test object configuration file are not available in UFT One.
If you want to remove support for a custom toolkit from UFT One after it is deployed, you must delete its toolkit configuration file from: <UFT_One_installdir>\bin\java\classes\extension
If none of the test object class definitions in a test object configuration file are mapped to any custom controls (meaning they are no longer needed), you can delete the file from: <UFT_One_installdir>\Dat\Extensibility\Java (and <UFT_One_Add-in_for_ALM_installdir>\Dat\Extensibility\Java if relevant).
If you want to remove only parts of the custom toolkit support that you created, consider the following:
To remove support for a specific custom class, delete its custom support class, and remove the references to this support class from the toolkit configuration file.
Before you delete a custom support class, make sure that no other custom support classes extend it.
To remove a new test object class that you defined, remove its definition from the test object configuration file.
Before you remove the definition of a test object class, make sure that no custom classes are mapped to this test object class and that no other test object classes extend it.
To remove support for test object methods or identification properties that you added, remove the relevant support methods from your custom support class.
Removing support for test object methods or identification properties from the support class does not remove them from the test object class definition. They are available in UFT One when editing tests but are not supported for this custom class.
To remove your custom support for test object methods or identification properties whose implementation you overrode, remove the relevant support methods from your custom support class.
To remove test object methods or identification properties from the test object class definition, remove them from the test object configuration file.
See also:
