Pest Management & EMu Notifications Deborah Hill & Mark Bradley

Introduction Business need EMu Procedures & Documentation Notifications Problems Results The Future - What next?

Business Need With a new Quarantine Suite the NGA has stepped up pest-checking procedures Need for the system to identify tasks to be done and track tasks completed, including results. All this data needs to be discoverable and reportable

EMu Procedures & Documentation

1. How to request a pest check using TASKS Sample notification How to complete a pest check using TASKS How to update pest check status Pest checks, tasks, holders and parent-child records How to check for pending notifications 6.

Notifications What Mark will discuss: – What are EMu Notifications? – How do Notifications work? – Shortcomings of default setup – Customising notifications & testing results

Notifications – What are they? EMu Notifications are simple system generated reports that inform users when something requires their attention. They are included in many EMu modules - notably the Loans, Events, Insurance and Movements modules, and any module with a Tasks tab

Notifications – What are they? Examples include: – Loan commencement and completion dates – Event commence/complete – Venue commence/complete – Insurance: Cover notification – Conservation treatment commence/complete and next treatment due.

Notifications – What are they? Specifically we are interested in the Tasks notifications. Task notifications can be run from any module that has a Tasks tab: – We use: Catalogue, Accession Lots, Events, Loans, Conservation, Movements (internal and external) – Not yet used: Insurance, Narratives, Rights, Groups

Notifications – how do they work? EMu automatically generates two types of notification reports: – an message sent to specified users – an html (web) document Both are based on the same data and are generated simultaneously.

Notifications – how do they work? A script called emunotify is included in the off-the-shelf EMu package Our Crontab (system process scheduler) has been created to trigger emunotify at 12:30am Monday through Friday. At this time both the and html notifications are generated.

Notifications – how do they work? The script checks for all records that satisfy the criteria: – Notify Date = todays date – Notify field contains at least one users party record Then generates the nofications and actions them.

Notifications – how do they work? The message is sent to users in the Notify field. The address used is from the Address tab in the Party record. A sample notification

Notifications – how do they work? The html document is created and left in a pigeon hole for later viewing. This pigeon hole is determined by the EMu User ID, as per the Party record To view this, a user goes to Admin Tasks module and chooses View My NotificationsView My Notifications

Notifications – how do they work? Can also view notifications for another user, by running the View Another Users Notifications task. Access to this task can be switched on/off in the Registry.

Notifications – Shortcomings Default format very limited: – one style for Task Notifications across all the modules. – The default just shows Commenced/Completed Date, IRN, Task Description, People Assigned to Task, and Notification Date.

Notifications – Shortcomings Too simplistic Our users want more information: – Summary Data for the record – clarity on which IRN we referred to (as some NGA users insist on using IRN to mean Catalogue record)

Notifications – Solution Solution: Customise the Notification reports. This was not easy. EMu Help has this feature buried deep in the help file.

Notifications – Customising How are these reports built? Rather than just one all-encompassing notification report, each notification is made up of component parts These parts and how they are put together are determined by a script (written in PERL), named notify.pl

Notifications – Customising In our case, notify.pl file is found here: /home/emu/nga/etc/notify/ and /home/emu/ngatest/etc/notify/ For other orgs substitute your environment for nga/ngatest

Notifications – Customising notify.pl looks like thisthis

Notifications – Customising First Step – change the notify.pl definition to include more fields Heres our current filecurrent file

Notifications – Customising Second step – modify the Task.htm fileTask.htm

Notifications – Customising Noticed all tasks across all modules drew on the same notification file, task.htm. This means they all look the same. To get around this problem, made copy of the task.htm file for each relevant module (e.g. cattaskcomm.htm for Catalogue Task Commence)

Notifications – Customising Added in required extra fields, and also expanded field headings: Catalogue Module IRN instead of IRN. Example Also required I edit the notify.pl to point at the new htm file. Example

Notifications – Customising Repeated this for each modules Task Commence notifications, then for each modules Task Complete notifications.

Notifications – Testing The biggest hassle – having to wait until the overnight Crontabs run to see the results. Solution: you can manually run emunotify from a terminal session (back end) Strongly advise you do this from the test environment, and not live or ALL the days notifications will be re-sent.

Notifications – Testing To see which environment you are in, type client at the command line To change environment type client emutest or whatever your environment is named. In our case the command is client ngatest.

Notifications – Testing Check logfiles to see if there are any errors, usually you can tell as expected doesnt arrive. Logs are found here: – /home/emu/ngatest/logs/notify/

Problems Party records – must have EMu User ID and address entered correctly Code errors – one mistake can ruin the whole notification run! Version control – work in test, copy across to prod.

Results Heres a sample of our notification after the customisation notification And heres a sample of checking mark-emus pending notifications via the admin task. pending notifications

Results Less confident emu users now exploring modules they previously avoided Good level of commitment to new process, users are excited to see this level of automation happening. Cuts down on communications Approval from senior management

Future – so what now? Accurate reporting on pest management – to be actioned. Further refining the reports, better layout, include more detail. A stepping stone towards a workflow management system within EMu?

Thanks! If anyone else is interested in exploring these aspects of EMu we are more than happy to share our knowledge. So get in touch! Deborah Hill – – Mark Bradley – –