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

EMu Procedures & Documentation

• 1. How to request a pest check using TASKS• 2. Sample notification• 3. How to complete a pest check using TASKS• 4. How to update pest check status• 5. Pest checks, tasks, holders and parent-child

records• 6. How to check for pending notifications

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 email 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 email and html notifications are generated.

Notifications – how do they work?

• The script checks for all records that satisfy the criteria:– Notify Date = today’s date– Notify field contains at least one user’s party

record

• Then generates the nofications and actions them.

Notifications – how do they work?

• The email message is sent to users in the Notify field.

• The email address used is from the Address tab in the Party record.

• A sample email 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 Notifications”

Notifications – how do they work?

• Can also view notifications for another user, by running the “View Another User’s 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 this

Notifications – Customising

• First Step – change the notify.pl definition to include more fields

• Here’s our current file

Notifications – Customising

• Second step – modify the Task.htm file

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 module’s Task Commence notifications, then for each module’s 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 day’s 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 email doesn’t arrive.

• Logs are found here:– /home/emu/ngatest/logs/notify/

Problems

• Party records – must have EMu User ID and email address entered correctly

• Code errors – one mistake can ruin the whole notification run!

• Version control – work in test, copy across to prod.

Results

• Here’s a sample of our email notification after the customisation

• And here’s a sample of checking mark-emu’s pending notifications via the admin task.

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 email 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 – 6240 6568– deb.hill@nga.gov.au

• Mark Bradley – 6240 6539– mark.bradley@nga.gov.au