Votre code Java doit permettre d'envoyer du courrier en utilisant le serveur Microsoft Exchange. Ou vous devez lire le courrier électronique à partir du serveur Microsoft Exchange en utilisant Java. Ou peut-être est-ce les calendriers qui vous intéressent et vous essayez d'obtenir des informations à partir de là ou vous essayez de synchroniser différents calendriers ? Comment travailler avec l'API de calendrier de Microsoft Exchange en Java ?
La méthode classique d'intégration d'un logiciel, quel qu'il soit, consiste à utiliser son API. Ainsi, si vous tentez de vous intégrer à Microsoft Exchange, vous essayez probablement de trouver comment utiliser l'API de Exchange.
Les API évoluent avec le temps - un peu d'histoire de l'API Exchange de Microsoft
La façon la plus courante d'intégrer Java à Exchange était auparavant les services Web Exchange (EWS). EWS SDK for Java was lancé dans le cadre de Microsoft Exchange 2007. Il s'agit d'une API basée sur SOAP, mais le fait est qu'en juillet 2018, Microsoft a annoncé qu'il ne ferait plus de mises à jour de ses fonctionnalités. Bien que le SDK EWS for Java will continue de recevoir des mises à jour de sécurité pendant un certain temps, il n'est pas logique de lancer un projet l'utilisant pour le moment.
Un autre changement important est qu'à partir du 13 octobre 2020, le soutien à l'authentification de base dans les services Web Exchange (EWS) cessera complètement. Microsoft veut que tout passe à l'OAuth. L'OAuth est en fait une bien meilleure option et c'est even approved comme norme internationale (ISO/IEC). Si vous n'avez pas entendu parler de l'OAuth, vous pouvez consulter ici et ensuite approfondir ici. Et bien que ce soit une amélioration, le fait est que lorsque la prise en charge de l'authentification de base sera terminée, les applications ne pourront plus utiliser l'authentification de base pour se connecter à Exchange à l'aide du système d'alerte précoce.
Et maintenant ?
Si vous souhaitez vous connecter à Microsoft Exchange via l'API à partir de Java et que vous voulez suivre les recommandations de Microsoft, vous devez utiliser Microsoft Graph.
Microsoft Graph a été construit en 2015 en plus de Office 365 et il délègue les appels à différents services Office 365 Cloud via un seul endpointhttps://graph.microsoft.com/. Il a évolué au fil du temps, de sorte qu'il comprend maintenant l'accès à d'autres produits Microsoft comme Exchange.
Dans Microsoft Graph, vous pouvez utiliser l'API Microsoft Graph ou Microsoft Graph data connect. Dans les deux cas, assurez-vous d'abord de vérifier la Conditions d'utilisation. Microsoft est très précis sur ce que vous pouvez et ne pouvez pas faire avec leur API, alors jetez un coup d'œil.
Dans la plupart des cas, l'API graphique de Microsoft est la meilleure solution. Nous en verrons un peu plus ci-dessous.
Vous devriez envisager Microsoft Graph data connect si vous avez besoin de traiter des données volumineuses ou si vous avez besoin d'un consentement granulaire (le client pourra examiner les champs spécifiques et les exclusions éventuelles, ce qui n'est pas possible avec l'API ordinaire). Mais il y a une règle importante que vous devez connaître si vous envisagez d'utiliser Microsoft Graph data connect : il n'enverra des données que du locataire Office 365 du client au locataire Azure associé.
Revenons à l'API ordinaire, car c'est l'option la plus courante. Il existe actuellement 2 versions des API REST Microsoft Graph - beta et v1.0.Vous pouvez jeter un coup d'œil à la version bêtamais, bien sûr, pour tout développement sérieux, vous devez vous en tenir à la version de production 1.0. Pour cette version, vous pouvez consulter le documentation et le SDK Java. Oui, si vous débutez avec cette API, il y a beaucoup d'études à faire !...
Pour utiliser l'API, vous devez d'abord enregistrer votre application. Je sais que ce n'est pas la première étape la plus excitante, mais si vous utilisez directement l'API, vous aurez besoin d'un identifiant d'application pour représenter votre application dans les appels API. Pour cela, vous aurez besoin d'un compte professionnel/école ou d'un compte Microsoft, puis vous pourrez choisir de vous enregistrer en utilisant :
- le portail d'enregistrement des applications Microsoft
- le portail de gestion Azure Active Directory (recommandé pour les applications de classe entreprise)
Si votre application est un client confidentiel (un service), vous devez créer un nouveau mot de passe d'application pour la sécuriser. Après votre inscription, un ID d'application sera créé pour votre application et affiché sur la page des propriétés de votre nouvelle application.
Enfin, veuillez noter que Microsoft Graph change également tout le temps. Pour avoir une idée de l'évolution dans le temps (depuis décembre 2015), vous pouvez consulter le changelog. Si vous souhaitez l'utiliser, nous vous recommandons de toujours vérifier quelle est la version de production actuelle de l'API.
Y a-t-il une meilleure solution ?
Si vous n'êtes pas très enthousiaste :
- Travailler avec Microsoft en premier lieu
- Le fait de devoir passer des tonnes de temps à étudier la documentation
- Devoir supporter les erreurs causées par les futures modifications de l'API graphique de Microsoft
Vous vous demandez peut-être s'il existe une alternative. Oui, il y a une meilleure solution !
Au lieu d'utiliser l'API directement, vous pouvez mettre une fine couche entre vous et l'API. Nous appelons cette couche Connect Bridge. Cette couche a été conçue pour être suffisamment fine pour que tout soit rapide et efficace, mais suffisamment épaisse pour que vous ne touchiez jamais à Microsoft Exchange ou même à l'API Microsoft Graph.
Connect Bridge est un outil payant, mais vous pouvez vérifier le Connect Bridge essai gratuit disponibles pour que vous puissiez voir si cela fonctionne pour vous. La beauté de cet outil est qu'il assure une compatibilité en amont et en aval.
Vous construisez votre code Java en l'intégrant à Connect Bridge, puis vos utilisateurs peuvent mettre à niveau Exchange, Microsoft peut lancer de nouvelles versions de l'API... et vous n'aurez plus à vous en soucier. Peu importe ce qui viendra après Microsoft Graph API v1.0. Votre solution fonctionnera toujours ! Vous écrivez votre code une seule fois et vous n'avez plus à vous soucier de toute cette complexité.
Il n'y a pas de limite à l'environnement dans lequel vous pouvez utiliser cet outil. Vous pouvez l'exécuter sur
- Une plate-forme SaaS construite en azur et gérée par le logiciel Connecting
- Dans vos locaux ou sur vos propres serveurs en nuage ou machines virtuelles (auto-hébergés)
Comment fonctionne le Connect Bridge ? Que fait-il en coulisses ? Il traduit essentiellement des instructions SQL standard en appels d'API. Sur votre code, il semble que vous accédiez à une base de données relationnelle en utilisant JDBC (ODBC et les services Web sont également pris en charge). Vous écrivez les instructions SELECT, INSERT, UPDATE et DELETE. Vous utilisez ce qui ressemble à des procédures stockées. Mais tout cela n'est qu'une couche d'abstraction.
Vous n'accédez pas à la base de données de la Microsoft Exchange (et croyez-moi, vous ne voulez pas le faire !). Mais c'est comme si vous le faisiez. Connect Bridge est livré avec un outil de requête où vous pouvez tester vos (fausses) requêtes, voir les (fausses) tables avec leurs (fausses) colonnes ou même trouver une (fausse) procédure stockée pratique. Comme je l'ai dit, on a exactement l'impression d'utiliser une base de données SQL, mais ce n'est qu'une abstraction.
Une fois que vous avez effectué tous les tests que vous souhaitez, il vous suffit de placer la connexion et les requêtes dans votre code comme si vous utilisiez JDBC pour vous connecter à une base de données... et c'est tout ! Vous disposez maintenant d'une solution fonctionnelle qui ne nécessitera aucune maintenance. Tout l'effort de maintenance est du côté de Connect Bridge. C'est pourquoi cet outil est payant. Je pense que c'est une idée très intelligente... qui vaut chaque centime !
Il est également bon de noter que cet outil gère également la sécurité et l'authentification, ce qui peut prendre beaucoup de temps si vous développez à partir de zéro.
Conclusion
Nous avons vu comment l'accès aux données Microsoft Exchange en Java peut être facilement réalisé en utilisant la plate-forme d'intégration Connect Bridge.
Et il y a une autre bonne nouvelle : c'est également possible avec Microsoft Dynamics et Microsoft SharePoint ! En fait, vous pouvez vous connecter à n'importe quel logiciel Microsoft, à Salesforce et à bien d'autres encore. Il vous suffit de vous procurer Connect Bridge, qui est la plate-forme d'intégration de base, et de choisir le bon connecteur.
Si vous voulez savoir quels sont les connecteurs actuellement disponibles sur Connect Bridge, vous pouvez vous adresser à https://www.connecting-software.com/connectors/
Si vous voulez savoir quels sont les plus récents connecteurs de cette vaste collection, jetez un coup d'œil aux Connect Bridges Dynamics 365 Finances et opérations et Dynamics 365 Business Central connecteurs.
Il est également important de savoir qu'il existe des produits prêts à l'emploi qui utilisent le Connect Bridge et qui sont des solutions totalement prêtes à l'emploi. Par exemple, CB Exchange Server Sync vous permet de choisir une synchronisation personnalisée, dans un sens ou dans les deux sens, des calendriers, des dossiers de courrier électronique, des tâches, des contacts, des dossiers publics, sans aucun codage.
Nous espérons que cet article vous a été utile ! Voici d'autres articles que nous avons publiés sur notre blog pour discuter d'autres possibilités d'intégration :