An administrator can manage ZENworks Reporting settings.
The jasperserver.log file is located at the following path:
For Windows: %ZRS_HOME%\js\apache-tomcat\webapps\jasperserver-pro\WEB-INF\logs
For Linux: /opt/novell/zenworks-reporting/js/apache-tomcat/webapps/jasperserver-pro/WEB-INF/logs
To manage log settings:
Click Manage > Server Settings > Log Settings.
In the Log Settings page, use the drop-down list to change the log level for each class being logged.
The four logging levels indicate the type of event recorded by a logger.
|
Setting |
Level of Information |
|---|---|
|
ERROR |
Writes minimal information to the log describing serious program faults. |
|
WARN |
Writes error and warning messages to the log. Warning messages contain cautionary information to help you whether the logged events require your attention. |
|
INFO |
Writes error, warning, and informational messages to the log. Informational messages describe significant events, such as those that affect application performance. |
|
DEBUG |
Writes error, warning, informational, and additional messages to the log. Debug messages are very detailed. Use this setting only to diagnose a problem. DEBUG can impact system performance and should not be used in production environments. |
The following table lists each logger name as it displays on the Log Settings page, it is used to find a particular log in the log file, and a description of the logger.
|
Logger Name |
Identifier in log |
Description |
|---|---|---|
|
SQL query executer |
JRJdbcQueryExe cuter |
Logs SQL text and parameter values for queries that are run by the SQL query executer. |
|
Input control value queries |
valueQueryLog |
Logs SQL text and parameter values for queries associated with input controls. |
|
Cascading input control parameter resolution |
FilterCore |
Logs activity associated with cascading input controls. Query-driven input controls can cascade when a query has a parameter whose value comes from another input control. When the parameter value is changed, the query is automatically rerun, possibly changing the list of values for its input control. |
|
Cascading input control query result caching |
TokenControlLogic |
Logs use of the cache for results of cascading input control queries. |
|
Hibernate SQL |
SQL |
Logs SQL run by the Hibernate layer to access the ZENworks Reporting repository database. This logger generates a large volume of logging that could affect performance. |
|
Ad Hoc data policy logging |
CommonDomainDataStrategy SubFilterInputControlGenerator Others |
Logs various activities of the Ad Hoc data policy implementations, which use SQL queries or in-memory operations to get data sets for Ad Hoc views. |
|
SQL generated for Domain queries |
JdbcBaseDataSet |
Logs SQL queries generated from queries using a Domain. |
|
Connection handling for Domains |
DataSourceResolverImpl |
Logs use of JDBC connections used by Domains to run SQL queries. |
|
Expression to JSON converter |
ExpressionJSON Converter |
Logs information about the conversion between DomEL and JSON, which is used by Ad Hoc filters. |
|
Domain-based security tests |
SemanticLayerSecurityResolver Impl |
Logs activity related to Domain column- and row-level security. |
|
Cascading input control resolution for Domains |
DomainFilterResolver |
Logs the same activity as the FilterCore logger (Cascading input control parameter resolution) above, but adds information specific to Domain queries. |
|
Ad Hoc cache activity |
CachedData |
Logs information about the life cycle of datasets that are cached in memory when Ad Hoc views are accessed. |
|
Timing for SQL queries run for reports |
JsControlledJdbcQueryExecuter |
Logs the time it takes a query run by the SQL query executer to return data to a report. |
|
Ad Hoc WorkingDataSet |
WorkingDataSet |
Logs activity for the WorkingDataSet, used by the Ad Hoc Editor to perform in-memory dataset transformations of query results. |
|
General controller |
AdhocAjaxController |
Logs activity of the Ad Hoc Editor. |
|
Crosstab controller |
AdhocCrosstabAjaxController |
Logs additional activity of the Ad Hoc Editor specific to crosstab reports. |
|
Groovy code generation for memory datasets |
GroovyGenerator |
Logs Groovy classes generated from DomEL expressions used by the Ad Hoc Editor for filters and calculated fields. |
|
Ad Hoc AJAX requests |
adhocAjaxRequests |
Logs information about AJAX requests done by Ad Hoc Editor and dashboard designer, including report parameters and response times. Enable this setting when you want Ad Hoc Editor and dashboard designer have encountered an error or slow response times. |
|
Ad Hoc cache activity |
com.jaspersoft.commons. datarator.CachedData |
Tracks the life cycle of datasets managed by the Ad Hoc cache as they transition between statuses. This log output includes information from the Ad Hoc cache in a format that lends itself to troubleshooting. Use this setting to understand how query response times contribute to the performance and responsiveness of the Ad Hoc Editor. Because it does not log the queries themselves, use it in conjunction with the SQL Query Executer log setting. |
To add a logger, scroll to the bottom of the page.
Use the drop-down to set the logging level.
The Ad Hoc settings limit the resources available for queries when Ad Hoc views are designed and run. The Query that you can set are:
Ad Hoc Filter List of Values Row Limit: The maximum number of items that should be displayed in the Condition Editor when a user defines filters for an Ad Hoc view that is based on a Domain. If this limit is exceeded when users define filters, then ZENworks Reporting displays a message. Setting this to a lower value can improve performance.
Ad Hoc Dataset Row Limit: The maximum number of rows that an Ad Hoc view can be return. ZENworks Reporting truncates the data when the limit is reached. Setting this to a lower number may improve performance, but your reports may not reflect the full data set.
Ad Hoc Query Timeout: The number of seconds the server should wait before timing out an Ad Hoc view while running its query. Setting this to a lower number may prevent exceptions from being displayed to users when they run Ad Hoc views. Setting this to a higher number may prevent complex calculations from timing out, but it results in the use of more database connections.
To set Ad Hoc settings:
Click Manage > Server Settings > choose Ad Hoc Settings.
In the Ad Hoc Filter List of Values Row Limit, specify the maximum number of items to display in the Condition Editor when a user defines filters for an Ad Hoc report based on a Domain.
In the Ad Hoc Dataset Row Limit, specify the maximum number of rows that an Ad Hoc view can return.
In the Ad Hoc Query Timeout (seconds) field, specify the number of seconds the server should wait before timing out an Ad Hoc report while running its query.
Click Change to save your changes.
Data policies determine how ZENworks Reporting handles data loading and processing for certain types of Ad Hoc views. They determine how data is cached and where certain calculations occur. For example, you can specify that the data accessed by Domain-based reports is grouped, sorted, and aggregated in the database rather than having the server process it in memory.
The data polices that you can set are:
Optimize Queries for JDBC-based Reports: Selects grouping, sorting, and aggregation of queries for JDBC-based reports. Otherwise, the queries run unaltered in memory.
Optimize Queries for Domain-based Reports: Selects grouping, sorting, and aggregation of queries for Domain-based reports. Otherwise, the queries run unaltered in memory.
To set data policies:
Click Manage > Server Settings > Ad Hoc Settings.
Select Optimize Queries for JDBC-based Reports to process queries for JDBC-based reports.
Select Optimize Queries for Domain-based Reports to process queries for Domain-based reports.
Click Change to save your current settings.
NOTE:These data policy settings does not update the existing reports created from Ad Hoc views in your repository. To change the data policy for an existing report, select the appropriate policy setting, open the corresponding view in the Ad Hoc Editor, and save the report again.
ZENworks Reporting can temporarily cache Ad Hoc query result sets for re-use. The cache is populated by the data that results from queries when creating or running Ad Hoc views. The datasets are uniquely identified with a key that references the query itself, the data source URI, and parameters used when the query was issued.
Caching reduces database loads and delivers frequently-used datasets to the user quickly. Caching applies when reports are created as well as when they are run. You can configure the Ad Hoc cache to optimize memory usage and response time for your usage patterns.
By default, datasets for each user are cached separately; a parameter in the cache key identifies the user. This per-user caching can result in duplicate datasets when different users run the same query. You can configure ZENworks Reporting to share cached datasets across users by editing the \WEB-INF\applicationContext-datarator.xml file.
The following code configures the cacheKeyInterceptor to ignore logged-in users’ credentials when creating the cache keys:
|
<property name="ignoredParameters"> <list> ... <value>LoggedInUser</value> <value>LoggedInUsername</value> </list> </property> |
After adding the code restart ZENworks Reporting.
Caching improves overall performance of data retrieval and sorting, but unused datasets can consume memory. To address these issues, you must configure the frequency to clear the cache.
To configure the frequency with which the cache is automatically cleared, edit the following configuration file:
|
Ad Hoc Cache Expiration |
||
|---|---|---|
|
Configuration File |
||
|
…\WEB-INF\adhoc-ehcache.xml |
||
|
Property |
Default Value |
Description |
|
maxEntriesLocalHeap |
1 |
The maximum number of cache entries in local heap memory. |
|
timeToIdleSeconds |
300 |
The number of seconds to wait after a dataset is has been accessed before removing it from the cache. The default is 30 minutes. Use 0 (zero) for no limit. |
|
timeToLiveSeconds |
300 |
The maximum time that a dataset is stored in the cache, even if it is being repeatedly accessed. Ensures that stale data is periodically replaced. The default is 90 minutes. Use 0 (zero) for no limit. |
After editing the configuration file restart ZENworks Reporting.
Administrators can view the query but not the content of the dataset in the cache. The Ad Hoc cache page also displays performance data about each query. This information is helpful when trying to resolve performance issues.
The following are the values for query:
Query (msec) – Time in milliseconds consumed, when query was sent to the data source (database) until the first row was received.
Fetch (msec) – Time in milliseconds from when first row was received from the data source (database) until the last row was received.
Memory used (MB) – Size in megabytes of the resulting dataset being stored in the cache entry.
The Ad Hoc cache page also allows administrators to manually remove datasets if necessary to fetch recent data.
To view and clear the Ad Hoc Cache manually:
Click Manage > Server Settings > Ad Hoc Cache.
The Ad Hoc Cache page is displayed with all the datasets that are in the cache, sorted by age.
In the Query & Source column, click a query for which you want to view the details.
The Detail page is displayed with additional information for the selected query, such as the number of rows in the cached dataset.
Click Clear to remove a data set from the cache.
Click Clear All at the top of the Ad Hoc Cache page, to remove all datasets.
Import settings allows you to simplify the import procedure. Import operates on a running server, and all imported resources are visible immediately. In addition, any configuration or security settings in the imported catalog affect immediately, without restarting the server.
You must import only through command prompt.
Usage: cd /opt/novell/zenworks-reporting/js/buildomatic/
./js-import.sh [OPTIONS]
NOTE:It is recommended to stop your server before using the import command line utility to avoid issues with caches, configuration, and security.
Reads a repository catalog from the your file system and creates the named resource in the ZENworks Reporting repository. The repository catalog must have been created by the export interface or the js-export command, either as a ZIP archive file or a folder structure.
Table 4-2 Options in js-import Command
|
Option |
Explanation |
|---|---|
|
--help |
Displays brief information about the available options. |
|
--input-dir |
Path for importing a catalog from a directory. |
|
--input-zip |
Path and filename for importing a catalog from a zip file. |
|
--update |
Resources in the catalog replace those in the repository if their URIs and types match. |
|
--skip-user-update |
When used with --update, users in the catalog are not imported or updated. Use this option to import catalogs without overwriting currently defined users. |
|
--include-access-events |
Restores access events (date, time, and username of last modification) on imported resources. |
|
--include-audit-events |
Professional edition only. Imports any audit data that exists in the catalog. |
|
--include-monitoring-events |
Professional edition only. Imports any monitoring data that exists in the catalog. |
|
--include-server-settings |
Determines whether the system configuration is updated from the catalog. There are two pre-requisites in order for the catalog to contain configuration settings: The originating server settings must be modified through the UI (Log Settings, Ad Hoc Settings, Ad Hoc Cache Settings). The catalog must be exported with the “everything” option from the user interface or the command-line utility. When server settings are imported, they take effect as soon as the server is started. |
Examples:
Import the myExport.zip catalog archive file:
cd /opt/novell/zenworks-reporting/js/buildomatic/
./js-import.sh --input-zip myExport.zip
Import the myDir catalog folder, replacing existing resources if their URIs and types match those found in the catalog:
cd /opt/novell/zenworks-reporting/js/buildomatic/
./js-import.sh --input-dir myDir --update
Import the myExport.zip catalog archive file but ignore any users found in the catalog:
cd /opt/novell/zenworks-reporting/js/buildomatic/
./js-import.sh --input-zip myExport.zip --update --skip-user-update
Import the myDir catalog folder with access events:
cd /opt/novell/zenworks-reporting/js/buildomatic/
./js-import.sh --input-dir myDir --include-access-events
Export settings allows you to export users and roles in addition to, or instead of, repository contents, use the server settings pages for system administrators.
Click Manage > Server Settings > Export.
Specify the name of the catalog zip file to export.
The Web UI supports only the zip archive format
Use the following check boxes to choose the contents of your exported catalog file:
Select Export Everything to export the entire repository, including permissions and report jobs, as well as all organizations, users, and roles.
Select Include access events if you want to include resource modification times.
Clear the Export Everything check box, then select only users and roles to export.
Select Include users with selected roles if you want to select only roles and the users.
In either case, you can select Include audit events and Include monitoring events separately.
Click Export.
The server generates the catalog zip file and your browser prompts you to save the file, depending on the size of the catalog and the options that you have selected.
Usage: cd /opt/novell/zenworks-reporting/js/buildomatic/
./js-export.sh [OPTIONS]
NOTE:It is recommended to stop your server instance before running the export utility.
Specifies repository resources such as reports, images, folders, and scheduled jobs to export to the file system. You can also export the internal definitions for scheduled jobs, users, roles, as well existing audit data. The export output is known as a repository catalog; it is either an archive file or a set of files in a folder structure:
Table 4-3 Options in js-export Command
|
Option |
Explanation |
|---|---|
|
--everything |
Export everything except audit and monitoring data: all repository resources, permissions, report jobs, users, and roles. If any server settings have been modified in the UI, those are included as well. This option is equivalent to: --uris --repository-permissions --report-jobs --users --roles |
|
--help |
Displays brief information about the available options. |
|
--include-access-events |
Access events (date, time, and user name of last modification) are exported. |
|
--output-dir |
Path of a directory in which to create the output catalog folder. |
|
--output-zip |
Path and filename of the output catalog zip file to create. |
|
--report-jobs |
Comma separated list of repository report unit and folder URIs for which report unit jobs should be exported. For a folder URI, this option exports the scheduled jobs of all reports in the folder and recursively in all subfolders. |
|
--repository-permissions |
When this option is present, repository permissions are exported along with each exported folder and resource. This option should only be used in conjunction with --uris. |
|
--roles |
Comma separated list of roles to export; if no roles are specified with this option, all roles are exported. |
|
--role-users |
When this option is present, each role export triggers the export of all users belonging to the role. This option should only be used in conjunction with --roles. |
|
--uris |
Comma separated list of folder or resource URIs in the repository. |
|
--users |
Comma separated list of users to export; if no users are specified with this options, all users are exported. Exporting a user includes all user attributes and, in order to maintain consistency, also exports all roles assigned to the user. When specifying users, you must give their organization ID if applicable, for example: --users user1, "user2|organization_1", ... |
|
--include-audit-events |
Include audit data for all resources and users in the export. |
|
--include-monitoring-events |
Include monitoring data for all resources and users in the export. |
Examples:
Export everything in the repository:
cd /opt/novell/zenworks-reporting/js/buildomatic/
./js-export.sh --everything --output-dir myExport
Export the /reports/samples/AllAccounts report unit to a catalog folder:
cd /opt/novell/zenworks-reporting/js/buildomatic/
./js-export.sh --uris /organizations/organization_1/reports/samples/AllAccounts --output-dir myExport
Export the /images and /fonts folders:
cd /opt/novell/zenworks-reporting/js/buildomatic/
./js-export.sh --uris /organizations/organization_1/images,/organizations/organization_1/reports --output-dir myExport
Export all resources (except users, roles, and job schedules) and their permissions to a zip catalog:
cd opt/novell/zenworks-reporting/js/buildomatic/
./js-export.sh --uris / --repository-permissions --output-zip myExport.zip
Export all resources and report jobs:
cd /opt/novell/zenworks-reporting/js/buildomatic/
./js-export.sh --uris / --report-jobs / --output-dir myExport
Export the report jobs of the /reports/samples/AllAccounts report unit:
cd opt/novell/zenworks-reporting/js/buildomatic/
./js-export.sh --report-jobs /organizations/organization_1/reports/samples/AllAccounts --output-dir myExport
Export all roles and users:
cd /opt/novell/zenworks-reporting/js/buildomatic/
./js-export.sh --roles --users --output-dir myExport
Export the ROLE_USER and ROLE_ADMINISTRATOR roles along with all users belonging to either role:
cd /opt/novell/zenworks-reporting/js/buildomatic/
./js-export.sh --roles ROLE_USER, ROLE_ADMINISTRATOR --role-users --output-dir myExport