In my last post in this series, I outlined an approach for building a simple service relay with RabbitMQ and Python to easily expose an on-premises Dynamics 365 Customer Engagement organization to external consumers. In this post I will walk through the prerequisites for building this out. I'm assuming you »
Integrating with external systems is a common requirement in Dynamics 365 Customer Engagement projects, but when the project involves an on-premises instance of Dynamics 365, routing requests from external systems through your firewall can present an additional challenge. Over the course of the next few posts, I will show you »
I've released an updated version of my popular Dynamics 365 Configuration Data Mover utility that was built with .Net 4.7 to address the new requirement to use TLS 1.2 (or better) for connections to Dynamics 365 online instances as described in this entry on the Microsoft Dynamics 365 »
I've previously showed how to access online and IFD instances of Dynamics 365 Customer Engagement from Python code. Because that sample code authenticated to the Web API using OAuth, it won't work with on-premises instances. Recently I've been doing some work with Python and an on-premises Dynamics 365 organization, so »
I was recently asked to add a feature to my Dynamics 365 Configuration Data Mover to enable connections through a proxy server. Because the tool is a .Net application, proxy server connections can be configured directly in the AlexanderDevelopmentConfigDataMover.exe.config file. For example, if you want to use the »