With everyone preparing their shopping cart ahead of time, won't thousands of students hit the enrollment engine at the same time and 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).
How DegreeWorks ‘Works’ - Banner
Degree Works integration is two parts. First, version R6 of the interface (v184.108.40.206r6a) 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 Degree Works 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;" (minus the quotes)
The terms appear okay in Banner. Why am I getting a Zero Active Terms error message in Diagnostics?
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.
A student has an active DegreeWorks plan. Why isn't it showing in CS?
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.
How can I confirm the Degree Works integration with CS?
To verify in SQL:
The Sign On Function setting should be the name of the integration function for degree works.
How to set up Co-reqs
Co-Requisites can be set up on the Corequisites tabs of the SCADETL (Course) and SSADETL (Section) forms. If you do transition from Concurrent PreRegs to CoReqs, the Concurrent PreReq rules should be removed.
Students are receiving intrusion errors and experiencing a lag time. What's going on?
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.
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
Section Level Attributes
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.
stvterm_end_date >= sysdate
o Closes terms when the term end date passes.
sobterm_dynamic_sched_term_ind = 'Y'
o Opens 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.
Older versions: CSCHED_TERMS must be updated in the Banner Terms Table.
I am working on installing the Degree Works integration. What do I use for the DegreeWorksOracleSystemID?
Use the "service_name" in tnsnames.ora.
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.
Are College 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.
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.
Why do courses with the same course number appear as separate courses?
Banner does not link sections together that have the same component.
How does College Scheduler display Class Sections?
There are two Banner settings associated with the display of Class Sections that are included in the standard data feed.
1. The Web Indicator (aka the Voice Response Indicator) - SSBSECT_VOICE_AVAIL - [SectionWebIndicator] - Schedule index 24
2. 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 CS 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.
We are switching hosts. If our host confirms that they do not require a proxy, is it as simple as removing the value for the HTTP_PROXY field?
The HTTP_PROXY can be set to NULL.
Rather than using alternate pins distributed to students, we're switching to time ticketing. Because of that, I assume the value of the field URL_CARTFAILED might need to be changed?
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".
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 College Scheduler Registration Cart, usually on the Student Registration menu: “RELEASE: 220.127.116.11f”.
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) := '18.104.22.168f';
We are moving 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.
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".
We recently upgraded to 22.214.171.124. 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 Degree Works plan updates?
1. The Scheduler fetches the Degree Works 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.
2. Changes to Degree Works 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 College 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.)