Sunday, November 11, 2018
I have written about executing recurring jobs in Dynamics 365 few times in the past. Over time, I suggested different scheduling mechanisms such as Microsoft Dynamics Workflow Timeout step or Azure Scheduler, as the pattern I suggested allows changing the scheduling mechanism without impacting other solution parts.
Flow can be also used as a scheduling mechanism, one that does not require coding like Azure Function, as it has a built in integration with Microsoft Dynamics 365 Online.
Once invoked on schedule, the executing component query Dynamics 365 for target business records and apply some business logic (Process) to each business record.
Sunday, October 28, 2018
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...
Thursday, October 18, 2018
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...
Monday, October 15, 2018
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...
Friday, October 12, 2018
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...
Monday, December 18, 2017
I noticed the following note in the developer guide article. This note embodies big promise for many organizations that are currently planning or actually migrating from version 2011 (and up) to version Dynamics 365, as it removes (or at least dramatically postpones) a big chunk of work required to migrate code that uses the 2011 SOAP endpoint to use Web API endpoint. In typical enterprise level projects (versions 2011 to Dynamics 365) the 2011 SOAP Endpoint (a.k.a OrganizationService) is heavily used in Plug-ins, Custom Workflow Activity components, external application integration and even client side code. For organization...
Tuesday, May 2, 2017
Looking at the list of traditional CRM activities I always miss the SMS, being a common and effective type of communication between organizations and customers. Sending SMS triggered by Microsoft Dynamics 365 events (e.g. Case created) used to be a developer’s task. You had to write Plugin or Custom Workflow Activity code to access the SMS provider web service and maintain it as endpoints sometime change. With Flow you can integrate applications in a declarative manner so an event in one application will trigger an action in another application along with custom conditional logic and even wait...