Argos Standards and Best Practices

Argos is used as a Web based reporting tool which can create reports against any of the production databases in an interactive, ad-hoc or scheduled manner. In order to ensure consistency, quality, and security, the following set of Standards and Best Practices has been developed. This document will be subject to change over time as our experience with the product grows and as roles become clarified between the MIS staff, Datablock Designers, Report Developers in client offices and end-users of the actual reports.

Environments

 Argos at Missouri State runs in two independent "environments", Production and Development.

The Production environment runs on a server known as drysdale.missouristate.edu and will be the typical environment that most clients will see and use when developing or executing reports.

The Development environment runs on the same server and is distinguished by the Users folder and will typically be used only by MIS and power users for developing new and modified Data Blocks and Reports.

Backups

Full Argos physical backups are made nightly at 1 AM.  Logical backups are made manually between 8 and 8:30 AM.  Physical backups only allow the entire Argos environment to be restored.  Logical backups allow individual items to be restored.

Security

All users of the Argos product at Missouri State must have their own individual userid which must match their Active Directory ID. We use the Active Directory ID to authenticate the password using the LDAP service.

A user's role will be determined based on their highest level of authority in the various groups they are associated with. This may be one of "Report Viewer", "Report Writer", "Datablock Designer" or "Administrator". Administrator is reserved for DBA staff only. Datablock Designer will be reserved for MIS staff and power users to create and modify Data Blocks. Report Writer will be used for report developers working in the client offices. Finally, Report Viewer will be assigned to those users allowed to run existing reports.

Users can be added to multiple groups; however, when they are, their security rights need to be assessed to each group based on their role.

Groups should be setup to identify different functional areas combined with the security rights required. For example: RegistrarsOfficeDevelopers versus RegistrarsOffice to associate users to the role they will be playing. This must be used in conjunction with the Folder "security rights" to restrict access to various data blocks and reports. Group security will also be used for access to the various database connections available.

Folder rights determine what members of a group or individual users are allowed to do within a Folder, Data Block, or Report. These rights can range from Full, Change Permissions, Execute, Modify, View/List Children and Create/Modify Children. Any or all can be allowed or denied. Typically Full and Change Permissions will be limited to Administrators only and changes will need to be discussed with Argos Administrators.

Firewall Restrictions will limited access to computers part of the Missouri State network.

Database Security on ADO Connections will always be "Use MAPS userid and password".  This will prompt the user for their production id and password as the Active Directory id is not defined in our production databases.  The use of "Allow Insert/Update" or "Allow Delete" will be expressly forbidden at this time.

Connections

Connections defined for production use are PROD, ODSPROD, Phoenix, Ascend, Apollo, Entropy, and RMSP.  These reflect the current production databases used at Missouri State.  PROD is the production Banner instance.  ODSPROD is the production ODS instance.  Phoenix is the production iSeries.  Ascend is the production Alumni/Advancement legacy database.  Apollo is the production Banner instance at the West Plains campus.  Entropy is the production non-Banner instance.  RMSP is the production RMS instance.  Other production instance will be added if any others are developed.  Access to the connections will be by Argos group.  Users will be prompted for their individual login ids when the connection is made.

Data Block Design

Data Blocks are the components that all reports are based upon. They identify how and what data to select before it can be used in underlying reports. Typically all Data Blocks will be designed and developed by MIS staff and power users.  A template data blocks is available and should be copied into the user's personal folder and modified to suit the needs of the data block.

All Data Blocks must first be designed, developed, and modified in the User Development environment.  After they are properly tested and reviewed, the developer will contact an Administrator and have the Data Block and its associated reports from the Development environment copied to the Production environment.  Note: modified Data Blocks cannot be exported/imported to replace an existing Data Block unless they are first deleted and replaced entirely.

Data Block query forms should be designed for a screen resolution of 1024x768, which is the Banner screen resolution standard. While a query form may be allowed to scroll up and down beyond 768 pixels, it should never exceed a width of 1024 as it may not be obvious that selection criteria or information may exist to the right of the visible form. Typically it is a best practice to attempt to keep all aspects of the form visible on the screen without requiring scrolling.

The Tab order between selection criteria fields should be modified to ensure that it is logical and understandable rather than in the order in which the fields were defined.

Use a readable font in an appropriate size and color. Typically one should select font colors based upon the Windows scheme names such as "WindowText" instead of selecting specific colors such as "Blue". In this way people can change their own color schemes to suit their preferences and visual abilities.

Form variables should be named consistently and preferably uses the following notation, where the first four characters indicate a parameter (parm), the next are the parameter type (see the appendix for a list of all the types), and the last identifies the data variable.  The part of the form variables would be separated by underscores (_).  Controls should be grouped in a panel whenever possible.  Database fields of course will use the naming defined from the database and the programmer has no choice.

Graphics on the Query Form should be kept to a minimum. Use of the Missouri State University logo is recommended.

Other

As we learn more about the Argos product, these standards and best practices will be revised to suit our environment more closely.  Any comments or suggestions should be sent to the Argos Administrators at qdug@missouristate.edu.

Scheduling Jobs in Argos

Only Argos Datablock Designers and administrators can schedule jobs using the scheduling facilities built in to Argos.  Argos reports may be scheduled with Appworx if desired.  The usage of Argos reports in the Appworx environment has yet to be determined.

The optimal time for scheduling Argos reports has not been determined yet.  Check with the Argos Administrators for the best time.

APPENDIX

Parameter Control Types