Home > Campus Portal > Execution

Execution

Implementation Teams
The Banner Implementation Team (BIT) served as a coordinating funnel for cross team issues and resolution of conflicts. This Team also reported back to the College's IT Standing Committee on the progress of the entire project. Three additional teams were instituted to assist with implementation of Pipeline and the SCT Web components:

  1. Functional team for Web for Student and Faculty (see chart)
  2. Technical Team for Web for Student and Faculty
  3. Pipeline Advisory Team (see chart)

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
Having SSL or "secure socket layer" installed on the Campus Pipeline server is a requirement for version 2.2 and above. SSL protects Pipeline users from eavesdropping and impersonation by encrypting and decrypting communication between the Web client (the Campus Pipeline user) and the Campus Pipeline server.

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).

SCT Events
SCT events can be categorized into three types: Synchronization Events, Notify Events, and "Smart Events™." Synchronization Events attempt to keep the Campus Pipeline in sync with the Banner system. Notify Events send messages to Campus Pipeline users when a significant event occurs on the Banner system. Possible instances for a Notify Event to be triggered include times when students' grades have been posted or an enrolled course has been dropped. Finally, "Smart Events™" send a message to a Campus Pipeline user with a URL imbedded in the message. The imbedded message contains a link to enable students to complete a certain task such as register for a course. At North Shore Community College the primary focus has been to configure the Synchronization Events to function properly.

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.

Training
We were fortunate to have the NSCC training resource recently reallocated to the IS department. The trainer provided key support to the project prior to the implementation of the new advance registration process. She provided targeted training sessions over a period of one-month training sessions to three categories of employees (faculty, support staff and managers). This training was critical to ensure:

  • That everyone knew how the system operated.
  • Everyone knew the student, faculty and staff perspectives and functionality that Pipeline provided.
  • Everyone was working on the same page, thus enabling us to break the cycle of doing it the "old way".

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
As stated earlier, the initial test was to provide inquiry to some Web Student services in June, 2000 for the summer semester. After successfully meeting the initial timeframe commitments, our next important test was to register students for classes using Campus Pipeline during the actual Fall registration period in late August, 2000. IS provided all the necessary registration support to abolish any concerns or fears that some members of the NSCC community had. The Executive Director and Director of Administrative Technology attended each registration and provided all of the primary support to students so they could activate their Pipeline accounts and then Web register. Registrar staff were trained during the registration process and provided supplementary support. Other personnel provided line-walking support, encouraging students to leave the lines and register themselves at designated computer labs.

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.

Advance/Early Registration
After the successful pilot, the next immediate test was to maximize the utilization of the WEB capabilities during the advance registration period for Spring 2001 (November/December 2000). The Web Student and Faculty teams, under the collaboration of BIT (and support of Academic, Student Service and Administrative Deans), spent a full day planning the Advance Registration process, including the coordination with the Advising process, and decision on use of PIN numbers. This outline was then presented to the full Faculty meeting in late October, prior to the Advance Registration period. The strategy was two-fold: 1) reinforce that Registration via the Web tools was the new business process and 2) reinforce the importance of advising in the Advance registration procedures. There was much discussion about use of PIN numbers at the Faculty meeting, but ultimate consensus to go forward with the Advance Registration plan. One aspect of advance registration that would make the process relatively easy is those students don't have to worry about financial aid, billing, health insurance waivers, etc.

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.