USNH Event Registration Software Functional Specifications

Transcription

1 USNH Event Registration Software Functional Specifications 9/20/04 Initial Draft Patrick Messer Research Computing Center /20/04 Initial Draft I. Overview For simplicity, the USNH event software application will be referred to as "events" throughout this document. The events system will run on computers maintained by the UNH Research Computing Center. Departments will use this software to create and publish upcoming events. Event attendees will be directed to a web location that displays a form listing event specific questions and prices. Once the form has been completed, the attendee will click on the Payment button. This action will take them to the InfiNET QuikPAY payment gateway where the ecommerce component of the transaction will be handled. Departments can run multiple events at any one time and there is no fixed limit to the total number of concurrent events hosted by the events server. Daily transaction logs will be sent to the CIS File Transfer Server, processed further by RCC and resubmitted to the FTS for automated entry into Banner finance. Event creators and site administrators will have access to appropriate reporting functionality to help manage and monitor various aspects of the site. II. The Use of Roles The events program is based on a comprehensive role based system that dynamically delivers content specific to a user's credentials. Some of the roles are hierarchical enabling higher level users access to a superset of features and data available to lower level users. The roles are: Public - Any visitor to the site who has not logged in (typically attendees) May see published events that are open for registration May register for events 04_09_20 Functional Specifications.doc Page 1 of 8

2 Event Manager creates and manages events, event managers will belong to one or more groups May view/create/edit/delete their own events within their group(s) May view events from other users in their group May view registrations and statistics for their events May upload branding banner for their events Group Manager - Manager of a group (i.e. department or organization) May view/create/edit/delete any events within their group May view registrations and statistics for all events within their group(s) May upload branding banner for their group May approve publishing of events within their group May approve new user accounts within their group Site Manager - Manager of a site (i.e. campus or college) May view/create/edit/delete any events within their site May view registrations and statistics for all events within their site(s) May upload branding banner for their site May approve publishing of events within their site May approve new user accounts within their site May create new groups within their site System Manager - Manager of all sites within the system May view/create/edit/delete any events May view registrations and statistics for all events May upload branding banners for all sites May approve publishing of all events May approve any new user accounts May create new sites within the system System Developer - programmer access for system development and maintenance May create system manager user accounts May perform system maintenance functions Access to each area of the system's functionality will automatically be tailored to the role of the user. For example: Group Managers accessing the events management functionality will only see events within their group, while Site Managers will see all events for their site (campus). This will also be true for reports and statistics: Site managers will be able to generate reports and administrate all events for their site. 04_09_20 Functional Specifications.doc Page 2 of 8

3 The roles described above provide the basis for distributed site administration. Site Managers will establish the accounts for Group Managers, who in turn, create the accounts for the Event Managers. While most events will be created and managed by Event Managers, Site Managers (as well as System Managers) will have the authority to intercede if necessary. III. Creating Events Authenticated "Event Managers" will be able to create events using a system of webbased forms. The forms will be broken into logical sections to help new users through the process. The following information will be able to be input. (* marks required fields) 1. Sponsor Contact Information * Name * * Phone URL Organization Name 2. Event Information * Event Name * Management Group (select list) * Event (Start) Date Event End Date Registration Open Date Registration Close Date * Accept On-Line Payment (Y/N) Other Payment Instructions (text field) Maximum # of Registrations Event Full Message (used if max registrations are reached) confirmation message (text field) Banner Image (file upload) 04_09_20 Functional Specifications.doc Page 3 of 8

4 3. Event Questionnaire Constructor This section will allow Event Managers to add questions to their event registration questionnaire using a variety of question types, including: label - requires no user input, allows text to be displayed on the questionnaire text - user input single line text multi-line text - user input multi-line text date - date radio - multiple options where only one choice may be selected checkbox - check to select value select - pick one choice from a pull-down list multi select - pick one or more choices from a scroll list hidden available for advanced applications (see below) multiplier - number input is a quantity multiplied by the value (how many meals do you want at $5.00 each?) There is no limit as to the number of questions (also referred to as user inputs ) that can be added to a form. Each user input type may be assigned one or more FOAPAL number and cost to it which will be added to the total charge of registration if that user input is answered in the affirmative. FOAPAL numbers and charges will require a date range within which the FOAPAL is valid. This will allow for multiple FOAPAL numbers to be assigned to a charge in the case where an event registration spans the period where one FOAPAL expires and/or is replaced by another FOAPAL. A coupon feature has been added which will provide flexibility in handling varying rates for different types of users. For example, let's say an event offers a discount to UNH Employees. A coupon code entered by the attendee could effectively change the registration fee from $15 to $5. Coupon codes can either be displayed on the form (trusting the user will answer honestly), or conveyed to the appropriate attendees through some other means ( , voice, direct mail, etc...). Hidden user inputs are another feature that will provide the flexibility requested by some departments. Hidden user inputs are not shown to the registrant but are interpreted by the registration form. This can be thought of as a form of pass through authentication and can be used to create the scenario where you display different content or charge varying rates to known populations. For example, a UNH Alumnus logs into the UNH Alumni Association's website: Wildcat World. Since by virtue of logging on they've identified themselves as an alumni. They are then shown a special link that passes a hidden user input to our form. All they see is a link to sign up for the class reunion BBQ. However when they click this link we know that they are in fact an alumnus and the content of the form they are presented changes accordingly. Events entered will require authorization before they can be published on the site. An event may be approved by the group manager for the group it belongs to, the site manager for the site it belongs to or the system manager. In some cases, the event manager may be given the role to self approve. 04_09_20 Functional Specifications.doc Page 4 of 8

5 A comprehensive reporting interface will be created that will allow departments to view the current status of events and download any related data for local processing. IV. Branding Each event form will contain a standard campus (KSC, PSU, UNH Durham, UNH Manchester, CLL) banner on the top of the form to provide campus branding. The Site Manager has the ability to upload images to be used here. Further branding will be available by department/event to provide as much of a custom look and feel as possible. The URL convention has yet to be finalized. For this discussion, we'll assume that the USNH sites will have the following names: UNH Plymouth Keene State College UNHM CLL USNH unh-events.unh.edu psu-events.unh.edu ksc-events.unh.edu unhm-events.unh.edu cll-events.unh.edu usnh-events.unh.edu (Note: it is possible for the events server to host names like events.ksc.edu even when served from the UNH network. This effort however would need to be discussed and agreed upon with the network administrators of each campus.) For each of these sites, a single banner will be displayed at the top of each event form. This is the site banner and for UNH would probably show Thompson Hall and University of New Hampshire. Going to unhm-events.unh.edu will display all the events for the UNHM campus. The site branding banner will be uploaded by the Site Manager and can be re-uploaded at any time to allow for changes or seasonal styling. The site banner will be the full screen width and may be any height desired by the site manager. In addition to the site branding, each department can also upload a branding banner for events within their department. This banner will be displayed below the site banner on event registration screens for that department. Department banners may be full width, or if an event banner would like to be used should be half width. Each event may also have a banner image. This image will be displayed to the right of the department banner. Departments wishing to use event banners should use a half-width department banner. Department banners and event banners should be the same height for aesthetic reasons. 04_09_20 Functional Specifications.doc Page 5 of 8

6 V. Interface with Banner Finance Each day QuikPAY sends the CIS File Transfer Server (FTS) a transaction notification file containing the daily transaction details of the RCC entrypoint. An automated events process developed by RCC will read this file each day and generate a banner transaction file that meets the input requirements of the automated SCT Banner feed file. A automated tool will be made available to RCC that will allow us to send SCT Banner a list of all FOAPALs currently in use on the events site and receive back a list of any that are no longer valid for ecommerce transactions. When RCC is notified that an active events FOAPAL is not valid, we will suspend all associated events immediately and notify the appropriate event, group, and site managers. RCC will drop these records from our banner transaction file to minimize potential feed issues with SCT Banner. VI. Interface With QuikPAY After an event attendee fills out a registration form, they are directed to the QuikPAY site. This site handles all of the ecommerce components of the transaction including gathering the requisite credit card/ach information. At this site people will see a common banner that displays an identifying image of each campus. A prototype is available at: The events system will use the current "RCC" QuikPAY entrypoint. This entrypoint is currently being used by both the Alumni Association and the Foundation so it will be a shared resource for which only one set of business rules will be available. Customer Service Representative (CSR), administrator, and reporter accounts on the RCC QuikPAY entrypoint will have access to all transactions including Alumni Association, UNH Foundation, and all departments hosting events. Policies will need to be established regarding the authorization of who has access to these accounts. 04_09_20 Functional Specifications.doc Page 6 of 8

7 VII. Documentation and Training Online documentation will be made available to all users of the system. Users registering for events will have available to them documentation describing details of the entire process including information on browser compatibility and how transactions will appear on their bank/credit card statements. Event, Site, and System Managers will have access to documents as they pertain to their role. For example, Event Managers will see instructions for creating events. Site Managers will have help on using the reporting tools. RCC will provide training with departments on how to create and manage events. While it is expected that most departments deploying events will be able to use the system without interacting with RCC, we will offer support to all users through our online help desk system. VIII. Application Programming Interface (API) The events system will be implemented using the API documented in the technical specifications. The API functions will be called directly to implement the web-based forms and will also be available for departments and possible 3 rd party vendors to call directly using XML RPC. All features and functions available through the web-based system will be available through the XML RPC API. This will allow departments with custom events registration software and/or databases to interface those systems to the events system in an automated way. IX. Timeline A delivery date of the events system is dependent upon epoc approval of the functional specifications. RCC has actively been coding fundamental components we anticipate will comprise a significant part of the final solution, and therefore feel that we can start beta testing within one to two weeks following epocs approval. Another one to two weeks is expected to be spent on the beta testing after which the production version should be ready to be deployed. X. Research Computing Center Facilities The Research Computing Center machine room is located on the third floor in Morse Hall, Durham. The room is temperature and humidity controlled and physically secured at all times. During the last two years the power supply was increased and moved to UPS systems. The events system will be deployed on two servers. The first system is our primary webserver which will host the events websites. The second system is the database 04_09_20 Functional Specifications.doc Page 7 of 8

8 server that will store all of the events data. The two systems work as one to provide users a responsive site. These computers serve multiple web sites, so the events system will be sharing these resources with other web/db applications. The current server configurations are: Web server: DELL Dual 860MHz CPU rackmount server 2Gb RAM Redhat Linux (RHEL) Apache webserver MODPerl development environment Database Server: DELL Dual 2.8GHz CPU rackmount server 6Gb RAM Redhat Linux (RHEL) Oracle 9i RCC uses the Legato Networker software for automated backups. Both the web and database servers are backed up by daily incrementals and weekly fulls. We have a 90 day rotation cycle which means that the tapes storing the backups are recycled every 90 days and the data stored on them is removed. RCC can work with epoc to implement an archive strategy that will meet any longer term or permanent data retrieval needs. RCC manages our own networks and servers. We have an excellent staff who handle system and network administration and security and several student employees that manage our help desk software. Our hours of operations are 8-6 Monday-Friday. 04_09_20 Functional Specifications.doc Page 8 of 8