Ozone Homepage
Project
Current Access
TEST Login Page
PROD Login Page
Need to Know
Resources
Announcements
 
 
 
 
 
 
 
 

Access to the Banner Instances are based on the project timeline. Depending on when you are logging into Banner there may be different choices.

SEED

SunGardHE installed this instance as part of the initial Banner installation. No data conversion, loading, configuration, training, or testing is to take place in this instance. All Banner patches are to be applied to this instance first to verify patching procedures and viability of the patch. This instance is not INB-enabled (it is not available through Internet Native Banner). Only DBA will have access to this instance. If necessary this instance can be recreated from the Banner installation scripts.

TRNG (SunGard SCT Training)

This instance is initially a clone of the SEED database. It is used for training purposes, both technical and functional. Initially this training is SunGardHE-provided and will use SunGardHE-provided data. Following the completion of the Banner implementation (all modules), it may be created periodically from the PROD database for end-user training. Upgrades and patches will be applied here second in order to train users on new features available with the Banner upgrade or patch. It is INB-enabled. Significant amounts of test data, including users, will be available in TRNG. Generic training accounts are typically used for access to this instance.

TEST (Testing/Development)

Data are loaded here either from CONV (initially) or straight from the Plus environments once the conversion scripts have stabilized. Rules and validation tables are loaded here from the CONF instance or later from PPRD. Security is set up in this instance to facilitate full testing scenarios and so may not mimic security to be set up in production. Each user will have separate accounts instead of generic accounts. End users will verify and validate rules and converted data in this instance. Later on in the Banner implementation process data will be loaded here from PROD as well as from Plus (e.g., during the student implementation all financial and HR data will come from PROD, while student and financial aid data will come from SIS). Testing of SQL scripts may take place here if it is not used for end-user testing. This instance is INB-enabled. Following implementation of all Banner modules this instance will be used only by application developers for creation of "bolt on" applications, Banner channels for Luminis, or similar value-added tools.

CONV (Conversion)

This instance is the repository for data initially converted from our legacy systems. It is usually not INB-enabled. It will be "scrubbed" multiple times as tweaks to the conversion programs progress. Rules and validation tables will be loaded here from TEST in order to assist in the testing of data conversion. IT staff may use this instance to test SQL loading scripts or perform other testing if TEST is in use for rules and data validation. Application developers will have update access to database objects in this instance. Once all Banner modules are implemented this instance will be deleted.

PROD (Production)

Once we are authorized to proceed with "go live," the data migration utilities are run against production SIS files and loaded into the production database. Rules and validation tables are copied from TEST to PROD. No seed or testing data of any sort, including test students or employees, are to be created in the production environment. Application developers have read-only access to production Banner objects.

Requesting A New Instance

All requests for new instances must be made in writing to the IT process team leader. The request must contain the following information:

  • Intended use of the instance
  • Proposed instance name (subject to change by the IT process team)
  • What data, rules, and validation tables will be housed in the instance (e.g., seed, conversion, or production data)
  • Where the data, rules, and validation tables in the instance will originate
  • How long the instance is intended to last
  • Why existing instances are inadequate to the intended use

The IT process team will review all such requests for new instances and recommend a course of action. Such course of action may be to approve the request, deny it with a suggested course of action using existing instances, or approve it with suggested changes. Requests for new instances should be made no later than two weeks prior to when the instance will be needed to allow for IT process team consideration.

 
Comments & suggestions: dcrouse@otterbein.edu Copyright@ 2007 by Otterbein University, Westerville, OH 43081