home › products › Enterprise Messaging Service

Enterprise Messaging Service

EMS allows you to communicate with every single employee regardless of when they come to work. How does a manager who works 6AM to 6PM ensure instructions are given to the midnight local? EMS handles that problem with elegance.

System Overview

The Enterprise Messaging Service is a product that will allow users to generate messages to a specific employee or set of employees based upon employee filters/attributes. EMS will provide screens to create and display messages to users of the system. The EMS system will allow for the creation of employee filters from a Customer data source (i.e. Terradata system, etc). Administrators of the EMS can control what employee filters a user can see while creating a message. This product will also provide a method for controlling access to different filters, data and screens based upon a user’s roles and responsibilities.

EMS can integrate into your organization’s secure network to allow for single sign-on. When a user logs into your organization’s intranet, EMS will check for messages and redirect the user to the EMS product to view messages. Once the messages have been acknowledged and processed, the user will be redirected to the original website selected.

EMS can be leveraged in many different ways:

  • One way communication via any web interface. Integrating this product at the ‘front door’ of your single sign-in application will provide a guaranteed method of message delivery to any and all of your employees
  • Current processes which require manual dialing of phone numbers to provide notification can be automated using this product. Some examples
    • Assignment changes that are currently done manually could be added to the EMS database and easy integration with your existing AVR platform could provide quick outbound calling.
    • New hire classes can be notified of changes to their schedules by using EMS
    • Gathering information about qualifications – i.e. “Are you qualified between A and B?”
  • Pushing rules changes to all employee’s via a cell phone
    • Human Resources needs to notify all employees that open enrollment begins on a specific date
    • The engineer group wants to ensure all of the management staff have received the current rule clarification, they can create a message, assign this message to their team, and verify that the information get passed out timely. Past experience shows that communication of this type typically is complete in less than a week for 85% of the population
    • The intermodal group wants to ensure every corridor manager knows a train for a certain customer needs the highest priority today and tomorrow, they can ensure the message gets delivered; regardless of the frequency someone opens their email.
    • The standards group documents a new process and wants to notify everyone who has been designated as a consumer of this information, they can create a broadcast message to let everyone know of the update.

To meet the business objectives, EMS is designed to allow many concurrent users to interact with the data through a variety of client technologies. To meet these data handling and integration challenges, PST’s EMS product employs proven, risk-mitigating, standards-based technologies and enterprise application architecture patterns that ensure seamless technical implementation and significant flexibility for each user level.

Architecture

The architecture for EMS is built on the Java 2 Enterprise Edition (J2EE) platform using Enterprise Application Architecture Patterns, Enterprise Integration Patterns and Domain-Driven Design. Built upon the mature and firm foundation of the Java 2 Enterprise Edition (J2EE) specification stack, layered and service-oriented software architecture, and industry leading Enterprise Resources (i.e.., relational database, message-oriented-middleware by way of JMS, directory services, security services), the product is being designed and built in such a way that it can serve virtually any type of client technology including browser-based web applications, XML web services, rich/native desktop applications, mobile applications and voice/IVR applications.

Application Server

EMS development is targeting J2EE 1.3, JDK 1.4.2, with current plans to certify on BEA’s Web Logic 8.1.

EMS Major Components Overview

The EMS Major Components Process flow depicts the major functional components identified as part of the Enterprise Messaging Service. These major functional components include the following:

Role Based Security

This component deals with role definition to be used in the administrative functions that define security within EMS. A Role within EMS is interpreted as a role within a security area. (I.e. CMS Administrator, TE&Y Employee, CMTS Timekeeper, etc). Roles are then assigned the authority to operate within EMS. This authority is associated to roles through the administrative functions described above. Roles will be attached to an individual person, group or organization and can be effective date driven.

Message Filtering

This component allows the administrator to define the message criteria to be used in sending messages. The message criteria will be used to build the distribution list for the Send Message function. Examples of message criteria may include Employee Id, EMS Role, geographic area, etc. This functionality will allow you to customize the display based upon the role, improving the usability of the application at all levels. For instance, by allowing only Employee ID as filtering criteria, you have effectively eliminated someone’s ability to broadcast a message to everyone in the system.

 

  • Ability to send a message to a specific employee or group of employees.
  • Ability to define the message criteria using the defined message filters which defines the distribution list
  • Ability to send a system wide message.
  • Ability to define message effective and expiration dates.
  • Ability to allow the user to define the number of times the message is displayed and acknowledged
  • Ability to define the message type which drives the action required by the user. Message types include Informational, Acknowledge, Yes/No, or Text Message. The acknowledge message type will require the user to check an acknowledge check box. The Yes/No message type will require the user to select Yes/No answer to the message. The Text Message type will require the user to enter a text response.
  • Ability to preview the distribution list prior to saving the message.
  • Ability to define the subject title line.
  • Ability to build the message

Sent Messages

This component allows the user to view all sent messages. A list of sent messages will be displayed. Once the user selects one of these sent messages, they will be provided the details of the message including the distribution list and the status of the message for each recipient (Such as, pending, reviewed, acknowledged, etc.). The ‘copy message’ function will allow the user to copy a previously sent message. The user will be transferred to the create message screen with the copied message data populated. The user will then have the opportunity to change the message prior to sending it as a new message.

View My Current Messages

This component allows the user to review messages in their message queue within EMS. The user will receive the message and respond according to the message type. These responses will be stored and reviewed by using the Received Messages function.

XML Interface

This component will allow an application ID access to query the EMS database to determine the following information:

  • Are their any messages I need to distribute for X user type?
  • If yes, what are they?