Can anyone confirm that repeating meeting entries will result in the creation of 1 parent document and 1 response document? We have some modifications to the mail template for Rooms and Resources that looks at the repeating entries, but sometimes we have failures as the code cannot find any responses for the parent. Our code was placed within the Postsave event, so we assume the responses have already been created? This appears to be intermittent with some users never having the issue.
Should we put some delay in our code to ensure that responses have been created on less powerful machines? Does anyone have any experience with modifications to mail template that relies on this type of functionality?
We’re updating it, but this has an explanation of repeating meetings that is valid
In brief, the parent document never shows on the calendar, only the child documents do (look for the CalendarDateTime field on those). You will get one response for every unbroken instance of a repeater, but once an instance in the middle is edited, the single response doc is split as needed. ALL instances are tied by matching APPTUNID fields. The schema should help explain this.
The room reservations do not follow this parent/child system once they make it into the Resource database - you will get once document per instance there. Your RnRMGR task will handle any changes.
Subject: Thank you, but not quite what I was looking for …
Thanks Susan, I’ve downloaded this previously and reviewed it at length. I am pretty sure I understand how things are supposed to happen. My question was more about the when and at what stages does the actual creation of the responses take place and if there are any exceptions to this.
My code failure suggests to me that I have a timing issue when trying to process the parent document to find all the subsequent responses (using docThis.Responses) in the Postsave event. I am assuming all activities have completed at this stage (including the creation of new responses) and to avoid damaging any standard calendar functionality we use this method to work on only saved documents. For the most part it works, but in a user base of 2500+ we have enough failures to warrant a fix.
An approach to this was to put a small delay (via Sleep) into the code to allow the finalisation of the response creation to take place. Anyone got any other suggestions or thoughts?
The initial creation of the parent and response doc is almost immediate - that’s the only way it shows up on the calendar immediately. In testing a few documents, the most time difference I see is 1 second. Granted, that 1 second could cause your code a problem. Not sure what approach is best to deal with that tho.
Depending on how you are trying to find the children, it could be that the data you are looking at is stale. That is if you are scanning a view, its contents may not have been refreshed yet.
Im not a Template Guru so I do not quite know what approach you are taking in the template to find and identify the children and if there are any other caveats. However I have heard of others using outdated info some times which could be what you are seeing.
As for how to deal with it, I do not have any great template solutions to offer because I do most of my work outside the template. Given you are running only during the PostSave event I do not know if there is much you can do unless you also try checking again before the doc is closed.