Monday, February 23, 2009

Errors when programmatically attaching events in forms

Today I had a very weird error. I had two datetime fields on a form, one on the first tab and one one the second. Let's call them date1 and date2 to make it easier.

I attached an event in the onload by using

crmForm.all.date1.attachEvent("onchange", myFunc1);

and for the date2 field:

crmForm.all.date2.attachEvent("onchange", myFunc2);

The weird part was that if I changed date1 first and then date2, myFunc2 didn't fire. But if I first changed date2 and then date1, both fired as they should.

So I tried just adding an alert instead using the normal onchange method via the form editor in CRM and that triggered every time, just as it should, so something is different.

The simple solution seemed to be to move date2 from the second tab to the first. That got everything working just as it should.

I havn't tried it but I think that one could also write a method that confirms all the event attachments and then calling this at the end of every onchange triggering function and perhaps some extra time when the tabs are changed to make sure the events are bound correctly.

I have checked the documentation in CRM for if this kind of runtime event attachment might not be supported but my interpretation of the text is that is should be all right according to it. The closest paragraph in the unsupported customization section is the following:

"The use of custom HttpModules to inject HTML/DHTML into the Microsoft Dynamics CRM Forms. "

As I wrote, my interpretation is that attaching events (not even overwriting the onchange), should be ok according to this since we arn't injecting anything, just adding an event listener. Hence I feel that this must be interpreted as a bugg in CRM.

Gustaf Westerlund
Microsoft Dynamics CRM Architect


Tuesday, February 17, 2009

Unicode conversion

When writing javascripts with alerts or similar when not working with english, special characters like the swedish åäö might not be shown correctly. I found this helpful page where you can enter the string you want to convert and then copy paste the result. Simple and nice.

Gustaf Westerlund
Microsoft Dynamics CRM Architect


Really cool way of getting FetchXML from advanced find

I've been having some problems with my blogs in Outlook but today I fixed it and started checked if there was anything special and found this very interesting article on Ronald Lemmens blog.

He describes how to, without any code or customizations to a system, easily get the fetchxml code from an advanced find by just putting some javascriptcode in the url of the window. Beautiful in all it simplicity!

Gustaf Westerlund
Microsoft Dynamics CRM Architect


Force update of Report

The project I am currently involved in uses Reporting Services reports that are shown as PDF:s as quotes that are sent to the customer. It is implemented by creating a custom report that takes the object id (like quote) which is called from an isv.config button and by using querystring parameters, the output is directed to PDF.

However, I got a puzzeling bug. The data in the quote is of course based on data in some CRM entities and when a quote was generated and the user found something was wrong, changed this in CRM, saved and then tried to regenerate the PDF, the change didn't show. I restared Internet Explorer, and regenerated the quote-pdf and now it showed correctly. Hence some sort of caching error.

I looked around the internet a bit and found that by adding the following parameter to the querystring, I could refresh the sessions variables and I would get a fresh and correct report.´


So, the entire url was (except for the report id etc.):


So, if you get a similar error, just try setting this.

It is also possible that IE caches the pdf and then you'll have to add some variable to the querystring, like a tick or datetime that is unique for every call (from that client) and that will bypass IE:s caching.

Gustaf Westerlund
Microsoft Dynamics CRM Architect


Tuesday, February 03, 2009

Workflow warning

Today I was troubleshooting a CRM server which had the CRMAsycnService and w3wp service totally hogging the machine. It was quite obvious that it was CRM that was the cause for this and since CRMAsyncService was involved, probably workflows or perhaps the deletionservice.

After a bit of looking around I found a workflow that was set to trigger on attribute change on an entity and then later in that same entity, changed some attributes. This caused an infinite loop which was the cause for the hogging. By first unpublishing the workflow and then removing all started systemjobs, I got the machine back up to speed.

My conclusion from this is that even though the workflow GUI seems easy it is deceitfully powerfull and you quite easily create workflows that hogg the server (the server hosting the async-service anyway). This should be taken into consideration when putting this tool into the hands of non-programmers since the risk for the entire system stability is large. This can be either application consultants or power users at the customer.

There is also no standard way of locking some of the triggers on workflows so that you can eliminate this risk. I you know of any, please leave a comment!

Gustaf Westerlund
Microsoft Dynamics CRM Architect


Monday, February 02, 2009

Process implementation strategy

When implementing a business process in Dynamics CRM there are several different implementation paths to choose from. There are advantages and disadvantages to the different techniques but there are some goals that I feel the implementations should meet, mainly:

1. Fully supported customizations only

2. Flexible and non-static.

3. Power user modifiable

4. Movable from environment to environment (dev-test-production)

I will discuss the different aspects bellow and why I feel they are important.

Fully supported customizations only

This is almost so self-evident that it doesn't even need mentioning but I have seen several CRM implementations that not only nudge this paradigm in the corner, but bite big large chunks out of it. For me, the number one reason why this is so important is that all customers will sooner or later want a hotfix or upgrade to a later version and when Microsoft, in their greatest foresight and benevolence definied the concept of supported customizations, they made this possible without costly maintanance agreements or hostile customer relationships. So, not following it should be punishable by death or something close to it.

I would presume that you CRM implementations are meant to last for your customers and that you want a long a fruitfull relationship with your customer, why you just cannot underestimate this point. If you have to make unsupported customizations, make sure they are as light weight as possible, document them thouroghly and how to validate them when installing a hotfix or upgrade.

A business process must hence be made as supported as possible.

Flexible and non-static

The solution has to be flexible and non-static. We, and our customers live in an ever changing world and to cope with this, business processes have to change as the world around a company changes. Just imagine the changes the telecom industry has gone through the latest 20 years. To fully accomodate this the customer implementations have to be flexible and changable. Microsoft Dynamics CRM is one of the most versatile and flexible systems available, especially now that it incorporates windows workflow foundation. Implementing a business process in code entirly, locks the processes down, and builds a dependance on the CRM delivering partner, something every customer-value focused consultant must despise. I do not need to force my customers to use my services when I can get them to choose me because of the value I deliver to them every hour of every day.

Instead, use the power of Windows Workflow Foundation combined with custom workflow activities. If needed, trigger these workflows using plug-ins and isv.config customizations.

Power user modifiable

A business process often involves users of different sorts and communicates with these using emails, tasks and other activites. The content of these and the recipients, sometimes dynamically set, sometimes static (like the CFO), might need to be changed. Therefore it is not very flexible for the customer if code has to be re-written everytime a mail has to be changed. It is a lot more flexible to create a workflow that creates the activity and then just execute the workflow from code, apart from the fact that it is a lot quicker to implement. Just write a method that enables you to execute the workflow by name instead of Guid.

Movable from environment to environment (dev-test-production)

All implementations of any notable size always includes at least three environements, not seldom up to 5 or 6 depending on how you count (local dev, central dev, test, training, production). Business process implementations have to be easy to move between solutions without any or with as little as possible environement specifics. Hence, try to use names (or some other environment indpendant value) instead of guids since guids are environment specifics when relating to workflows and other similar things. Try to get all environement specific settings in one place, one file or create an entity for them. This can be a challange but try, it will pay off in the long run.

These are my thoughts on the business processes implementation stategy concerning Dynamics CRM 4. I would be happy to discuss the topic so please leave comments!

Gustaf Westerlund
Microsoft Dynamics CRM Architect