D365 Learn Developer experience updates

Microsoft made some Developer Experience Updates in different tools and Web API in order to enhance the CRM functionality and also fixed the bugs addressed to Microsoft in previous release.

1. Authentication

1. Existing authentication flows require username + password
   –> Requires password maintenance
   –> Requires user license
2. Server to Server Authentication
   –>Available in Fall 2016 release
   –> “Client Credentials” flow
   –> Authenticate with AAD using a secret or certificate
   –> Support for 3rd party solutions
   –> Does not require a user license.

2. Introducing client APIs for creating and managing records in Dynamics 365 mobile clients while working offline
Use new client APIs for Dynamics 365 for phones and Dynamics 365 for tablets

1. Utility.getCurrentPosition: Returns the current location using the device geolocation capability.
2. Utility.getBarcodeValue: Returns the barcode information, such as a product number, scanned using the device camera.

Get Barcode value

Xrm.Utility.getBarcodeValue().then(
function (result) {
Xrm.Utility.alertDialog("Barcode value: " + result);
},
function (error) {
Xrm.Utility.alertDialog(error.message);
})

Get GeoLocation

Xrm.Utility.getCurrentPosition().then
(function (location) {
Xrm.Utility.alertDialog("Latitude: " + location.coords.latitude +
", Longitude: " + location.coords.longitude);
},
function (error) {
Xrm.Utility.alertDialog(error.message);
})

3. Dynamics 365 Web API enhancements

1. Access to local data while Dynamics 365 for Outlook is offline
   Instead of using getServerUrl() make use of getClientUrl(). getServerUrl() method is deprecated

   context.getClientUrl()- Return Type(string)



2. Return entity data on create or update

1. Create with Record URL
   The create request previously provided the response as shown below. Only the record Id is obtained in the response header.



2. Create with data returned
   The create request after D365 update provides us with all the data of the created record. The below screenshot shows the data of the entity created as no query is specified in the URL.

   Now if the developer need any field data that got created such as created on, modified on fields data can be retrieved in the same create request. No need of another retrieve request.

   

   Note: This capability is applicable only for dynamics 365 (online and on-premises)

   You can compose your POST request so that data from the created record will be returned with a status of 201 (Created). To get his result, you must use the return=representation preference in the request headers.

   To control which properties are returned, append the $select query option to the URL to the entity set. The $expand query option will be ignored if used.

   When an entity is created in this way the OData-EntityId header containing the URI to the created record is not returned.

   This example creates a new account entity and returns the requested data in the response.

   Request

   POST [Organization URI]/api/data/v8.2/accounts?$select=name,creditonhold,address1_latitude,description,revenue,accountcategorycode,createdon HTTP/1.1
   OData-MaxVersion: 4.0
   OData-Version: 4.0
   Accept: application/json
   Content-Type: application/json; charset=utf-8
   Prefer: return=representation
   
   {
   "name": "Sample Account",
   "creditonhold": false,
   "address1_latitude": 47.639583,
   "description": "This is the description of the sample account",
   "revenue": 5000000,
   "accountcategorycode": 1
   }
   

   Response

   HTTP/1.1 201 Created
   Content-Type: application/json; odata.metadata=minimal
   Preference-Applied: return=representation
   OData-Version: 4.0
   
   {
   
   "@odata.context": "[Organization URI]/api/data/v8.2/$metadata#accounts/$entity",
   "@odata.etag": "W/\"536530\"",
   "accountid": "d6f193fc-ce85-e611-80d8-00155d2a68de",
   "accountcategorycode": 1,
   "description": "This is the description of the sample account",
   "address1_latitude": 47.63958,
   "creditonhold": false,
   "name": "Sample Account",
   "createdon": "2016-09-28T22:57:53Z",
   "revenue": 5000000.0000,
   "_transactioncurrencyid_value": "048dddaa-6f7f-e611-80d3-00155db5e0b6"
   }
   

3. Update with data returned

   Request

   PATCH [Organization URI]/api/data/v8.2/accounts(00000000-0000-0000-0000-000000000001)?$select=name,creditonhold,address1_latitude,description,revenue,accountcategorycode,createdon HTTP/1.1
   OData-MaxVersion: 4.0
   OData-Version: 4.0
   Accept: application/json
   Content-Type: application/json; charset=utf-8
   Prefer: return=representation
   
   {"name":"Updated Sample Account"}
   

   Response

   HTTP/1.1 200 OK
   Content-Type: application/json; odata.metadata=minimal
   Preference-Applied: return=representation
   OData-Version: 4.0
   
   {
   
   "@odata.context": "[Organization URI]/api/data/v8.2/$metadata#accounts/$entity",
   "@odata.etag": "W/\"536537\"",
   "accountid": "00000000-0000-0000-0000-000000000001",
   "accountcategorycode": 1,
   "description": "This is the description of the sample account",
   "address1_latitude": 47.63958,
   "creditonhold": false,
   "name": "Updated Sample Account",
   "createdon": "2016-09-28T23:14:00Z",
   "revenue": 5000000.0000,
   "_transactioncurrencyid_value": "048dddaa-6f7f-e611-80d3-00155db5e0b6"
   }
   

4. HTTP headers
   Every request should include the Accept header value of application/json, even when no response body is expected. Any error returned in the response will be returned as JSON. While your code should work even if this header isn’t included, we recommend including it as a best practice.

   The current OData version is 4.0, but future versions may allow for new capabilities. To ensure that there is no ambiguity about the OData version that will be applied to your code at that point in the future, you should always include an explicit statement of the current OData version and the Maximum version to apply in your code. Use both OData-Version and OData-MaxVersion headers set to a value of 4.0.

   
   

4. Reference metadata by name

Get the metadata information by the URLs specified below.

5. Discovery Service Enhancements

Existing Region based discovery service

Global Discovery Service

1. With new discovery service you are able to hit a single end point which will return all the organization for a user.
2. Available only for commercial hosted instances.
3. Will return all the CRM versions (8.0,8.1). No need to worry about the versions used by the client.
4. You can use the single end point to discover all the instances by using v1.0

6. Tooling Updates

Tools that have been updated.

1. Solution Packager
   –> Updated support for localization of Sitemap, Solution info, and BPF/Process objects
   –> Added support for new solution component types added for fall.
2. Plugin Registration Tool
   –> Updated to support Service Bus connect string based connections only. I don’t have a connection string will be removed soon.

   

   –> Added Event Hubs support

   
3. Configuration Migration tool
   –> The things that are common between Field Service and Project Service are added to core engine of CRM itself.
   –> Added support for new “specialized” types in Resource management entities in CRM
4. CrmSvcUtil
   –> Updated to support connection string and better handling of option set data.
5. Tooling.Connector
   (Performance is improved as it uses the string that is present in the cache, if call is made to same connection for 2nd time using the constructor)
   –> Added new connection string options to support creating new connections or reusing existing connections
   –> Updated connection fault recovery logic to better handle unexpected faults and cleanly recover connections.
6. Tooling.CrmConnectControl
   –> Updated with Accessibility Support
   –> Added new feature to configure display language at runtime.
7. Powershell
   –> Microsoft.Xrm.Tooling.Connector and Microsoft.Xrm.Tooling.PackageDeployment updated to support new logging feature to allow for better control over log files and capture of content.