Argos Reporting Policies and Procedures

Policy Last Revised: 05/11/2010

Argos is a web-enabled reporting tool for use by the UAH community to extract and analyze data and generate reports from Banner and other authoritative data sources. The following standards and policies have been established to ensure consistency, quality and security. OIT reserves the right to modify these policies and procedures as needed to appropriately address the information needs of the UAH community.

Argos Access

During the initial development of a given suite of products, the relevant Data Steward(s) will designate the levels of access to grant functional area users. A functional area user is a member of a department at UAH who typically manages the forms used to enter Banner data and who needs access to that data. Functional areas are loosely based on Banner modules and the functions within those modules, which is how the Argos products are organized. Members of the greater campus community with a legitimate business need for data access may submit an Argos Account Request Form, signed by their supervisor, to initiate account creation.

Argos training will be offered in the format of Evisions video-tutorials or classroom training, as appropriate. Completion of the Argos training designed for a particular level of access will be required prior to full account activation.

User Roles

Argos users will be assigned defined access based on their data needs and their role within the university. A general description of each Argos role is provided:

  • Report Viewer – users with the authority to log into the Argos system and execute and retrieve pre-written reports, OLAP cubes, and dashboards.
  • Report Writer – users with the authority to create new reports based on pre-existing data blocks.
  • Data-Block Designer – OIT staff members with the authority to create new OLAP cubes, dashboards and data-blocks for use in constructing reports.
  • Argos Administrator – OIT staff members with the authority to create Argos accounts and assign users to one or more user roles.

Training

All users will be required to complete the introductory report viewer training. The Report Writer will require skills beyond those taught in the introductory course(s).

Prior to the development of the initial suite of Argos products, functional areas are expected to review an introductory presentation that will assist everyone in the needs assessment phase. Additionally, courses will be developed to get started with Argos and use it more efficiently at UAH. Finally, hands on report writer training will be offered.

Security

Argos access is granted only to individual users. Argos users must adhere to all security policies required by the Alabama Supercomputer Authority, UAH and OIT for computer access including appropriate use of information and resources and FERPA restrictions. These usage policies may be reviewed in the policy section of the OIT website.

Access to data through Argos is intended to be query only. Changes to data in authoritative data sources will continue to be done through those discrete systems.

Given that the purpose of implementing Argos is to improve access to data for the purpose of decision- making across the University, data that has not been defined as sensitive under federal, state, or contractual regulations will be considered non-restrictive. Concerns regarding access to this data will be carefully considered but the information needs of the University will take precedence.

Directory Structure

The underscores are to distinguish these folders as the official Argos implementation folders and to group them together. The "production candidate" that is referred to below is any data-block (including reports), OLAP or dashboard that is being created by OIT for the purpose of release to a functional area or the larger UAH community. There will be four primary working folders. These will be as follows:

Development will be considered the development area for Data-block Designers. The area will contain folders representing the names of each designer. This is where all production candidates should be kept during the development phase on a functional area roll-out or any future development efforts.

Training will be considered the training area first exposure point for the functional areas. The area will contain one primary folder for each functional area, which will be further subdivided into separate folders for each user who has been granted access. The functional area folder will contain a copy of the data-blocks, reports, OLAP cubes, and dashboards that represent the first iteration of a production candidate suite of products.

Testing will be considered the development and testing area for "production" level reports for the functional area users. The area will be organized in a mirror image of the production environment, and will follow the Data-block Naming Conventions listed below. Immediately following training, OIT staff will place the candidate suite of products into Testing. The functional area will be notified that any reports being developed for business use are to be constructed (or copied to) this data-block. For the purpose of version control, subsequent modifications to the production candidate are made only to the Testing data-block. Changes will not be propagated to the Training folders. It is the responsibility of the functional area to test /modify all working reports after any data-block changes are made. During the refinement phase of the project, the suite of products in the Testing folder is the single source for production candidates. When modifications are requested during this refinement period, data-block designers will rename the existing data-block to _BAK and revise a copy of the data-block in the same folder.

Production is the folder where the finalized production candidate and all reports will be copied, when the data-block achieves final acceptance by the functional area. This area contains the folders as listed in the Data block Naming Conventions section. No data-block level modification will occur in the Production folder.

Data-block Naming Conventions

The following folder structure and naming conventions will exist in the _Test and _Prod folders:

Accounts Receivable

AR_[Name_of_Datablock] (ODS)
AR_[Name_of_Datablock]_OLAP (ODS)
AR_[Name_of_Dashboard]_DBRD (ODS)

Finance

General Accounting

FGA_[Name_of_Datablock] (ODS)
FGA_[Name_of_Datablock]_OLAP (ODS)
FGA_[Name_of_Dashboard]_DBRD (ODS) 

Accounts Payable

FAP_[Name_of_Datablock] (ODS)
FAP_[Name_of_Datablock]_OLAP (ODS)
FAP_[Name_of_Dashboard]_DBRD (ODS) 

Purchasing

FPU_[Name_of_Datablock] (ODS)
FPU_[Name_of_Datablock]_OLAP (ODS)
FPU_[Name_of_Dashboard]_DBRD (ODS) 

Inventory Control

FIC_[Name_of_Datablock] (ODS)
FIC_[Name_of_Datablock]_OLAP (ODS)
FIC_[Name_of_Dashboard]_DBRD (ODS) 

Foundation Accounting

FFA_[Name_of_Datablock] (ODS)
FFA_[Name_of_Datablock]_OLAP (ODS)
FFA_[Name_of_Dashboard]_DBRD (ODS)

Contracts and Grants Accounting

FCG_[Name_of_Datablock] (ODS)
FCG_[Name_of_Datablock]_OLAP (ODS)
FCG_[Name_of_Dashboard]_DBRD (ODS) 

Research Administration

FRA_[Name_of_Datablock] (ODS)
FRA_[Name_of_Datablock]_OLAP (ODS)
FRA_[Name_of_Dashboard]_DBRD (ODS)

Budget Office

FBU_[Name_of_Datablock] (ODS)
FBU_[Name_of_Datablock]_OLAP (ODS)
FBU_[Name_of_Dashboard]_DBRD (ODS)

Human Resources

HR_[Name_of_Datablock] (ODS)
HR_[Name_of_Datablock]_OLAP (ODS)
HR_[Name_of_Datablock]_DBRD (ODS)

Student Financial Services

SFS_[Name_of_Datablock] (ODS)
SFS_[Name_of_Datablock]_OLAP (ODS)
SFS_[Name_of_Datablock]_DBRD (ODS)

Student

STU_[Name_of_Datablock] (ODS)
STU_[Name_of_Datablock]_OLAP (ODS)
STU_[Name_of_Datablock]_DBRD (ODS)

Data Sources

The Banner Operational Data Store (ODS) will be the default data source for Banner data. The ODS contains Banner data refreshed on a nightly basis. If circumstances require up to the minute data from the Banner production tables, a special request may be submitted to OIT.

Daily operational performance of the Banner system is paramount. When access to production data is requested, considerations that are evaluated include, but are not limited to, the following:

  • How does the data-block affect Banner performance? Does it run quickly?
  • Is the data available in the ODS?
  • How often does the data need to be refreshed? Daily? Hourly?
  • Is there a time sensitive function that requires up to the minute data (add-drop, budget, etc.)?
  • How many people will be running the reports?

Mirrored ODS data-blocks may be offered.

It is possible for a data-block designer to use Banner Production to create a parameter on the data-block form with proper approval.

Data Blocks

To request the creation of a new data block, a completed Data Block Design Form will be submitted to OIT.

All data-block and OLAP cube designers MUST use the Visual Designer when possible. If the Visual Designer is not deployed, the preferred SQL programming practice is to include the table or view name preceding the field name as follows: POSITION_DEFINITION.POSITION_EMPLOYEE_CLASS.

Parameters must adhere to the naming convention consisting of three parts separated by an underscore. The name will begin with 'parm' to clearly identify it as a parameter. The two letter abbreviation for the control type of parameter used will follow. A brief description that provides sufficient information to distinguish the parameter comprises the third portion of the parameter name. The elements of the parameter name will be separated by underscores (_).

Control Type
Parameter Type
Code Example 
 Button bt  parm_bt_Submit 
Check box  cb  parm_cb_Current_Enr_Students_Only 
Date  dt parm_dt_Graduation_Date 
Drop Down Box  dd  parm_dd_Major 
Edit Box  eb  parm_eb_Last_Name_Search 
List Box  lb  parm_lb_Students 
Multi-column List Box  mc  parm_mc_Results 
Memo  mm  parm_mm_Comments 

Data-block query forms should be designed for a screen resolution of 1024X768 which is the standard screen resolution for Banner. Graphics on the query form should be kept to a minimum and the UAH logo is recommended.

Data-block parameters or sets of parameters that have the potential of being useful in other data-blocks should be saved to the Library of Objects.

The following are suggested "best practices" for maintaining consistent data-blocks across Argos.

  • The UAH Header and Name are in the Library of Objects and should be added whenever a data-block is created.
  • The text in the data-block name should match the data-block name in the folder structure.
  • The Data-block Name bar should extend to the end of the panel containing the input parameters.
  • Input parameters should be displayed in columnar format with tops and sides aligned whenever possible.
  • Required fields should be indicated (Bold Red Tahoma 8) to the right of the input parameter.
  • Labels for input parameters should be followed by a colon (Bold Black (the default window text) Tahoma 10, Parent Font Yes).
  • Onscreen instructions should be centered under the input box (NOT Bold Black (the default window text) Tahoma 10).
  • In a QuickLaunch report, the button should always read "Submit" and the button should be aligned with above and along the right side of the multi-column list box where data is returned.

Reports

To request the creation of a new report the user must complete the Report Design Form. All reports MUST adhere to the following standards.

  • Date and Time Stamp – The calendar date and time the report was generated.
  • Report Runner – The first and last name of the person running the report.
  • Data Connection – The connection (ODS or PROD) used as the source of the report data.
  • Page Number – The page number must appear on each page of the report.
  • Logo – The UAH logo must appear on the first page of each report.

The following are suggested "best practices" for maintaining consistent reports across Argos.

When creating banded reports, begin with the report templates available in the Library of Objects. A template should always be added whenever a report is created. It contains all of the required data as specified in Policies and Procedures as variables.

If you significantly modify a template, save it back to the Library of Objects for use by others or at a later time.

During Training the use of these templates for these report types is to be encouraged.

Scheduling

Argos contains a component for submitting jobs at a scheduled time and date. The scheduling of these jobs will be restricted to data block designers and administrators. Unless otherwise stipulated all jobs will be scheduled to run after normal University operating hours to prevent degradation in the operational performance of the Argos and Banner systems.