Skip to content

CrmStain #4

February 13, 2011

Just a quick one here before I forget…

CRM workflow is a splendid but limited thing…very limited. So like most, unless you’re sending an email with a fixed attachment to a fixed recipient, you may find yourself wanting more…more in the form of custom activities.

The ability to add custom workflow is pretty cool although limited in it’s own way. Input and Output dependency properties are the big handcuff here. Why why why no activity parties? But I digress. The CrMStain here is a persistence error you get if you create a class level variable in the custom activity. Now not being a WF guru, my sense here is that this is not a CRM specific issue and it’s more a WF thing and probably more a “I’m an idiot and need to read a little more about it thing”. That said, for now it will hold the #4 slot so that I don’t forget about it and do it again.

I really want a new 1080p LCD or Plasma…maybe even 3d…but damn, I can’t help but sit here and look at my 4 year old 40″ 720p Samsung watching Return of the Jedi and think, it still looks good. I’m hoping the dark side wins out.

CrMStain #3

February 12, 2011

To attachEvent or not to attachEvent. 

I stumbled upon a fun one yesterday that cost me a couple hours of my life. I have a form with admittedly way too much javascript that was causing me to lose my mind.  For the life of me I couldn’t figure out why clearing a lookup field first would defeat the onchange event of all other lookup fields representing a relationship to the same entity (I had 5 custom currency fields on this form).  The events were attached using the .attachEvent in onload of the form (we use Stunnware Javascript Factory).  So to recap, I clear the first currency field, event for that field fires, all other events no long fire, no matter what. I tried re-attaching events to no avail. I was able to kludge a solution by firing all of the events as the page loaded. This seemed to work, but spawned yet another headscratching behaviour. When I prefired the events to “initialize” them, they then fired anytime the form was closed, sometimes multiple times for no apparent reason. My mind 3/4 of the way lost and suffering from my annual winter flu (flu shot? flu shot, I don’t need no stinkin flu shot…ok maybe next year) I decided to sleep on it and pick it back up in the morning with a cup of coffee and Star Wars the Clone Wars blaring in the background for the kids.

Cut to left side of couch, under afghan, cup of joe on the coffee table and SWCW blaring in the background…

Convinced I wasn’t losing my mind, I created the same scenario described above in a vanilla test CRM org. No Javascript factory, just painful text copied and pasted into the little javascript “editor” provided by CRM. Sure enough, the same behavior was observed. Aaah, I got 1/2 of my mind back…1/4 of it may be unrecoverable.  Anyhow, I tried one last gasp and moved the onchange calls into, you guessed it, the “OnChange” javascript “editor” in the CRM UI. Wouldn’t you know it, functioned as expected.

I’m not sure what the moral of this story is. I’m still going to use Javascript Factory because without it I’d have thrown myself off the top of the building long ago. Just in this case it needs a little…workaround.

CrMStain #2

February 3, 2011

Disabled users and disabled organizations can throw the whole multitenancy into the throes of an evil awful useless error message loop.

On several occasions I have received CRM authentication errors, asp.net errors in ISV content and other mysterious errors when I was either:

  • An active user in a disabled organization
  • A disabled user in the default (or other organization)

In both cases either enabling the disabled organization (which is not really a solution) or enabling the user fixed the issue.

Aaaaah CRM.

CrMStain #1

February 3, 2011

CRMStain numero uno…This little gem cost me more hours on multiple occasions…

My particular scenario starts with a reporting services report created in Visual Studio 2008 and connecting to the CRM database. When I run the report in VS, get results, report looks good, ready to go. I move the report to the CRM server by uploading through the UI using the existing file option. Run the report and strangely the report comes up and has some data…but not all. The report has been thoroughly unit tested and against the same entity record that is now mysteriously missing some data. So google is my friend and I begin my hunt. Nothing…a veritable dearth of information exists regarding the CRM/SSRS reports at the time but I do run into one interesting post that seems like it could be related.

In any event, I found a post that if I can find again I will reference here but for now I’ll just cut to the chase. The reason for my mysterious missing data was that the UILanguageId for the service account user was set to 0. Once updated to 1033, the missing data showed up on the report run from CRM.

So there you have it, CRMStain #1.

Hello world! Eh…Hello CRM World.

February 3, 2011

Hi all, I’m a software engineer using Microsoft CRM 4.0 to build a fairly complex Claims system for a major insurance company.  CRM wasn’t my 1st, 2nd or 3rd technology of choice, but given the company’s investment in the product, and an agenda or two, it became my technology of use.  I was like most developers who’ve been exposed to CRM at first.  I was intrigued but somewhat skeptical.  My skepticism has been tempered somewhat as I find the product to be fairly capable.  Of course this learning has left me with far too many CRMstains and scars as I’ve encountered head scratcher after head scratcher of bugs and features of CRM 4.0.  For a time it was my honest belief that when Microsoft needed a place to send a developer to die…it was the CRM product team.  So get to the point. This blog will be a place for me to recount and immortalize some of the great, some of the good, some of the bad and some of the downright awful things I’ve encountered with the product.  Enjoy.

Follow

Get every new post delivered to your Inbox.