jmckay123 Absent Member.
Absent Member.
345 views

Reading all calendar data

I'm still a bit confused about how to retrieve all possible properties from an item. Per your suggestion, I tried setting the version to 1.09 in Logon, and that allowed me to get the missing percentComplete. Now I am reading calendar items. I thought if I specify no view or "all" then I should get everything? For calendar items, I am missing a few critical things. For example I get RRULE but I do not get EXDATE and RDATE which are documented. Also, for meeting events, I need a list of attendees, their response status, and the name of the meeting organizer. Is that information available? Should I be using a higher version #? (I'm testing with GroupWise 2018). Thanks for your help.
Labels (1)
0 Likes
3 Replies
Anonymous_User Absent Member.
Absent Member.

Re: Reading all calendar data

There are multiple databases in the system.
The user has a database.
There are also shared databases.
The shared databases have the attachments, recipients and recipient status.
(The message body is also an attachment.)

For an example:
An item is sent to multiple people on a post office.
An item representing the email is put in a user's database.
In that item, there is a link to a common email.
In the common email, there are links to the message body, attachments,
etc.

When you ask for an item and pass an empty view (or "default"),
you get the contents of the user's mailbox item.

Getting all of the contents of an item, can be resource intensive.
(It can take up to 8 times longer to get all of the email data.)
To help improve the performance of the system, the user is required
to explicitly ask for the attachments.

This is what the Win32 Client does:
It gets a few fields of an item to display for the user.
When the user opens the email, the client gets more information.
When the user clicks on an attachment, the client reads the
attachment data.

In the SOAP call, you have to explicitly ask for the attachment data.
You enter "default" in the view.
You then include other keywords in the view:
"attachments" - return the attachments
"message" - return the message body
"peek" - If included with "message", return the message body, but
don't mark the item as being read.
"recipients" - Return the recipients
"recipientStatus" - Return the status of the recipients in a sent item.

Another case that may be what you are coming up against:
If a field is not set in the data base, the schema element is not
returned. For example, if you don't specify place text on an
appointment, the <place> element is not returned.

If you still have a problem, can you give me an explicit example of
what you set and what you get back? (You will probably need to send
the SOAP requests and responses.)

Thanks.
Preston



>>>


> I'm still a bit confused about how to retrieve all possible properties
> from an item. Per your suggestion, I tried setting the version to 1.09
> in Logon, and that allowed me to get the missing percentComplete. Now I
> am reading calendar items. I thought if I specify no view or "all" then
> I should get everything? For calendar items, I am missing a few
> critical things. For example I get RRULE but I do not get EXDATE and
> RDATE which are documented. Also, for meeting events, I need a list of
> attendees, their response status, and the name of the meeting organizer.
> Is that information available? Should I be using a higher version #?
> (I'm testing with GroupWise 2018). Thanks for your help.


0 Likes
jmckay123 Absent Member.
Absent Member.

Re: Reading all calendar data

Thanks for the clarification. I tried to update my original question (which apparently didn't go through) to note that I had figured out that adding "recipientStatus" to the view does in fact give me the information I was looking for. I'm still trying to figure out if it is possible to get information about recurring event exceptions, specifically a list of deleted dates, and revised date/time for instances. I tried adding both exdate and rdate to the view with no effect. I realize that the stream of instances does in fact include changes to date/time, and deleted instances do not show up, but it is hard to reconcile those to the original instance that they modify, which is necessary to accurately represent the recurring event.
0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: Reading all calendar data

We have a different implementation of recurrence than everybody else.
We don't have a rule that is applied on each new day.
When the appointment / calendar item is created with a rule,
we create all of the items (fan out).
Our various clients have logic to try to present the calendar items
like other implementations.

You can try to collapse the fanned out calendar items on your side
by getting all of the items with the same <recurrenceKey> value.
But, you will have many problems.
Each user that gets the recurrence set will have a different
<recurrenceKey> value.
You can specify a <iCalId> value to uniquely identify the recurrence
set, but I believe there are issues with doing that.
If a recurrence set is modified, there is a new recurrence
set created (with a new <recurrenceKey> value) and the original
set is purged.
It is difficult to determine when an individual item is deleted
from the set. (The only way I know is to track the events that
happen and determine if the item is part of a set. Then, you
have to keep track of the additions and deletions on your side.)

Preston


>>>


> Thanks for the clarification. I tried to update my original question
> (which apparently didn't go through) to note that I had figured out
> that adding "recipientStatus" to the view does in fact give me the
> information I was looking for. I'm still trying to figure out if it is
> possible to get information about recurring event exceptions,
> specifically a list of deleted dates, and revised date/time for
> instances. I tried adding both exdate and rdate to the view with no
> effect. I realize that the stream of instances does in fact include
> changes to date/time, and deleted instances do not show up, but it is
> hard to reconcile those to the original instance that they modify, which
> is necessary to accurately represent the recurring event.


0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.