Data-Transfer: Configuration Consistency through all stages

A blog post by Robert Pröll


Posted: 04.2019 | Category: DataTransfer | Author: Robert Pröll Tags: DEPLOYMENTS DYNAMICS CRM CI/CD DEVOPS ALM

Robert Pröll | .NET Software Architect

Intro

Configuration entities mostly do not change quite often but have a huge impact on the system, like pricing values, integration system URLs…

So it’s important to ensure the right values are used. This article describes the following scenarios:

  • Static Configuration (Product names)
  • Different configurations for each environment (Exchange-URL)
  • Hierarchical Structures (Business Units)
  • Special cases to consider

The key aspect of the concept is to keep the same id’s (where possible) through all environments, which makes it much easier to debug, analyze, update…


Real World vs Theory

In most projects config entities used for development instances are a small subset of the production data which makes it easier to maintain but always produces gaps in different places what creates data based errors and time consuming analysis tasks.

Of course, there some tools to transfer data but this needs to be done or can’t be done due to technical limitations.

Let’s see some examples:

 

Product Catalog  

A product catalog needs at least 4 entities (Product, Units, Prices etc.) with different types of attributes.
Products are categorized and hierarchal organized, so the parent product must be created first.

Important Cases

  • Product Name (Static) => Nothing to do
  • Parent Product (Hierarchy Attribute) => Import order must be handled
  • Currency (Lookup to existing entity with different id) => Query by primary name must be executed (“EUR”) to get the id
  • Price => Secret, should be changed for production only
  • Primary UOM => The primary uom is always created by crm with a new id, this needs to be considered as well

The examples above show that is possible to handle such cases manually, but this is risky when it comes to sensitive data like pricing values.

Specific behavior

Products are entities with some special restrictions:

  • Only draft products can be newly created – Followed by an activation request

 

Business Units

Business units also have a hierarchal structure but with a single preexisting root node.
That means another root node cannot be created – The existing one must be used instead.

 

Special cases to consider

Some entities cannot be directly imported and needs to be modified based on specific target system parameters.
See: Deploy Dynamics365 Document Templates (Word & Excel)

 

KDTooling:

The above cases and much more can be handled by KDTooling Deployment Manager:

Supported Attribute behaviors:

Description

Use cases

Static

Static values without any manipulation

EnvironmentSpecific

Values which need to be adjusted for each enviroment. Lookups will be resolved on demand by the primary attribute. 

Ignore

Don't export the attribute

Hierarchical

Hierarchical Elements will be automatically reordered before the import starts

HierarchicalMulitpleRoot

Same as Hierarchical but with multiple root entities.

AutoResolve

Query target id by primary attribute without any manual configuration

 


Attribute Behaviour

Attribute Behaviour

Environment Specific Values

Environment Specific Values

Import process

Import process



About the author

Robert Pröll

.NET Software Architect

Key areas of interest: ALM, .NET C#, PowerShell, Azure, Dynamics 365 Tooling

Robert started in the area of ASP.NET projects and has now more than 10 years of experience in the international Dynamics Enterprise business.

He works mainly as a principal software architect at Kupp and as an external consultant for Microsoft.