Data Export is an add-on service made available as a Common Data Service solution that adds the ability to replicate Common Data Service data to a Microsoft Azure SQL Database store in a customer-owned Microsoft Azure subscription. The supported target destinations are Microsoft Azure SQL Database and Microsoft Azure SQL Server on Microsoft Azure virtual machines. Data Export intelligently synchronizes the entire Dynamics 365 schema and data initially and thereafter synchronizes on a continuous basis as changes occur (delta changes) in the Dynamics 365 (online) system.
The Data Export service provides an interface for managing configuration and ongoing administration of this service from within Common Data Service. For more information, see Data Export. This topic explains the corresponding programmatic interface and issues for this service.
Because this service requires access to an external Microsoft Azure SQL Database from Common Data Service, a number of prerequisites must be satisfied before you can successfully access this service. The following perquisites are more fully explained from an administrator's perspective in the section Prerequisites for using Data Export Service.
The entities that will be exported are enabled with change tracking. For more information, see Use change tracking to synchronize data with external systems.
Code is run in the context of a user with the System Administrator security role.
Note that programmatic access to this service does not require the installation of the associated Data Export managed solution.
The subscription must support the volume of data being replicated from your Common Data Service instance.
Firewall settings must allow access from the IP address of your Data Export service. For more information, see Configure an Azure SQL Database server-level firewall rule using the Azure Portal.
It is recommended that option "Allow access to azure services" be enabled.
The database user, specified in the data export connection string, must have the proper create and alter permissions on the target database. At minimum these include: CRTB, CRTY, CRVW, CRPR, and ALUS. For more information, see Permissions (Database Engine).
At least one user have extensive permissions on the schema. The following script creates such a new user.
For online solutions and services, Azure provides a Key Vault service to safeguard cryptographic keys, passwords, and other secrets. To use Azure Key Vault, this customer-owned service must be configured so that permission is granted to "Dynamics 365 Data Export Service", which is used to safely store the SQL Azure connection string. To perform this configuration with a PowerShell script, see How to set up Azure Key Vault. Alternately, this service can be managed through its REST API; see Key Vault management.
It is also advised that you add the domain https://discovery.crmreplication.azure.net/ to the trusted sites list in your browser and to enable pop-ups for this site.
For the reader's convenience, these interfaces are summarized in the following tables.
Because only Common Data Service System Administrators are authorized to perform data export operations, these APIs enforce caller authorization through the use of Azure Active Directory (AAD) security tokens. The following code snippet demonstrates generating such a token for a web application by using the administrator's name and password. You must replace the AppId, crmAdminUser and crmAdminPassword with values appropriate to your service. This approach can be used for development and testing, but more secure means should be used for production, such as the use of Azure Key Vault.
//For interactive applications, there are overloads of AcquireTokenAsync() which prompt for password.
For instructions on how to obtain a AppId see Authorize access to web applications using OAuth 2.0 and Azure Active Directory. For more information about Azure user security, see Authentication Scenarios for Azure AD.
After the configured retry interval, another attempt is made to synchronize the record. This is repeated up to the configured maximum number of retries.
The record is marked as processed.
A corresponding failed record entry is written to the error log.
The next record is processed.
The entries in the error log are write-only. Future successes or failures during synchronization of the same record do not result in the alteration of past entries for this record. For example, a failure entry will remain in the error log even after the record has been successfully synchronized during some later synchronization cycle.
This error processing logic is subject to change in future releases of this service.
RecordId: N/A, NotificationTime: , ChangeType: Trigger Initial Export, FailureReason: There is already an object named 'hatest201_lead' in the database.
Entity: account, RecordId: b2a19cdd-88df-e311-b8e5-6c3be5a8b200, NotificationTime: 8/31/2016 6:50:38 PM, ChangeType: New, FailureReason: Invalid object name 'dbo.hatest201_account'.