Banner FAQ
Environment and Versions
What are the minimum Banner versions?
The minimum version for Banner Student Self-Service is 8.5.1. The minimum version for Oracle is 11.2.
How can I check what interface version we are on?
The installed interface version can be identified in Self-Service Banner on the bottom left corner of the Registration Cart, usually on the Student Registration menu: “RELEASE: 8.0.4.1f”.
The interface version (or Current Release) is also available via SQL in the source of the csched PL/SQL package body:
curr_release CONSTANT varchar2(30) := '8.0.4.1f';
Installing the Degree Works integration, what do I use for the DegreeWorksOracleSystemID?
Use the “service_name” in tnsnames.ora.
Is Scheduler compatible with DegreeWorks 4.4.1?
Yes and no. Each Degree Works implementation is customized because the installations aren’t as standardized as Banner.
How can I confirm the DegreeWorks integration is working?
To verify in SQL:
select sign_on_function
from CSCHED.csched_settings;
The Sign On Function setting should be the name of the integration function for degree works.
If our new host doesn’t require a proxy, do we remove the value in the HTTP_PROXY field?
Set the HTTP_PROXY to NULL.
After upgrading to 8.0.3.1., is it okay for ACTIVITY_DATE and GROUPID columns to be empty?
ACTIVITY_DATE and GROUPID were added in version 8.0.3, and can remain null. (Consider a NULL ACTIVITY_DATE an indicator of pre-8.0.3 records.)
How frequently do we pick up DegreeWorks plan updates?
- Scheduler fetches the DegreeWorks plan during Scheduler sign-on (when you hit the Scheduler link in SSB). Changes made to DW while in the Scheduler won’t be visible until you sign in again.
- Changes to DegreeWorks aren’t immediately saved to the tables (that the Scheduler reads). For example, if you’re looking at the Student’s plan and recently made an edit, it may not be “permanently” saved yet. Exit the student’s plan before signing in to the Scheduler.
Is there an easy way to test the Scheduler integration?
We aggregate all the logs and health checks on the Scheduler side (via Amazon Cloudwatch). On your side, you can tail the Bridge log (in /var/log by default) to look for the “Starting” and “Started” messages. (And verify there are no new ERRORs or WARNings.)
To switch to time ticketing (rather than using alternate pins distributed to students), do we change URL_CARTFAILED?
The URL_CARTFAILED does not typically require adjustment. If the SSB Servers are stressed and the Registration Cart cannot be saved, the student is forwarded to the Cart Failed URL to register “manually”.
To move databases, what about the oracle wallet info? Can I just copy the directory to the new server?
Yes, as long as it’s the same Oracle Database version, and same OS. That being said, we recommend regenerating the wallet.
Won’t thousands of students hitting the enrollment engine at the same time crash it?
You could say large numbers of students hitting the Register button is the same problem it’s always been, with or without the Planner. Registrations represent a whole lot of processing and then we stack them up into registration events.
Hitting the “Register” button from the registration cart invokes the same baseline procedure as if the student had attempted to register from the SSB Schedule. So, from that point on, the system load associated with the registration events is almost identical to baseline. The Planner interface adds one small step to that process. When the registration is finalized, and Seat Count is updated for the Section, a temporary Seat Count record (called a Delta) is recorded. Performance testing (formally during development, and informally for a few production clients) has been very positive. During these evaluations there was no measurable (statistically significant) increase in registration execution times. Primarily, this is because the registration process is so complex that the changes made by the Planner become relatively insignificant.
There is, however, a significant overall performance improvement with the Planner. In baseline, searching Catalog and Schedule takes place through SSB. If the Planner is widely adopted this “search load” moves to the Planner server instead of SSB. This frees up more resources to process Registrations. The Search Load on SSB is replaced by the much more efficient Planner Schedule Service that extracts and delivers the Schedule data to the Planner. And the Schedule Service only takes a few seconds, once per hour, and doesn’t have to generate a single web page. (That’s the equivalent of one user per hour searching the SSB schedule for about six seconds…)
No load related issues have been reported by users of the Enhanced Banner Interface since its introduction in March of 2013 (v8.0).
Errors and Messages
Why am I getting a Zero Active Terms error message in Diagnostics? The terms are in Banner.
Check the “Master Web Term Control” checkbox on the bottom right-hand corner of the SOATERM form in Internet Native Banner.
sobterm_dynamic_sched_term_ind = 'Y'
The other requirement is that the STVTERM_END_DATE hasn’t passed.
Why are students getting intrusion errors and experiencing lag?
The “Intrusion Error” message is coming from Banner SSB Security. It occurs when the SSB security token cannot be validated. Typically, this is due to having multiple instances of the same ID open at the same time.
These errors often occur in labs because folks don’t sign out completely, and then someone else signs in (to the same machine/browser). This can be exacerbated by the Scheduler because users leave SSB (when they sign in) and return later (to register) in the meantime an old token may have expired.
Why am I getting a “No Terms” error message?
The main culprit is that there are zero terms set to Active, and CS depends on Automatic Term Selection to populate terms. Verify there are active terms, then schedule job again (SQL code below). Although not common, check that job_queue_processes is set to a non-zero value.
exec CSCHED.csched.p_job_schedule;
Why is there a warning message that a student is not eligible to register?
This is a broad eligibility check that includes many different criteria. If any of them fail, then the student is not eligible. It’s implemented as part of another Banner system called “Mass Registration”. The data is coming from the Banner Mass Registration Function sfkmreg.p_check_eligibility
Why isn’t a student’s active DegreeWorks plan showing?
There is a short period after updating a student’s record in DW where it displays after a save, but isn’t “permanently” saved yet. Also, DW is checked when the user signs in to the Schedule Planner. If the user is already signed in when DW is updated, the update won’t show in the Planner.
Why do courses with the same course number appear as separate courses?
Banner does not link sections together that have the same component.
How To
How does DegreeWorks work in Banner?
DegreeWorks integration is two parts.
- First, version R6 of the interface (v8.0.1.2r6a) includes the “Sign on Function”. The Sign on Function is a setting in the settings table (CSCHED_SETTINGS) that accepts an Oracle Function name. During Sign-On, the Function is dynamically called with the PIDM – Banner’s internal ID – as a parameter. Whatever data is returned (as a CLOB – Character Large OBject) is included in the Sign on Packet.
- Second, we establish a Degree Works Sign on Function. The initial DegreeWorks function can be modified to account for differences in Degree Works implementations. (Or can be adjusted to integrate other systems, like CAPP or DARS.) The basic function connects to the Degree Works server through an Oracle Database Link. The link points to the Degree Plan tables, and the function generates the Degree Plan in XML from the link.
How can I update the schedule data in Banner?
In SQL, run:
exec CSCHED.csched.p_job_schedule;
How do I set up Co-reqs?
Co-Requisites can be set up on the Corequisites tabs of the SCADETL (Course) and SSADETL (Section) forms. If you transition from Concurrent PreRegs to CoReqs, the Concurrent PreReq rules should be removed.
Can I add section-level attributes?
Yes. Schedule Planner supports attributes added at the section level.
On the SSADETL form in INB, go to the Attribute page, add, and save. The “”Degree Program Attributes”” tab of the SSADETL form in Banner INB.
How do I add tables to Banner to populate terms?
Terms (since interface v8.0.2) are controlled by Automatic Term Selection. ATS is described in the Installation Guide.
Two default criteria establish primary selection rules:
- This closes terms when the term end date passes:
stvterm_end_date >= sysdate
- This open terms when they become available in Self-Service Banner. This field is the “Master Web Term Control” checkbox on the bottom right-hand corner of the SOATERM form in Internet Native Banner:
sobterm_dynamic_sched_term_ind = 'Y'
Older versions: CSCHED_TERMS must be updated in the Banner Terms Table.
Where can I see what was sent to the registration shopping cart?
There is a table in Banner that has historical information of shopping cart data. The table is called CSCHED_REGCART. You can take a look at that table for the student’s PIDM. Each cart there is time stamped.
The Active Indicator (CSCHED_REGCART.ACTIVE_IND) identifies the “current” cart. The “N” records represent the history of saved carts.
How does Scheduler display Class Sections?
There are two Banner settings associated with the display of Class Sections that are included in the standard data feed.
- The Web Indicator (aka the Voice Response Indicator) – SSBSECT_VOICE_AVAIL – [SectionWebIndicator] – Schedule index 24
- The Print Indicator – SSBSECT_PRNT_IND – [SectionPrintIndicator] – Schedule index 17
The Web Indicator is used by Banner to control the display of Sections in Self Service Banner.
The Print Indicator is used by Banner to control the inclusion of a Section in the student’s transcript.
By default, the Web Indicator is used by Scheduler to identify sections to “hide” (SectionWebIndicator = ‘N’)
This way, the sections typically visible in Self Service Banner are the same sections that are visible in the Scheduler. These two settings are not related to Attributes.
The Attribute Web Indicator is set in the SORWDSB table (Student-Overall-Repeating Table-for Web Display) on the SOAWDSB form (Web Display List Customization Form). SOAWDSB is a multipurpose Web display control form that covers multiple types of codes.
Where is the regcart and audit info stored for Banner 9 Plan Ahead?
The data is stored in the baseline Plan Ahead tables, SFBPLAN and SFRPLAN.
The College Scheduler rows can be identified by the College Scheduler Persona Code. The Plan is updated each time the student “Sends to cart”.