State University Database System (SUDS) Master File Submission Subsystem Basic User Guide

Transcription

1 State University Database System (SUDS) Master File Submission Subsystem Basic User Guide System Overview The address for SUDS is This is a secure site and all communications are encrypted. Institutional Data Administrators (DAs) will receive their passwords via e- mail from a System Administrator (SA). DAs will, in turn, log in to the system and create users authorized to process information for their university. Each user is assigned to a role and a set of authorized submissions which defines the scope of that user s authority. Users upload files that are pipe ( ) delimited and in a specified format. The number of files to be uploaded is dependent on the submission type. Once all required files and any desired optional files for the submission are uploaded, the user will be prompted to edit the submission. Results of the edit and standard reports are returned in a series of screens that the user browses or, optionally, downloads to a.csv file. Fatal errors should be corrected on the source file and re-uploaded to the system to be re-edited. This process is iterated until the submission is free of all level X and Z errors and all level 9 errors are explained. Once that is accomplished, the user is ready to officially submit the data to the BOG. Once submitted, BOG staff will review the edit results, level 9 explanations, and standard reports. The submission will either be accepted or rejected. If rejected, then a reject reason will be posted to the user and a resubmission requested. If accepted, the submitted data will be promoted to the production database. User Roles, Authorized Submissions and Passwords SUDS roles follow the inverted pyramid scheme with the Data Administrator (DA) at the top of the inverted pyramid creating users and granting authorities to those that will process their data. Each user is also restricted to the submissions they have been authorized by their DA to act upon. Any user can also be designated as a Security Manager by either the DA or another Security Manager. Only a System Administrator can designate DAs. It is up to the DA and university policy to determine granularity of their security scheme. DA s are encouraged to designate at least one Submitter and one Security Manager for their university. DAs are discouraged from allowing logons and passwords to be shared. System Administrator This role is the highest level and is assigned to no more than 3 individuals in the BOG Information Resource Management section (BOG-IRM). A user with this role has the authority to create any user. A System Administrator is authorized to process all submissions and includes the Data Administrator, Submitter, Uploader, Validator and Researcher roles. Data Administrator This role is the highest level assignable at the institution level and is assigned to only 1 individual at each institution. A user with this role has the authority to create users for their institution. The Data Administrator is authorized to process all submissions and includes the Submitter, Uploader, Validator and Researcher roles. Submitter This role allows the user to officially submit university files to the Board of Governors. The Submitter role includes the Uploader, Validator and Researcher roles. Uploader This role allows the user to upload files for editing/review. The user can initiate and review all edits and reports of the files for a submission. The Uploader role includes the Validator and Researcher roles.

2 Validator This role allows the user to review edit reports for submissions that have already been uploaded and edited. This user will also be able to enter explanations and comments. The Validator role includes the Researcher role. System Developer This role is assigned to individuals in the BOG-IRM office and will have read-only capability for any institution. System Developers will be available to university personnel to assist in problem analysis. Researcher This role is designed to be given to university researchers who want to do studies with system data and need access to the reporting view. The reporting view will give the researcher the ability to identify students from within their own institution, follow them across the system and do other kinds of system/school comparison research without having to expose personally identifying information regarding the students. NOTE: a user with the Researcher role will NOT be able to log in to the Master File Submission Subsystem. Security Manager Security Manager is not a role per se but rather an attribute of a user. Any user can be designated to be a Security Manager. The scope of authority on submission files for this user will depend on the Roles and Authorized Submissions granted. Security Managers are the only users that will have access to the ADMIN tab on the home page. Authorized Submissions A user can be authorized to process ALL types of submissions or can be restricted to a subset of submissions. When the user is first created the Security Manager can elect to authorize ALL submissions and the system will automatically generate the required entry in the Authorized Submissions table. The list of authorized submissions can be edited at any time by a Security Manager. University data submission files include highly sensitive personal identifiers to establish the referential integrity of records across tables. When authorizing a user to process or have access to individual data submissions, the Security Manager shall take into consideration the legitimate educational or business need of the designated user to that information. The grant of authority on a particular submission is a function of the institutional DA and serves as a constructive written authorization to access and transfer data. The Data Administrator must also take reasonable measures to protect against any unauthorized access, transfer, disclosure or use of information contained in data submission files. Passwords Passwords will be strong passwords, requiring the use of at least one capital letter, at least one numeral, and a minimum of 8 characters in length. Passwords can be reused after 3 password changes. Passwords will expire every 90 days, thus a new password will be required 4 times a year. Passwords will be encrypted in the database and therefore not visible to anyone. If a user forgets their password their DA or Security Manager has the ability to reset it.

3 Common Operations Command Flow The common activities or operations for administering access, uploading, reviewing, and monitoring the data submission process are described below as a series of steps. These activities are organized by Role. The activity name is in bold text. The colon (:) separates location or item identifiers on a screen. Arrow Points (< >) indicate a button or URL to be clicked. Indented stacked items indicate an ordered flow of operations. Stacked items not indented indicate different operations or activities that begin at the same location. Blue text items represent a selection on a particular named row. For DA and Security Managers Create User: Admin Tab: <Create> Modify User (reset passwords, manage authorizations): Admin Tab: <Edit> by username: User Detail: <Reset PW> User Detail: <UPD User> User Detail: <Del User> User List Submissions Authorized: <Add Submission> Submissions Authorized: Check a submission: <Delete Submission> Submissions Authorized: <Apply Changes> For Uploaders and Higher Roles Make An Initial Submission: Home: <Upload Now> Submission: Table Name: <Upload> Upload File: <Browse> to specify source data file: <Upload> [Repeat above for all included files in the submission] Home: <Edit Submission> Re-Upload Corrected Data: Home: <Chk Uploaded> Submission: User Action: <Re-Upload> Upload File: <Browse> to specify source data file: <Upload> [Repeat above for all included files in the submission] Home: <Edit Submission> For All Change Own Password: Home: <User Profile>: <Chg PW>: <Chg PW> See Edit Diagnostic Summary Report: Submission: <Submission Summary> To download content as a.csv file: <Download Univ_Submission_Summary Report.csv> at end of screen page <Open> or <Save> See Results Of A Submission:

4 Home: <Chk Uploaded> Submission: Table Name: <Edit Summary> See Detail Error Report for a complete table: Edit Summary: <All Tablename Errors> To download content as a.csv file: <Download Univ_Table_Detail Error List> at end of screen page <Open> or <Save> See Detail Error Report for a single column and message: Edit Summary: Column Name: <View Dtl> To download content as a.csv file: <Download Univ_Table_Column Name_Message ID_Row Dtls.csv> at end of screen page <Open> or <Save> Other Make.CSV files associate with Pipe ( ) instead of Comma (,) for creating or reading submission files: Start: Control Panel: Regional and Language Options Regional Options Tab: <Customize> Numbers Tab: List Separator -- Change comma (, DEFAULT) to pipe ( ) <Apply> <OK> <OK> Close Control Panel window

5 Logging on to the System User names are created for the system according to the following pattern: UNIV_FNAME#_LNAME where - UNIV is your university s 2-4 character abbreviation, - FNAME is your first name (as entered by your security manager), - # is a sequence number, usually 1, needed in the event that a single university has more than one person with the same first and last name, - LNAME is your last name (as entered by your security manager). Log on to the site specified at the beginning of this document after obtaining your password from your security manager, data administrator or system administrator. If requested, accept the SSL certificate from the server. Enter your username and password. Underlined labels usually have Help or descriptions behind them. If this is your first logon to the system, you will be required to change your password to one conforming to the strong password rules stated above. NOTE: For first-time logons, Cancel will not be active and you will need to close your browser window should you decide to not logon at this time. After successfully changing your password you will be allowed to Continue.

6 For future logons, if you forget your password or your username/password combination doesn t work, please contact your security manager. They can check the spelling of your name in the system and reset your password if necessary. NOTE: There is a 20 minute inactive time out set for your session. This means that after 20 minutes of no action on the active SUDS screen your session will close. The next thing you attempt to do will immediately move you back to the Welcome/Login screen. Once logged in you will be presented with the SUDS Home Page. The options on the page will depend on role and authorizations assigned to you by your security manager. Seen only by designated Security Managers

7 Administering Users If and only if you have been designated as a security manager, you will see the Admin tab in the upper right hand corner of the Home page. Clicking that tab will display a screen of Existing Users. If there are no users at your university besides yourself, you will get a screen indicating that no data was found. Clicking the Create button will present the User Detail screen allowing you to create a new user.

8 Enter all required fields (designated by * ). Take special care to correctly assign User Role, Security Manager status, and ALL Submissions status. Remember that the username will be created based on First Name and Last Name. The only fields that the end user will be authorized to update are Middle Initial, Phone and E- mail so it is crucial that you validate your entries prior to clicking on the Create User button. Once the user is created the Submissions Authorized information appears on the right hand side of the SUDS User Detail screen. When this system is fully operational, the user s password will automatically be sent to the address entered in the field. For now, however, copy/paste the password only into an that is sent from your local server. The easiest way to do this is to copy the password to your clipboard then click the this user link next to the entry. This should bring up your local system, with the TO field already containing the user s address. You need only paste the password in to the body of the . We STRONGLY discourage sending the user name along with the password in the same in the event that the address is typed incorrectly. Because the username is easy to determine, we also STRONGLY discourage identifying the user by name in the . Security managers should be in contact with their users prior to creation of the logon so that an with only a password will be sufficient. The contents of the Submissions Authorized on the right hand side of the screen displayed depend on whether or not you chose to create the user with ALL Submissions = Yes. In the above example the option

9 was set to No and therefore No Data Found is displayed in the right hand column. A user left in this state will be able to log in to the system and see the submission calendar but will not be able to do anything else, including drilling down in to each type of submission to see which tables are required or optional. A user created with ALL Submissions = Yes will display ALL Submissions as the initial record in this section. Clicking on the Add Submission button will add a row to the right hand column and allow you to choose a particular submission. Continue to click on the Add Submission button until you have authorized the user for the appropriate submissions. Note: Each submission added will generate a confirmation message when you click Add Submission for another row or click Apply Changes after the last authorization.

10 User List Return to the User List screen without applying any un-committed changes to the database. Home Return to the Home page without applying any un-committed changes to the database. Del User Delete the current user and all authorized submission entries. Upd User Commit changes made to User Details. NOTE: Use the Apply Changes button to commit changes made to Authorized Submissions. Reset PW Reset the user s password to a system generated password. You will have to cut/paste the newly generated password in to an and send it to the user using the same process you used when creating the user. Delete Submission Deletes all the Authorized Submissions that have a check in their checkbox. Apply Changes Commit changes made to the Authorized Submissions list. NOTE: Use the Upd User button to commit changes made to User Details. Add Submission Add an Authorized Submission for the user.

11 The Home Page Either item takes you to the same place: Full Calendar In general, the upper left corner of every screen will display the user s name, their institution and the Logout command. At the bottom of every screen are a number of useful links as well as another way to Logout of the system. All of the links at the bottom of the screen will open in a new Window so that you will not lose your place in the system. The right hand side of the Home page displays a list of all submissions that are either due in the next 90 days or are overdue. Notice that since user Gobble Gook was not designated as a Security Manager that the Admin tab is no longer visible. The Calendar tab, the Full Data Request Calendar text link and the User Profile button are active for all users. However, the drill-down links in the Details column are only active for those submissions the user is authorized to process. User Profile The User Profile button brings up a screen that gives a synopsis of the user s attributes within the system.

12 From this screen the user can change Middle Initial (which isn t used in creating the user s logon id), phone number and address. There is also a Chg PW button that will allow the user to change his/her password. Passwords will be strong passwords, requiring the use of at least one capital letter, at least one numeral, and a minimum of 8 characters in length. Passwords can be reused after 3 password changes. Passwords will expire every 90 days, thus a new password will be required 4 times a year. Passwords will be encrypted in

13 the database and therefore not visible to anyone. If a user forgets their password the DA or Security Manager has the ability to reset it. The user will receive a password expiration notice on their SUDS Home screen beginning eleven (11) days prior to the expiration date and continuing until the password is changed. The user will receive a password expiration notification from the system beginning five (5) days before expiration. The day after password expiration the user s account will be set to inactive and will require the intervention of the DA or security manager to re-activate and reset the user s password.

14 Full Data Request Calendar The Full Data Request Calendar provides an unlimited forward and backward view of your institution s historical submissions and upcoming schedule. There are begin and end date range filter selectors (complete with pop-up calendars for selection) and a filter for complete/accepted submissions (the default is incomplete/not accepted view). Downloads what you see in the table above as a.csv file that can import directly into Excel or any program that understands what to do with a.csv file. You can save locally or open in an application. Drilling Down Select Upload Now or Chk Uploaded from the links in the Details column of the calendar.

15 Submission Screen Clicking the Upload Now link in the Details column of the Calendar will take you to the Submission screen. When no files for the submission have been received the Submission screen appears as: Note: Only a user with User Role of Uploader or greater will see the column named User Action or the button named Edit Submission. Click the Upload link to specify the source of the file and bring the data into the system. The Chk Uploaded link on the Calendar screen indicates that at least some data has already been uploaded and the Submission screen will display information regarding the uploaded data. Downloads what you see in the table above as a.csv file that can import directly into Excel or any program that understands what to do with a.csv file. You can save locally or open in an application.

16 The Submission screen has three (3) sections: Submission Specifics repeat the information on the row selected at the previous Home screen. Messages will display warnings and other system-generated information from the load process and the edit process. System-generated messages will respond to user actions. For example, the message on the sample above indicates that submission will not be possible until all Level 9 errors are explained. Once the errors are explained through the Explanation or Comment screen the system will generate a new message: Ready to submit along with a Submit button (if the user is authorized). An Available Reports button opens the Reports screen listing both static and dynamic reports. Tables in Submission lists the required and optional upload components for the submission. Level indicates the referential integrity constraints between the tables. For example, the tables in the Physical Facilities Space File submission requires hierarchy of CAMPUS SITES BUILDINGS ROOMS That is, each Room belongs to a Building, each Building is on a Site and each Site is assigned to a single Campus. File Size indicates the size (in bytes) of the file received in the last upload. User Action (only for Uploaders or higher role) provide link for re-upload. Table Required/Optional designates whether or not the table is required for this submission. Table Name is the name of the database table into which the records in the uploaded file will be inserted. Rows Received shows the count of records received in the last upload. Load Errors counts the number of rows with errors detected in the load process. For every table, the load process checks for: Fatal load errors (levels Z and X) are rows that cannot be loaded in to the database due to referential integrity constraints (i.e. a room row with no parent building row), unique key violation, or simply that the file itself was unreadable for some reason. Since these rows are not loaded in to the database the best that can be done is to store the contents of the row without formatting nicely in to columns for the error report. Non-fatal load errors (level 9) are errors such as characters in a numeric field or contents of a column too long. Columns in the database are defined as numeric only when computations are to be performed (eg. Operating Budget Expenditures). For these, the load process reports the error and the column contents but changes the value to NULL before loading in to the database. It is up to the university to determine whether or not such errors must be fixed at the source and re-loaded or can be explained. Forced match to submission parameter (level 1) errors are those where the contents of the file were in disagreement with the individual logged in and the submission being uploaded. For example, if the user is from UNF and the REPT_INST column of the input file is not UNF then the load process reports the error and the column contents and changes the value of REPT_INST to UNF before loading into the database. Fatal Load Errors? Flags the record set as unloadable due to level Z or X errors, errors for which no explanation will suffice. Correction and resubmission will be necessary. Report provides the dynamic link to the Edit Summary report for the specific table. Total Errs counts the number of errors generated in the edit program plus the errors generated by the load program. Must Explain counts the number of errors that can potentially be accepted by explanation. The Submission Summary button opens a screen that represents the traditional Edit Diagnostic Summary report. This report shows counts of errors detected and frequencies of values for specific columns. NOTE: Unlike the traditional report, there are no zero counts shown for edits that were not triggered or for column values that were not found in your submission file. See Exhibit A following. If an explainable error is included on an element there will be a link to click in the column after the error level to open the Explanation or Comment screen. See Exhibit B following. Upon saving the explanation, it will be displayed in the Explanation column of the Submission Summary report.

17 Edit Summary The Edit Summary screen repeats the table specifics from the previous screen and then lists each diagnostic error that was triggered by your submission. Included in the display are specifics about the column name (element) in error, the diagnostic that was triggered, the level of severity and a frequency of the number of records in which the error was detected. The link to EXPLAIN the errors is available on this report and, like the Submission Summary report, opens the Explanation or Comment screen. See Exhibit B following. The link to View Dtl opens up a listing of the records in error. This is discussed further on the following pages. The Include Standard Frequencies button inserts the standard frequency counts into the Edit Summary section like the Submission Summary report, but limited to the columns in the current table under review. When this view is enabled, column sorting is disabled. You can use the Frequencies section of this screen to display actual counts of every value on every column of the table. The View link in the Frequencies section opens a screen showing a count of values for the selected column. Detail Errors (Row Details) Details of the records generating the errors behind each message for the column are available from the View Dtl link of the Edit Summary section. All values in all columns in the table are included.

18 Look up the column you are reviewing in the Data Dictionary from this link. See Appendix C following. Downloads what you see in the table above as a.csv file that can import directly into Excel or any program that understands what to do with a.csv file. You can save locally or open in an application. Bad Data Contents will include the column name and content that failed to pass through the business rule behind the edit. When 2 or more columns are checked against each other, all the column names and their content will be displayed to disclose the exact nature of the problem. Rowseq Nbr is assigned as the table is built and is an ordinal identifier for the record in the set uploaded. Univ Row ID is a number assigned by the university on the file being submitted. It is any eight (8) character alpha/numeric value placed on the record by the institution to aid in identifying records that need to be corrected back at a source system and replaced before the table is re-uploaded to the SUDS system. NOTE: Personal identifying information on the uploaded data file used to build referential integrity between records on tables will NOT be displayed on this screen and will NOT be included in the saved data file. The Rowseq Nbr and/or Univ Row ID can be used to match/merge these detailed error records with the original submission data to identify particular source records.

19 Available Reports The Available Reports screen will be the front end for requesting standard optional reports from the submitted data as well as viewing saved reports already run for a file submission. There are two sections: SAS Saved Reports will list recent reports by file submission and report identifier and show who last requested the report and when it was last run. Dynamic SQL Reports will list the available reports associated with this submission. When a report is selected a report will execute immediately and return the results to a screen (complete with the capability of downloading a.csv file of the results) or will prompt for additional selectors and specifications for executing the report from our library of SAS reports. Tables and column data populated as a result of the system s edit process will be made available in this section.

20 Exhibit A Summary Report Exhibit B Explanation or Comment Screen

21 Exhibit C Record Details Data Dictionary View Edits specific to the column in this table are shown.

22 Exhibit D Upload Screen