En raison du passage d’EWS à MS Graph, diverses entreprises doivent adapter leurs produits numériques. Dans le premier article, j’ai déjà couvert quelques problèmes que vous pourriez rencontrer lors d’une telle transition vers l’API Microsoft Graph REST v1.0 avec le SDK MS Graph Java. Alors, plongeons directement dans les cas d’utilisation suivants.
Lire toutes les chambres disponibles et les listes de chambres de l’entreprise (l’obtention de plusieurs listes de chambres n’est pas possible)
Dans de nombreuses entreprises, les salles peuvent être réservées automatiquement lors de la création d’un rendez-vous Outlook. Cela est possible car toutes les chambres sont attribuées à une adresse e-mail par l’administration. En ajoutant l’adresse e-mail de la ressource aux participants de l’événement, un processus de réservation est automatiquement déclenché, qui vérifie si la salle est disponible ou non. Il est également possible de créer des listes de chambres, qui ont également leur propre adresse e-mail. Pour cette raison, nous pouvons lancer la vérification de disponibilité pour plusieurs chambres en même temps. Par exemple, une liste de pièces peut représenter un bâtiment.
Dans le cas où votre application d’entreprise doit obtenir toutes les chambres ou listes de chambres pour un locataire. Avec l’API Microsoft Graph REST v1.0, cela peut être fait à l’aide de l’API Places. L’exemple suivant montre comment créer une requête GET en Java pour lire toutes les chambres d’un locataire (HTTP: GET /places/microsoft.graph.room):
GraphService service = getGraphService();
//load available rooms for one tenant
String extendedUrl = service.getGraphServiceClient()
.places()
.getRequestUrlWithAdditionalParameter("microsoft.graph.room");
RoomList roomList = new RoomListRequestBuilder(extendedUrl,service.getGraphServiceClient(),null)
.buildRequest()
.get(); Dans cet exemple, nous créons une URL avec la pièce jointe spécifique « microsoft.graph.room » en premier lieu qui est utilisée pour indiquer à l’API que nous voulons une liste de toutes les chambres du locataire. Ensuite, nous utilisons le générateur de requêtes pour créer et envoyer la requête.
Selon la documentation Microsoft, les listes de salles peuvent également être lues (HTTP: GET /places/microsoft.graph.roomlist). Au lieu d’utiliser la valeur de paramètre « microsoft.graph.room », nous devons utiliser le paramètre « microsoft.graph.roomlist ». Appliquée à l’exemple ci-dessus, l’URL étendue ressemblerait à :
String extendedUrl = service.getGraphServiceClient()
.places()
.getRequestUrlWithAdditionalParameter("microsoft.graph.roomlist");
Cependant, la documentation Microsoft montre clairement que la lecture de plusieurs listes de pièces n’est pas possible via le SDK Microsoft Graph Java. Si vous vérifiez le SDK lui-même, il n’y a pas de générateur de requête correspondant pour créer la requête appropriée. Bien que la documentation indique également d’autres technologies telles que GO, PowerShell ou PHP, cette option de liste de salles est disponible. la documentation souligne que toutes les implémentations sont encore en cours de test et ne doivent pas être utilisées en production.
En fin de compte, dans la version actuelle de Microsoft Graph REST API v1.0, toutes les salles doivent toujours être lues, même si vous n’avez besoin que d’un sous-ensemble de certaines salles.
Lire les instances d’événements récurrents sans date de fin
Il existe différents types de rendez-vous. Fondamentalement, les rendez-vous peuvent être divisés en rendez-vous uniques et en série. Dans Office365, un rendez-vous de série a la structure suivante. Il y a un événement de calendrier pour toute la série. En plus de cela, il y a un événement de calendrier pour chaque instance. Dans EWS, l’événement de la première instance est également l’événement de série pour toute la série. Si vous regardez l’exemple suivant d’un événement de série, lisez via MS Graph :
{
"@odata.context": "https://graph.microsoft.com/v1.0/$metadata#users('dfb7498b-0c85-4386-bfe7-eddssbdd45390ea5')/events/$entity",
"@odata.etag": "W/\"1+bFCkpFZUSj6sPne4wWRgAAjrcaBg==\"",
"id": "AAMkADg4ZTk4NTQ5LTEyMWYtNDg5OSDFSSC1hZjcxLWMzZThhZGIwOTE0ZQBGAAAAAACeiB2A59PoRKo3vfjfoBEBBwDX5sUKSkVlRKPqw_d7jBZGAAAAAAENAADX5sUKSkVlRKPqw_d7jBZGAABuo5X8AAA=",
"createdDateTime": "2022-09-22T04:35:05.4543959Z",
"lastModifiedDateTime": "2022-09-22T04:37:06.4192553Z",
"changeKey": "1+bFCkpFZUSj6sPne4wWRgAAjrcssfaBg==",
"categories": [
],
"transactionId": null,
"originalStartTimeZone": "W. Europe Standard Time",
"originalEndTimeZone": "W. Europe Standard Time",
"iCalUId": "040000008200E00074C5B7101A82E0080000000020D324248C44DCED8010000000000000000100000001FA3A5B1E378134990BBA3383A6A7674",
"reminderMinutesBeforeStart": 15,
"isReminderOn": true,
"hasAttachments": false,
"subject": "title 1",
"bodyPreview": "",
"importance": "normal",
"sensitivity": "normal",
"isAllDay": false,
"isCancelled": false,
"isOrganizer": true,
"responseRequested": true,
"seriesMasterId": null,
"showAs": "busy",
"type": "seriesMaster",
"webLink": "https://outlook.office365.com/owa/?itemid=AAMkADg4ZTk4ADFFSSFFNTQ5LTEyMWYtNDg5OC1hZjcxLWMzZThhZGIwOTE0ZQBGAAAAAACeiB2A59PoRKo3vfjfoBEBBwDX5sUKSkVlRKPqw%2Bd7jBZGAAAAAAENAADX5sUKSkVlRKPqw%2Bd7jBZGAABuo5X8AAA%3D&exvsurl=1&path=/calendar/item",
"onlineMeetingUrl": null,
"isOnlineMeeting": false,
"onlineMeetingProvider": "unknown",
"allowNewTimeProposals": true,
"isDraft": false,
"hideAttendees": false,
"onlineMeeting": null,
"responseStatus": {
"response": "none",
"time": "0001-01-01T00:00:00Z"
},
"body": {
"contentType": "html",
"content": "<html><head><meta http-equiv=\"Content-Type\" content=\"text/html; charset=utf-8\"><meta name=\"ProgId\" content=\"Word.Document\"><meta name=\"Generator\" content=\"Microsoft Word 15\"><meta name=\"Originator\" content=\"Microsoft Word 15\"><style><!--@font-face{font-family:\"Cambria Math\"}@font-face{font-family:Calibri}p.MsoNormal, li.MsoNormal, div.MsoNormal{margin:0cm;font-size:11.0pt;font-family:\"Calibri\",sans-serif}a:link, span.MsoHyperlink{color:#0563C1;text-decoration:underline}a:visited, span.MsoHyperlinkFollowed{color:#954F72;text-decoration:underline}span.EmailStyle17{font-family:\"Calibri\",sans-serif;color:windowtext}.MsoChpDefault{font-family:\"Calibri\",sans-serif}@page WordSection1{margin:70.85pt 70.85pt 2.0cm 70.85pt}div.WordSection1{}--></style></head><body lang=\"DE\" link=\"#0563C1\" vlink=\"#954F72\" style=\"word-wrap:break-word\"><div class=\"WordSection1\"><p class=\"MsoNormal\"> </p></div></body></html>"
},
"start": {
"dateTime": "2022-09-23T12:30:00.0000000",
"timeZone": "UTC"
},
"end": {
"dateTime": "2022-09-23T13:00:00.0000000",
"timeZone": "UTC"
},
"location": {
"displayName": "",
"locationType": "default",
"uniqueIdType": "unknown",
"address": {
},
"coordinates": {
}
},
"locations": [
],
"recurrence": {
"pattern": {
"type": "daily",
"interval": 1,
"month": 0,
"dayOfMonth": 0,
"firstDayOfWeek": "sunday",
"index": "first"
},
"range": {
"type": "noEnd",
"startDate": "2022-09-23",
"endDate": "0001-01-01",
"recurrenceTimeZone": "W. Europe Standard Time",
"numberOfOccurrences": 0
}
]
}
}Un exemple est l’événement de série pour une série d’événements où les dates se répètent quotidiennement et la série n’a pas de fin. Pour les séries qui n’ont pas de date de fin spécifique, Office365 définit toujours une valeur pour la date de fin à chaque fois : « endDate »: « 0001-01-01 ». La valeur est la même pour toutes les séries sans date de fin.
La seule façon de lire toutes les instances d’une série avec Microsoft Graph REST API v1.0 est avec l’API d’instance. Pour l’exemple ci-dessus, l’appel ressemblerait à ceci :
email = "userEmail";
eventID = "ID of the series event";
startDate = "2022-09-23";
endDate = "0001-01-01";
GraphService service = getService();
LinkedList<Option> requestOptions = new LinkedList<>();
requestOptions.add(new HeaderOption("Prefer", "outlook.body-content-type=\"text\""));
requestOptions.add(new QueryOption("startDateTime", startDate));
requestOptions.add(new QueryOption("endDateTime", endDate));
List<Event> instances = service
.getGraphServiceClient()
.users(email)
.events(eventID)
.instances()
.buildRequest(requestOptions)
.expand("attachments")
.get()
.getCurrentPage();L’exemple montre qu’une date de début et une date de fin doivent être définies pour la requête. Le problème ici, la date de fin est antérieure à la date de début, donc la demande n’aboutira pas. Comment pouvons-nous obtenir les instances de la série maintenant ?
En supposant que nous ayons le cas d’utilisation, si la date de fin est égale ou inférieure à la date de début, l’application métier doit lire les 30 prochains événements. En utilisant les informations du modèle de récurrence (recurrencePatternType et date de début), nous pouvons définir la date de fin que nous utiliserons pour la requête via l’API Instance.
En supposant que nous ayons le cas d’utilisation, si la date de fin est égale ou inférieure à la date de début, l’application métier devrait obtenir tous les événements pour les 100 prochains jours. Dans ce cas, nous pouvons facilement définir une méthode de mise à jour :
String update(String numberOfDays, String startDate, String endDate) {
if(LocalDate.parse(endDate).isBefore(LocalDate.parse(startDate)) ||
LocalDate.parse(endDate).isEqual(LocalDate.parse(startDate))){
LocalDate newEndDate = LocalDate.parse(startDate).plusDays(Long.valueOf(numberOfDays));
endDate = newEndDate.toString();
}
return endDate;
}Nous ajoutons simplement le nombre de jours et renvoyons la nouvelle date de fin que nous pouvons utiliser pour la demande via l’API d’instance.
Globalement, il est logique de restreindre l’intervalle de temps pour les séries sans date de fin ; sinon, vous obtiendriez tous les événements du futur en même temps et la charge utile serait trop importante pour être transférée. Ainsi, il y a deux manières possibles de définir la date de fin : vous définissez la nouvelle date par rapport au nombre d’événements que vous souhaitez obtenir, ou vous définissez la nouvelle date par rapport à un nombre de jours précis.
Déterminer l’ID du dernier rendez-vous généré d’un utilisateur
Parfois, il est important de déterminer l’ID du dernier événement généré pour un utilisateur à l’aide d’une requête personnalisée. Considérons ce qui suit…