Putting all javascript code in external files

by Gustaf Westerlund | Nov 11, 2008

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

by Gustaf Westerlund | Oct 26, 2008

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

by Gustaf Westerlund | Oct 26, 2008

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