Putting all javascript code in external files

Dynamics CRM is great. It has some really nice functions like being able to add javascripts to different event in the form to handle special needs of the GUI.

However, it is only fine as long as these scripts arn’t that many and not too complex. When they start getting more and more complex, bigger and their numbers start increasing it soon becomes an impossible tast of maintaining them all and there is no built in function to handle javascript includes without special code. It also takes a long time developing more complex code in the javascript form window in CRM and then running the preview or publishing it each time before testing.

There is light in the tunnel however, by using the technique specified bellow, you can both
get global javascript files, save and refresh only to see you changes, and keeping all scripts for one entity in one file (and not one for onLoad, one for onSave and one for each onChange that is needed).

A lot of credit for this has to go to Michael Höhne at Stunnware since he added a posting on his blog on how to manage javascript includes in runtime.

So, first of all we have to put some standard code in the onLoad. This should only be done once and it shouldn’t really be changed until you need to publish it for release (switching of the caching).

var LoadFile = function(url, cache)
{
var httpRequest = new ActiveXObject(“Msxml2.XMLHTTP”);
httpRequest.open(“GET”, url, false);
if (!cache)

{
httpRequest.setRequestHeader(“If-Modified-Since”, “Sat, 1 Jan 2000 00:00:00 GMT”);
}

httpRequest.send(null);
return httpRequest.responseText;
}

eval(LoadFile(“/isv/mycrmext/javascripts/MyGlobal.js”, false));
eval(LoadFile(“/isv/mycrmext/javascripts/Account_onload.js”, false));

This code simply loads and executes the two files MyGlobal.js and Account_onload.js located in the directory C:Program FilesMicrosoft Dynamics CRMCRMWebISVmyCRMEXTJavaScripts
and can be found at the url: :port/isv/mycrmext/javascripts/”>http://:port/isv/mycrmext/javascripts/.

So, copy-paste it into the onload event form in the account form editor in CRM. Activate the event, save and publish.

Then you can create the two .js-files at the specified directory. Start with just some test code like:
alert(“This is the MyGlobal.js-file”);
or something similar.

The next step is to try to avoid using the onsave and onchange events. This is quite easy when you know how but it is sort of in the gray area of supported customizations so be aware of this.

In the file Account_onload.js add the following code:
var MyOnSave = function()
{
alert(“onSave”);
}

var MyOnChange = function()
{
alert(“onChange”);
}


alert(“onload)

crmForm.attachEvent(“onsave”, MyOnSave);
crmForm.all.name(“onchange”, MyOnChange);

This attaches a simple function to the onsave event of the form and another to the onchange event of the attribute “name”.

The functional defintions/declarations can be put into any of the includefiles.

Now, just save the file, and open an account to see the magic! (It should show a dialog when loading with the text “onload”, when the accountname is changed, it should show “onchange” and when saved, it should show “onsave”.

Please note that I would advise you to put the javascript files in the same “host” from a IE perspective since you will get less problems with cross domain scripting and similar IE related security issues. This doesn’t however mean that you cannot put the js-files anywhere on the internet where the clients can access it.

Gustaf Westerlund
Microsoft Dynamics CRM Architect

Logica
www.logica.com

Attribute problems

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

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

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

Handle customization.xml (.zip) with care

As you probably know as a Dynamics CRM professional, all entity customizations, javascripts and more can easily be exported and imported between systems. This is a really neat feature of Dynamics CRM since it relieves us a lot of tiresome and repetitive work of recreating lots of settings for each environment set up.

It is not uncommon for a project to involve more than 3 or 4 depoyments that need to be identically set up. Usually the following are used:
– Production environment
– Test environment
– Central development environment
– Distributed developent environment(s) – usually locally run VPC:s
– Educational environment

If care isn’t taken when creating customizations and exporting and importing the customization files it is not hard to imagine problems arising when the same entity has been edited by different people at more or less the same time. This can result in the several of the different systems not being identical and perhaps even dataloss or the worst possible case, a system might crash. Therefore it is very useful to define a strict path for all customizations and the distribution of all customizaton files.

We usually handle this by simply defining the central development environment as the customization-master. This means that all entity customizations are done on this environment only. Then customizations are exported by almost always exporting all customizations and importing into all other systems from this file. This will hopefully reduce the risks of creating environments that are non-identical or erroneous.

Gustaf Westerlund
Microsoft Dynamics CRM Architect

Logica
www.logica.com

The power of SharePoint

Presently I am employed at Logica as a consultant and the projects I am involved in are always Dynamcis CRM centered. However, I used to work at Humandata earlier, run by the SharePoint MVP Göran Husman and I am since this time a devoted SharePoint fan.

At the time I was involved in several SharePoint implementations and we also had SharePoint as our Intranet at Humandata.

A couple of months ago Microsoft Office SharePoint Server was released at Logica as the global Intranet tool and I must say it is amazing to see the true power of SharePoint in a large organisation. At Humandata we were less than 20 employees and we all knew each other and more or less lived in the same City. The story at Logica, however, is drastically different, with around 40 000 employees in 41 countries.

With SharePoint we can now all communicate, I have taken the initiative to start a Logica-Global Dynamics CRM community to connect all the very talented Logica employees that in some way or another work with Dynamics CRM. We are still in start-up mode but the future looks bright and SharePoint is the enabler that makes it all possible.

Apart from this, it is also a great tool for running projects in. Instead of millions of post-its with all the questionsmarks in the project, we use a discussion board. Instead of impossible hierarchies of folder for SureStep documents, we use one Document Library with Meta-data describing what part of SureStep the document should be connected to. This way, documents are easier to find, easier to work with, easier to share and we get version control all for free.

So, if you are part of a large organisation, try to push for the use of SharePoint especially if this organisation is spread over a large geographical area and the use of virtual meetingspaces and focalpoints is of great use.

If you are employed at Logica and would like to be part of the community, just send me an email or leave a comment bellow – they are moderated so I don’t have to publish them if they are private.

One thing to be remembered though, even if SharePoint is easy, nobody is born to understand it or the concepts in it, especially if you are used to working in a normal directory based filesystem, so make sure all your users get a good basic run-through and give them the possibility to dig deeper on their own. If you neglect the educating of the users you risk spoiling most of your investment, and the users view of SharePoint, something that is both sad and bad.

Gustaf Westerlund
Microsoft Dynamics CRM Architect

Logica Sweden
www.logica.com