[OPEN-ILS-DEV] Notification system design

[Don McMorris]

On 12/22/06, Mike Rylander <mrylander at gmail.com> wrote:
> On 12/21/06, Josh Stompro <stomproj at larl.org> wrote:
> > Are there any design docs or wish list on how Evergreen handles various
> > types of notices and delivery methods, and how they will work together?
> > If not could I start one?  I am incredibly frustrated with the
> > notification systems of the other ILS's I have worked with and would
> > like to help design the "Notification Of Triggers Customer Resource
> > Announcement Process - Evergreen" system, or NOTCRAP-E system for
> > short.  The name could probably use some work though.
>
> AAAAAAAAAAAAAAAAAHAHAHHAHAHAHAH... holy moly... ahhhh.  Man, that name
> ... whew! ... it just kinda snuck up on me, and then POW!  It's a
> perfect working title, methinks.
>
> There are no design docs for the notification infrastructure as yet.
> This was nearly all Bill's stuff, so I don't know how far we should go
> while he's not around to defend himself ;), but a generalized
> notification service is something we've discussed (and makes sense, if
> more than email notification is desired).
>
> There are two competing types of "triggers" we'll need to consider
> here:  real-time, action based triggers (hold arrives at its
> destination; fine is generated on an overdue item),
--I just want to throw in here (while it's early) that even though
this is "real time", a (short) time delay would likely be desired (IE:
1 hour).  This would give a chance for staff to correct procedural
errors/etc., or for "batch" events to be fully processed (IE: overdue
item checked in, fine assessed on account, patron comes back 20
minutes later to check out an item and pay fines).

> and time span
> expiration triggers (item is 14 days overdue; hold fulfillment is
> taking forever, would you like to try other formats/editions?).
>
> The first of those, in our experience, is served well by a full
> fledged OpenSRF service.  An example of this is the penalty server,
> where any change to a user's circulation, hold, or fine standing
> causes a recalculation of their penalties (blocked, delinquent, etc).
> The second type, examples of which are the current overdue notices and
> collections listing, is usually handled by a nightly process.  Both
> end up in some sort of notification to someone, and collecting them in
> a pluggable service sound like a good idea to me.
--100% agreed

>
> Some things to think about:
>
> * we'll need a persistence model -- if reporting on notifications is
> desired then it should probably be rolled into the central database
> schema
>
> * should there be two service types  -- "action" triggers and
> "scheduled" triggers -- or should there simply be a polling process
> that fires time-based events, OR should all be scheduled allowing for
> a delay in "actions" (for example, a held item arrives but is damaged
> and can't fulfill the hold -- so no notification should be sent)
--I'm for time delay.  As for how to accomplish this... Say, a
scheduled job to run every 30 minutes, and only mails notices that are
entered greater than 30 minutes ago.  HOWEVER, there should also be a
mechanism for immediate e-mailing... What I'm envisioning is if a
patron calls and would like an account summary of fines/holdings/etc.
e-mailed to him (for some reason, he doesn't want to look it up in the
PAC), a staff member than choose an option/do something fairly simple
to execute this.  Perhaps also, on this note, a mechanism for staff to
send raw messages to the user directly from the Staff client (instead
of copying the e-mail to their stand-alone e-mail client)?

>
> * where do we delimit plugins -- should there be plugins for both
> accepting/recording events and firing/performing notifications
>
> >     I know where the email notification files are at now, and I see that
> > automated phone notification is on the feature list for a future
> > release, is there anything about how it all is going to be tied
> > together, or about what events trigger notices, and about other forms of
> > notification (SMS, IM, Telegraph, Smoke Signals, Exchange Calendar
> > Events, etc).
>
> The nice thing about email is that there are gateways from it to other
> services like IM and SMS.  Even a phone notification system could use
> text-to-speech to allow an email gateway, I think.  (Asterisk may even
> have this today ... not sure.)
>
--Oh yeah.  A well designed set of parameters to pass to the
notification worker (assuming you go that way) would pretty much allow
the worker to be modified in the future to support additional,
evolving technologies without modification necessary to the ILS core.
Forgetting exactly how OpenSRF commands are passed/etc., an example
might be as follows:
OpenSRF.NOTCRAP-Notify(-1,-1,1,1,1,181289,462154,0,0,0,0,<null>).
Field Explanations:
#01: Override contact method--If -1, use setting from patron record.
Otherwise, use method specified by number.
#02: Delay length(minutes) from receipt of all message parts:
-1==Policy Defaults, 0==now
#03: Message number (of sequence for this patron)--For when multiple
messages are to be included for a single patron, this will allow batch
messaging instead of several individual messages
#04: Number of messages in sequence
#05: Message type (IE: "1"=overdue,"2"=held item, etc.).
#06: Patron Control Number
#07: Item Control Number (-1==Misc)
#08-#11: Option-specific fields (IE: fine amount, type of fee,
held-until date, etc)
#12: Staff-entered free-text message (in addition to policy text)

> Hmm...  It's not a server-side notification thing, but a feed-based or
> RESTful infrastructure for events is a very interesting idea.  Like an
> iCal generator for a patron's current checkouts, perhaps?
--LibraryELF perhaps? At least it gets your name/URL out there in
another place! ;)

>
> > Josh
> >
> >
> >
>
>
> --
> Mike Rylander
> mrylander at gmail.com
> GPLS -- PINES Development
> Database Developer
> http://open-ils.org
>
--Don