If upgrading from a previous version of the QAD .NET UI, please be sure to review the release notes for the versions in between your current version and this version.
Operational Metrics History
With the QAD Operational Metrics History, you can view changes in operational metrics over time. The system stores the history of operational metric activity and then generates charts of the data for you. The metric history data is also used to speed up the performance of metric programs when launched from the menu; by using the most recent history data, the system does not need to run the underlying metric browse queries and calculations each time. QAD Operational Metrics History is available as a plug-in to the QAD .NET UI. The QAD Operational Metrics History plug-in can be installed on QAD Enterprise Applications – Enterprise Edition 2012 or 2012.1. You can download the plug-in from the QAD Store
Mobile Application for Browses
With the QAD Mobile Browse app, you can use selected QAD Enterprise Applications browses on mobile tablet devices. QAD Mobile Browse is available for Apple iOS devices (iPad) and Android tablets. QAD Mobile Browse for the iPad is available on the Apple iTunes store and QAD Mobile Browse for Android tablets is available on the QAD Store (http://store.qad.com).
Browse Performance Controls
When developing custom browses with Browse Maintenance, be sure to follow the browse performance guidelines described in User Guide: Introduction to QAD Enterprise Applications. If not developed carefully, custom browses can cause performance issues. If custom browses are causing performance issues, you can configure the system to identify those browses, send warnings to the Message Inbox, and cancel the browses after a specified time.
Canceling the browses after a specified time prevents long-running browse queries from adversely affecting application server performance, which can affect all the users of the system. You can have the system identify, report, and eventually cancel long-running browses. You can alert administrators that a performance problem could be developing by having the system periodically send messages to the Messages Inbox. The browse name and query conditions are included in the messages to help administrators identify problematic browses and their user-specified conditions. In general, performance issues can often center around just a few browses. To track particular types of browses, you can use regular expressions to specify the names of the browses you want to monitor and possibly cancel after some specified time. To configure the system to identify, report, and cancel such browses, use the following settings in the client session configuration file (client-session.xml):
<NotifyRole> indicates which role (or group) of users gets notified on any browse alert. Notification is sent to the Messages Inbox.
<NotifyEmail> specifies a comma-separated list of e-mail addresses to which browse alerts will be sent.
For example: <NotifyEmail>email@example.com,firstname.lastname@example.org</NotifyEmail>
(The SMTP elements in this file need to be configured for your SMTP server for this setting to work.)
"/> specifies a browse performance warning or cancelation, where:
browseId specifies a browse ID. The browse ID is the first two letters of the browse name, followed by the number (without the br or .p in the browse name). For example, the browse ID of Item Browse (ppbr100.p) is pp100. You can also enter a regular expression. For example, pp* specifies all browses whose browse IDs start with pp. The default is blank.
warnAt specifies the interval in minutes for sending warning messages to users in the <NotifyRole> role (or group). The warning messages can alert administrators that a performance problem could be developing because of a long-running browse query. The messages include the browse name and the query conditions entered by the user.
cancelAfter specifies the minutes after which the browse will be canceled, with 0 specifying no cancellation.
Use warnAt and cancelAfter to have the system report warnings up to some time after which the browse is canceled automatically. For instance, in <timeout browseId="pp*" warnAt="2" cancelAfter="10"/>, the system reports warnings every two minutes for all browses running whose names start with pp. After ten minutes, those browses are canceled.
The following is included in client-session.xml:
<timeout browseId="" warnAt="0" cancelAfter="0"/>
<timeout browseId="ppbr100.p" warnAt="2" cancelAfter="5"/>
<timeout browseId="so*" warnAt="2" cancelAfter="5"/>
By default, the settings are not active; they are included as comments in client-session.xml. To use the settings, remove the comment markers (<!-- ... -->) and edit the default values.
How To Disable Browse Total Count Thread
The <MaximumBrowseRecordsToCount> configuration setting in the client session configuration file (client-session.xml) limits the total count of records for browses, which controls excessive database server load if the query corresponds to a large set of records. (The default is 50,000 records.)
However, counting the records can also have a performance impact. Generally, the greater the number of records that satisfy the query, the longer it takes for the count to complete. In some cases, the count operation can pose such a demand on system resources that disabling it might be warranted. Custom browses (defined using Browse Maintenance) can include pre- and post-processor logic that can cause the total count thread to impact performance, since the logic would have to be executed across the entire data set to count the records properly. In such cases, you can either change the logic of the custom browses or disable the total count thread for the system.
To disable the total count thread, set <MaximumBrowseRecordsToCount> to a value less than or equal to zero (for instance, 0 or -1).
Provides a mechanism to set the timeout on a browse “get all records” request to a single value with a <TreatGetAllAsOneRequest> setting in the client-session.xml configuration file. The “get all records” request is actually a series of requests to the server. Setting the parameter to false will treat each request separately for timeout. Setting the parameter to true will use one timer for the set of requests. Suppose the timeout value is 5 minutes and 3 calls are made, each taking 4 minutes. A false setting would not time out, as no single request exceeds 5 minutes. A true setting will time out on the second request, as the 5 minutes is used up.
Browse Performance Controls in AIA Environments
The browse performance controls, which enable the system to identify, report, and cancel long-running browses, are now working for environments using AIA. (Note that the Cancel button has been removed because in this case it does not cancel the browse.) This feature requires that QAD Enterprise Applications be using Progress 10.2B.
Generalized Code Optimization
The loading of generalized code list values is now configurable and can be restricted to a system-defined record count. You can configure the record count limit by setting <GeneralizedCodeMaxValues> in the client-session.xml file. The default is zero, which specifies no limit on the list count. A negative value such as -1 specifies no generalized code pull-down lists. Finally, a value greater than zero specifies to show the generalized code pull-down list only when the list has the specified number (or less) of records.
Date Display Correction in Reports from Browses
The display of dates in reports from browses (choose Browse | Actions | Report) is now in the correct format. Previously, only days were shown.
Column Filters on Browses Saved As Favorites Limitation
If you set a column filter on a browse and add that browse as a favorite, note that the column filter is not retained (the filter is for action that takes place after the browse is loaded). When launching a browse saved as a favorite, you will need to apply column filtering after the browse is launched.