Regroup Design Blueprint

Transcription

1 Prepared by Dory Weiss, ITS Last Edited September 28, 2012 November 15, 2012 Regroup Design Blueprint Executive Summary The functionality to send Informational, Operational, and Official messages via the current Group application is being replaced with Regroup, a SaaS (Software as a Service) product that provides group mail, text and voice broadcast, marketing, social media integration, and group management solutions. As a hosted service, Regroup staff are responsible for hardware and server administration, which reduces the maintenance burden for ITS. This design blueprint details the integration between ITS Applications and Regroup. Detailed information about the architecture and design of Regroup itself is available on the Regroup support website ( System Architecture Architectural Design Approach The move to a SaaS solution means that the Regroup application will provide the majority of the Group features previously provided by ITS Application custom code. For instance, sending, group authorization, message tracking, and other key pieces of functionality are now provided by Regroup. ITS Applications will be responsible for ensuring that those pieces of the Regroup system meet all system requirements. Design work performed by ITS Applications will focus on the authentication and data pieces needed to integrate Regroup into the UT application environment. The data used to generate lists is owned by the appropriate business area TRECS owns employee data, Registrar IT owns student data therefore the design work for this project has focused on converting the data provided by data owning areas into the format required by Regroup. In order to minimize the impact on data-owning areas, no changes to the interface between the new list generation process and the data owning areas have been made. The design work assumes that no changes will be made by data-owning areas to underlying data storage. However, consideration has been given to how the list generation process should change when student and employee data is no longer kept in Natural/ABABAS. 1

2 Architecture Design Group membership data ( details in data integration diagram) Data load process ADABAS/mainframe.csv group membership Logon via custom Django front end for Regroup site Regroup Recipient client(s) Regroup user Send via client Group Authentication TED / person ID data Figure 1 High Level View of System Architecture The integration with Regroup consists of a nightly process to generate and upload group membership data to Regroup via SFTP in the form of a.csv file. The list generation process resides on the mainframe and relies on secured modules provided by TRECS, Registrar IT, and ITS Applications Identity and Access Management team to provide information for UT students and employees. The list generation process is loosely coupled to Regroup the only dependency between the two processes is that a dataset of recipient s must be sent to Regroup in the expected format. This will allow the listgeneration process to be replaced as the data-providing systems are moved into new technologies. Users will access the Regroup web application through a Python/Django login page provided by ITS, and authorization to use the Regroup web application will be determined by a Shibboleth query of TED. Users may send via the Regroup web application or by sending a message from their client to a Regroup address. Additional Regroup functionality (i.e., tracking a message, viewing a message archive, etc.) is available via the web application. Regroup Design Blueprint 2

3 List Generation Batch process(es) build datasets of STUDENT lists nightly Batch process(es) build datasets of EMPLOYEE lists nightly Administrative/ Outside areas GDS Read datasets and create dataset of all EID + group ID Group ID data Sort dataset Regroup SFTP Build CSV, retrieving name from T3N$ELKP and from T4N$EADR Batch Jobgroup Dataset ID > Regroup Group ID table Mainframe/ Adabas Group IDs created by Regroup Figure 2 Mid Level View of List Generation Process Integration of group membership data with the Regroup system consists of an SFTP transfer of a CSV file containing the groups to which each EID belongs. Source systems will continue to generate lists of EIDs in ADABAS datasets representing the membership for each group. A nightly batch process will run to determine current membership of all EIDs for all groups. The nightly batch process consists of three steps; in the first step, a program reads through the existing group membership datasets and generates a new, generational dataset of all memberships (each record will be of the form EID + group ID). This new dataset will then be sorted by EID in step 2, and in step 3 a separate Natural program will combine all memberships for each EID and add name and address. Finally, the Natural program will create the desired CSV file and transfer it to Regroup. Regroup Design Blueprint 3

4 Sending UT-branded Regroup site utexas.regroup.com UT-branded Regroup site utexas.regroup.com UT Shibboleth login screen User authorized? Y Review Messages Moderate Messages N Send Messages Review Message Metrics Error message and no access Figure 3.1 Mid Level View of Sending Process Regroup will provide the web interface for Group . When a user accesses the Regroup site (utexas.regroup.com), she will be automatically redirected to the UT Shibboleth login screen to validate with EID and password. After successful authentication, authorized users are taken to the UT-branded Regroup main page, where they can perform various actions such as reading or sending messages. An error message is displayed for unauthorized users. Personal client Regroup site User authorized? Y Sends message to list N Moderator approves or denies Figure 3.2 Mid Level View of Sending Process Another option for using Group is to send a message via an client (e.g., Outlook), addressing it to a Regroup list. Regroup receives the message, determines if the user is a member of receiving list and checks the security settings of the list, and either sends the message or forwards it to the list s moderator to approve and deliver the message. Regroup Design Blueprint 4

5 Shibboleth Authentication Browser Regroup website Regroup (SP) ITS Shibboleth (IdP) ITS IdP Attribute Authority Navigate to login page Redirected to SP Redirect to SP Redirected to IdP Redirect to IdP Authenticate Redirected to SP Redirect with Token to SP SP queries IdP for Account Details Return Account Details Redirect Browser to Regroup website Redirect with Token Obtain Account Details Return Results Access Granted Grant Access? Figure 4 Detailed View of Shibboleth Authentication Process Authorization to access Regroup is determined by a Shibboleth query of TED. Regroup Design Blueprint 5

6 Data Design Persistent/Static Data The ITS-owned portion of the Regroup implementation does not own any data about recipients. Employee information is owned by TRECS 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. Regroup stores recipient data in its own files, which are not documented here. External Interface Data Interface with Data-Owning Areas 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) 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. Interface with Regroup The following.csv format is required by Regroup for data integration: Figure 5.CSV Format Example The following fields will be utilized in the upload process: FirstName, LastName, #1, UserName (EID), GroupID (Regroup generated). Regroup Design Blueprint 6

7 User Interface Design User Interface Navigation Hierarchy Users may access Regroup by navigating directly to the Regroup website (utexas.regroup.com) or by sending an message to a Regroup address. User Interface Design Overview The user interface for Group will be provided by Regroup. Users entering the Regroup domain (utexas.regroup.com) will be redirected to the standard UT Shibboleth login screen for authentication. Once they have successfully logged in, they will be redirected back to the Regroup site. The Regroup web interface allows users to read messages from and post messages to the groups to which they belong. Users who are authorized as administrators also have the ability to create new groups and configure settings through the interface. Additional information about the Regroup interface is available on the Regroup support pages ( Figure 6 Screenshot of Regroup Home Page (List of User s Groups) Regroup Design Blueprint 7

8 Figure 7 Screenshot of Regroup Post a Message Page Regroup Design Blueprint 8

9 Figure 8 Screenshot of Regroup Group Overview Page User Function Categories (or s) The following s have been identified for Regroup. Initial upload of dataset of group members Manual Regroup, Dataset provider, ERPS, SFTP agent 1. ERPS manually initiates list generation process 2. List generation process consolidates datasets from Dataset providers 3. Resulting dataset is SFTPed to Regroup 4. Regroup processes dataset Regroup Design Blueprint 9

10 Upload updated dataset of group members Nightly scheduled process Regroup, Dataset provider, SFTP agent 1. Dataset provider creates dataset via nightly process 2. List generation process consolidates datasets from Dataset providers 3. Resulting dataset is SFTPed to Regroup 4. Regroup processes dataset Generate dataset of group members Nightly scheduled process; manual when creating a brand new list Dataset provider Dataset provider creates dataset Nightly scheduled process; manual when creating a brand new list Create new permanent list in Regroup Authorized user chooses create new group in system Regroup, List owner 1. User opts to create new group 2. User fills out group information 3. Regroup creates and saves group If user needs user data to be regularly refreshed, s/he will need to have the list integrated into the nightly list generation process. This will require that a list generation module is built by the data-owning area. Create new one-off list User defines a new group Regroup, Authorized user 1. User opts to create new group 2. User fills out group information 3. Regroup creates group Regroup Design Blueprint 10

11 Send basic via client User sends an to a Regroup address Regroup, Sender 1. Sender creates and sends to Regroup address 2. Regroup distributes mail to group members If sender is not already authorized to send to group: 2a. List owner (moderator) is notified of 2b. List owner (moderator) approves/denies Define type for basic via client User sends an to a Regroup address Regroup, Sender When creating , sender includes type in Subject Line If no type included, then what? Send basic via Regroup website User sends an via Regroup group page Regroup, Group member 1. User logs into Regroup 2. User selects group to send to from home page 3. User selects post a new message 4. User composes message 5. User hits Send 6. Regroup sends to address list for group Define type for basic via Regroup website User sends an via Regroup group page Regroup, Group member User selects from available types when creating message Regroup Design Blueprint 11

12 Send HTML (with plain text version) via client User sends an HTML-formatted to a group address Regroup, Sender 1. Sender creates and sends to Regroup address 2. Regroup distributes mail to group members in HTML and plain text If sender is not already authorized to send to group: 2a. List owner (moderator) is notified of 2b. List owner (moderator) approves/denies Define type for HTML (with plain text version) via client User sends an HTML-formatted to a group address Regroup, Sender 1. Sender uses the group address that corresponds to the intended message type (e.g, all_students_official@utexas.regroup.com) 2. Regroup prepends the corresponding message type to the subject (e.g., [Official] ) Send HTML (with plain text version) via Regroup website User sends an HTML-formatted via Regroup group page Regroup, Group Member 1. User logs into Regroup 2. User selects group to send to from home page 3. User selects post a new message 4. User composes message and hits Send 5. Regroup sends to address list for group in HTML and plain text Define type for HTML (with plain text version) via Regroup website User sends an HTML-formatted via Regroup group page Regroup, Group Member 1. Sender selects the Regroup group that corresponds to the intended message type. 2. Regroup prepends the corresponding message type to the subject. Not all options may be available for all users Regroup Design Blueprint 12

13 Send attachment via client User sends an with an attachment to a group address Regroup, Sender 1. Sender creates , attaches file, and sends to Regroup address 2. Regroup distributes mail to group members If sender is not already authorized to send to group: 2a. List owner (moderator) is notified of 2b. List owner (moderator) approves/denies Send attachment via Regroup website User sends an with an attachment via Regroup group page Regroup, Group Member 1. User logs in to Regroup 2. User fills out information on , with distribution list and type 3. User opts to attach file(s) to and is presented with upload options 4. User uploads file(s) to attach 5. User hits Send 6. Regroup sends to address list for group Review attachment recipient reviews an attachment sent to a group address Regroup, Recipient 1. Recipient receives with attachment 2. Recipient opens attachment Opt-out of Informational messages User selects opt-out Regroup, Group member/recipient, UT Direct 1. User logs into UT Direct Message Center Customization page 2. User selects Informational opt-out 3. Preference is saved on dataset providers files 4. Dataset provider refers to setting when creating Informational distribution lists Regroup Design Blueprint 13

14 Opt-out of Marketing messages User selects opt-out Regroup, Group member/recipient, UT Direct 1. User logs into UT Direct Message Center Customization page 2. User selects Marketing opt-out 3. Preference is saved on dataset providers files 4. Dataset provider refers to setting when creating Marketing distribution lists Approve message(s) for distribution Sender creates message and hits send Regroup, Admin, Sender 1. Regroup forwards the message awaiting moderation to list admin 2. List admin uses links in the message to approve 3. Regroup distributes to recipient list Admin moderates message via Regroup website: 2. Admin logs into Regroup 3. Admin is offered list of messages for approval 4. Admin reviews and approves message(s) 5. Regroup distributes (s) to recipient list Revision History Identify changes to the System Design Description. Version Date Name Description 1.0 8/31/12 Dory Weiss Initial draft 1.1 9/7/12 Dory Weiss Revisions after internal review Signatures Formal written signoff is preferred for larger, more complex projects. Name Role Signature Date Regroup Design Blueprint 14

15 Regroup Design Blueprint 15