The following sections provide instructions on how to make basic changes to the Enterprise Tester Web files.
Changes to the web.config file can leave Enterprise Tester inoperable. We advise taking a backup of your web.config file and database prior to making changes.
Locating the web.config File
The web.config is located in the web subdirectory of the application installation path, which defaults to c:\Program Files\Catch Limited\Enterprise Tester\Web\ folder.
Changing Path Separator Value
By default, the “|” is reserved for use as a path separator for package, requirement and script paths in imports and exports and cannot be used in Requirement, Script or Use Case names. Should you need to use the “|” extensively as part of your naming convention, the path separator can be changed in Enterprise Testers web.config file as follows.
Open the Web.Config file (usually located in c:\Program Files\Catch Limited\Enterprise Tester\web\) and find the following section near the top of the file.
<appSettings>
<add key="migration.providerName" value="Migrator.Providers.SqlServer.SqlServer2005Dialect"/>
</appSettings>
Add a new line with the path separator of your choice after “value=” as shown in bold below. The following example will replace “|” as a path separator with the pipe character “~”.
<appSettings>
<add key="migration.providerName" value="Migrator.Providers.SqlServer.SqlServer2005Dialect"/>
<add key="PathService.PackagePathSeparator" value="~"/>
</appSettings>
Changing the Indexes Folder Location
By default the location of the Indexes folder will default to the "Data" folder of your installation. The indexes folder can grow up to 1 gigabyte in size, so if you don't have a lot of space free on your installation drive, or prefer to store data in a different location, you will need to update the web.config file to specify this location.
To change the location, locate the <appSettings>...</appSettings> section in the web.config file and add a new value "search.indexes.path" on the line after <appSettings> like so:
<appSettings>
<add key="search.indexes.path" value="c:\savemy\indexes\" />
The "value" section of this entry needs to contain the absolute path of the folder where you want to have the indexes stored.
Storing Attachments in a File System
Enterprise Tester provides the option of storing attachments in a file system rather than in the Enterprise Tester database. By default Enterprise Tester will store attachments in the database, unless the user configures to do otherwise.
Configuration of Storage Method and Location – New Installations of Enterprise Tester
If you have just installed Enterprise Tester, and have yet to create any data, you can configure the location for storing attachment contents by editing the web.config file.
Open the web.config (normally found in C:\Program Files\Catch Limited\Enterprise Tester\Web\web.config) and locate the appSettings section, which will normally look something like this:
<appSettings>
<add key="migration.providerName" value="Migrator.Providers.SqlServer.SqlServer2005Dialect" />
</appSettings>
Now, if you wish to use In-database storage of attachments, you can leave the file as-is, however if you wish to use file-system based store, you need to add an additional value using the key "attachment.storage.method" with the value "FileSystemCas".
<appSettings>
<add key="migration.providerName" value="Migrator.Providers.SqlServer.SqlServer2005Dialect" />
<add key="attachment.storage.method" value="FileSystemCas" />
</appSettings>
By default this will store attachments in the folder ../Data/Attachments/ (so normally c:\Program Files\Catch Limited\Enterprise Tester\Data\Attachments)
If however you wish store attachments in another location (i.e. if you have a lot of attachments and wish to store them on a NAS disk) you can set the path by adding another entry with the key "attachment.storage.path".
<appSettings>
<add key="migration.providerName" value="Migrator.Providers.SqlServer.SqlServer2005Dialect" />
<add key="attachment.storage.method" value="FileSystemCas" />
<add key="attachment.storage.path" value="f:\et-attachments\" />
</appSettings>
Setting Maximum File Sizes
To support the attachment of very large files change to the configuration of the application are also required. By default Enterprise Tester sets a limit of 64mb for requests. To support attaching larger files you will need to change this value.
In the web.config file, locate this section:
<system.web>
<httpRuntime executionTimeout="18000" maxRequestLength="65535" />
The value "maxRequestLength" controls the maximum size of requests in kilobytes, changing this to value such as 1024000, will allow you to upload files up to 1gb in size.
Garbage Collection
When you delete an attachment, the associated contents (if stored on say the file system) won't be immediately removed. Instead a periodic process occurs called "garbage collection" where any content no longer referenced by the database is then removed. By default this process runs once every hour. The frequency can be configured by specifying an additional key "attachment.storage.garbagecollection.dwell":
<appSettings>
<add key="migration.providerName" value="Migrator.Providers.SqlServer.SqlServer2005Dialect" />
<add key="attachment.storage.method" value="FileSystemCas" />
<add key="attachment.storage.garbagecollection.dwell" value="5" />
</appSettings>
In the example above we have set "dwell" to 5 minutes. Attachments will be “cleaned up” every 5 minutes. Generally speaking, it is recommended that unless you are performing tests, this should be set to 30 minutes or higher.
In addition if you wish to disable garbage collection altogether, you can add the key "attachment.storage.garbagecollection.disable" with the value "true".
<appSettings>
<add key="migration.providerName" value="Migrator.Providers.SqlServer.SqlServer2005Dialect" />
<add key="attachment.storage.method" value="FileSystemCas" />
<add key="attachment.storage.garbagecollection.disable" value="false" />
</appSettings>
Changing Attachment Storage from Database to File System (Existing installation of Enterprise Tester)
Enterprise Tester provides a mechanism to migrate between storing attachments in the file system or database for an existing instance of Enterprise. Before commencing, the Enterprise Tester website should be taken offline. The easiest way to do this is to stop IIS or stop the application pool Enterprise Tester belongs to.
Migrating from In-database to the file system
To store attachments in a location other than /Data/Attachments, you will need to add the "attachment.storage.path" setting to the web.config file (ensure the attachment storage method remains the same). Next, start a command prompt, and change the Enterprise Tester bin folder:
cd c:\Program Files\Catch Limited\Enterprise Tester\Web\bin\
Now run the following executable:
AttachmentMigrator.exe
A message similar to the following should appear:
Enterprise Tester Attachment Migration Tool Version 1.0.0.0
Current Attachment Storage Configuration: FileSystemCas
This tool will migrate attachments to the new storage location: InDatabase
WARNING! This operation cannot be reversed, and if it fails, will leave your database in a inconsistent state. Please ensure you have backed up the database before proceeding.
To proceed type "yes" and press enter
As the message suggests, you should always backup both your database and web.config file prior to using this tool - as if it fails halfway through, it will leave your Enterprise Tester database in an inconsistent state.
When you are ready type "yes" and press enter.
You will then see progress displayed on screen, and eventually the migration will complete.
Initializing...
Initialization Complete.
Plugins Folder: c:\Program Files\Catch Limited\Enterprise Tester\Web\bin
Attachments Folder: c:\Program Files\Catch Limited\Enterprise Tester\Data\Attachments\
Database Type: SqlServer
....................................... Processed 40/265 (15%)
........................................ Processed 80/265 (30%)
........................................ Processed 120/265 (45%)
........................................ Processed 160/265 (60%)
........................................ Processed 200/265 (75%)
........................................ Processed 240/265 (91%)
.........................
Migration completed and web.config file updated, total time: 4.5294003s
Now restart IIS or the application pool, and your attachments will now be stored in the new location.
If you are migrating from file system to in-database storage, you will need to manually delete/archive the attachment files after the migration.
Setting Automatic Refresh Lookups
Enabling/Disabling Automatic Refresh Lookups at start up
By default, Enterprise Tester is automatically set to refresh lookups on startup of the application. In the web.config file, by default defecttracking.settings.populator.syncuncachedonstartup is set to ‘true’. This initially triggers a check for “uncached” projects. If “uncached” projects are found, a refresh lookups synchronisation is triggered at startup. To disable, set defecttracking.settings.populator.syncuncachedonstartup is set to ‘false’.
Enabling/Disabling Automatic Refresh Lookups when a new project link is created
By default, Enterprise Tester is automatically set to refresh lookups when a new project link is created under the Resources tab. In the web.config file, by default externaldata.createlink.autorefreshlookups is set to ‘true’. This triggers a refresh of all the cached custom/inbuilt field data when a project link is created. The refresh process will only work if the defect tracker is also enabled. To disable the automatic refresh lookup, change externaldata.createlink.autorefreshlookups to ‘false’.
Changing Server Key Generation Method
When upgrading from V3.X or prior to V4.X, the server key generation method will automatically update to this method. When upgrading from V3.x and prior or when making this change manually to a production system, please contact Catch Limited Support (support@catchlimited.com) to pre-arrange a time for a new license to be generated, this will minimize any outage period.
In versions prior to 4.0, the server key used by Enterprise Tester was generated from this information:
- Machine Name
- Processor Count
- Mac Addresses of permanent network interfaces
- Operating System Name
- Operating System Version
In virtualized environments the MAC addresses can often change, causing a new server key to be generated next time Enterprise Tester starts, displaying a message on screen to customers that their license is now invalid or expired.
A new server key generation method that generates a stable server key even if the MAC address changes over time, to use it you must add the following line to your web.config file:
<appSettings>
…
<add key="Licensing.ServerKey.GenerationMode" value="Stable" />
Once added, on the next start up, a new "stable" server key will be generated.
At this point you will need apply a new license text which can be provided by Catch Limited on request. Please provide youre new server key.
EC2 Support
If you are using EC2, then by default windows instances will be allocated a new hostname every time they start up. This is in the form of "ip-XXXXXXX" (where XXXXXX is a hexadecimal number), so even when using the stable server key generation mode this would require that a new license is entered every time Enterprise Tester starts up.
To remedy this, access the EC2 server via remote desktop, and then:
- Click start -> EC2ConfigServer Settings
- When the EC2ConfigServer settings dialog appears, uncheck the "Set Computer Name" checkbox.
Another recommendation is to assign the machine a more meaningful name, as this will be recorded in log files and can be used to determine which machine they were recorded on (i.e. development or production).
To give the server a more meaningful name:
- Go to Start-> Control Panel -> System.
- Clicking "Change settings"
- Give the machine a unique name i.e. "ETPROD-COMPANYNAME".
- Click OK, you will be prompted to restart.
- Restart
Once restarted, access Enterprise Tester in a web browser, obtain the server key, request/generate a new valid license, and apply it.
You should now be able to start/stop the EC2 instance without having to enter a new server key every time.