The calendar service rest api (/api/calendar/events) returns only a subset of the calendar entries visible in the Notes Client. E.g. draft recurring meetings and all tasks do not show up in the calendar service respone. Is this a bug or a feature?
Subject: Re: Calendar service rest api odd behaviour
Tasks are definitely excluded from the /api/calendar/events response. That’s not a bug.
I was able to reproduce the problem with draft recurring meetings. A non-recurring draft meeting is included in the response, but a draft recurring meeting is not. That’s a surprise to me and seems more like a bug.
The REST code uses a lower level library to read the list of calendar events. I’ll contact the colleague who owns the library to see if I can get a more definitive answer.
Thanks.
– Dave
Subject: another case of strange behaviour
To my surprise the calendar api does not seem to have a documented method to create meeting invitations and so I checked, how they can be accessed. New meeting invitations created from the Notes Client show up in the /api/calendar/events response with a noticetype block, indicating that they are notices instead of regular event types:
“x-lotus-noticetype”: { “data”:“I” },
If I try to access this notice via event-ID (/api/calendar/events/{id}), a com.ibm.domino.calendar.store.StoreException: Error reading event is returned, though (/api/calendar/notices/{id} works).
If I post an event message with this noticetype, this message is accepted by the server, however, it does not create a meeting invitation (as I hoped for) but creates a regular appointment of apptype 0 (without attendees) and not of apptype 3 as I requested. All this is quite confusing, isn’t it?
Subject: Implicit scheduling
When using the REST calendar API, you don’t explicitly create a notification. Instead, you create (or otherwise operate on) a meeting and the API sends out any implied notices. For example, if you create a meeting with one attendee, the API puts the meeting on the organizer’s calendar and sends an invitation to the attendee. If you then delete the meeting, the API removes the meeting from the organizer’s calendar and sends a cancel notice.
See below for some more details. I hope this helps.
– Dave
Create a Meeting in JSON Format
To create a meeting you POST an event to the events resource (/{database}/api/calendar/events). You must include a Content-Type header and a request body. When using JSON, set Content-Type to application/json. Here’s the minimum JSON payload for a meeting with one attendee:
{
“events”: [
{
“summary”: “Test meeting (JSON)”,
“location”: “test location”,
“description”: “test description”,
“start”: {
“date”: “2017-07-13”,
“time”: “13:00:00”,
“utc”: true
},
“end”: {
“date”: “2017-07-13”,
“time”: “14:00:00”,
“utc”: true
},
“attendees”: [
{
“role”: “req-participant”,
“status”: “needs-action”,
“rsvp”: true,
“email”: “DeanMelnyk@acme.com”
}
],
“organizer”: {
“email”: “DukeLawson@acme.com”
}
}
]
}
One important caveat: The organizer property must match the owner of the database as specified in the request URL (/{database}/api/calendar/events). In this case, DukeLawson@acme.com is the Internat email address of the owner.
Create a Meeting in iCalendar Format
You can also create a meeting in iCalendar format. You still POST the event to the events resource, but the Content-Type header should be text/calendar. Here is the the minimum iCalendar payload for a meeting with one attendee:
BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//My Client//0.0.1//EN
BEGIN:VEVENT
DTSTART:20170713T130000Z
DTEND:20170713T140000Z
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION
;RSVP=TRUE:mailto:DeanMelnyk@acme.com mailto:DeanMelnyk@acme.com
DESCRIPTION:test description
SUMMARY:Test meeting (iCalendar)
LOCATION:test location
ORGANIZER:mailto:DukeLawson@acme.com mailto:DukeLawson@acme.com
END:VEVENT
END:VCALENDAR
Again the ORGANIZER property must match the owner of the database.
Subject: out-of-the-box preferred
Thanks Dave,
my customer considers custom Domino code as a last resort only, so I guess I’ll have to stick either with a data service enabled mail template or even enabling fulltext indices on all the mailfiles and using /api/data/documents with search query.
Thomas
Subject: external system
Dave, I have to integrate Domino into an external system with a calendar and meeting scheduling system of its own. If a meeting is scheduled in that external system, the meeting definition remains external, only the meeting invatations need to be sent do Domino, if a Notes mail user is among the meeting participants. We wanted to use the REST API to send these invitations instead of mails. That’s why a separate method in the REST API to post meeting invitations would be nice.
Subject: I don’t think you need the calendar API for that use case …
In any case, that’s not what the REST calendar API was designed to do. Why not just send a MIME message with an iCalendar (text/calendar) part? Notes/Domino has supported incoming iCalendar messages for several releases.
Thanks.
– Dave
Subject: Recommended way to access tasks
Thanks Dave,
if the calendar service does not return tasks, what could be the recommended way to access them? The data service returning the task view content?
Thomas
Subject: Re: Recommended way to access tasks
Yes. You could certainly use the data service to access the tasks view. One caveat is you would have to enable the data service for both the database (the mail file) and the tasks view. That is commonly done in a custom mail file design. All mail files that inherit from the design will then allow access through the data service.
Of course, there are other ways to access the tasks view over HTTP. For example, you could create a web agent or implement a REST service in XPages. There are other options too, but all require server-side programming. The data service is the only option that works out-of-the-box.
– Dave
Subject: several reasons
Dave, I wanted to avoid mail invitations because that would be a second interface to configure besides the REST API and this would mean considerable overhead. Besides that security for the REST API is easier to establish with https calls than sending encrypted mail messages.
I have no idea who defined the specs for the calendar service REST API at IBM, but a method to post meeting invations for a calendar service doesn’t sound like an extraordinary requirement to me.
Thomas