Busy Time not updated after reschedule meeting

HCL Domino Domino Forum
1

We are editing the meeting from agent

When meeting gets booked, lets say 10:00 AM - 11:00 AM. Now reschedule this meeting to 10:00 AM - 10:30 AM, Book a new meeting from 10:30 AM - 11:30 AM. This new meeting gets declined automatically.

After rescheduling the first meeting, when Free availability time gets checked from notes, it shows 10:00 AM 11:00 AM instead 10:00 AM - 10:30 AM i.e. room is unavailable so it gets declined but it is available from the resource calendar.

When meeting gets edited from the notes, it works fine so i don’t think that ACL is the issue over here.

We have tried the following options to update busy time but the issue still remains.

Call doc.REPLACEITEMVALUE(“$BusyPriority”, “2”)

Call doc.REPLACEITEMVALUE(“$CSVersion”, “2”)

Call doc.REPLACEITEMVALUE(“SequenceNum”, “1”)

Call doc.REPLACEITEMVALUE(“$SMTPKeepNotesItems”, “1”)

Call doc.REPLACEITEMVALUE(“$NoPurge”, tempvariant)

Call doc.REPLACEITEMVALUE(“_ViewIcon”, “0”)

Call doc.REPLACEITEMVALUE(“WebDateTimeInit”, “1”)

Call doc.REPLACEITEMVALUE(“CalendarDateTime”, startDateTime)

Call doc.REPLACEITEMVALUE(“$PublicAccess”, “1”)

Call doc.REPLACEITEMVALUE(“BookFreeTime”, “1”)

Call doc.REPLACEITEMVALUE(“Broadcast”, “”)

Call doc.REPLACEITEMVALUE(“IsBroadcast”, “0”)

Call doc.REPLACEITEMVALUE(“Resources”, “”)

Call doc.REPLACEITEMVALUE(“UpdateSeq”, “1”)

Please let me know, if we miss any parameter or configured any wrong parameter?

We have also tried to update busytime with the NoticeType parameter (I,U,A,R,S,P almost every one of them)

This is getting very critical for us, we are on this from last 15 days but no luck till now so your guidance/suggestions are appreciated.

2

Subject: some thoughts

$BusyPriority should be set to “1” to book the time. $BusyName should be on the note with the user’s name in it in canonical format and NoticeType needs to be “A” otherwise busytime won’t think it is an entry on the user’s calendar

3

Subject: Verified! but still issue remains

Thanx for the response…

We tried $BusyPriority to “1” when meeting gets booked. Also verified $BusyName canonical format and NoticeType to “A” but still the same issue remains.

However we observed a behaviour, after we add the following parameters in the notes.ini file:

AMgr_DocUpdateEventDelay=1

Amgr_DocUpdateAgentMinInterval=1

AMgr_NewMailEventDelay=1

AMgr_NewMailAgentMinInterval=1

Schedule_Check_Entries_When_Validating=1

SERVER_TIMESYNC_INTERVAL=1

When we reschedule the first meeting 10:00 AM - 10:30 AM [Original timings 10:00 AM - 11:00 AM], and book the new meeting after 4 mins. i.e. at 10:34 AM than meeting gets booked with the accepted status [its working fine when new meeting gets booked after 4 mins.]

And when the new meeting gets booked in between 10:30 AM to 10:34 AM, it’s booked with the declined status.

So from this behaviour, it looks like BusyTime do gets updated but after 4 or 5 mins later.

Is there any default parameter that is set to 4 or 5 minutes in the notes.ini that causes this behaviour?

4

Subject: More thoughts

One change you need to make to your Agent is to have it increase the SequenceNum value every time you reschedule it. Otherwise workflow will not work because you are not following the C&S schema on how to reschedule a meeting. Reschedule changes mandate you bump SequenceNum. Non-reschedule changes mandate you bump UpdateSeq (and update the $CSWISL item accordingly) In order to modify C&S docs you should make sure you check the C&S Schema ( here ) and follow the rules for item updates outlined there.

Schedule Manager (Sched) only looks at 4 items on a note currently: $BusyName, StartDateTime, EndDateTime and $BusyPriority (Optional). All other items are not looked at so dont focus on them.

The Sched task needs to be running on the users Home Server (according to the Domino Directory record for each user). It will tell the Domino server which databases it wants to be notified of C&S changes in and then wait for Domino to say “Hey, go check out UNID 1234512345 in database mail\foo.nsf”

At that time Sched will open the dB, make sure it is one that Sched should monitor for changes (e.g. it is the right replica on the Home server that matches the user name found in the $BusyName item) and if all the safety checks pass, the users record is updated in busytime. Because the notification mechanism is asynchronous it can take up to ~5 seconds for Sched to be notified of the change and then process it into busytime. Unless your Sched or server is under some extreme CPU load, it should most definitely NOT take minutes.

Is your Agent making the changes on the users Home Server and in their mail file; not in a replica elsewhere on the server or on a server other than their Home Server?

You can enable debug output from Sched by setting DEBUG_SCHEDULE=31 and then restart the Sched task. As it runs it will trace what it is doing and what notes it processes. You should look for the initial db scan text that looks like:

CheckDbForCalendarEvents> Checking database mail\foo.nsf

and then look for the message that Sched has decided to monitor that dB:

CheckDbForCalendarEvents> Setting scheduling event notification to directory manager for database mail\foo.nsf

If you do not see it then you will see some debug text that explains why not (probably something related to the NAB data or a bad profile). Since you have busytime data though I do not expect this to be an issue unless you are looking at the wrong replica.

Once Sched is restarted and you are ready, run the Agent and have it make a simple change like shortening the meeting. Then watch the server console for a message from Sched about processing the update. It will look something like:

ProcessOneAppt> Found valid user John Doe/Acme

followed by more output that shows the entry being added to the busytime cache and then to disk or perhaps some other problem with the changes you made to the doc. This though should be enough to get you moving forward with your work.

Oh one more thing, Sched only updates busytime as described above so if you run the Agent on a local replica, busytime will not be updated until the user replicates back to their Home Server…

Bruce

IBM