As I have described earlier, a controlled and consistent handling of the customization file is very important in order to maintain coherent and properly mirrored systems.
As I am reading the book “CRM as a rapid devleopment platform” by David Yack at the moment, I will probably be commenting a bit on some of it’s content. Even though I might not fully agree to all that is said in the book, I must really give it my best recommendations since it is really a good tool and has a lot of very useful tips and code libraries that can be used.
One of the things Yack treats in the book is the how to import and export customizations and his recommendation is to take as few entities as possible. My personal view is still that the best way to maintain “mirrored” systems and avoid any problems when importing, is to almost always move the entire set of customizations (using the import/export all entities) since I believe that will reduce the risk of anything bad happening and that the systems might accedentally not be the same until someone notices that an entity hasn’t been moved from one system to another. Yack’s manner of handling this is not directly wrong in my opinion, and it might work well but there might be need for more extensive documentation of exactly what customizations exist in all the different systems (for those who didn’t read that posting, most commonly: Production, Test, Central Dev, Educational and Distributed VPC Devs)
A similar problem that might give rise to some headaches is that you might have seen to it that all systems have the same customizations and then notice that some attribute might have the wrong data type, and since you can’t just change the datatype, you remove it and then recreate it using the same name as before. Now you try to export and import this entity to some other system, it will crash due to the fact that CRM will try to append the changes made but it doesn’t log that you have removed the attribute and will just export an image of the exisitng system. When importing, it will try to find any changes and add these. When it find’s a missmatch in the datatype of the entity in question, it will simply stop the importing.
So, try not to change attributes or entities this way. If you have created an attribute with the wrong datatype, remove it and create the new one with another name.
It is probably also possible to first remove the attribute, export the customization and import it to ALL system and then add the attribute, export and import it to all systems. Then you might get it to work but it’s easy to miss one development VPC system and then you’ll have to remove the attribute(s) by hand and that just isn’t very good since these kinds of changes should be limitied to the customization master system.
Gustaf Westerlund
Microsoft Dynamics CRM Architect
Logica
www.logica.com
Recent Comments