Azure Data Factory (ADF) remains a massive area for me, and within the projects I'm involved in. Previously, those looking to use ADF to map into Owner or Customer fields in the Common Data Service may have hit a few issues. Thankfully, this is now all in the past.
The Dynamics 365 / Common Data Service Web API allows developers to leverage a wide variety of functionality, from almost any conceivable location - such as, for example, an Azure Data Factory V2 pipeline. With this in mind, let’s dive in and see how to achieve this.
Complex integration pieces that involve on-premise systems can be difficult to scope out and implement. One of the benefits of working with the Microsoft cloud is that there are multiple tools available to help us in this regard. Figuring out the correct one to use, though, can be a challenge…
A few weeks ago, I did a post on the process involved when migrating Microsoft Azure Cloud Solutions Provider (CSP) subscriptions across tenants. Having done some actual work relating to this since then (shock horror!), I thought I'd follow up with a new post, sharing some additional thoughts and lessons learned.
One of the best things about Azure Data Factory is its ability to incorporate continuous integration and automated deployments quickly alongside your solution. However, if you’re working with SQL Server data sources and are using square brackets to interact with tables, then you may be in for a bumpy ride…
When you are amid a pesky IT issue, it can be difficult determining whether the problem is down to a bug/system fault or human error. Like this recent example involving Azure Data Factory illustrates, it is generally best to assume the latter, to avoid any prolonged difficulty.
The Dynamics 365 Customer Engagement/Common Data Service connector for Azure Data Factory can, in most cases, fit into your data integration needs. However, it is worth highlighting the two field types which are, specifically, not supported; namely, the Customer and Owner field types.
By default, the Dynamics 365 Customer Engagement connector for Azure Data Factory V2 exposes a predefined list of fields, that must have data mapped to them for any Copy Data task to complete successfully. This behaviour can be impractical depending on your particular scenario; fortunately, there is a way in which you can override this.
Azure Data Factory V2 not just has 1, but three separate connectors that all claim to hook up to Dynamics 365 Customer Engagement/Dynamics CRM! So which connector is the "right" one to use and what differences do they have? With a little help from Alan Partridge, we can clear up any confusion...
When working with Azure templates for the first time, there's always a risk of misconfiguring a setting. All fine when testing, until you realise you have been charged an unexpected amount on your credit card. In this post, I provide an example of this in practice when working with Stream Analytic Job resources.