Thursday, February 8, 2018
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...
Tuesday, January 30, 2018
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...
Saturday, July 23, 2016
Friday, March 11, 2016
Monday, August 10, 2015
In the previous post, I walked through the ABP Target Records Scenario. In this post, I’ll go through the Aggregative Query Scenario. Prerequisites 1. Download the Asynchronous Batch Process Solution, import into Microsoft Dynamics CRM 2015 on-premise/Online organization2. Go to Settings – > Solutions and Open the ABP solution. Go to the Batch Process entity definition and check the Settings checkbox in the ‘Areas that display this entity’ section3. Save and publish the solution As always, I advise against publishing any external solution on your production environment without testing it first. Aggregative Query Scenario ...
Tuesday, July 15, 2014
In the previous post I described a solution to the business problem of logging & handling implementation level exceptions (presented in the first post of this series).
In this post, I will supply an actual solution, demonstrate common usage scenarios and other solution features.
Before I walkthrough usage scenarios, some implementation notes:
In order to support exceptions raised from transactional components (such as Plugin registered to pre/post operation stages), the LogException method in ExceptionManagement.cs file is using the ExecuteMultipleRequest class to execute the e4d_LogExceptionRequest request. As the ExecuteMultipleRequest instance is external to the Plugin transaction, it manages to create the Exception record...
Monday, June 2, 2014
In this 3-parts post I would like to suggest a general approach and solution for logging and handling exceptions in Microsoft Dynamics CRM 2013 implementations. By exceptions, I don’t mean Microsoft Dynamics CRM product core exceptions which occur from time to time. These are logged by various designated repositories (such as Event Viewer and CRM Trace) and beyond our reach anyway, certainly in Online deployments. I do mean unexpected events that arise from custom code written in both server and client side in most Microsoft Dynamics CRM 2013 implementations. These events are usually related to poorly written code,...