How Can We Help?
Updating the web.config file
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.
- appSettings
- Changing Path Separator Value
- Changing the Indexes Folder Location
- Setting Automatic Refresh Lookups
- Storing Attachments in a File System
The web.config file contains information specific to your Enterprise Tester instance including your database type and location. It also allows you to change default settings for some features or to enable or disable certain features. See the help topic appSettings for a full list and description of configurable settings.
The web.config is located in the web subdirectory of the application installation path, which defaults to c:\Program Files (x86)\Catch Limited\Enterprise Tester\Web\ folder.
- appSettings
- Server Key Generation
- Specifying the Date Format
appSettings
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.
Some configuration settings in Enterprise Tester are not yet exposed in the User interface. You can apply custom settings to some features in the appSettings section in the web.config file. In the appSettings section, you can add key/value pairs which can be used to control features of Enterprise Tester .
Supported Keys
| Key | Feature | Example Value |
| avatars.storage.path | The path to avatar images used on the website | c:\Enterprise Tester\data\Avatars\ |
| attachment.storage.method | Storage method to use, either InDatabase or FileSystemCas – defaults to FileSystemCas. | FileSystemCas |
| attachment.storage .garbagecollection.disable |
Set to true to disable garbage collection or false to enable garbage collection. | true or false |
| attachment.storage .garbagecollection.dwell |
Minutes between garbage collections, should generally be set to an hour or more. | 30 |
| attachment.storage.path | Path to where attachments are stored, defaults to \Data\Attachments|f:\et-attachments. | f:\et-attachments |
| AutoDashboard.Enabled | If set to “true” a dashboard with a number of pre-defined project specific gadgets being created when a new project is created. The Default value is “False” | true or false |
| Baseline.Export.MaxAttachmentSize | The maximum size for attachments (in bytes) to be included in any exported baseline, if not set it will default to 4mb. | 1024000 |
| defecttracking.settings.populator .syncuncachedonstartup |
If true (the default) then at startup we check to see if any projects are “uncached” and require a refresh lookups sync to be executed, if so we trigger an update at startup. | true or false |
| defecttracking.settings.populator .updatefrequency |
How often custom field metadata is updated, defaults to 00:00:00 | 00:00:00 ( disabled) |
| defecttracking.settings .timebetweensynchronizations |
Time to wait after completing a defect synchronization pass across all projects, before checking again. | 00:01:00 |
| EnhancedFeaturesEnabled | Turns the issue collector on or off. Default is set to on (true).If turned off then users won’t be able to use the Report Bug or Request Feature/Enhancement options in the Enterprise Tester user Menu. | true or false |
| EnterpriseArchitect.Synchronization .Requirements.DisplayExistingElementsReport |
Disables displaying / calculating the existing elements report for requirements EA import/sync. This report can be very costly (half hour +) to calculate for large EA projects where there may be tens of thousands of requirements. Default for 4.2 and above is “false” | true or false |
| Export.MaximumBatchSize | Defaults to 1000 database transactions per batch. When exporting a large amount of data from ET you can reduce the number of transactions per page to improve the performance of the export. | 50 |
| externaldata.createlink.autorefreshlookups | If true (the default) then after creating a link the lookup refresh process will be triggered to refresh of all the cached custom/inbuilt field info. The refresh process will only work if the defect tracker is also enabled. | true or false |
| extjs.timeouts .ajaxFormSubmitTimeoutInSeconds |
The timeout when submitting ExtJS forms (in seconds). | 30 |
| extjs.timeouts .ajaxRequestTimeoutInMilliseconds |
The timeout for ajax requests (in milliseconds). | 30000 |
| extjs.timeouts .ajaxUpdaterTimeoutInSeconds |
The ajax update timeout for requests (in seconds). | 30 |
| FileUploadRestrictions | Restrict file uploads of specified file types. Also see addendum in this page. | .com, .pac, .txt |
| incident.create.defaultStatus | Defaults to “Open”, but can be set to either a single value i.e. “Closed” or multiple options, separated by commas i.e. “Open, Ready, Awaiting Review” – in which case each value in the list will be tried until we can find a match – useful if you have different projects which have different sets of statuses. | Open, Created |
| Jira5.Session.Page | This setting specifies the number of JIRA issues to retrieve per page when synchronizing with JIRA. The default setting is 1000. This can be useful when the number of JIRA issues retrieved causes timeout issues. | 75 |
| JIRA.Issues.DateFormat | The date format used for rendering ET date fields to strings, as required by JIRA – defaults to “dd/MMM/yy hh:mm a”. | dd/MMM/yy hh:mm a |
| jira.refreshlookups.sampleIssuesForAdditionFields | When refreshing loops using the JIRA 5.2+ plugin, by default it will attempt to “Sample” each JIRA project for examples issues of each issue type, to discover additional custom fields which are only displayed on the edit screen. This feature was introduced in ET 4.10, and for very large JIRA instances may be quite slow – if all the custom fields you wish to map appear on the create screen in JIRA, then you can skip the time-consuming sampling process by changing this setting. For more details on this feature and how you can determine if it’s causing performance problems with refreshing lookups please see the addendum below on this page. |
true |
| JIRA.remotelinks.prefix | The prefix added to the start of relationship names when synchronized to JIRA as remote links, it defaults to “ET: ” – to disable the prefix, you can switch it a blank value, or distinguish between ET instances by setting it say “ET-Prod: ” and “ET-Dev:”. | ET: |
| JIRA.session.timeouts.close | The max time it can take to close a connection to the JIRA soap service, defaults to 00:02:00 (2 minutes – prior to v3.3 this was fixed at 1 minute) | 00:02:00 |
| JIRA.session.timeouts.open | The max time it can take to open an http connection to the JIRA soap service, defaults to 00:02:00 (2 minutes – prior to v3.3 this was fixed at 1 minute) | 00:02:00 |
| jira.session.timeouts.receive | The max time it can take to receive data from the JIRA soap service, defaults to 00:15:00 (15 minutes – prior to v3.3 this was fixed at 10 minutes) | 00:15:00 |
| jira.session.timeouts.send | The max time it can take to send a request to the JIRA soap service, defaults to 00:02:00 (2 minutes – prior to v3.3 this was fixed at 1 minute) | 00:02:00 |
| JIRA.session.timeouts .dwellBetweenScraping |
The time to wait between successive screen-scraping requests when fetching options for custom fields, for low-spec JIRA servers you might need to adjust this to give the server a chance to “breathe” between requests, to avoid degradation in performance for other users. Defaults to 1 second delay. For high-spec JIRA servers, you can set this value at 0 seconds, to have no delay between scraping requests | 00:00:01 |
| licensing.serverkey.generationmode | Generates a stable server key even if the MAC address changes over time. | Stable |
| log4net.config | When upgrading ET, by default the logging.config file is overwritten to remove debugging settings that can effect the performance of ET. You can select not to have the logging.config file overwritten by selecting a new location to store the config file. | c:\Program Files (x86)\Catch Limited\Enterprise Tester\data\logging.config (default) |
| MinimumPasswordStrength | Enables a minimum password strength to be enforced for users logging directly into Enterprise Tester. The system default for new installations is Medium. | Poor, Weak, Medium, Strong, or VeryStrong Note the capitalisation of the first letter for each setting. |
| migration.providerName | The name of the provider class used for applying database migrations. | Migrator.Providers.SqlServer.SqlServer2005Dialect |
| nhibernate.driver.oracle.enable-multiquery | Enables support for multiple query results being returned from Oracle in a single round-trip. This should be enabled for all ET installations which use an Oracle database, to improve performance.Support on version 4.9.1 and above of Enterprise Tester only. | true |
| notifications.peruserlimit | The maximum number of notifications to record per user, once the limit is reached older notifications will be discarded for newer ones. | 100 |
| PathService.PackagePathSeparator | The separator character used for display requirement/script paths – defaults to “|” in v4.2 and above(the default is “/” in V4.1 and earlier) . | # |
| project.templates.path | The path to the set of baselines which are used as project templates available when creating a new project. | c:\ET\project_templates\ |
| remotelinks.synchronization .dwellBetweenSynchronizations |
The value can be specified as either a number e.g. 5 – which would be 5 seconds, or formatted as what’s called a timspan e.g. “hh:mm:ss” – so 5 minutes would be specified as 00:05:00. Default value is currently 5 (5 seconds) – this means every 5 seconds ET will check each implementation of what’s called the “IRemoteLinksQueueingSynchronizer” interface and ask it to process any pending changes. A setting of 0 seconds will disable the periodic synchronization, but does not prevent the remote link changes from being “Queued up” in any implementations of IRemoteLinksQueueingSynchronizer. This may not be an issue, but for very large/busy installations of ET, this is probably not a good idea as the queue may grow quite large and consume memory unnecessarily. To disable remote links altogether for Jira, what you need to do is:Go to Admin -> Extensions – Modules -> JIRA IntegrationSelect “JIRA 5.0+ Remote Link Synchronizer” Click the “Disable” button, this will disable the remote link synchronizer completely. |
|
| SAML.Enabled | Enable SAML support | true |
| SAML.Provider | Switched SAML implementation style | Microsoft |
| SAML.Issuer | IDP Issuer | <IDP Issuer> |
| SAML.IDP | IDP SSO URL | <IDP SSO URL> |
| SAML.Certificate | SAML Certificate | <X.509 Certificate> |
| SAML.Logout | Specify the URL that users will be directed to when they log out of Enterprise Tester.Do not add an Enterprise Tester URL here or users will be automatically logged back into Enterprise Tester. An application portal, a corporate home page or an IdP logout function are all good choices. |
https://your_selected_url |
| ScriptService.MaximumStepsPerScript | The maximum number of steps allowed for a script – default is 100. | 100 |
| search.indexes.path | The path to the indexes folder (in v4.0 and later, if not specified, this defaults to the \Data\Indexes folder of the installation directory. | c:\Enterprise Tester\data\Indexes\ |
| search.indexworkprocess.timebetweencommits | The time between commit changes to the search index. | 00:01:00 |
| search.indexworkprocess.workerdwell | The time to wait before waking up again processing search index changes (changes in ET will also trigger the worker process to “wake up”). | 00:00:15 |
| search.indexworkprocess.waituntilemptytimeout | The time the index worker processor will wait for the queue to empty – currently used in unit tests. | 00:01:00 |
| search.reindex.waituntilemptytimeout | The time to wait before aborting the reindexing process when waiting for the index queue to flush – 5 minutes by default. | 00:05:00 |
| Search.Relationships.Expand.AllRelationships | Defaults to false, if set to true then “all relationships” are indexed, which will results in a much larger set of re-indexing occurring after each change within the application. | true or false |
| site.root.url | Root URL to use for the site when generating external links for applications such as defect trackers, this can be useful when ET uses the wrong address when generating links. | http://myapp.com/EnterpriseTester/ |
| site.root.url.scheme | Configures how absolute URL’s are generated by the ET application, you may need to change this setting when exposing Enterprise Tester from behind a reverse proxy.For full details on each of the values, and what it does to the generated absolute URLs please see the addendum at the bottom of this page.. | Https |
| synchronization.mapattachmentsstep .dontsyncfileswithsamenameandsize |
Defaults to false, but if set to true then when synchronizing if a file is found that has the same file name and file size as a previously synchronized file, it will be skipped – useful if you want to avoid attachments which have been duplicated by another synchronization process or user error. | true or false |
| TrialSupport.EnableAnonymousTrialStatistics | Enable the sending of anonymous trial statistics to allow Catch Software to monitor the quality of the installation and initial project setup experience for users with an Enterprise Tester trial license applied. | true |
Setting a Key
To set a key:
- Open the web.config file in a text editor.
- Locate the section starting with <appSettings>
- Add the new entry, in the format off: <add key=”key-name” value=”value” />
- Save changes
- Refresh ET in browser, it should reload with the new settings applied.
Example – before adding new values:
<appSettings>
<add key="migration.providerName" value="Migrator.Providers.SqlServer.SqlServer2005Dialect"/>
</appSettings>Example – after adding new values:
<appSettings>
<add key="migration.providerName" value="Migrator.Providers.SqlServer.SqlServer2005Dialect"/>
<add key="search.index.disable" value="true"/>
<add key="versionControl.changeTracking.disable" value="true"/>
</appSettings>Addendum
FileUploadRestrictions
An additional change to the web.config file is required for the FileUploadRestrictions app setting so that meaningful error messaging is provided when disallowed files are attempted to be uploaded.
httpErrors, existingResponse PassThrough should be added to the system.webServer section of the web.config file.
<system.webServer>
<httpErrors existingResponse="PassThrough" />
</system.webServer>jira.refreshlookups.sampleIssuesForAdditionFields
When refreshing lookups in the JIRA (REST based plugin – JIRA 5.2 and above), if this option is set to true (the default) it will use both create screen meta and a technique of sampling issues of each issue type in a project and getting their edit screen metadata to compile a list of all available custom fields. This does require that the project contains issues to sample in the first place, and will still not detect fields that are neither on the edit or create screen ( e.g. transition screens).
Sampling may be slow for instances with very large numbers of issue types. If performance is slow, it may be necessary to turn this value to false. Note that this does mean any field that you wish to map for synchronization must appear on the create screens for those issue types/screen schemes.
If enabled, and the logging level is “INFO” or “DEBUG” then when doing a refresh lookups, you will see this in the log file:
GetEditCustomFields - starting to retrieve metadata for sample issues
... activity
GetEditCustomFields - completed retrieval of metadata for sample issues, elapsed time: 00:01:22.000Which allows you to see how much time is being spent retrieving getting custom field information by sampling issues and getting their edit meta data.
Additionally, if the feature is set to “off” (false) and the log level is “DEBUG” then in the logs you will see this message:
GetEditCustomFields - skipping because sampleIssuesForAdditionalFields is set to false.So you can be assured that sampling of issue edit metadata is not occurring.
site.root.url.scheme
Here are the values that the appSetting site.root.url.scheme can be configured as.
| Value | Description | Comment |
|---|---|---|
| Http | Forces base URL to http when processing OAuth requests. | |
| Https | Forces base URL to https when processing OAuth requests. | |
| SameAsRequest | Uses same scheme (Http/https) as the request’s URL. | This is equivalent to how ET used to work for v4.5 and below. |
| XForwardedSchemeOrSameAsRequest | Checks for the x-forwarded-scheme header, if present, will use the value specified there, if header not present, will revert back to the “Same as request” behaviour | This is the new default for v4.6 and above. |
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 (x86)\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 “~”.
<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.
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’.
In the web.config file, locate the appSetting section and add the following key value pair to disable the automatic refesh lookups at start up.
<appSettings>
<add key="defecttracking.settings.populator.syncuncachedonstartup" value="false" />
</appSettings>
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’.
In the web.config file, locate the appSetting section and add the following key value pair to disable the automatic refesh lookups at start up.
<appSettings>
<add key="externaldata.createlink.autorefreshlookups" value="false" />
</appSettings>
Storing Attachments in a File System
Before you Begin
By default Enterprise Tester stores attachments in the file system from V4.3 and above. Note that the original installation must be V4.3 (released September 2012) and above. In this case, you do not need to make any additional configurations to your system unless you would like to change the default file storage location or the maximum file size. See the Additional Configurations section below.
Where the original installation of ET was a version earlier than 4.3 then the default attachment storage is in the database and you will need to migrate the attachments from the database in addition to making the changes to the web.config file described below. Failure to migrate your attachments from the database after changing the attachment storage method will make those attachments in the database unavailable to users and will leave your system with attachments in both the database and the file system. The migration process described below will not migrate attachments from the database if new attachments are already being stored in the file system. In this case, please contact Catch Support for assistance.
Before running the AttachmentMigrator tool ensure you backup the following;
- Enterprise Tester Database
- Enterprise Tester file directory (where Enterprise Tester is installed i.e. (c:\Program Files\Catch Limited\Enterprise Tester\)
Changing Attachment Storage from Database to File System
Enterprise Tester provides a mechanism to migrate between storing attachments in the file system or database for an existing instance of Enterprise.
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).
1) Download EnterpriseTester- xxx-BIN.zip
2) Go to the properties of the zip file and select Unblock.
Select Apply.
3) Extract the EnterpriseTester-XX-BIN.zip file.
4) Copy all the files from the unzipped BIN directory to Enterprise Tester
i.e. c:\Program Files\Catch Limited\Enterprise Tester\web\bin
5) Replace all the files in the destination folder
6) Create a new folder inside the BIN directory called “MigrationRunner”.
NOTE: Do not put a space between Migration and Runner
7) Copy all files from the Bin directory into the MigrationRunner directory
8) Copy the web.config file from the Enterprise Tester\Web directory to the Enterprise Tester\Web \Bindirectory
9) Stop IIS
10) Go to …\Catch Limited\Enterprise Tester\Web\bin\MigrationRunner directory and run the AttachmentMigrator.exe
executable. The following message will appear :
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.
11) Type yes and press <Enter> to proceed.
You will then see progress displayed on screen, and eventually the migration will complete.
12) Copy the web.config file
From – …\Catch Limited\Enterprise Tester\web\bin
To – …\Catch Limited\Enterprise Tester\web\.
This has the change made to the attachment.storage.method so the attachments are now stored in the file system.
13) Open the command line and run the following
cd\Program Files (x86)\Catch Limited\Enterprise Tester\web\bin
14) Now run postinstall.exe ziprelease
15) 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.
Additional Configurations
Changing the Attachment Storage Location
By default, attachments are stored in the folder ../Data/Attachments/ (so normally c:\Program Files(x86)\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 1gigabyte in size.