Composition of the Functional Team was rather broad and included representatives from numerous constituent areas of the College. Representation included the Registrars Office, Financial Aid (2 representatives), Student Services and Support (2 representatives), Student Accounts, Academic Affairs (2 representatives), Admissions, Corporate and Community (Continuing Ed), the NSCC Web Administrator and the Director of Administrative Technology. The Technical Team included members drawn entirely from the Information Systems Department.
From the beginning the Functional Team desired appropriate sponsorship from the Executive Level, a definite charge from the Administration and a place within the governing structure of the Institution. The functional team received its sponsorship from the Dean of Administration who presented a draft charge and scope document assigning the team its place in the College governance structure. The charge was re-enforced by the Deans of Academic Affairs and Enrollment Management and Student Development.
The team elected a chair and vice-chair and began to define the steps needed to implement the product. Team members received copies of the Web Implementation Manual. Several meetings were scheduled during the month of March.
SSL & Digital Certificates
In order to provide SSL on our Pipeline server we first needed to purchase a digital certificate from Verisign, the most commonly used digital certificate authority in the world. There are two standard levels of encryption, 40-bit and 128-bit. While 128-bit encryption is more secure than 40-bit, we opted to purchase the 40-bit. We felt that for our purposes, the 40-bit encryption should suffice, as it is less costly and requires a lower bandwidth to operate. This is a consideration as most of our users are likely to be connecting to Campus Pipeline with a 56K modem connection.
We purchased the digital certificate from Verisign online. We received the digital certificate via email within two days after completing the purchase. The installation of the certificate was simple; first create a new web server (five minutes), then copy and paste the digital certificate from the email into the web server (five minutes), re-run a handful of Campus Pipeline installation scripts which configure the new web server (30 minutes), and finally re-direct the old web server to relay all users to the new secure Web server (5 minutes).
When certain actions occur in the Banner application, the Banner System triggers events. For example, when the Admission's Office accepts a new student's application, a trigger is fired which creates a new Campus Pipeline account. Or, when a student registers for a course, an event is fired which adds the registration information to the Campus Pipeline system.
In a more technical perspective, the SCT event model can be divided into two basic steps. In the first step, the events, which are essentially Oracle triggers, are fired when certain DML actions (i.e. insert, update, delete) occur against particular tables in the database. These triggers, which are written in PL/SQL code, insert event relevant values into several Oracle tables, called the event queue. This completes the first step of the event process. The second step occurs on the Campus Pipeline server with a program called the Event Listener process. The Event Listener process, which is written in Java, is configured to "wake up" every few seconds and query the event queue. If the query finds an event which has not yet been handled by the Campus Pipeline system, it executes the event and marks the event as complete. There are two different types of complete status: "successful" and "failed." If an event fails, the SCT Event Listener crashes and needs to be restarted.
In order for the events to work properly, and to add our own customized functionality to the event system, we needed to modify nearly all of the out-of-the-box SCT events. The event code is written in a programming language called PL/SQL. We used a free Windows utility, called Toad (http://www.toadsoft.com), to assist in the modification of the events. In addition, we used the Java programming language to produce our own customized Event Listener, which we describe in more detail later.
One example of how we choose to modify the SCT event code follows. The SCT event process, by default, uses the student's Social Security Number as the username. We found this to be unacceptable. Consequently, we added a few PL/SQL procedures and functions to handle the generation of Campus Pipeline usernames according to our specifications. Because of this change, we needed to alter nearly all the SCT event triggers to adhere to our own username requirements.
In addition to modifications to the SCT event code on the Banner system, we also wrote our own customized Event Listener for the Campus Pipeline server. While we still use the SCT Event Listener process, our customized Event Listener serves as an intermediate step before the SCT Event Listener process handles the events. It may be helpful to think of this intermediate customized Event Listener as a filter to the SCT Event Listener. In other words, our customized Event Listener analyzes all the Banner events first. It then determines which the event listener should handle the event, the SCT or the customized listener.
We decided that a customized Event Listener was necessary to handle a few specialized events that we deemed important to our Campus Pipeline administration model. One such specialized event is the synchronization event, which, when fired, causes a complete Banner/Campus Pipeline "synchronization" for any given student or faculty member. This "synchronization" assures that the student or faculty member's course load accurately reflects the data in the Banner system. Another specialized event is the change password event. This event allows System Administrators to change a Campus Pipeline user's password from within the Banner form GXICPMN (see page 10).
Our customized Event Listener also monitors the SCT Event Listener process. In the event that the SCT Event Listener process fails, our customized Event Listener sends an email to the Campus Pipeline administrator's email account, notifying him of the failure.
In total well over thirty session were offered and more than 200 people were trained. Additional special training sessions for departmental areas where also coordinated. Every IS staff member was trained so that they understood the process and could provide direction and support to the majority of usage questions.
Web Registration Pilot
We only activated the online registration during the scheduled registration times. We also did not implement the optional PIN number for registration. Our goal was to register 300 students via the Web and after the seventh registration period we did in fact register 300 plus students. During one registration period alone, over 700 students showed up and over 150 of these students registered themselves. The satisfaction level from students was excellent at every Web registration.
We soon realized that when large numbers of students showed up at the computer labs it became difficult to have many students follow the directions of the one support person. To rectify this bottleneck, a short video that was approximately two minutes was created that visually demonstrated with audio instructions the entire Pipeline account activation procedure. During the last registration we simply had students wear headsets and watch the movie (AVI file). This was extremely beneficial to the students and drastically sped up the process. Hardcopy and Web based instructions were also available, however the videos were more effective for our students.
The current advising system is also in the process of revision and re-invention. The Web for Faculty team decided to integrate current advising practices into the Web Advance Registration, without major changes at this time. Currently the Degree Audit module of Banner is in development and not yet implemented (planned for Fall 2001 implementation). During spring, 2000 approximately 20-faculty advisors had used the Banner registration screens to register their advisees on-line during the Advance registration period. These faculty were trained and had the option of using the Web for Student Registration alternative during the current Advance Registration period. In addition, all faculty were given the option of being trained on the Web product for use during the advance advising period, although, given the short timeframe, it is not expected that many will actually use the option this semester. Most advisors will work with their advisees on the student schedule, give the advisee their PIN number, and send the advisees to Web register. These students have three Web registration options during this Advance Registration period, once they get their PIN numbers: register at home computer, if they have access; register at any open student computer lab on campus; register with staff support at designated times/locations during a two-week period. The registrar support staff was then formally trained on how to assist registration through the Web. Furthermore, they were given access to the form "GXICPMN" and trained on how to use it. This meant that these support staff could handle any student account issues.
In future, the Web for faculty team and an ad hoc Advising team will revise the Advising process integrated with the Banner products to include the CAPP (Degree Audit) function, and provide more flexible advising centers
At this point in time 6000+ students have activated their Pipeline accounts and seventy five percent of advance registrations for Fall 2001 have taken place via Pipeline.