In order to bring you the best possible user experience, this site uses Javascript. If you are seeing this message, it is likely that the Javascript option in your browser is disabled. For optimal viewing of this site, please ensure that Javascript is enabled for your browser.
Login  |   On Demand  |   Home  |   qad.com




Application Changes
If upgrading from a previous version of the QAD .NET UI, be sure to review the release notes for the versions in between your current version and this version.
The following summarizes application changes for this version of the QAD .NET UI.
Copying Links to Clipboard
You can now copy (and paste) QAD Shell URL (qadsh://) links to Desktop programs and browses by choosing Actions | Copy Link To Clipboard. You can then paste the URL into a browser to run the Desktop program or browse.
E-mail Action Options
The Action/E-mail feature in programs running in Desktop mode allows you to create an e-mail with a QAD Shell URI (qadsh://) to a Desktop program. There has been an inconsistency in this feature because different e-mail clients handle the QAD Shell URI differently, some recognizing it and allowing the e-mail recipient to launch the link and some not recognizing it and instead requiring the recipient to copy the link and paste it into a Web browser.
New options are now available to:
Allow an administrator to set (using client-session.xml) whether they want the QAD Shell URI to be used directly (which is and has been the default) or if they want to wrap this QAD Shell URI in an HTTP URI (http://), which is more widely recognized by e-mail clients.
Provide an option to turn on or off the inclusion of the full URI in the e-mail. (By default two links are put in the e-mail—the first is the program label that links to the URI and the second is the full URI. This option controls the second link.)
Provide an option to create the link as text instead of HTML (for e-mail clients or settings that are text-based).
These options are controlled by the following settings, which can be added to client-session.xml:
<EmailAction.UseHTTP>true</EmailAction.UseHTTP>
When set to true, the HTTP URI is used in the e-mail. When false, the direct QAD Shell URI is used.
<EmailAction.IncludeURI>true</EmailAction.IncludeURI>
When set to true, the full URI is added as a link in the e-mail. When set to false, it is not included.
<EmailAction.UseText>true</EmailAction.UseText>
When set to true, the link is text. When set to false, the link is HTML.
Parameters in Terminal Script in User Option Telnet Maintenance
You can now specify the following parameters in the Script Value field in User Option Telnet Maintenance:
${d} – Domain
${u} – User ID
${e} – Entity
${c} – Code Page
Any number of these can be included in Script Value, with each separated by a space. For example:
/dr01/scripts/telnet.ksh ${d} ${u} ${e} ${c}
These will then be available in the telnet script as standard parameters (${1} ${2} ${3} ${4}).
Lookups Not Limited to Starting Point of Field Value
By default, the initial item on a field’s lookup browse is the current value in the field. For example, on the Sales Order Maintenance program’s Credit Terms field, if the current value is 30D (for 30 days after invoice date), the lookup browse for the field will list the terms codes for the field starting with 30D, the current value. Although this is the list that many would like to see, in some cases you might want the lookup to list all the possible options for the field rather than just the ones starting at the current value. For example, for the Credit Terms field, you might want to have all the term codes listed, not just the ones starting at 30D.
You can now have the lookup browses for specified fields list all the options for the field rather than just the ones starting at the current value. The configuration steps must be done by a system administrator with access to the QAD system files.
Note: The ability to change the lookup browse listing only applies to programs that run in Desktop mode.
Changing the Lookup Browse Listing
To change a field’s lookup browse to list all the options for a field, do the following:
1
Identify the program name (for example, for Sales Order Maintenance, the program name is sosomt.p).
2
Identify the field name (for example, for the Credit Terms field, the field name is so_cr_terms).
3
In your QAD installation, locate the com/mfgpro/setting.dat file and com/qad/mfgpro/setting.dat file.
4
Add the following line to the end of both setting.dat files:
bl: program_name :b: field_name =true
where:
bl indicates “blank lookup”.
program_name specifies the program, but with no dot (“.”) before the p. For instance, sosomtp rather than sosomt.p.
b indicates the current frame.
field_name specifies the field. For instance, so_cr_terms specifies Sales Order Maintenance’s Credit Terms field.
For example, for Sales Order Maintenance’s Credit Terms field, you add the following line to the end of both setting.dat files and make sure to leave an extra blank line below it:
bl:sosomtp:b:so_cr_terms=true
5
Restart the Connection Manager.
Output to Text Lines Now Configurable
You can now configure the maximum number of lines displayed to the user when running a legacy report with output to text. To do so, use the <QView> ... <TextReportLines> setting in the client-session.xml file. The default is 100,000 lines:
<TextReportLines>100000</TextReportLines>
Browse Performance Checking
The system can now do a performance check on the index use of a new browse definition when you save it from Browse Maintenance. The performance check, Show Index Information, helps to avoid the creation of poorly performing browses with non-indexed fields in joins, filters, and sorts.
When a browse definition is saved from Browse Maintenance, the Progress Query Parser’s INDEX-INFORMATION is examined. Checks are made to determine whether indexes can be used. Improperly defined query definitions are indicated as whole index scans and are displayed in red in the Index Information tab. For instance, the browse definition could result in a table scan that could cause performance issues and you might need to modify the definition so that no whole index scans occur. Tables with large numbers of records might negatively affect performance, so you might need to analyze the query string to identify possible causes. To do so, open the Query String tab to view the dynamically generated query string as determined by the Browse Engine.
The performance check is on by default, but can be changed from the Show Index Information setting Tools | Options or from the config-session.xml file, which now includes the following:
<DotNetBrowseMaintenanceShowIndexInformation>true</DotNetBrowseMaintenanceShowIndexInformation>
The setting specifies whether the output of the Progress INDEX-INFORMATION attribute for a query is displayed when there is an issue.
Note: The ability to examine what the Progress Query Parser determines as the indexes for a query is limited. The Browse Engine currently only exposes the dynamic query string before appending sorts, local variables, pre and post processor commands, and so on. This performance check helps eliminate most poorly performing browses that have been built from improperly constructed definitions. However, this check does not cover situations where users apply search conditions and sorts after the browse has been displayed in the user interface.
Browse Export and Import Identifies Language Mismatches
Previously, when a browse was exported using Browse Maintenance, the labels used in the browse were included for all the supported languages. However, when imported, the only the labels for the user importing the browse were included with the imported browse. Now, an imported browse includes all the labels for languages supported by the system, not just the ones for the user’s current language. If the browse includes labels for languages that are not defined in the system, a warning message is included in the system log file (“WARNING: The Language language for the Label Term label term does not exist in the target language. Label not imported for this language”).
Find Feature for Legacy Reports Output as Text
Any legacy report that is output to text now includes a Find box on the toolbar for searching the report. You can also activate the Find feature by entering Ctrl+F.
Active Directory Enhancements
The QAD .NET UI supports Microsoft’s Active Directory authentication. With this release, Active Directory support has been enhanced so that the QAD .NET UI:
Allows any domain to be specified at login.
Allows the default domain to be specified on the home server.
Enables a list of valid domains to be specified on the home server.
Removes OS user ID restriction. Allows any domain and user ID combination to be entered, except local domain.
Enables user ID mapping between Active Directory and QAD, which eliminates the eight-character user ID limitation.
Eliminates blank QAD password vulnerability.
Eliminates domain spoofing.
With these Active Directory enhancements, users are required to do the following:
Enter a QAD user ID and password the first time they use Active Directory authentication.
Re-encrypt the credentials store whenever their Active Directory password changes. They are prompted to enter the Active Directory password used during the original encryption.
Re-enter their QAD credentials whenever they are unable to remember the Active Directory password used during the original encryption.
With Active Directory, QAD passwords are encrypted in a credentials file named <domain> - <user> -credentials.xml, located on the home server in a / <environment> /storage/user-data/ <user> directory. Passwords are encrypted using AES with a 256-bit key generated at runtime using the password base key derivation algorithm (RFC 2898).
Active Directory Configuration Settings
The following settings in client-session.xml: configure Active Directory:
<QAD.Authentication.ActiveDirectory.Enabled>
This setting enables or disables Active Directory authentication, with true enabling Active Directory and false disabling Active Directory.
<QAD.Authentication.ActiveDirectory.Domain>
This setting specifies the default Active Directory domain. If a domain is not specified, the current PC domain is used. Domains are resolved in the following order:
1
Login form: users can specify a domain using the syntax {domain}\(username).
2
Configuration setting in <QAD.Authentication.ActiveDirectory.Domain>
3
Current active PC domain.
<QAD.Authentication.ActiveDirectory.ValidDomains>
This setting specifies a comma-delimited list of valid domains used during Active Directory authentication.
Note: In client-session.xml, the <QAD.Authentication.ActiveDirectory> setting has now been replaced by the <QAD.Authentication.ActiveDirectory.Enabled> setting.
Enabling Active Directory Authentication
To enable Active Directory authentication:
1
Define users so that the user IDs match the Windows user IDs. Assign temporary QAD passwords to new user IDs.
2
Locate the client-session.xml file on the home server. (By default, the file is located in the TomcatInstallDir /webapps/qadhome/configurations/default directory.)
3
In the client-session.xml file, set <QAD.Authentication.ActiveDirectory.Enabled> to true.
When a user first logs in to the QAD .NET UI, the system prompts the user to enter the temporary QAD password that was assigned to the user ID. Entering the temporary password then completes the Active Directory setup. The next time that the user logs in to the QAD .NET UI, the user must use their Windows user ID and password.
Note: In previous releases, when setting up Active Directory, you had to enable the Enforce OS User ID option in Security Control (mgurpmmt.p). Additionally, the passwords for user IDs had to be sent to blank. Starting with QAD .NET UI 2.9.5, these steps are no longer necessary.
QAD Shell URL (qadsh://) Protocol Enhancements
The qadsh:// protocol has been enhanced as follows:
The qadsh:// protocol is now registered on a user basis, allowing different users to access different versions of the QAD .NET UI client on the same machine.
The qadsh:// protocol is now registered during the launch of the QAD .NET UI, ensuring that the protocol is defined correctly.
The qadsh:// protocol is only registered if the registry setting for the currently running QAD .NET UI client is different than the one already registered.
The qadsh:// protocol always points to the last QAD .NET UI version that was launched rather than the version most recently installed.
The user registry settings do not require administrative permissions, enabling XCOPY installations.
Legacy Report Output and HTML Syntax
You can now configure specific legacy reports to display HTML syntax in output to “page”. The current default displays the HTML code instead of rendering the HTML itself. This default exists to overcome the problem in which the report data had special HTML characters such as < or >. If the data has such characters and output to “page” is used, then an error results and the report does not render. However, there are situations in which HTML (such as a link or a button) in the report output is useful, so you can now specify which report programs are allowed to display HTML.
Requirements
The report program specified to display HTML must not have the possibility of data in it that has special HTML characters that are not proper HTML syntax. For example, the item number abc<1000> has HTML brackets in it but is not proper HTML syntax and causes the report not to render.
The report cannot be on the list of reports in the enhanced format (beautifyReports.lst).
Setting Report Programs to Display HTML
1
Edit com/mfgpro/setting.dat and add a comma-delimited list of report programs to the htmlReports setting.
2
Make the same change to com/qad/mfgpro/setting.dat.
3
Restart the Connection Manager.
Note: QAD does not provide support for HTML customizations of reports.
Allowing Changing of Legacy Report Output
Legacy reports can now be configured to output their report files to a directory other than the default working directory of the common Connection Manager user.
This feature is turned off by default but can be enabled as follows:
1
Locate com/mfgpro/setting.dat.
2
Follow the instructions in that file to set the reportPath setting.
3
Make the same change to com/qad/mfgpro/setting.dat.
4
Restart the Connection Manager.
5
Restart the QAD .NET UI client.
This only applies to Desktop reports run from the QAD .NET UI. It does not apply to:
Terminal or CHUI mode.
Reports that have two output fields (such as Invoice Post and Print).
Batch reports (in any mode).
File system permissions must be taken into account when using this mechanism. Keep in mind that even though the report file can be redirected to a different location, it is still being written by the common Connection Manager user. As a result, that user must have the access to write the report files to whatever location is specified here.
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.
You can then explore the chart data further, change the time range, scroll right and left or zoom in and out of particular areas of interest, and export the chart data to Excel for further analysis.
When you open an operational metric page, the system uses the most recent history data to display the initial view of the metric page if the data is less than 24 hours old. This allows the page to be displayed more quickly than if the underlying metric browses were queried to retrieve the data.
The system saves history data whenever the browse queries for the metrics are run. In addition to the history data, a pie chart that summarizes the metric results is also saved so that the Operational Metrics View process map can show the most recently generated results.
The system queries the metric browses (and saves history data) in the following situations:
When you click an operational metric’s Refresh button.
When you open an operational metric and the history data is more than 24 hours old. (Note that 24 hours is the default; the interval is configurable and applies to all metrics in the system.)
When the QAD_OpMetricsAutoRun report is run. Typically, this report is run when metrics are scheduled for periodic running, but if a report administrator runs this report from the report designer, it also runs the metric and its processes.
The history data is never deleted from the system.
A new “as of” label next to the metric name indicates the date and time of the metric data being displayed. If the browse queries are currently running, “loading...” is displayed next to the metric name; when they finish running, the “as of” time shows the current time.
Metric history data contains at most one history record per day for a given metric. If the metric’s browses run more than once in a given day, the history reflects the most recent run.
Configuring Operational Metrics History
Configuring Operational Metrics History includes the following:
Operational Metrics History Update Interface
Operational Metrics History and the QAD Reporting Framework
Operational Metrics History Update Interval
By default, if operational metric history data is more than 24 hours old, the system updates the data (by running the metric browses) when you launch a metric collection. Otherwise, the most recent history data is used to display the metric more quickly.
You can change the time interval by adding (and modifying) the following to the client-session.xml configuration file:
<Metrics>
...
<StaleDataAllowedHours>24</StaleDataAllowedHours>
...
</Metrics>
The time interval applies to all metrics in the system.
Operational Metrics History and the QAD Reporting Framework
Operational Metrics History uses the QAD Reporting Framework report server’s scheduled batch mode to auto-run a special report that runs the desired metric and generates and stores metric history data. The new QAD-supplied report, QAD_OpMetricsAutoRun, is used for auto-running the metrics in scheduled batch mode.
Your system must be configured to run scheduled reports in scheduled batch mode (see the Scheduled Batch Mode section in the Reporting Framework User Guide’s Administering Reports chapter).
Additionally, the Set Up a Scheduled Batch section in the Reporting Framework User Guide’s Administering Reports chapter describes how to create a parameter file to contain command-line parameters with fixed values, using a params.pf file as an example. In that file, you must add the following line in order for the metric report to run properly:
-enable:qad.plugin.opmetrics
Using 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 graphs of the data for you.
For example, in the Sales Orders metric collection, open the Sales Orders Past Due metric. Notice the thumbnail images to the right of the displays for Past Due Orders and Past Due Cost. Click the thumbnail image for Past Due Orders:
When you click on the chart thumbnail, a metric history chart displays:
Navigating the History Chart
Under the thumbnail image of the chart, click the icons that allow you to:
Change the time range of the display (1 week, 1 month, 3 months, 6 months, 1 year, 2 years, 3 years).
Toggle the Zoom control to:
Zoom in
Zoom out
Zoom horizontally
Zoom vertically
Export the history data to Excel for further analysis.
Detach the chart to a separate window to enlarge the view.
You can also click-drag to navigate the metric history chart.
If you mouse over a data point, it shows you its value. The color of the dot on a given day corresponds to the metric result for that day. Boundaries for the result ranges (where red indicates an error, yellow indicates a warning, and green indicates good) are also displayed on the chart as colored dotted lines.
Clicking the chart thumbnail again hides the metric history chart.
Scheduling Batch Processes for Operational Metrics History
Although metric history gets generated whenever a user manually refreshes a metric (or opens a metric that does not have recent history data), you can schedule metrics to be run at regular intervals to guarantee the regular creation of history data. For example, you might want to schedule a certain metric to be auto-run daily and a different metric to be auto-run weekly.
Operational Metrics History uses the QAD Reporting Framework report server’s scheduled batch mode to auto-run a special report that runs the desired metric and generates and stores metric history data. This must be configured as described in Operational Metrics History and the QAD Reporting Framework.
Scheduling and Running Batch Processes
You can schedule and edit these batch processes directly from a metric display.
From the toolbar, choose Schedule to schedule batch processes:
The Schedule pull-down options include:
New — schedule a new batch process. Enter a valid batch ID.
Note: Batch IDs must first be defined by an administrator using Batch ID Maintenance. It can be useful to name the batches according to the time interval at which the report server is configured to run that batch. For example, you might define a batch called “daily” that is configured to run every day and another batch called “weekly” that is configured to run once a week. When a batch ID is specified by the user, the metric auto-running only occurs if a report server is configured to process that batch ID.
View Schedule — view currently scheduled batch processes in a browse. You can view further details and modify the batch process by right-clicking on the ID and choosing Scheduled Report History, Parameters, and Scheduled Report Maintenance. Use Scheduled Report Maintenance to modify batch details. (See the Reporting Framework User Guide’s Maintaining Scheduled Reports section for further information.)
View History — view previously run batch processes in a browse that includes their status, such as New, Waiting, Running, Complete, or Error. (See the Reporting Framework User Guide’s Viewing Report History section for further information.)
Saving Operational Metrics as Favorites
To save a metric as a favorite, you can either:
Drag the menu item for the metric from the Applications pane to the Favorites pane.
When the metric is open, click the Add to Favorites button in the toolbar.
Important: These two ways do not create the new favorite in the same way:
When you drag the metric from the Applications pane to the Favorites pane, the new item in the Favorites pane points to exactly the same metric with the same history data. Clicking on the favorite opens the same metric as clicking on the metric in the Applications pane.
When you click Add to Favorites, however, a new metric is created and the new item in the Favorites pane points to the new metric. The reason it creates a new metric is that you are free to make custom changes to it before saving it as a favorite. As with all favorites, the new favorite metric is only visible to the user that saved it. Although the new favorite can have the same name (by default) as the one on the Applications pane, clicking on the favorite opens the new metric. Although the new metric is based on the same browses, the history data saved for the new metric is different. Additionally, the new metric saved as a favorite by using Add to Favorites does not have the scheduling functionality.
Note: If you want the metric saved as a favorite to be the same metric (with the same history data) as the one on the Applications pane, be sure to drag the menu item from the Applications pane to the Favorites pane.
Attaching Metrics History Manually
Metrics history is attached to specific metrics collections, which reside as XML files on the QAD home server. If these XML files are replaced by new or modified files (during an upgrade, for example), the system reconnects the existing history to the new XML files. However, in some cases, due to certain changes in the new (or old) XML files (changes in metric names, for example), the history might not get reconnected. To address this, a history connection screen can be enabled, allowing an administrator to manually connect the history to metrics. To enable this feature:
1
Edit the client-session.xml file, and find the <Metrics> element.
2
Inside the <Metrics> element, add the following:
<ManualAttachHistory>true</ManualAttachHistory>
3
Launch the QAD .NET UI client.
Now, when an administrator (someone with access to create metric collections) runs a metric and right-clicks on the metric name, there will be a History menu item with the following options:
Merge — this brings up a window in which the current history chart will be displayed along with a chart in which can be displayed one or more sets of history that are available to merge with the current history.
Replace — this brings up the same window as above, only the selected history set completely replaces the current history, instead of merging with it.
Unlink — this disconnects the metric from any history, allowing history to start fresh.
The changes done in all three cases only take effect if the collection is saved using the Replace option.