Just stumbled upon a new Azure environment, where Azure Function Apps have been upgraded to version 2. Right away, noticed that my Azure Function code referencing Dynamics assemblies does not compile, complaining aboutThe type or namespace name 'Xrm' does not exist in the namespace ‘Microsoft' (are you missing an assembly reference?) After digging around, I found out that the project.json is not longer valid with v.2.Instead, the function.proj file must be created and reference Dynamics assemblies in the following manner: 461
The automated process of user provisioning becomes common in many projects. Often, the process includes components outside of Dynamics 365 such as creating a user in Azure Active Directory, assigning plans and licenses and adding user to AAD groups. All of these can be automated using the Microsoft Graph API. In this post, I’ll demonstrate assigning Microsoft Dynamics 365 license to an existing user with Postman. You can later convert Postman requests to JS or C# code or use in Flow and Logic Apps. Prerequisites Have Postman application installed Have access to Office 365 and...
As a Solution Architect I often review Microsoft Dynamics 365 custom server and client side code.
One of the most common rejects regards tracing and exception handling mechanisms, or their absence. Some code constructs may have empty Try/Catch blocks or none at all, other catch exceptions and just re-throw. As for tracing, code often contains debugging ‘aids’ such as alerts and debugger statements or no tracing notifications at all.
Why is this a reject?
Unhandled raw exceptions float to UI, confusing and frustrating users while exposing internal implementation details to potential attackers
System Administrator is unaware of custom code exceptions unless users decide...
Finally found the time for overdue maintenance on the Drag & Drop solution I created two years ago.
First of all, as the CodePlex platform, previous home of this solution, is being decommissioned, downloading the component got the whole CodePlex project and few visitors commented that they could not find the actual solution.
So now you can download an unmanaged solution from it’s new home @ Github.
Second, I fixed a major bug related to the plural name of some entities.
For most entities, appending ‘s’ to the entity schema name would result in the matching entity name for Web API. Some...
In part 1 of this post I demonstrated building and using a service which receives a FetchXML query and returns Dynamics 365 data to any Portal page in an asynchronous manner as a JSON object. This service is similar to the SDK’s RetrieveMultiple message.
In this part 2, I’ll demonstrate a different service, which like the SDK Retrieve message, receives a record type, record id (GUID) and columns set to return the required data as a JSON object.
This is useful when you already have a specific Dynamics 365 record id at hand and you want to retrieve additional data for...
Leveraging Colin Vermander brilliant article on using Liquid Templates to return JSON, I would like to demonstrate creating and using a ‘service’ to asynchronously retrieve Dynamics 365 data into any portal page.
Why is this useful?
Liquid Templates tags are rendered on server side before a response is returned to the browser, so FetchXML tag will return a static result once the page is returned.
But what about responding dynamically to client side events such as option selection, button click or expending an element to view more details?
Sending the page to the server again is no longer an option if you want...
The requirement for recurring job execution is quite common in Microsoft Dynamics implementations. Here are some of the business requirements I have encountered:
Send monthly newsletter to target customers
Synchronize MSCRM Users details with Active Directory once a day
Once a month, disqualify all leads that have no open activities
Once every hour, export Appointments from mail server and import into Dynamics 365
Microsoft Dynamics 365 has no reliable built in scheduling mechanism that can be leveraged for custom solutions. The Asynchronous Batch Process Pattern I have written about in the past can be used with daily...
Azure Function is a fantastic mechanism for various integration scenarios. Here are few key characteristics:
Being a serverless application, Azure Function has the best time to market when it comes to deploying a web service
Pay-per-use pricing model means you pay only for what you use
Built in integration options in PowerApps and Flow allows you to give non-developers new building blocks when designing application and processes
CORS (Cross-Origin Resource Sharing) support allows consuming Functions from server/client side in any domain you find suitable
What can you do with Azure Functions in the context of Microsoft Dynamics integration scenarios? Just about anything:
Export/Import data to/from...