Introduction

The Enterprise Messaging Service will provide system to user and system to system messaging for the enterprise.  The initial primary business driver for this service will be the HR Personnel Action Forms (PAFs) notification process.  The following is a high-level view of what the system might look like:

Goals

The goals of the EMS are to provide a more efficient way to message users and other systems in the enterprise.  The system will also provide a user interface where messages can be displayed in a secure web application, thereby alleviating the security concerns with using standard email.  

Messaging Definitions

For the purpose of working together and being on the same page, the following definitions related to discussion of messaging at Virginia Tech.

  • Message - a message is the text that is to be delivered/displayed to an end-user, or one that is sent from a system to a system (ie. JSON or XML)
  • Notification - a notification is the text that is sent to an end-user and contains information that a user may take action upon such as a link to the EMS web application user interface or some other web application
  • EMS Web application (Web-based UI) - the interface that an end-user interacts with to get messages in the EMS System
  • Message Queue - a standards-based (AMQP/JMS) system to system asynchronous messaging queue.  This allows for a consistent and robust messaging framework.
  • Message Store - a database of messages, audit logs, etc.
  • Message Controller - the messaging storefront responsible for delivery of notifications, an application programming interface that is used to process all functions of the EMS
  • Service Application - a relying application service such as Banner, BPM, etc.  These are the systems that have a need to send a message to an end-user or another system.
  • SMS - text messaging protocol
  • Push Messages - how smartphones get native messages in their respective operating systems
  • Interactive Voice Response (IVR) - a system that can call a standard telephone and use a computer synthesized voice to speak messages to the person on the other end of the call.
  • Service Message Type - a service application can define a message type that an end-user can use to make decisions about how they want to receive notifications about that message.  The combination of service and message type might be STUDENT - GRADES AVAILABLE

Project Scope

The scope of this project includes developing a system that allows systems to message end-users and other systems that may or may not include a notification as a separate message and a message viewing application.  The system should not require any purchased software.  However, there may be requirements for additional virtual hardware, and depending on analysis may require delivery services that may have an associated cost.

Stakeholders

Initially, the business drivers for the system will be HR's PAF notifications and the Graduate School's Graduate Contract notification application.

Human Resources - Stacey Poertner and Cathy Petry

Graduate School - Monika Gibson

Potential Stakeholders - Melinda West and Alex Guest

General Requirements

  1. Services will be able to restrict sensitive data or messages to only be viewable in the web application, not in notifications via email or other insecure transmission method
  2. Services will be able to set expirations on messages 
  3. Services will be able to set due dates on messages, and have the user notified via screen hints
  4. Service will record meta data about message processing indefinitely (this is pending review for data retention policy)

Functional Requirements

  1. System will provide a web application view of the messages received by service and type
  2. System will provide a way for users to set preferences for message delivery
  3. System will provide a standards-based method for services to publish messages to the system

 

 

 

  • No labels