when I was thinking about possible solutions I set up two restrictions which it should have met
- make it transparent to any schedule (schedule pattern) change (ie. no additional development needed)
- avoid 'brute force' (looping) way of identifying schedule dates (eg. 2nd Tuesday in a month)
so here is what I've came up with.
Conceptually, I decided to utilize native scheduling capabilities of sharepoint's calendar event, especially recurring events.
since patching of serverA is only regularly defined event, I denoted it myself as master event.
patching of all the other servers depend on serverA patching, so I denoted them myself as dependent events.
patching of serverA has clearly defined frequency. but will it always be 2nd Tuesday in a month? so not to make it fix/hardcoded, I will leave it on user decision to define it's schedule. taking into account mission requirements, this can be easily done with sharepoint's calendar recurring event.
as per other servers, their schedule depends on serverA schedule. their schedule is defined as some shift in days to the serverA schedule. again, to make it transperant, I will let user to define this schedule shift.
implementation wise, serverA's schedule (master event) will be recurring calendar list event, other servers schedule shifts will be defined as a property of this master event.
unfortunately, sharepoint doesn't support OOTB schedule that could reoccur based on other event. so this will need little tweaking. I will achieve this with a small workflow.
so let's go through implementation.
I have created patch calendar.
it's standard sharepoint's calendar, I just extended it by one multiline plain text field. it will hold definition of dependent events (repeating section in a form)
then I have customized patch_calendar list form.
I have added a repeating section with two fields. each repeating section row will allow to define one additional dependent event (one additional server). for each dependent event there are defined its title and its shift in days to the master schedule (serverA).
repeating section is connected to DependentEvents list field.
this setup allows freely defined varying number of dependent events (servers) as well as it's relative schedule.
apart from repeating section and its label all the other fields are standard calendar item fields.
at runtime an user defines schedule of all the required servers following way
that is, schedule of serverA is defined directly by an user. this schedule is saved to the calendar item and taken as master schedule.
as already mentioned, schedules for dependent events is going to be created by a small list workflow.
since there is no obvious pattern for these events to setup recurring calendar event (resp. not such a pattern that sharepoint would support), all these will be created as a single events.
here is how does workflow look like
first, let's get master event recurrences
since OOTB Query list item doesn't support recurring event expansion, web service call has to be made to get current item's expanded recurrences
here is whole CAML query
<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:m="http://schemas.microsoft.com/sharepoint/soap/">
<FieldRef Name="ID" />
<FieldRef Name='EventDate' />
<FieldRef Name='EndDate' />
<FieldRef Name='RecurrenceID' />
for my purposes only recurring event start and end dates are interesting, so pick them from returned result
then get definition of dependent events from current item
now I have almost everything I need to create calendar items for dependent events.
it's done within two nested loops - first one loops through all the recurring instances of master event, second one through all the dependent event definitions.
within the inner loop start and end dates of new dependent event are calculated based on master event start and end date and schedule shift definition for dependent event.
finally calendar item is created with these new dates and defined dependent event title. rest of the properties are copied from master event
this how does calendar looks like after workflow is run
excerpt from workflow log