Evergreen DokuWiki

User Tools

Site Tools

You are here: start » evergreen-user » action_trigger
evergreen-user:action_trigger

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
evergreen-user:action_trigger [2009/12/07 17:11] – ericksonevergreen-user:action_trigger [2022/02/10 13:34] (current) – external edit 127.0.0.1
Line 57: Line 57:
 == Processing Delay == == Processing Delay ==
  
-This value defines the amount of time the system should wait after a target object becomes "relevant" before reacting on that target object.  Some examples will help here:+This value defines the amount of time the system should wait after a target object becomes "relevant" before reacting on that target object.  This value is stored in the database as an interval data-type, use compatible input formats.  Some examples will help here:
  
   * Overdue notices use the "checkout.due" hook.  An item is technically due the second the due date hits.  It is at that point the circulation becomes relevant in the context of the checkout.due hook.  The goal for this type of notice, though, is to react 7 days **after** the item becomes relevant, i.e. 7 days past due (aka overdue).  Note, for interval fields, you can use English text like "7 days", "3 months", etc.   * Overdue notices use the "checkout.due" hook.  An item is technically due the second the due date hits.  It is at that point the circulation becomes relevant in the context of the checkout.due hook.  The goal for this type of notice, though, is to react 7 days **after** the item becomes relevant, i.e. 7 days past due (aka overdue).  Note, for interval fields, you can use English text like "7 days", "3 months", etc.
Line 66: Line 66:
 == Processing Delay Context Field == == Processing Delay Context Field ==
  
-This is the field on the target object that defines the time stamp to use as the base time for determining if the target object falls within the configured processing delay.  +This is the field on the target object that defines the time stamp to use as the base time for calculating the time since the target became relevant or, in the case of looking into the future, the time **until** the target becomes relevant.  This value is used to determine if a given target falls within the configured processing delay.   
 + 
 +For checkout.due, the delay context field is the due date.  With a 7-day notice, we add 7 days to the due_date to determine if the item is in fact 7 days overdue.  For hold.available, the delay field is shelf_time.  With a 1-hour delay, the system just adds 1 hour to the shelf_time value to determine if the system has waited long enough before sending the notice.   
 + 
 +The field name maps to a <field> entry in the IDL for the target object's class.  The field must be a date/time field.
  
 == Processing Group Context Field == == Processing Group Context Field ==
 +
 +This field is used to group events so they can be reacted upon en masse.  The most common example of this is to group by the user field on the target object so that a patron, for example, will only receive 1 email for all items that are 7 days overdue and not 1 per item.  
 +
 +The field name maps to a <field> entry in the IDL for the target object's class.  
 +
 == Validator == == Validator ==
 +
 +The validator module to use.  To create a custom validator add code/modules to the ''OpenILS::Application::Trigger::Validator'' package and create an entry for this new code in the list of Validators.
 +
 == Reactor == == Reactor ==
 +
 +The reactor module to use.
 +
 == Failure Cleanup == == Failure Cleanup ==
 +
 +The failure cleanup module to use (optional)
 +
 == Success Cleanup == == Success Cleanup ==
 +
 +The success cleanup module to use (optional)
 +
 == Granularity == == Granularity ==
 +
 +A string used to distinguish among events that should be run (by the action_trigger_runner.pl script) at different times.
 +
 +If a site is busy or large enough that all the events typically run overnight won't be able to finish by morning if they're all run in a big lump, or if you have some events that you don't even need to run every night, you can use the granularity field (and the --granularity and --granularity-only options of action_trigger_runner.pl) to group events and selectively run them.
 +
 == Max Event Validity Delay == == Max Event Validity Delay ==
 == Opt-In Setting Type == == Opt-In Setting Type ==
Line 79: Line 105:
 == Template == == Template ==
  
 +A [[http://template-toolkit.org/|template toolkit]] input document, data are specified using the Event Environment and Event Parameters options for the event definition.  This template is used, for example, by the SendEmail reactor.
 +
 +<code>
 +[% USE date %]
 +[% USE Dumper %]
 +[% SET user = target.0.usr %]
 +To: [%- user.email -%]
 +From: 
 +Subject: Item Due Reminder
 +
 +Dear [% user.first_given_name %]
 + 
 +[% FOR circ IN target %]
 +   Title: [%- circ.target_copy.call_number.record.simple_record.title -%]
 +   Barcode: [% circ.target_copy.barcode %]
 +   Due: [% circ.due_date %]
 +[% END %]
 +
 +[% Dumper.dump(target) %]
 +</code>
 +
 +== Event Environment ==
 +
 +Controls which data are available when processing this trigger (Validator, Reactor, Cleanup).  Many trigger definitions include //usr//, //target_copy//, //pickup_lib// or //target_copy.call_number.record.simple_record//.  The Event Environment values are paths to objects in the system.  This data is stored in action_trigger.environment, bound to action_trigger.event_definition via event_def.
 +
 +== Event Parameters ==
 +
 +This allows one to define key/value type data which becomes available during the processing of the trigger (Validator, Reactor).  These options may be useful when creating custom validators for example.  The Parameter Name can match ///[\w,\-\.]+///, but just ///\w+/// is more practical.  The Parameter Value is eval'd on the server side, so they must be stored as valid Perl values.  For strings, wrap them in quotes.  This data is stored in action_trigger.event_params, also bound by event_def.
 +
 +===== Processing Action Triggers =====
 +
 +When events occur records are created in the action_trigger.event table and these events are processed by the action_trigger_runner.pl script.  Usually as a set of cron tasks for the opensrf user.
 +
 +<code>
 +# General A/T
 +*/2 * * * * action_trigger_runner.pl --process-hooks --run-pending
 +
 +# Run Specific Granularity Only
 +20 20 * * * action_trigger_runner.pl --run-pending --granularity Daily-Active-Report --granularity-only
 +
 +# Just do these hooks
 +21 21 * * * action_trigger_runner.pl --run-pending --hooks=checkout
 +
 +# Example with Wrapper
 +4 4 * * * /openils/cron/daily-overdue.sh
 +</code>
 +
 +It's not uncommon to have dozens of entries in the crontab for Evergreen.  One may also want to create create wrapper shell scripts for the action_trigger_runner script to permit in-line documentation or other features.  Here is an example.
 +
 +<code>
 +#!/bin/bash
 +# I'm some documentation on this script!
 +# Run holds available, only the daily-hold granularity
 +
 +/openils/bin/action_trigger_runner.pl \
 +  --debug-stdout \
 +  --verbose \
 +  --run-pending \
 +  --hooks=hold.available \
 +  --granularity=Daily-Hold \
 +  --granularity-only \
 +  >/var/log/atr.log \
 +  2>/var/log/atr.log
 +
 +logger --id --tag atr "Action Trigger Runner for Daily Available Holds Done" 
 +</code>
  
evergreen-user/action_trigger.1260223897.txt.gz · Last modified: 2022/02/10 13:33 (external edit)
Except where otherwise noted, content on this wiki is licensed under the following license: CC Attribution-Share Alike 4.0 International
CC Attribution-Share Alike 4.0 International Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki

© 2008-2022 GPLS and others. Evergreen is open source software, freely licensed under GNU GPLv2 or later.
The Evergreen Project is a U.S. 501(c)3 non-profit organization.