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.
Robert Pröll
.NET Software Architect
Product-Catalog, BusinessUnits, Config-Entities and other specific behaviors
Data-Transfer: Configuration Consistency through all stages
Posted: 04.2019 | Category: DataTransfer
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
Environment Specific Values
Import process
Tags: