I've read the blogs on setting up a scheduled subscription that fires more than once a day.
It blows my mind that you actually have to create a separate subscription for each time you want the schedule to fire in one day.
Forget duplicate notifications, how do you handle the resulting duplicate subscriptions (except for the start time) from a subscription management standpoint?
If we created a scheduled subscription for a user that fired once per hour in our Subscription Management interface, when the user returned to maintain that subscription they would see 24 copies of virtually the same subscription (?)
The only solution I see to this is to create a "dummy" subscriber (with the same E-mail address etc...) that corresponds to each actual subscriber. The initial subscription would be assigned the actual user id while the duplicates would get the "dummy" user name. We would have to modify our delete and change subscription logic to delete/re-create all the copies.
Does anyone see a better way?
I think I've come up with a "better" workaround.
I am going to create my own table to track multiple subscription entries that differ only by the time they fire.
There will be a "master" id for the real subscription and related sub id's for the additional subscriptions generated. This will allow multiple different subscriptions in the same class, each with multiple firings per day. There is no longer a need for a separate subscriber id in this scenario.
When the user calls up the edit subscription interface, only the master record will be shown. I still need to manage my table on subscription create/edit/delete. The other trick is instance update, which may wipe out the NS subscription table - if so, I have to delete from my tracking table also.
If there is a better way or patch from Microsoft please let me know...
|||Depending on the volume of notifications and subscribers, you could use Chronicles tables to keep track of the datetime that each subscriber was notified.HTH...
Joe
No comments:
Post a Comment