Custom Urgent System Design Blueprint

Transcription

1 Prepared by Dory Weiss, ITS Last Edited November 15, 2012 System Design Blueprint Executive Summary The functionality to send Urgent messages in the current Group is being replaced with a new streamlined process. The new system is designed to emphasize simplicity, speed, and robustness. Urgent s must be sent quickly (approx. 70,000 messages must be sent in 30 minutes or less), and the interface must be simple and easy-to-use, even under stressful circumstances. System Architecture Architectural Design Approach The ability to quickly and reliably send to all UT students and employees in the event of an emergency is considered a critical business process. This project has focused on designing a system with minimal components (to reduce the number of points where a problem could occur). The legacy Group system has proven to be incredibly robust, so the architecture of the new system is a simplified version of the legacy application. Modules and processes from the legacy system have been reused where appropriate. The data utilized by the system is owned by other business areas TRECS owns employee data, Registrar IT owns student data so the design is structured to avoid changes to underlying data structures. Moreover, effort has been made to minimize the impact on dataowning areas, and no changes to the interface between the system and the data owning areas have been made. Design work has also focused on architecting a new user interface. Urgent s may be sent under highly stressful circumstances, so the interface has been designed to be simple and fast as well as to minimize possible user errors. In order to provide geographical redundant functionality, it will also be possible to send urgent s via Regroup (the hosted solution that will replace the rest of the legacy Group system.) A group for sending urgent messages with the necessary authorizations and recipient list will be available via Regroup in the case of a disaster. Design documents for Regroup will be available separately. 1

2 Architecture Design Sending Web Interface Mail Server User Client Sender Recipient List Generation Process External Systems External Files Recipient List Generation (Mainframe Batch Process) Figure 1 High Level View of Architecture The system consists of a nightly process to generate and upload a list of recipients to the mail server and a web interface for sending an to this list. The list generation process resides on the mainframe and relies on secured modules provided by TRECS and Registrar IT to provide information for UT students and employees. The list generation process is loosely coupled to the process for sending . The only dependency between the two processes is that a dataset of recipient s must be present on the mail server and in the expected format. This will allow the listgeneration process to be replaced as the data-providing systems are moved into new technologies. System Design Blueprint 2

3 System Domain Design Mainframe List Generation List Generation Process Dataset of Recipients SFTP Transfer Server (transfer.its) SFTP Mail Server TRECS Module Registrar IT Module TRECS Data Registrar IT Data Mainframe Batch Process Figure 2 Mid Level View of List Generation Process The list generation process for the system is a simplified version of the process used in the legacy Group system. The process runs nightly on the mainframe. It first makes calls to secured modules provided by TRECS and Registrar IT that individually build a dataset of recipients in a common format. These datasets are then combined into a single dataset and SFTPed to Custom Urgent mail server by way of the ITS Transfer server. System Design Blueprint 3

4 Sending TED Query for EID entitlement Server Web Application Postfix MTA Urgent User Client Sender Recipient Dataset of Recipients Figure 3 Mid Level View of Sending Process Sending an via the system begins with the user accessing the Django web application. The web site resides on a dedicated physical server and will query TED to check for an EID entitlement that grants authorization to send Urgent s. Once a user s authorization has been verified, s/he submits the message subject and text via a web form, and a process runs to distribute the message to the recipients listed on the dataset uploaded during the list generation process. Outgoing messages are handled by an instance of Postfix running on the same physical server. Once sent by the mail server, recipients access the via their preferred client. Data Design Persistent/Static Data The system does not own any data about recipients. Employee information is owned by TRECES and stored on the file BD-EMPLOYEES. Student information is owned by Registrar IT and stored on the file NR-STUDENTS-WHOLE-FILE. addresses are retrieved from these files via Natural secured modules provided by each department. External Interface Data Datasets received from TRECS and Registrar IT are expected to be created in a common format, as documented in the LDA TXDLBMCL: * ** #TXDLBMCL * * PREF-EID (A15) System Design Blueprint 4

5 2 -ADDRESS (A75) 2 EXCLUDE- (A2) /* Employee or student areas can * ** use this field to return the * ** user's subscription option. * ** Emp: 'I' means user has * ** unsubscribed from receiving * ** informational msgs. * ** Stu: 'Y' means user has * ** unsubscribed from info msgs. * ** " " value - pgms will call the * ** area to check the value. 2 FILLER (A30) 2 REDEFINE 3 # -SWITCH-SENT (L) /* if true, then EXCLUDE- * /* was passed. User Interface Design User Interface Design Overview The design for the website has been developed in collaboration with the users of the system. User interviews and multiple rounds of usability testing have been conducted to ensure that the design and function of the site meets the users needs. Urgent s are frequently sent in stressful situations, so users should be presented with a single, simple page with as few decisions to make as possible. The page should have little or no unrelated navigation. There will be few options on the page, the most obvious of which will be the Send button. If the user selects from a set of radio buttons for the type of event (e.g., Evacuation or Severe Weather ) and event stage (e.g., Initial or All Clear ), the subject and message field will automatically populate with template text provided by University Operations-Communications which can be edited to accommodate specific details. A Clear Form link will to cancel and reset the page without sending any message, and there will be links to the Regroup site and a Send Message to Event Incident Link that will open an Outlook message to the Event Incident List. User Interface Navigation Hierarchy The Urgent page will be an entirely separate URL from the other Group page(s). Authorized users will be able to access the new page by entering the address directly into their browser (that address should also be bookmarked) or by following a link displayed on the Emergency Status Update page. System Design Blueprint 5

6 Figure 4 Screenshot of website User Function Categories (or Use Cases) Initial Determination of Authorized Users Urgent s are only able to be sent by a select list of users who will be authorized via an EID entitlement. Authorized users for the Urgent System will be determined by the Director of University Operations-Communications and the Director of Emergency Preparedness. These users will be initially authorized by the EID team during the development of the system based on a list provided by the Director of University Operations-Communications and the Director of Emergency Preparedness. Enhancement: The system will be tailored specifically for those users and urgent situations. System Design Blueprint 6

7 Grant/Remove Authorization The system will interact with the EID Entitlement system to determine user authorization. Authorized users for the Urgent System will be determined by the Director of University Operations-Communications and the Director of Emergency Preparedness. Enhancement: Allows for fluidity and responsiveness regarding user authorization Generate Recipient List A Recipient List will be maintained at all times to be available when an needs to be distributed. Initially, that list will be created manually. Thereafter, a nightly process will create a new replacement list with the latest information available. In the event that the nightly process fails, the process will default to the last available list. User Accesses the Web Page to Create In order to create an Urgent , the user will access the Urgent page via their preferred browser. The page will check the user s EID Entitlement and present authorized users with a blank form. The user may enter a free-form message or select from a drop-down of issue types (Weather Event, Armed Intruder, etc.) that will populate the message with a preapproved template for the user to customize with specific event details. These templates will be provided by the Director of University Operations-Communications. Once the user hits send, the will be sent to the server and then distributed to the recipient list. Enhancement: The Urgent system will be tailored specifically for a small, defined group of users and urgent situations. It will be streamlined to prevent confusion and allow users to quickly disseminate information in tense situations. The system will also be available from any location where the internet is accessible and not depend on specific software or downloaded applications. Review Sent Messages Message sent via the urgent mail server will be archived in an AEMS mailbox; sent messages may be reviewed by system stewards. Additionally, any sender or recipient may review a sent message by accessing their preferred client s saved/archived history. Save Template Authorized users will be able to create new templates on the Urgent site. The creation of these new templates will be based in a separate, administration section so as not to clutter the site or add confusing elements. Authorized users may click on a create new template link, enter their new template information in a presented form, and select an issue type with which it will be associated. The template will be saved and available for future use. Enhancement: Allows for updates to system based on new requirements and newly identified situations. System Design Blueprint 7

8 Edit/Delete Template Authorized users will be able to delete templates on the Urgent site. Authorized users may click on a list templates link which will present a list of existing templates. Each template will have the option for editing or deletion. Enhancement: Allows for updates to system based on changed requirements. Glossary Apollo User authorization system maintained by ITS Applications Issue Type The type of incident to which the is referring (Weather Event, Armed Intruder, etc.) Recipient List Dataset of Urgent recipients compiled from datasets provided by TRECS and Registrar IT Revision History Identify changes to the System Design Description. Version Date Name Description 1.0 7/31/12 Dory Weiss Initial draft 2.0 8/24/12 Dory Weiss Revisions after internal & ISO review 2.1 9/25/12 Dory Weiss Added screenshot Signatures Formal written signoff is preferred for larger, more complex projects. Name Role Signature Date System Design Blueprint 8