1. Kuali Enterprise Notification An Update for Cornell - January 2007
Aaron Godert (CIT, ATA)
John Fereira (CU Library Systems) Aaron Hamid (CIT, ATA)

2. Agenda Functional Segment (Functional Attendees Can Leave)
Introduction/review
Functional requirements
Demo
Roadmap for delivery
(Functional Attendees Can Leave)
Technical Segment
Technical goals
Architecture and design
Specific features
Kuali integration

3. 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

4. A Single “Action List”!

5. 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

7. A Communication Broker

8. 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

9. 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…”

10. 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
Text message to mobile phones

11. Potential Consumer Applications
Bursar Applications
Registrar Applications
Library Applications
Overdue checkout item notices
Item recall notices
Event announcements

12. Demo

13. Features in 1.0 Send notifications via s2s API/WS calls
End users can send via message form (EDL)
End 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)

14. Features in 1.0 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

15. 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 (might slip to 1.x)
Tweak action list, logging, searching, and preferences to be more generic and less workflow specific

16. Future Features JSR Compliant Portlets
Action list
Preference management
KNS Maintenance documents for administration
Attachments
Additional content types plug-ins
Additional tickler plug-ins
s2s revocation of notification messages
Ability to schedule recurring messages
And more…

17. Time Frame for Deliverables
1.0 - April 2007
1.X+ (future features) - aiming for 3 month cycles
Kuali Rice bundling - Summer 2007
Unknowns
Synchronization with KEW 2.4 timeline
Synchronization with Kuali Rice timelines

18. Functional Interest? Looking for functional testers
Always open to new requirements
More information:
Contact

19. 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

20. The Architecture

21. The Design

22. The Tools Java SDK 1.5+ Spring Framework Apache OJB
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

23. The Tools OpenSymphony Quartz Apache Tomcat 5.5+ JSP/JSTL XML/XSD XSLT
Spring integration
Apache Tomcat 5.5+
JSP/JSTL
XML/XSD
DOM/Xpath
XStream
XSLT
Apache Axis

24. 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

25. Notification Request as XML

26. A Notification Request as XML
Notification Channel

27. Notification Request as XML
Notification Producer

28. Notification Request as XML
Senders

29. Notification Request as XML
Recipients

30. Notification Request as XML
Delivery Information

31. Content Types
Two content types provided out-of-the-box:
Simple
Event

32. Flexible Content Types
To add a new content type:
Write the sample XML for inside of the <content> tag
Write the XSD to validate your content type
Write the XSL to transform your content type during rendering
Add a new record to the “Content Types” table - (name, description, active/inactive, XSD text, XSL text)

33. Flexible Delivery Endpoints
Core pieces of this framework are in place; needs more work
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 #
address
Implement the “deliver()” method
Call out to an SMS API
Call out to an API
Delivery will be asynch - wire up a Quartz job in Spring

34. KEW Integration Action list User and group management Logging
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

35. 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

36. 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

37. Technical Interest?
Looking for people to write test client systems in various languages
Looking for people to review documentation
Will accept any form of technical QA or volunteer development :-)
More information:
Contact