We noticed that NotificationUpdate Polaris API (PAPI) in Polaris 7.7 functions differently than it did in 7.4 regarding hold notices.
Previously, if you updated hold notices outside the scheduled SQL Hold Notice Processing job time, the API would remove the notice from the queue AND update the patron account to show the notices as delivered. Now, if you’re delivering notices outside the SQL Hold Notices Job processing hours the API removes the notices from the queue without updating the patron account. This is because the NotificationUpdate API now looks for the hold notice in two places whereas previously it only looked for it in one.
That second location is updated by the SQL Hold Notices Job, so as long as your process follows closely after that job finishes, you should be fine. The notices will always get removed from the queue no mater what, but the patron record will only get updated if the notice were in the two places with the 2nd one being populated by when SQL Hold Notices Job runs.
We’re also seeing the you must always use the reporting ord ID of system (orgID #1) in all cases or the patron account won’t be updated. If you use the system orgid in the PAPI update, the patron account will still be updated with the reporting org id in the patron record.
Thanks for sharing this, Wes, it’s good to know about!
I hope you don’t mind a few questions, we’re just strapping in for our own 7.7 rollercoaster ride…
It’s odd that the hold notices job adjusts something, since both notice jobs execute GenerateHoldNotices, and I wouldn’t expect the email mgr or export steps to factor in. Do you know what the specific step or action is that’s different? I’m wondering if it can be worked-around by adding it into the main Notices job…
Also, do you have a sense of how long the time period is after the Hold Notices job that the write-back will update the patron record?
Lastly, am I right in understanding that the Reporting Org ID needs to be #1 only for 1st hold notices? Or does that affect others, as well?
I haven’t had a chance to fully chase this all the way through, but the gist seems to be this:
PAPI_NotificationUpdate now uses Notices_WriteNotificationLog to write the notice history when the update’s ReportingOrgID is not 1. This new stored procedure uses HoldNotices instead of NotificationQueue. It does still join in NotificationQueue though, which I misread during my initial go-over of all this and that’s where the ‘needs data in two places not one’ comes from.
In the previous version, the phone notice history was always written using Notices_WriteNotificationHistoryForTelephony which only uses NotificationQueue. We can still get the update method to call Notices_WriteNotificationHistoryForTelephony in the new version, but only by setting ReportingOrgID to 1.
In theory Notices_WriteNotificationLog should be writing history, assuming the entry exists in HoldNotices, but that seems to not be happening most of the time for a still unknown reason. It does seem to work in some scenarios though, but I’m still unsure of the specifics.
For some reason during my first go through of this I was also mistakenly thinking HoldNotices would be empty during times when the hold job hadn’t ran, which is why we wanted to switch our dialout timing. This obviously isn’t the case but would still be relevant if we ever switched back to using the real ReportingOrgID in the updates since there are potentially gaps in that table for items trapped between hold job runs.
For simplicity I would probably just make it org id #1 always since it seems to put the real reporting org ID in the final record regardless of what it in the API call.
Also, it seemed that this behavior was specific only to the 1st hold notice, but we didn’t have tons of time to pick apart all the nuances.
Thanks for all this added details, Mike, they’re helpful! Under the weather at the moment, but I’ll wrap my head around it when I’m back. Knowing we both use MessageBee, I wonder if they’re already treating some of these changes as part of any Polaris-using customer moving to 7.7…
The problems we were having with notice updates was with our homegrown telephone notification system. So, I wouldn’t infer anything about MessageBee’s processes from this thread.