Introducing the Microsoft Dynamics 365 web services

Dynamics 365 has several web services, these provide access to pretty much every piece of data and functionality within the application. Whilst some web services have distinct duties, there are a couple dedicated to working the application data which have overlapping functionalities. This is due to the evolution of the product; web services are added and deprecated over time. I’ll be looking at the web services currently available in 365, you may come across the ‘2007 endpoint’ however this was deprecated with CRM 2011.

This article is part of a series

Deployment

For on premise installations, the deployment web service enables programmatic management of deployment activities. Rarely used and discrete, you are unlikely to use this service in a typical project. Provides the same operations you can perform on the server using the Deployment manager tool (you can also perform administration tasks using PowerShell cmdlets). The service can be used to manage deployment entities and configuration settings.

Discovery

Dynamics 365 is a multi-tenant application where a single deployment can host multiple instances. Again, rarely used and discrete, you are unlikely to use this service in a typical project. The service can be used to detect which servers and organisations are available to a given user. There are actually two implementations of the discovery service:

• IDiscoveryService; the older implementation, provided as part of the Microsoft.Xrm.Sdk assembly, so primarily aimed at .Net developers.
• Web API Discovery; the newer implementation, but is easier to consume for a wider range of programming languages, platforms, and devices.

Organization Data Service (aka OData or REST endpoint)

The organization data service implemented the OData v2 Standard and has been available since CRM 2011, but is now deprecated with 365 and should no longer be used. It should still be available to use for a few more years, but don’t expect new features and move to the Web API when you can.

The organization data service always lacked the full feature set that the organization service provided, it is limited to simple create, read, update, delete (CRUD) operations. It was most often used from JavaScript written inside the CRM application as it was easier to implement than using SOAP requests with the organization service.

Organization Service (aka SOAP endpoint)

Available since CRM 2011 the service provided a classic SOAP endpoint and is probably the most commonly used web service. This service provides access to the full range of 365 operations, and messages. For .Net developers the SDK provides a set of assemblies that mean using the service is simple with the complexities of the SOAP endpoint abstracted away. Non-.Net developers have a more challenging environment and they must communicate directly with the SOAP endpoint which is typically a far more complicated affair.

With the arrival of CRM 2016 the organization service is now deprecated in favour of the Web API. The endpoint will be removed sometime after Dynamics 365 version 9 (at the time of writing we are on version 8).  Those who are connecting to the organization service using the SDK can continue to do so, the SDK assemblies will be updated to use the Web API – a change that will apparently be transparent to us. Those directly communicating with the SOAP endpoint should make plans to retarget their code to use the Web API.

Web API

The newest kid on the block arriving with CRM 2016 this service will eventually provide full feature parity with the organization service – however there are currently a number of limitations. The API will eventually replace both the organization and organization data services. The API is built on open web standards and implements OData v4 providing a RESTful API.

A key benefit of the API is that it provides a service that can be easily accessed across a wide range of programming languages, platforms, and devices. This is a welcome change as in the past non-.Net developers typically had a harder time communicating with the application. API access is possible in several ways:

• .Net developers should probably just continue using the SDK. It may currently be linked to the deprecated organization service, but as noted above Microsoft intend to retarget to the web API.
• Non-.Net developers (or those who don’t wish to use the SDK) can compose HTTP requests for specific operations or use third-party libraries for the chosen language and platform.
• Those developing plugins or custom workflow activities have the use the SDK.
• All client side access including requests from web resource resources and form scripts inside 365 should compose HTTP requests.

Service functionalities

Setting aside the deployment and discover services, and the web API limitations noted above, broadly speaking the web services provide the following core functionalities.

The organization data service, organization service, and web API offer the ability to perform CRUD operations; create, retrieve, update, delete records within the Dynamics database.

The organization service provides messages, whilst the web API provides functions, and actions. Ignoring the different structures these are generally equivalent and provide specific application behaviours beyond simple CRUD operations;

• Data – the core messages to work with any record data.
• Metadata – to retrieve and manipulate the metadata schema of the application. (The metadata defines the entities the application contains and the information that can be stored).
• Dynamics 365 – perform actions specific to 365 processes, e.g. add items to a queue, start a bulk delete, qualify a lead, and many more.

Original Post https://woodsworkblog.wordpress.com/2017/06/25/introducing-the-microsoft-dynamics-365-web-services/