Scheduling Grid Reports for Job Status, Financial and QC History Grid Reports

Many job status, financial and QC history reports that execute as grid reports can be executed on the system batch queue at scheduled times by using the CCINSH—Instrument Schedule application that is also used for task scheduling.

This section contains details on how to configure and setup the generation and distribution of these management reports. It involves creating a script that can be executed as a scheduled task, where the script uses a saved search and a report template to generate the grid report.

Locate and Upload the Report Script Bundle for Automating Grid Report Generation

  1. Locate the automatedreporting.jar script bundle file.
  2. Create a script in the CCSCRT—Script application.
  3. Enter the following fields:

    Organisation Scope—Checked

    Script Code—AUTO_REPORT_BUNDLE, to match what is looked for in the first line of the report script to load the bundle.

    Name —Enter an optional name for the auto report script bundle.

    Description —Enter an optional description for the auto report script bundle, for example, Auto report bundle.

    File—Locate and upload the automatedreporting-0.1.jar file (the sequence number on the end of this file may differ depending upon the latest build of this add on).

    Script Type—019—Bundle

    Is Authorised—Checked

Locate and Upload the Report Script for Automating Grid Report Generation

  1. Locate the AutomatedReporting.groovy script file.
  2. Create a script in the CCSCRT—Script application.
  3. Enter the following fields:

    Organisation Scope—Checked

    Script Code—This code is linked to from the a scheduled task, for example AUTO_REPORTING.

    Name —Enter an optional name for the report script.

    Description —Enter an optional description for the report script, for example, Auto reporting.

    File—Locate and upload the AutomatedReporting.groovy file (see example).

    Script Type—022—Scheduled Task

    Is Authorised—Checked

The logic of this script is fairly straight forward:

  • Read the code of the preference that contains the directives required for the report, passed in as Parameter 1 in the task schedule.
  • Read the name of the search application (ccstrp, ccfnrp, or ccqchs) upon which to enact the search, passed in as Parameter 2 in the task schedule.
  • Read all the saved search criteria, using the name of the saved search as set in the preference's value.
  • Assign all the saved search criteria to the grid report object.
  • Assign the report template, using the code of the report template as set in the preference's value.
  • Assign the printing and emailing requirements, using the distribution details as set in the preference's value.
  • Execute the search and pass the result sets to the report engine.
  • Perform the specified emailing and printing instructions.
  • Perform any post-generate file saving options, using the report code in the preference's value.

Create a Saved Search used to Extract Data for the Grid Report

The power of application-based scheduled reporting lies in the ability to use the application search interface to define the scope of the report. Once the search criteria is entered this can be saved, and is scoped to the user and laboratory.

The first parameter passed into the task schedule script contains, amongst other things, details about which saved search is used to extract data for the grid report. Therefore, a saved search needs to be created.

All search applications can save the search criteria for later re-user. These saved searches are user and laboratory dependent and cannot be shared (via the UI) across users.

  1. Access the CCSTRP—Job Status Report, CCFNRP—Financial Report, or CCQCHS—QC History Summary application, depending upon the type of grid report to be automated.
  2. Create a saved search with the criteria used to extract data for the grid report, and give it a meaningful Name, for example, Incomplete Jobs. This name, and the current user and laboratory is referenced as the 'SAVED_SEARCH_NAME', 'SAVED_SEARCH_USER' and 'SAVED_SEARCH_LABORATORY', respectively, in the preference that is passed in as Parameter 1 to the task schedule script. Refer to Performing Searches.

    Note: Log into a CCLAS session for the applicable user and laboratory prior to creating the saved search.

  3. Either start the application again, or use the New Search flow to open the search screen with the default criteria, then select the recently saved the saved search criteria, to confirm that it applied the intended criteria.
  4. Either let the next scheduled grid report be executed, or force a trial of the report to ensure that both the search and reporting criteria are extracting the correct data.

    Note: One way to distribute a saved search to other instances, without manually adjusting the saved search criteria with the application, is to search for the saved search definitions using the MSFPRF—User Preferences application, use a SQL command to extract the saved search definitions, and then export them to another instance. The Counter property allows for the concatenation of multiple records, where required. The export creates a SQL file, which can be edited and then used to insert the saved searches into another environment. It is best if any existing records for a related saved search are deleted prior to this, just in case the number of rows are different (due to the differences in criteria).

Create a Report Template used to Generate the Grid Report

The first parameter passed into the task schedule script contains, amongst other things, the code of the report template to be used to generate the grid report. Therefore, a report template needs to be created.

Typically, a report template is named to describe the purpose of the report.

A report template may be provided as a template file (RPT in Crystal), or come bundled in a ZIP file if extra information is required to create the report output.

The output file name can be fixed, or driven by a syntax. Syntaxes are selectable from the drop-down list, and can be associated with a number of wildcard type tags (variable dates and the likes).

  1. Author a report template using a report tool supported by CCLAS.
  2. Create a report template for a grid report using the CCTPLR—Report Template application. Refer to Configuring Grid Report Templates.
  3. Enter the following fields:

    Scope—Select the scope for the report template. Scope rules apply when this report template is used by the report script.

    Report Template Code—This code is referenced as the 'reportTemplateCode' in the preference that is passed in as Parameter 1 to the task schedule script.

    Type—Grid

Create a Preference to pass in as Parameter 1 to the Task Schedule Script

The task schedule script accepts two parameters: 1) The code of the preference that contains a bundled list of settings for the task schedule script, and 2) The name of the search application associated with the grid report. Therefore, a preference for Parameter 1 needs to be created.

This preference ties everything together for the as it contains all the instructions for running the schedule that cannot be defined in the search criteria, and otherwise must be configurable.

This preference contains settings for the report template, saved search, whether the report is downloaded, distribution details, whether the report is persisted to EFS, and whether the report is persisted to a CCLAS report and therefore viewable via the CCREPT—Report application.

  1. Create an application preference using the CCPREF—Preference application. Refer to Maintaining Application Preferences.
  2. Enter the following fields:

    Scope—Select the scope for the preference. Scope rules apply when this preference is used by the report script.

    Preference Name—This name is passed in as Parameter 1 to the task schedule script, for example, JOB_SCHEME_SUMMARY_NOT_COMPLETED, so it should be named to reflect the function of the report.

    Description—Enter an optional description for the preference.

    Setting Type—STRING

    Setting Value—A multi-lined string, that can contain some, or all, of the settings shown below.

    Is Active—Checked

    Preference Type—PREFERENCE

Setting

Mandatory

Meaning and Description

REPORT_TEMPLATE_CODE

Example:

reportTemplateCode=STATUS_JOB_SCHEMES

Yes

The code of the actual report template that is used.

These is maintained via the CCTPLR application, and is also linked to other properties (for example, for the report engine used, output formats and names).

SAVED_SEARCH_NAME

Example:

SAVED_SEARCH_NAME=IncompleteJobs

Yes

The name of the saved search.

SAVED_SEARCH_USER

Example:

SAVED_SEARCH_USER=ME

Yes

The user who was logged into CCLAS when the saved search was created, and for whom the saved search is executed when the report is generated.

SAVED_SEARCH_LAB

Example:

SAVED_SEARCH_LAB=MYLAB

Yes

The laboratory that the user was logged into CCLAS when the saved search was created, and for which the saved search is executed when the report is generated.

IS_DOWNLOAD

Example:

download=Y

Yes

Indicates whether the generated file is downloaded and stored somewhere after generation. Set to Y if it should be. Set to N if the report should just be emailed.

EMAIL_TO

Example:

emailTo=admin@mylab..com

No

The list of email addresses (separated by semi-colons), if the reports are to be emailed after generation.

PRINTER

No

Code of the printer (as configured by the CCDEVI—Device application), if the reports are to be printed after generation.

COPIES

No

The number of copies of the report to be printed (default 1), if the reports are to be printed after generation.

IS_EFS_SAVE

No

Indicated whether a copy of each generated report is saved into the EFS. Set to N otherwise.

EFS_SAVE_PATH

No

The EFS folder path, if the reports are to be saved into the EFS folder.

EFS_SAVE_FILENAME

No

The EFS file name, if the reports are to be saved into the EFS folder.

IS_CCREPORT_SAVE

No

Indicates whether a copy of each generated report is saved into the CCLAS report repository, viewable via the CCREPT—Report application, allowing the report to be located and downloaded later on, without needing to know which EFS folder the report was stored in.

The name of the report is based on the value in the CCREPORT_CODE setting.

CCREPORT_CODE

No

The code of the report in the CCLAS report repository.

This allows the report to be updated if the code already exists within the CCREPT—Report application.

If a specific report code is not supplied, then a unique report code is created.

Create a Task Schedule to Generate the Grid Report

  1. Create a task schedule using the CCINSH—Instrument Schedule application (this application is also used for task scheduling).
  2. Select the Schedule Type as Task.
  3. Enter the following fields:

    Schedule Code—Enter a mandatory code for the task schedule, for example, JOBSCHEMENOTCOMPLETE.

    Schedule Name—Enter an optional name for the task schedule, for example, Incomplete Jobs.

  4. Select the Details tab.
  5. Enter the following fields:

    Schedule Description—Enter a meaningful description for the task schedule.

    Is Active—Checked

    Script Code—This was the script that was uploaded as the report script for automating grid reports.

    Frequency—Cron expression for the frequency of running this report.

    Folder

    Filename Wildcard

    Parameter 1—Name of the preference that was created to be passed in as Parameter 1 to the task schedule script.

    Parameter 2—Name of the CCLAS application, in lower-case.

    Notes—Enter optional notes for the task schedule.

    Warning: When the report file is created on EFS with a static filename, any regeneration overwrites the EFS file, however a separate record is created in the CCREPT—Report application, so if the report is generated twice, only one EFS file is created, but two reports is created in the CCREPT—Report application, both of them pointing to the same EFS file name.

Create a Task Schedule to Generate the Grid Report

  1. Execute the schedule into the system batch queue. Refer to Scheduling Grid Reports for Job Status, Financial and QC History Grid Reports.

    The task runs on the defined schedule, until terminated or inactivated.

    Note: Scheduling runs as a batch service and does not require that the CCINSH—Instrument Schedule application to be running once it is executed.

Creating Scheduled Reports from Other Applications

In principal, it is possible to schedule reports from any CCLAS application that opens with a search page.

The the AutomatedReporting.groovy script file used for grid reporting caters for job status, financial and QC history reports. It can be extended to cater for other report types that are generated as grid reports from other search applications, as required.