Kuali Enterprise Notification

Tell Me What I Want And

Need To KnowAaron Godert (Sr. Software Architect, Cornell University)

John Fereira (Programmer/Analyst, Cornell University)

Introducing KEN

• Kuali Enterprise Notification (KEN) provides a single list for all university related communications– Workflow items (KEW)– Non-workflow items (KEN)

• Examples of non-workflow items:– Your book is overdue– A concert is coming up on campus– Graduation check list to all Seniors

A Single “Action List”!

A Kuali Rice Component

• There are several middleware components that make up Rice

• KEN is one of them• Each component works

with the others to provide complementary technical functionality

A Communication Broker

Functional Goals

• Eliminate sifting through email• Quickly find what you need, to go about your

university related business• Provide a controlled environment

– Eliminate unwanted messages, prevent duplication– Integrated user and group management

• Audit trail• Centralize communication broker• More robust preference and searching

capabilities

Functional Requirements

• Three types of notifications:– 1.) Things I have to do

• Electronically (online) - KEW• Manually (physically) - KEN

– 2.) Things I need to know about• “School is closed - Snow Day!!!”

– 3.) Things I want to know about• “Dr. Nobel Laureate is coming to speak to

the Computer Science club on…”

Functional Requirements

• Target groups of people and specific people• Control delivery dates • Notifications automated by systems - s2s• Manual entry of notifications - generic message

form• Event notification

– Integration with personal calendars

• Multiple delivery end-points– Email– Text message to mobile phones

Potential Consumer Applications

• Bursar Applications• Registrar Applications• Library Applications

– Overdue checkout item notices– Item recall notices– Event announcements

Technical Goals

• Adhere to SOA principles• Develop collaboratively using the

Community Source model• Build using standard Open Source

J2EE technologies• Re-use technical products in Kuali

The Architecture

The Design

The Tools• Java SDK 1.5+• Spring Framework

– Service interface and implementations– Spring MVC

• Apache OJB– Object relational mapper

• McKoi DB (evaluating Apache Derby)– Quickstart

• Start with Oracle DDL (evaluating Apache DDLutils)– Production

The Tools

• OpenSymphony Quartz– Spring integration

• Apache Tomcat 5.5+• JSP/JSTL• XML/XSD

– DOM/Xpath– XStream

• XSLT• Apache Axis

Sending a Notification: s2s

• Java API - Java services (injected using Spring)– POJO in and POJO out

Notification n = new Notification();n.addRecipient(“TestUser1”);…NotificationResponse response = notificationService.sendNotification(n);

– String in and String out (XML)String notificationXml = <construct me some XML>;String response = notificationService.sendNotification(notificationXml);

• Web service invocation– String in and String out (XML)

Notification Request as XML

A Notification Request as XMLNotification Channel

Notification Request as XMLNotification Producer

Notification Request as XMLSenders

Notification Request as XMLRecipients

Notification Request as XMLDelivery Information

Content Types

• Two content types provided out-of-the-box:– Simple

– Event

Flexible Content Types

• To add a new content type:1. Write the sample XML for inside of the

<content> tag2. Write the XSD to validate your content

type3. Write the XSL to transform your

content type during rendering4. Add a new record to the “Content

Types” table - (name, description, active/inactive, XSD text, XSL text)

Flexible Delivery Endpoints

• Not yet built• Java interface to implement

– Specify properties that would get set by a user in their preferences

– Property values would be used to actually deliver the message

• Mobile phone #• Email address

– Implement the “deliver()” method• Call out to an SMS API• Call out to an Email API

• Delivery will be asynch - wire up a Quartz job in Spring

Kuali Rice Integration

KEW Integration• Action list

– KEW already has the concept of an action item

• User and group management– KEN’s recipient service is implemented by calling the

KEW user and workgroup services – Common set of users and groups for both applications

• Logging– Notifications become action items, action items get

automatic logging

• EDocLite (EDL)– Our generic notification message sending form is an

EDL– Positioned for workflow approvals of messages

KSB Integration

• Exposing the Java service “sendNotification()” directly on the bus– HttpRemoting over SSL– POJO (serializable) input/output

• Exposing as a WS on the bus using the generic web service feature of KSB– I don’t have to touch Apache Axis!– Implement a KSB Java interface

• Responsible for translating XML (String) to POJOs

– Wire up the call in Spring with approximately 10 lines of XML

KNS Integration

• Not yet integrated• Maintenance document features

– Dynamic rendering and persisting of administrative reference tables• Adding/updating/deleting Notification

Producers, Notification Channels, Content Types, etc

• Automatic workflow integration• Automatic versioning of records

Features in 1.0• Send notifications via s2s API/WS calls; users

can also send via message form (EDL)• Users will see their notifications alongside of

workflow items in a more general action list– Within the list, users will be able to:

• Search for by channel, type, producer, sender, and priority• Save searches for later use• Take action on notifications (clearing/acknowledging)• Click on notification to see more details about the notification• View a log for the notification (who, what, where, when, why)

Features in 1.0

• Users will be able to set up multiple delivery end points or “ticklers”– We’ll come OOTB with an email tickler

• Flexible content types (XML/XSD/XSL)• Basic authorization - Notification Channel

to Notification Producer mappings• CAS end user authentication• SSL for transport of anything over HTTP

(WS/web app)• User and group management

Status of 1.0 Features• Basic features are in place

– Can send a notification s2s and through a generic message form

• Basic KEW and KSB integration complete– Notification messages are showing up in the single

action list– Basic logging, searching, and preferences are in place– EDL form for sending messages

• Still need to:– Build sample clients in various technologies to test– Build multiple delivery end point framework– Tweak action list, logging, searching, and preferences

to be more generic and less workflow specific

Future Features

• SMS delivery end point• JSR Compliant Portlets

– Action list– Preference management

• KNS Maintenance documents for administration

• Attachments• Additional content types OOTB• s2s revocation of notification messages• Ability to schedule recurring messages• And more…

Time Frame for Deliverables

• 1.0 - April 2007• 1.X+ (future features) - aiming for 3

month cycles• Kuali Rice bundling - Summer 2007

Interested?

• Looking for contributors on the Kuali Rice effort and KEN

• Looking for developers to write test clients in various technologies

• Always open to new requirements• More information:

http://wiki.library.cornell.edu/wiki/display/notsys

• Contact ag266@cornell.edu