SSP Technical Requirements Overview

Owned by Jason Elwood
Last updated: Dec 19, 2013 by Russ Little
2 min read

Executive Summary

SSP runs on standard java web container in Java. It can be run in a VM environment and does not require dedicated hardware. The data is stored in MsSQL or PostgreSQL. SSP can connect to existing LDAP services for authentication. Reporting is done with Jasper Reports (open source software) accessing the SSP database and possibly a datawarehouse. Integration to a SIS is done through a separate DB and is unidirectional, with the SIS being the data authority.

Software Requirements

  • Display: HTML5
  • Logic: Java – Object oriented design with API’s exposed for integration and reporting
  • Data: Microsoft SQL Server 2005-SQL Server 2008 R2, or PostgreSQL 9 or newer

Server

Any web server that can deploy a Java .War file. Windows, Linux, Unix, etc.  Apache Tomcat or Internet Information Server and Tomcat is recommended, but other options are possible.  Standard Web Server hardware is fine.  Generally, a VM (Virtual Machine) is created to host the web software as do several other colleges. This provides the ability to scale up and down to meet performance needs. Typically 4 GB of ram is plenty on a modest CPU.

Database / Data

  • Microsoft SQL Server
  • PostgreSQL

The database does not need to be a dedicated server.  The SSP database can be created in an existing instance and run it with many other DB’s on the same server.  The code uses a ORM to abstract the DB tier, and no logic is done in the DB.  Any SQL compliant DB engine should work, but the app currently only supports PostgreSQL and Microsoft SQL Server 2005 for the summer 2012 release. Jasper Reports is used to create the reports from the system. Standard reports are provided, and additional reports can be created in Jasper.

Integration / Data

Integration to the SIS uses a separate DB that is designed to be easy to use and navigate. If the SIS data can be mapped to the fields in the external integration database, SSP can consume it. This is typically done as a SQL view of the data in your SIS or datawarehouse or through a data load from a flat file, query or other ETL process to the integration database.  The database mappings are fully documented.

Security

For authentication best practice is to connect SSP to an existing single sign-on (SSO) or authentication service such as LDAP, CAS, Active Directory or Novel Directory.  SSP does have the ability to be standalone for security if no LDAP connection is possible.  All Access control is managed in the SSP application. SSO provisions are available for accessing the UI and for making secure API calls.

Configuration

Much of the SSP is configurable either with web based configuration forms or simple configuration files. Most of the work involves mapping business process to the configuration options.  The configuration is not a technical exercise.