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
Sunday, October 26, 2008
The application platform on which CRM has been built
Some dicussion has been ongoing on wheter the application platform on which Dynamics CRM has been built will be used for other purposes, most noticable has probably been David Yacks book that I have discussed previously, that focuses more on this platform than on Dynamics CRM.
Today, since it is Sunday and I have some "free time" I took the opportunity to read The CRM Teams Statement of Direction and I found a very interesting part in the end that give a very direct statement on how Microsoft views this:
"Thus the underlying technology platform becomes an application engine to run a whole range of business applications. Microsoft Dynamics CRM simply becomes one business application that is run on the application platform."
So, perhaps we have put our card on the right horse this time (compared to Lehman and Brothers investors) since the future might show that experience in CRM development isn't only going to be a great asset when working with CRM but also a great asset since it will allow us to have a good heads start on the application platform, and the new applications that will be built ontop of it.
Discussions has also been around what is going to happen with NAV and AX. This is mere speculation, but it might just be that theses applications are the first to be migrated to the new application platform. So, get you MPC (Material and Production Control) books out and dig into ERP since that might just be the right skill to have.
If you havn't noticed, the work name for the new version of CRM is V.Next. Let's see if it will be 5.0 or perhaps 8.0? :)
Gustaf Westerlund
Microsoft Dynamics CRM Architect
Logica
www.logica.com
Today, since it is Sunday and I have some "free time" I took the opportunity to read The CRM Teams Statement of Direction and I found a very interesting part in the end that give a very direct statement on how Microsoft views this:
"Thus the underlying technology platform becomes an application engine to run a whole range of business applications. Microsoft Dynamics CRM simply becomes one business application that is run on the application platform."
So, perhaps we have put our card on the right horse this time (compared to Lehman and Brothers investors) since the future might show that experience in CRM development isn't only going to be a great asset when working with CRM but also a great asset since it will allow us to have a good heads start on the application platform, and the new applications that will be built ontop of it.
Discussions has also been around what is going to happen with NAV and AX. This is mere speculation, but it might just be that theses applications are the first to be migrated to the new application platform. So, get you MPC (Material and Production Control) books out and dig into ERP since that might just be the right skill to have.
If you havn't noticed, the work name for the new version of CRM is V.Next. Let's see if it will be 5.0 or perhaps 8.0? :)
Gustaf Westerlund
Microsoft Dynamics CRM Architect
Logica
www.logica.com
Sunday, October 19, 2008
CRM as a Rapid Development platform
David Yack, a Microsoft MVP has written a very good book for developers working with Microsoft Dynamics CRM 4.0 independantly of the actual solution, being CRM or some other solution.
He focuses a lot on viewing the Dynamics CRM platform as a development platform instead of just an application with a powerful API. This is a view I believe many Dynamics CRM developers share with him. The book also focuses a lot on working as a consultant and the choices that one needs to take when working as a consultant, like, is this sort of solution going to be working independantly of new hotfixes, patches and upgrades or are we going to create a cause for conflict with our customer.
As many of you know, Dynamics CRM addresses these issues as a platform in the definition of "supported" customizations and this is discussed throughout the book.
Included in the price of the book is also an entire library of useful tools that can be used when developing and that Yack recommends using in real life projects and that are licenced as such.
It is THE book for all Dynamics CRM developers looking for both tips and tricks on how to for instance, actually create a plug-in and also great use in understanding that Dynamics can be used as a platform for developing almost any kind of application. Yack has deliberatly left out information concerning how to use CRM out-of-the-box and other normal application based aspects of Dynamics CRM, something I find very good since it focuses the book on what it is meant to do.
If you work with development in Dynamics CRM, this is probably going to be one of the best investments you can do, since it will help you create better customizations faster with more customer value, and who doesn't want that?
Thanks David Yack for a great book!
Read more here: http://www.thecrmbook.com
Gustaf Westerlund
Microsoft Dynamics CRM Architect
Logica Sweden
www.logica.com
He focuses a lot on viewing the Dynamics CRM platform as a development platform instead of just an application with a powerful API. This is a view I believe many Dynamics CRM developers share with him. The book also focuses a lot on working as a consultant and the choices that one needs to take when working as a consultant, like, is this sort of solution going to be working independantly of new hotfixes, patches and upgrades or are we going to create a cause for conflict with our customer.
As many of you know, Dynamics CRM addresses these issues as a platform in the definition of "supported" customizations and this is discussed throughout the book.
Included in the price of the book is also an entire library of useful tools that can be used when developing and that Yack recommends using in real life projects and that are licenced as such.
It is THE book for all Dynamics CRM developers looking for both tips and tricks on how to for instance, actually create a plug-in and also great use in understanding that Dynamics can be used as a platform for developing almost any kind of application. Yack has deliberatly left out information concerning how to use CRM out-of-the-box and other normal application based aspects of Dynamics CRM, something I find very good since it focuses the book on what it is meant to do.
If you work with development in Dynamics CRM, this is probably going to be one of the best investments you can do, since it will help you create better customizations faster with more customer value, and who doesn't want that?
Thanks David Yack for a great book!
Read more here: http://www.thecrmbook.com
Gustaf Westerlund
Microsoft Dynamics CRM Architect
Logica Sweden
www.logica.com
Subscribe to:
Posts (Atom)