350 likes | 429 Views
Kuali Enterprise Notification Tell Me What I Want And Need To Know. Aaron Godert (Sr. Software Architect, Cornell University) John Fereira (Programmer/Analyst, Cornell University). Introducing KEN.
E N D
Kuali Enterprise NotificationTell Me What I Want And Need To Know Aaron 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 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
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 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)
A Notification Request as XML Notification Channel
Notification Request as XML Notification Producer
Notification Request as XML Senders
Notification Request as XML Recipients
Notification Request as XML Delivery Information
Content Types • Two content types provided out-of-the-box: • Simple • Event
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)
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
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