Your Java code needs to send mail using Microsoft Exchange Server. Or you need to read email from Microsoft Exchange Server using Java. Or maybe it is the calendars that you are interested in and you are trying to get information from there or trying to sync different calendars? How do you work with the Microsoft Exchange Calendar API in Java?
The classic way of integrating with any kind of software would be to use its API. So, if you are trying to integrate with Microsoft Exchange you are probably trying to find how to use Exchange's API.
APIs change over time - a bit of history of the Microsoft Exchange API
The most common way to integrate from Java to Exchange used to be the Exchange Web Services (EWS). EWS SDK for Java was launched as a part of Microsoft Exchange 2007. It is a SOAP based API, but the thing is that in July 2018 Microsoft announced it would no longer do any feature updates to it. While EWS SDK for Java will continue to receive security updates for a while it makes no sense to start a project using it at the moment.
Another important change is that from October 13th, 2020 support for Basic Authentication in Exchange Web Services (EWS) will stop completely. Microsoft wants everything to move over to OAuth. OAuth is actually a much better option and it is even approved as an International Standard (ISO/IEC). If you have not heard of OAuth, you can check here and then go deeper here. And although it is a move for the better, the fact is that when support for Basic Authentication ends apps will no longer be able to use Basic Authentication when connecting to Exchange using EWS.
So, what now?
If you want to connect to Microsoft Exchange via API from Java and you want to follow Microsoft's recommendations, you should use Microsoft Graph.
Microsoft Graph was built back in 2015 on top of Office 365 and it delegates calls to different Office 365 Cloud services via one single endpoint https://graph.microsoft.com/. It has evolved over time so that it now includes access to other Microsoft products like Exchange.
Within Microsoft Graph you can use Microsoft Graph API or Microsoft Graph data connect. Either way, make sure you first check the Terms of Use. Microsoft is quite specific about what you can and cannot do with their API, so do have a look.
For most cases, Microsoft Graph API is the way to go. We'll see a bit more about it below.
You should consider Microsoft Graph data connect if you need to handle big data or if you need granular consent (the customer will get to review the specific fields and any exclusions which is not possible with the regular API). But there is an important rule that you need to be aware of if you are considering Microsoft Graph data connect: it will only send data from the customer's Office 365 tenant to the associated Azure tenant.
Let's go back to the regular API, as that is the most common option. There are currently 2 versions of Microsoft Graph REST APIs - beta and v1.0. You can have a look at the beta version, but, of course, for any serious development you should stick to the production version 1.0. For that version, you can check the documentation and the Java SDK. Yes, if you are just starting with this API there is a lot of studying involved!...
To then use the API, you will first need to register your app. I know this is not the most exciting first step, but if you are using the API directly, you'll need an Application ID to represent your application in API calls. For this you'll need a work/school account or a Microsoft account and then you can choose between registering using:
• the Microsoft Application Registration Portal
• the Azure Active Directory management portal (recommended for enterprise-class applications)
If your application is a confidential client (a service), you must create a new app password to secure it. After you've registered, an application ID will be created for your app and displayed on your new app's properties page.
Finally, please note that Microsoft Graph is also changing all the time. To get an idea of changes over time (since Dec 2015), you can have a look at the changelog. If you want to work with it, we recommend you always check what the current production version of the API is.
Is there a better way?
If you are not much into:
• Working with Microsoft in the first place
• Having to spend tons of time studying the documentation
• Having to put up with the errors caused by future changes to the Microsoft Graph API
You might be wondering if there is any alternative. Yes, there is a better way!
Instead of using the API directly, you can put a thin layer between you and the API. We call this layer Connect Bridge. This layer was built to be thin enough to have everything fast and efficient, but thick enough so that you never touch Microsoft Exchange or even the Microsoft Graph API.
Connect Bridge is a paid tool, but you can check the Connect Bridge free trial available so you can see if it works for you. The beauty of this tool is that it ensures forward and backward compatibility.
You build your Java code integrating with Connect Bridge, and then your users can upgrade Exchange, Microsoft can launch new versions of the API… and you won't have to worry about it. It does not matter what will come after Microsoft Graph API v1.0. Your solution will still work! You write your code once and then all the complexity is something you simply don't ever have to worry about.
There is no limitation on the environment where you can use this tool. You can run it on
• An Azure-built SaaS platform managed by Connecting software
• On premises or on your own cloud servers or virtual machines (self-hosted)
How does Connect Bridge work? What is it doing behind the scenes? It basically translates standard SQL statements into API calls. On your code it looks like you are accessing a relational database using JDBC (ODBC and Web services are also supported). You write SELECT, INSERT, UPDATE and DELETE statements. You are using what looks like stored procedures. But that is all just a layer of abstraction.
You are not accessing the Microsoft Exchange's database (and trust me, you don't want to do that!). But it looks as if you were. Connect Bridge comes with a Query tool where you can test your (fake) queries, see the (fake) tables with their (fake) columns or even find a convenient (fake) stored procedure. Like I said, it feels exactly as if it were using a SQL database, but it is just an abstraction.
Once you have done all the testing you want, you just put the connection and the queries in your code as if you were using JDBC to connect to a database… and that's all! You now have a working solution that will require zero maintenance. All the maintenance effort is on the side of Connect Bridge. That is why this tool is a paid tool. I think that this is a very clever idea… worth every penny!
It is also good to note that this tool also handles security and authentication, which can take up a considerable amount of time if you are developing from scratch.
Conclusion
We have seen how accessing Microsoft Exchange data in Java can be easily done using the Connect Bridge integration platform.
And there is more good news: this is also possible with Microsoft Dynamics and Microsoft SharePoint! As a matter of fact, you can connect to any Microsoft software, to Salesforce, and to many others. You just need to get Connect Bridge, which is the base integration platform and pick the right connector.
If you want to know what connectors are currently available at Connect Bridge, the place to go is https://www.connecting-software.com/connectors/
If you want to know which are the newest connectors in this vast collection, have a look at Connect Bridges’s Dynamics 365 Finance & Operations and Dynamics 365 Business Central connectors.
It also important to know that there are some ready-made products that use Connect Bridge and that are totally out-of-the-box solutions. For example, CB Exchange Server Sync allows you to choose custom one-way or two-way synchronization of calendars, email folders, tasks, contacts, public folders with no coding at all.
We hope this article was helpful to you! Here are some more posts we have on our blog discussing other integration possibilities: