Have you ever considered connecting to Microsoft Dynamics from your Java code? Yes, I know… you'd rather stay away from anything Microsoft… But what if you could get the data from Microsoft Dynamics (or even to Microsoft Dynamics) without getting your hands dirty?
What are my options?
The classic way of integrating with any kind of software would be to use its API. If you want to use the Microsoft Dynamics API, you have, in fact, two options. Both are REST APIs and if you ever need to look them up, make sure to look for “Microsoft Customer Engagement REST API". Microsoft is now using the term "Customer Engagement" for anything relating to Dynamics.
Getting back to your options, if you are looking for the Microsoft Dynamics API, these are:
• Web API
• Online Management API
Web API would be the natural choice of API for most cases. It implements OData (Open Data Protocol) and supports Dynamics 365 (both online and on-premises), Dynamics CRM 2016 and Dynamics CRM Online. The version of OData used is version 4.0, and using OData is a big plus.
If you have not heard of OData, you can start here and then go deeper here. And if you are not sure about the advantages of OData, I will just say it is approved as an International Standard (ISO/IEC). To use this API, you would probably use either SDL OData Frameworks or Apache Olingo, as these as the Java libraries that support OData V4.
The second option, the Online Management API is specifically meant for instance-related tasks. You can perform various tasks on the online instances in your Office 365 tenant such as create, retrieve, delete, backup and restore an instance. This a specific use API, not something you would use in a generic integration scenario.
An alternative to the classic API integration with Web API and/or Online Management API would be to try a no code / low code solution. It would be possible to use PowerApps and create an application that would connect to Microsoft Dynamics. However, this approach doesn't make much sense for a developer… after all you CAN code, why would you try to avoid it?
If you go with PowerApps you have the major drawback of being stuck to the templates that are defined. And you will also end up with an application that is totally useless when offline and that will not really handle any tricky parts like security. I think these are limitations that you would only put up with if you could not code.
The danger zone - could integrating with Microsoft Dynamics work against me?
Let's say you go with the classic API integration. The first thing you need to be aware is that there will be lots of studying involved. The basic API documentation can be found at https://docs.microsoft.com/en-us/dynamics365/customer-engagement/web-api/about?view=dynamics-ce-odata-9.
If you need to work with previous versions of Dynamics (before 9.x) then you need to study https://docs.microsoft.com/en-us/previous-versions/dynamicscrm-2016/developers-guide/mt607689(v=crm.8).
In short, there is a lot of documentation you need to get your head around. It is not super difficult to get started, but it is more so if you are working on a real-life application. Make sure you have the time for it if this is the path you choose.
But the real danger are the updates. The product lifecycle in Dynamics moves fast! If you look at the past 10 years, this what you get (for more details have a look at (for more details have a look at https://docs.microsoft.com/en-gb/previous-versions/dynamics/ for the older versions or https://community.dynamics.com/p/products for current ones):
• Dynamics 365 for Finance and Operations
• Microsoft Dynamics AX 2012
• Dynamics 365 for Sales
• Dynamics 365 for Customer Service
• Dynamics 365 for Field Service
• Dynamics CRM 2016
• Dynamics CRM 2015
• Dynamics CRM 2013
• Dynamics CRM 2011
• Dynamics 365 Business Central
• Dynamics NAV 2016
• Dynamics NAV 2015
• Dynamics NAV 2013 R2
• Dynamics NAV 2013
• Dynamics NAV 2009 R2
• Dynamics NAV 2009
Unified Service Desk
Management Reporter for Microsoft Dynamics ERP
Microsoft Dynamics Business Analyzer
Microsoft Dynamics Marketing
In short, in the past if you were talking to Dynamics API you would have had to consider the Microsoft Dynamics CRM API (2016, 2015, 2013, 2011, 4.0), the Microsoft Dynamics GP API, the Microsoft Dynamics AX API (2012/2009), …
You can only imagine what the next 10 years will bring us!... Now let's say you build your Java integration with Dynamics today. How many man-hours will you need to keep that integration up to date for the next 10 years? Every time a new version is launched, you will need to study the API changes and go back to your code to make the necessary changes.
All this back-and-forth is time consuming and error prone. And, let's face it… plain boring! There is nothing exciting about making an integration work and it is even less exciting to keep it working in the future.
The safe zone - could integrating with Microsoft Dynamics work for me?
Is there a better way of doing this integration of Microsoft Dynamics in Java then? The solution is to get an integration tool between you (and your Java code) and the API. The tool we suggest is Connect Bridge.
This is a paid tool, but it does have a 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 built your Java code integrating with it, and then your users can upgrade (or even downgrade if that ever is the case) and you don't have to worry about it. Microsoft can also launch new versions of the API, reorganize all their Dynamics solutions or do whatever they want… Your solution will still do what it was meant to do with zero effort on your side!
How does this work? Connect Bridge basically translates SQL statements into API calls. You are writing your Java code as if you were accessing a relational database using JDBC (ODBC and Web services are also supported). You are using SELECT, INSERT, UPDATE and DELETE statements. You are using stored procedures. But that is all just a layer of abstraction.
You are not accessing the database of Dynamics (and that is a good thing!). But it looks as if you are. Connect Bridge comes with a Query tool where you can test your (fake) queries, see the (fake) tables with their (fake) columns and find a convenient (fake) stored procedure. Like I said, it looks exactly as if you are looking at a SQL database, but it is just an abstraction. And after you are done with testing, you just put everything in your code as if you were using JDBC to connect to a database… et voilá! A working solution that will require zero maintenance. All the maintenance effort is on the side of Connect Bridge. That is why it is a paid tool and that is why it is worth every penny!
It is important to note that this works for reading data out of Dynamics but also for putting data in there. For putting data in, you use INSERT or UPDATE statements or one of the available stored procedures. And although it will look scary the first time you do it because it feels as if you are actually touching the Dynamics database, you just have to remember that you are always going through the API, so you are on safe ground.
We have seen how accessing Microsoft Dynamics data in Java can be easily done using the Connect Bridge integration platform. The good news is that this is also possible with Microsoft Exchange and Microsoft SharePoint! In fact, you can connect to any software of the Microsoft ecosystem, to Salesforce, and to many others:
• SharePoint 2010, 2013, 2016, 2019, Online
• Office 365
• Exchange Server 2003, 2007, 2010 SP1, 2013, 2016, 2019, Exchange Online
• Active Directory
• Excel, Word, PowerPoint
• Teams, Planner
You just need to have Connect Bridge, which is the base integration platform and pick the connector for the specific software you want.
If you want to explore the connectors currently available at Connect Bridge, the place to go is https://test.connecting-software.com/connect-bridge-connectors/.
An interesting additional option you have in Connect Bridge is the smart sealing of documents. There is an add-on that uses blockchain technology to seal documents in Dynamics. It gives you the highest security level, guaranteeing the document has not been tampered with, but the fact that uses distributed ledgers in a clever way makes it far more cost-effective. And it can also work with documents that are stored elsewhere, for instance in SharePoint.
We hope this article was helpful to you! Here are some more posts we have on our blog discussing other integration possibilities:
Share this Post