Why CRM Developers should unit test their code

I haven’t written any unit tests for quite some time but I have decided to get back on the testing band wagon.  I will be writing more blog posts on unit testing but I thought I would start with a blog post about the benefits of unit testing.

When you mention unit tests to CRM developers or any developers is a bit of Marmite question.  Some developers love unit tests and some developers dislike writing unit tests and there isn’t much in the middle.

I believe most developers know they are beneficial but because they involve the tricky/boring setting up testing data and if you don’t write tests regularly they can seem difficult to write.

Writing Unit tests will mean you have more code to maintain but the benefits greatly out weight the negatives.

My experiences of unit testing and CRM projects is a lot of CRM practices are not using unit tests (I said this is my experience) or some of them write a few tests but this is usually down to the individual developer rather than a company process.

Why don’t CRM Developers unit test

Here are some of the common reasons/excuses

• It takes too long
• I haven’t got time
• Integration tests will test the code
• It’s too difficult to test CRM code because of PluginContext
• The company doesn’t make unit testing compulsory

Benefits of Unit Testing

1. You already test your code, make the tests reusable and available to others
2. Tests prove the code works
3. Unit Tests make you try to break and then fix your code
4. You can make big changes to the code and test the code still works
5. The tests can be run every time the code is changed
6. Testing is not slower
7. Writing code to be tested creates better code
8. Testing reduces the number of bugs in the code
9. Refactoring the code can be done easier and with confidence
10. It’s great when you get a green light
11. Unit tests make the code more readable and understandable
12. Testing before you code helps improve the design of the code
13. Writing unit tests stops coders block
14. Less bugs make it out of Development
15. Bugs unit tested stay fixed
16. Unit Tests will help you when you have forgotten the business logic
17. Changing code in one part of the system can break code in another part of the system
18. You only write test for the required functionality

You already test your code, make the tests reusable and available to others

When a CRM developer writes some code he often tests the code either by creating a console app or by debugging the code (either using the plugin profiler or remote debugging on the server).

I know you are testing your code because you have to test the code before you deploy it.  A lot of CRM developers hope they will find the bugs by integration testing and testing the code from the front end (the CRM web application).

The problem with integration testing is it takes longer to test the code and you have to create the data and test the functionality again every time.

Once you write a unit test to test one part of your functionality you can rerun the test again and again, instead of having to run through the process manually.

Instead of writing a console app or debugging the code, unit tests will enable you have tests you can rerun and more importantly you will have tests other developers can read and run.  If in the future another developer has to fix some code in that area they will have tests to help document the code and will be able to make changes and test the code.

Tests prove the code works

Writing and running unit tests shows the code works and passes the tests.  This depends on you writing effective tests but most of the time you will write tests to test the functionality required.  If you are using Test Driven Development you will write the tests first and then write the code.

Unit Tests make you try to break and then fix your code

When writing unit tests developers will often try to break the code by passing in Null values or unexpected inputs.  These are easy tests to write and help reduce easy/lazy errors from entering the production system.

Often if you are not unit testing the code you don’t think to write defensive code because the main priority is to test the functionality required

You can make big changes to the code and test the code still works

One of the main benefits of writing unit tests is you have created tests to test the functionality.  This means you can change the code and run the tests again to see if it still works.  You can refactor the code with confidence you can test it.

This is an important point for developers who are scared changing some legacy code because they are not sure what code depends on what.

The tests can be run every time the code is changed

Code can get changed lots of time particularly if it’s in a core piece of functionality.  Having tests which can be easily and quickly run every time the code is changed will give you confidence nothing is broken.

When bug fixing often CRM Developers will fix parts of the code they didn’t work on or have little knowledge of.  Unit tests will give the CRM developer confidence their fixes haven’t accidentally broken the code.

Testing is not slower

It would seem logical to think writing units would make the process of writing code longer.  The truth is this isn’t true.  A lot of the time spent on code is fixing bugs after the initial development is done.  Unit testing will help you find more of these bugs up front and reduce the time spent bug fixing.

Writing code to be tested creates better code

When you write code which is easily testable it tends to be better designed and adheres to the single responsibility principle and the code is more modular and reusable.

The developer will also spend more time thinking and designing the code.  Code which is easy to test is easier to maintain and has loose coupling and dependency.

Testing reduces the number of bugs in the code

When a developer writes unit tests they test their code in a more systematic approach and testing various different scenarios.  When CRM Developers manually test their code they usually go follow one or two successful paths through the code.

Refactoring the code can be done easier and with confidence

Refactoring the code can be a lot more confidence when the developer can test the code with unit tests.

It’s great when you get a green light

It’s a great to write a test and then get the green light.  Not only is it a small win it’s great to see how many tests you have running against a piece of code.

Unit tests make the code more readable and understandable

Unit tests

Testing before you code helps improve the design of the code

Writing tests before you have written the code will help the developer think about the design of the code, what they are trying to achieve.

When thinking about writing tests for code the developer will try to simplify the code to make it easier to test.   This process will make the code easier to maintain, debug, extend and understand.

Writing unit tests stops coders block

Writing unit tests stops developers suffering from coders block.  Coders block is when a developers gets overwhelmed by the task of designing the code and doesn’t know where to start.  Writing units tests gets the developer writing code and gives the developer an easy place to start.

The developer can refactor and improve the design of the code later and will be able to test the code works with the unit tests.

Less bugs make it out of Development

CRM Development is complex and the code can contain many bugs.  The aim is to squash as many in the development environment as possible.  Unit testing is one of the tools used to find and fix bugs.

Code reviews and integration testing are the other two main bug detectors.

Unit testing won’t find all the bugs and doesn’t mean you don’t have to do code reviews and integration testing but it will help the CRM developer to find some bugs in his code.

Finding bugs in the development environment is quicker than finding bugs in a production environment, logging the bug, recreating the bug, debugging the code, fixing the bug, retesting and pushing the bug all the way back up towards production.

Bugs unit tested stay fixed

When you fix a bug and unit test the fix, it’s more likely to stay fixed and if it isn’t fixed it can quickly be tested again.

Unit Tests will help you when you have forgotten the business logic

Unit tests are a great way to document the code because you it’s easy to see what the code should be doing by looking at what the test is testing.

Business logic fades (quicker than you think) so a developer has a bug to fix the unit tests will help the developer understand what the code should do.  The CRM developer will be able to quickly test the code with the unit tests.

Changing code in one part of the system can break code in another part of the system

I call this “accidental bugging,” and
it seems to occur a lot near the end of a software project, when developers
are under pressure to fix existing bugs. Sometimes they introduce
new bugs inadvertently as they solve the old ones. Wouldn’t it
be great to know that you broke something within three minutes of
breaking it? We’ll see how that can be done later in this book.

You only write test for the required functionality

You only write unit tests to test for functionality required.  This is a good way to stop developers adding in extra functionality which might be needed in the future.

More reading on why you should unit test

Is Unit Testing worth the effort? 

I Pity The Fool Who Doesn’t Write Unit Tests

Top 12 Reasons to Write Unit Tests

Write Maintainable Unit Tests That Will Save You Time And Tears

Hosk’s Top CRM Articles of the week – 27th March

Article of the Week

Building multi-tenant web apps talking to CRM
Great post from CRM MVP David Yack

Best of the Rest

Microsoft Dynamics CRM 2015 – Global Navigation UI Changes

Have a look at the new CRM 2015 navigation changes

Why developers need to be organised and stop wasting time

A Hosk Developer article about why developers should be organised and structured just like the good code they write

no code alerts from Leon Tribe

I like it when bloggers put codeless or no code solution in the title because I know what I’m going

Tip #349: Bulk delete in bulk over multiple entities

You can bulk delete over multiple entities, I never knew that

CRM 2013 – Error using Plugin Profiler – Could not load file or assembly ‘Microsoft.Xrm.Sdk, Version=5.0.0.0

Interesting error about debugging using the plugin profiler.  The plugin profiler used to debug must match the CRM dll

the CRM chart guy – Add Key Figures to Dashboards in MS Dynamics CRM

Another great blog from the king of CRM charts

CRM 2015 – Workaround for bug: “managed solution cannot be deleted”

Good article about deleting a managed solution which refused to be deleted

CRM 2015 – Understanding the plugin profiler and a puzzling error

A Hosk article about the plugin profiler

CRM 2015 SDK and the CRM 2013 developer toolkit

Getting the CRM 2015 SDK and CRM 2013 dev toolkit to play nicely.  Hey Microsoft where is the CRM Developer toolkit for CRM 2015, it’s been ages

CRM 2013 – How to change the field label size

The settings for changing field label sizes are hidden in the section!

Tip #351: Tracing for plugins and custom workflow activities

Tracing for CRM online

Using the Configuration Data Migration Tool with non-unique display name values

Scott Durow helps people understand and get round this gotcha

Turbo forms in CRM 2015 – interesting article from CRM MVP Mitch Milam

Great blog post from Mitch about the new turbo forms

Rollup fields

CRM MVP Jukka explains how rollup fields work

 

Last Weeks Top CRM Articles

Hosk’s Top CRM Articles of the week – 20th March

Useful Hosk Links

Hosk list Of CRM 2013 Tools

A list and review of CRM 2013 tools, this will probably work in CRM 2015 as well

Hosk’s CRM Developer Articles

A collection of my favourite CRM Developer articles I have written

MB2-703 – CRM 2013 Customization and Configuration Certification Information

All the CRM 2013 content to help you pass the exam

HoskWisdom – Hosk Developer Quotes

 Words of Wisdom from the Hosk.  I have written over 900 articles, surely I should have said a few memorable things

Why developers need to be organised and stop wasting time

In this blog post  I will tackle the subject of being organised in your CRM development.

CRM developers may not think being organised and structuring their development environment is very important and are already starting to think BORING.

Cluttered and unstructured development environments will contribute to a CRM developer wasting time on a daily basis.  Read more to find out why and how you can organise yourself.

It’s OK to be messy outside of work  but when developing you should have a professional mindset and be focused, organised and structured in your work.

Why are some people messy and some people tidy?

The brain is a mystery inside a riddle riding on the back of a conundrum, whilst sitting in the ear of a problem.  – Hosk

There are thousands of articles on the topic of being tidy/messy, what this says about your personality, how to be tidier.  Here is a little brain food snack on the subject

Unfuck Your Habitat: tidy advice for messy people

A messy (or tidy) desk may reveal personality traits, such as creativity, generosity: U.S. study

The Psychology Behind Messy Rooms: Why The Most Creative People Flourish In Clutter

Personally I am a messy person, I seem to enjoy clutter.  Maybe I am viewing this the wrong way, Tidy people cannot seem to be comfortable in an untidy/messy room.

If I were to guess I would imagine this must be linked to the brain and perhaps creative people are more comfortable with clutter, maybe due to creativity being an inspirational, unordered processes.

I am not yet persuaded either way with regards to the effects of tidy/untidy desks on a person, I believe tidy people write articles promoting tidy desks and people with untidy desk write articles about the boost in creativity of untidy desks and somewhere in between is a tidy desk with messy drawers full of stuff.

Tidying is a habit

I have trained myself (a bit) and have been trained (nagged) into being tidier and I have found this is a habit.  I read this book Level Up Your Day: How to Maximize the 6 Essential Areas of Your Daily Routine which had some interesting

• Tidy up the plates after dinner
• When you have finished lunch
• put the clean washing directly into the drawers and cupboards
• make your bed in the morning

You can also link the habits into a small chain

This article from the excellent Farnham street blog shows tidying and decluttering is a state of mind

The article is excellent (as is the blog), it made me think differently about clutter and why people persistently refuse to throw items away, despite knowing they are unlikely to use them.

I assume it’s part of getting older but I have become less attached to items/things in recent years and I enjoy getting rid of things.  Why hoard films, CDs, books I don’t plan on using again.  Decluttering is a by-product of having children when you have to get rid of all your stuff to make room for loud plastic toys.

Another article not about actual CRM Development

You might be wondering why is Hosk writing another article which doesn’t contain examples of code or customizations.

If you think how much time you spend actually writing code.  In my blog post Should you hire a Rockstar developer for your CRM project?

I mention what non-coding writing tasks developers have to do, not to mention the rule the more senior you become the less code you get to write.

• Gathering/understanding requirements
• Documentation
• Meetings
• Learning
• Code reviews/mentoring/explaining
• Code Design

Being a developer isn’t just about creating code and customizations, there are lots of other skills and knowledge you need to become a great developer.

Messy developers are wasting time

I said earlier I was an untidy person with a messy desk, my desk could be described

• untidy
• messy
• disorganized
• inconsistent

Having these traits as a developer will make your life harder not easier.

Some of the traits mentioned above are signs of a unprofessional\poor development and are mentioned in the article – The problems with complex code and complex CRM Customizations

Here are some of the main culprits of complex code

• Large methods – Monster methods
• confusingly named classes, methods and variables
• methods which do lots of things
• not consistent
• tight coupling
• dependent code
• poorly structured code

The result of complex code is to make the code/customizations hard to understand, modify, debug and extend.

If you were to replace the word method with folder you can see how being disorganised is making your development environment more complex and harder to use.  The harder your own development environment is to understand and use the longer everything takes.

Let’s take some points and translate them to the development environment

• Large folders which have lots of different documents in
• No structure to anything
• Poorly named folders, documents
• Internet browsers with lots of disorganised bookmarks
• No Standard approach to Documents
• Ad Hoc approach to TFS projects

The goal of being organised is to make things simplier, easier to understand and use, the same as the goal of writing good customizations – Why your CRM code and customizations should be simple

The concepts can be used when thinking about your development environment.

Manage complexity and make your development environment simplier

Examples

I was helping some junior developers set up some project code on their computer.  This involved checking some code out of TFS and then doing a bit of configuration.

They started off putting the projects in different locations

My Documents

C:\

Then we needed to get some DLL’s from the CRM SDK, we looked in 3 or 4 locations before we found the right folder.

The problem is only going to get worse the more projects the developer works on and the more versions of CRM which are released.

You might believe I am being picky but consider finding projects, SDK location, CRM tools/solutions, customer are very common tasks a developer will perform multiple times a day.  If the developer doesn’t know where these things automatically they will be wasting time every time.  This will add cumulatively over time and all these little bits of time will add up to a lot.

Why being organised/structured important for developers

I remember when England won the rugby, Jonny Wilkinson was like the David Beckham of English rugby, always delivering a brilliant performance on the big occasions and indeed kicking the winning drop-kick.

Like David Beckham Jonny Wilkinson was a prodigious practicer, he would spend hours kicking, kicking and then some more kicking.

Wilkinson had a distinctive technique which would involve going through exactly the same steps for every kick, one part of preparing for the kick is putting his hands together

you can read about his technique

It’s all in the hands

How Do I Kick Like Jonny Wilkinson? A serious kicking regime

Wilkinson himself breaks his regime down into four parts – ball position, measuring the run-up, visualising the ball flight and striking the sweet spot on the ball.

The process Wilkinson goes through during every kick is aimed to focus just on the action of kicking the ball and blocking out all the distractions.

If you compare this to CRM development, there are lots of distractions trying to take your focus away from doing the CRM development

• People
• Where have I put that file
• The internet

You need to block out the distractions and focus on the CRM Development, e.g block out the noise.

What can CRM developers learn from this

In my article Good CRM design should not make users think 

A well designed CRM system is where users use the system instinctively without needing to stop and think – Hosk

If a user stops to think, the user experience goes down and ease of use drops right off, whilst the user searches for clues for where to go or what to do next.  This is time wasted thinking about what to do rather than doing it.

A similar experience can happen to developers if they have not organised their development environment.

A disorganized development environment will lead to the developer searching for files/tools/documents/source code instead of developing.  If this happens on constant basis the developer can not only have their concentration broken but they can waste lots of time.

Consider the effects of disrupting your focus, developers often need to focus for blocks of hours and disruptions can break you train of thought.

What should be ordered in the developers environment

There are lots of areas of your development environment which should be order the

Folders

I believe it’s important to have consistent folder structures on your computer for each of these areas

Projects

CRM versions

Documentation

I put  my projects in a folder C:\Projects, I know where to look for each project I have checked out of TFS.

I have a CRM  year number (CRM 2013, CRM 2015) off the project folder.  Inside the CRM version I have a folders

• SDK
• Tools
• Solutions
• Books
• Documentation

Servers

You will have lots of CRM servers (front end, back end), SQL servers and maybe some other servers.

Have a consisten folder structor and include the same tools on each server.

C:\Company name

you could have folder for tools, documentation, config, 3rd party software, Release

It will will help to have a consistent deployment process, this will not only help with the deployment process but will also help you see what has been deployed and older solution files which might be needed to rollback changes.

Internet Browsers

Don’t have an ever growing list of bookmarks, which slowly grows bigger and bigger.

Use the favourites bar and use folders

Staying up to date with CRM

This isn’t really the development environment but I will add it.

Get an RSS reader software (feedly, Netvibes, outlook, pulse).  Subscribe to popular CRM blogs.  If you want a list of CRM blogs check out step 1 on the blog Tips to boost your career in Microsoft Dynamics CRM

Twitter

You can get windows applications but Tweetdeck is a fantastic chrome extension.  I would then setup a list to follow some great CRM tweeters.

CRM Admin

Create a CRM admin users for each CRM organisation, make this user a deployment administrator.  This stops the potential problems which can arise when you lock this functionality to individual users.  When the CRM admin, deployment administrator is a single user

The Benefits of an ordered and structured environment

Your development environment should be structured and organised so you can use it quickly, efficently and without thinking.

Your development environment should be consistently structured, so when you switch between projects you know exactly where to look.

The benefit of an organised development environment is it doesn’t slow you down or make you stop to think where to put or where to find items.

Like code you will need to refactor your development environment to ensure it doesn’t get too messy and complex.

Unstructured development environment seems like a small sin but due to the high usage, slower usage will be multiplied many times during a day/week/month/year and could cost a developer a great deal of time by the end of the year.

CRM developers spend enough time on non-coding tasks, don’t reduce the time you have by wasting it on navigating your development environment.

CRM 2013 – Error using Plugin Profiler – Could not load file or assembly ‘Microsoft.Xrm.Sdk, Version=5.0.0.0

I was working on a project and one of my plugins was throwing an error, so I fired up the Plugin profiler to debug it.  This is the second article I have written about the Plugin Profiler this week

CRM 2015 – Understanding the plugin profiler and a puzzling error

If you want some step by step instructions for debugging with CRM 2013 Plugin Registration tool, this article is pretty good

Debugging online plugin in CRM 2013

Error whilst debugging

I loaded up CRM 2013 plugin profiler, oohed and ahhed at the spruced up appearance.

I installed the profiler

I triggered by plugin by creating a record

This gave me the serialized error, I downloaded it.

Debugged in the Plugin registration tool, choose my dll and downloaded txt.

Attached to the process in Visual Studio and started debugging.

The code instantly threw an error

Could not load file or assembly ‘Microsoft.Xrm.Sdk, Version=5.0.0.0

I have seen many CRM error in my time and they are usually a bit misleading but this error told me it couldn’t load the Microsoft.Xrm.Sdk version 5.0.0.0

The CRM SDK has versions which are different from the CRM release, it is what CRM would be if it used sensible numbering instead of years.

e.g.

CRM 2011 – Version 5.0.0.0

CRM 2013 – Version 6.0.0.0

CRM 2015 – Version 7.0.0.0

You can see the CRM SDK versions if you go to this page

CRM SDK 2013 Release History

CRM SDK 2015 Release History

The zero’s will go up as service releases and patches are released by the important number is the first digit.

I was debugging a CRM 2013 instance but it was complaining about a missing CRM 2011 SDK dll!

Let me try something

I had a thought, why don’t I try using the CRM 2011 plugin registration tool but surely this wouldn’t work.

So I connected the CRM 2011 Plugin registration and used it to debug my plugin.

Now I have to admit I wasn’t expecting it to work but

What has happened

It seems I am working with a CRM 2013 project but the DLL’s used in the plugins are CRM 2011, I went off to check the dlls being used by the plugins

I’m guessing someone created a new CRM project and copied the DLL’s from a CRM 2011 project.  This will work fine unless you need to use any of the new functionality in the CRM 2013 SDK.

It might also bring up an unusual error sometime in the future.

It’s interesting to note the core plugin functionality is the same between version CRM 2011 and CRM 2013.

 

CRM 2013 – How to change the field label size

I had created some new fields, I put them onto the form and I found I couldn’t see half of the text, GRRRR

This was very annoying, annoying like The most annoying type of airline passenger is 

There must be a way to resize fields

I clicked on the field but couldn’t find anything useful

 

Engage Critical thinking

I was sure somewhere you can change this setting.  I was sure I have set the labels to be above the fields.

Thinking critically I thought the next possible place to set fields will be the section and there it was

You Label width for all the fields in a section is held in Display – Width

In formatting you can also set the alignment and label position

 

I changed the width to 200 and bam I could see all the text

CRM 2015 – Understanding the plugin profiler and a puzzling error

I am a big fan of debugging my plugins using the plugin profiler, it’s easy, quick and you can do it on your own computer without adversely affecting any fellow developers

The alternative for debugging plugins is to debug on the server, I usually don’t like doing this because if the plugin is not in the sandbox is can stop the whole server and I have personally found remote debugging doesn’t always work with the debugger dropping off after 30 seconds.

Puzzling problem with the plugin profiler

Recently a CRM developer was debugging using the plugin profiler and he had a puzzling problem

He was creating a plugin which fired on post event of creating  which when a new entity was created, it created a Task, which referenced the newly created entity.

Here is a brief description of what the code was doing

• created a new task
• update the description on the task
• set the Regarding to be an entity reference to the newly created Entity

The code was erroring, the CRM developer was puzzled.

This problem is what I would call a CRM riddle and to get to the answer you need to do a bit of thinking.

When you are investigating a bug you need to reject your prejudices and biases.  You probably have an idea of the cause of the problem and it’s fine to check this first but if it isn’t the cause you need to make sure you are systematic and logical in your investigating.

I have written a blog post recently where I have investigated a bug, you need to investigate bugs like Sherlock holmes looking for clues – Sherlock Hosk and the case of the annoying bug

When debugging, eliminate what isn’t causing the problem and whatever code or customization is left must be the culprit. – Sherlock Hosk 

When testing your code I alway feel it’s just as valuable to find out what isn’t causing the problem because you are narrowing down the list of potential causes for the bug.

This highlights the process you should use, methodological, changing one variable at a time.

In the article Why all developers should be friends with a cardboard developer,  I suggest, you get the cardboard developer to stand next to you.

• You have stepped back from the problem, you have stopped to think
• Go through step by step
• Explain what you want to happen
• Explain what is happening

For debugging I would add these points

• change one variable
• Test to see if problem is resolved
• repeat

A mistake a lot of CRM developers make when testing for a bug is changing lots of variables and then not knowing what change has resolved the problem. If you do this you are now in a pickle because it means you have to change all the variables again or get the customer to change all of the variables to resolve the problem.  The other choice is you test again, changing one variable at a time.

Understanding the plugin profiler

To understand the problem you need to understand how the plugin profiler works.

Here is a good step by step guide

Debugging online plugin in CRM 2013

When you turn on profiling the profiler works by capturing all the data being sent and serializing it all into a file and then throwing an error.

This is why you see the error message

#exception (Recommended)

When the profiled component is triggered, an exception will be thrown with the compressed profile in the error message

Below is a picture from the step by step guide above

This is really like adding some code at the end of your plugin throws a InvalidPlugInExecutionException, which would roll back the transaction and not save those changes to the CRM database.  (I’m not sure it does throw an InvalidPluginExecutionException but I am saying it acts as if it does)

This allows you to keep running the test without the plugin creating/updating any records in CRM.  It means you can trigger the plugin multiple times.

Back to the Problem

We know when using the Plugin profiler to debug records don’t get updated or created.

This plugin was being triggered on the create message of a record. Let’s say it was the contact record.

The user put in the contact details, pressed save to create the contact record. This action was captured by the plugin profiler and saved to a serialized file with the InvalidPlugInExecutionException so the record was not being created.

The CRM developer was stepping through the code using the plugin profiler.  The plugin was creating a task, the next step tried to set the regarding to the newly created record.

The problem was being caused by the plugin profiler.  The CRM Developer was running the code in the plugin profiler the on the create of the contact record, the code was creating a new task record and attempting to set the regarding on the task to the newly created contact record but it was throwing an error because the contact record didn’t exist.

When the CRM developer turned off the plugin profiler the code worked fine but this left him confused for a while.

Understanding the how CRM works is important

I am often saying in blog posts

Always start with the CRM SDK

When I say this I mean CRM Developers should first look in the CRM SDK to see if they can understand how this part of the system is working, try to understand the underlying logic of CRM.

Most developers find example code by taking the easy option and searching the internet, finding a code example which someone has written, copying and modifying and using it.

The problem with this is you don’t learn how or why the code works and the CRM developer will not understand the process behind the code.

When you try to create the code yourself, you will experience lots of small errors but overcome them.

CRM Developers first find out how things don’t work to understand how CRM customizations do work – Hosk

In my blog post CRM 2013 – How to get guid of initiating record in CustomWorkflow

I couldn’t work out how to get guid of the initiating record of a custom workflow.  The reason for this was the plugin context passes in a target field and this has the initiating entity.

Custom workflows do not have a target instead they have PrimaryEntityId.

I found out this information by looking in the CRM SDK and thinking about the problem.

The puzzling plugin profiler problem puzzled the CRM developer enough to ask me what was going on, why did it work when the CRM developer stopped using the plugin profiler?

It’s important to understand how CRM works because when things go wrong and errors start popping up, this is when understanding how CRM customizations work will help you work out what the problem is but if you haven’t stopped to learn how things work then they will continue to be a mystery and resolving the errors will be very difficult.

What does the CRM SDK say

if you search the CRM SDK for plugin profiler you will probably get to this page

Analyze plug-in performance

This is a great page with lots of information, below is an excellent description of how the plugin profiler replay works

Replaying plug-in execution does not require a connection to a Microsoft Dynamics CRM server and organization. The advantage of this method is that you can obtain the plug-in execution profile from a customer and debug the plug-in remotely. A restriction of the replay feature is that you cannot change the sequence of calls your plug-in code makes in the debugger while you are debugging.

The replay feature provides the plug-in with a snapshot of the call data and event execution context from the Microsoft Dynamics CRM server. You are getting the same events, GUIDs, and so on from calls to the Organization service but no data is being modified on the server as you debug the plug-in. During the debugging procedure in the previous section, the plug-in actually connects to the server and makes calls in real time.

Whenever I read the CRM SDK I always learn something new, here is what I learned from the paragraphs above

• The plugin profiler doesn’t need a CRM connection to work
• You can profile on a customer production system and debug remotely
• You get a snapshot of the data -same events and same guids
• No data is being modified

Hosk’s Top CRM Articles of the week – 20th March

Article of the week

turn CRM green

The article of the week showcases the new themes which look awesome.

What’s new for Microsoft Dynamics CRM Online 2015 Update 1

An overview of the new functionality coming in CRM 2015 U1 and if you are not sure why shoul read it then read this – Why you should read the What’s new for developers CRM 2015 SDK 

Best of the Rest

The rest of the article are mainly around the new CRM 2015 highlights and functionality

CRM Online (Carina) API Enhancements Highlights

Tip #346: Scheduling daily bulk delete jobs

This is one of those tips which is good to know because you might need it sometime in the future

Hosk CRM DEV Tip – Always filter your queries

Why you should always filter your queries in CRM.

What’s New with CRM Online (Carina) Highlights

Why all developers should be friends with a cardboard developer

Also known as rubber ducking but this is a method to help you resolve your problems yourself without wasting your fellow CRM Developers precious time

A few interesting things I learnt from the many convergence 2015 tweets

The Hosk’s very brief twitter  highlights from convergence 2015

Release history for the CRM SDK

Interesting I have never seen this document before

get ready for the next release CRM 2015 UR 1

A General overview of the new functionality coming your way

Dynamics CRM 2015 Update 1 SDK assemblies preview (7.1)

You can get the new assemblies quicker if you tick the preview button

http://leontribe.blogspot.de/2015/03/marcs-lemonade-stand-2015.html

CRM MVP Lleon Tribe gives the low down on salesforce using a lemonade stand so everyone can understand

CRM 2015 – resizing the social tab

it is possible to resize the social tab, find out how

CRM 2015 new release has themes

you can change the colour and add a logo

Deploying a CRM2015 solution to CRM2013
Good article on deploying CRM solutions

CRM 2015 roadmap

What changes are coming down the pipe

See what’s new in the CRM2015 Online Update 1 ‘Carina’ SDK

Last Weeks Top CRM Articles

Hosk’s Top CRM Articles of the week – 13th March

Useful Hosk Links

Hosk list Of CRM 2013 Tools

A list and review of CRM 2013 tools, this will probably work in CRM 2015 as well

Hosk’s CRM Developer Articles

A collection of my favourite CRM Developer articles I have written

MB2-703 – CRM 2013 Customization and Configuration Certification Information

All the CRM 2013 content to help you pass the exam

HoskWisdom – Hosk Developer Quotes

 Words of Wisdom from the Hosk.  I have written over 900 articles, surely I should have said a few memorable things

A few interesting things I learnt from the many convergence 2015 tweets

The main thing I learnt from convergence is people tweet too much about convergence 🙂 Particularly the CRM MVP from new Zealand – nzCRMguy , who I’m sure broke my twitter feed at one point.  To be fair he did tweet a lot of excellent tweets, it was just rather frustrating to read them a little bit at a time.

I don’t deny this blog post is also part frustration at having to watch convergence 2015 from twitter rather than being their in person, I’m sure if I was there I would be tweeting my head off.

You will probably read a lot about convergence and the new functionality coming in the next CRM 2015 release but here a few things I found  interesting.

The tweets come from

CRM MVP Jukka Niiranen

https://twitter.com/jukkan

CRM MVP Mark Smith

nzCRMguy

CRM 2015 – Themes and branding

My initial thought was woohooo.  Changing the colours and branding is an often requested by customers and the previous way was to change an image file on the server.  This was unsupported (but mostly harmless) change.

One reason changing CRM was useful was customers wanted to distinguish betweeen their different environment e.g. DEV, TEST, PROD.   The branding feature should easily allow this to happen

Most Recently used

Any changes to the CRM 2015 navigation are welcome because it is one of the most difficult and frustrating layouts I use.  It’s hard to find things and difficult to navigate.

Most Recently used looks like a bit like favourites but it is a list of the recent records you clicked on.  This should be useful and speed up navigation

Also the new MRU (Most Recently Used) menu in #CRM2015 Spring with pinned items is pretty sweet #MSDYNCRM #UX #CONV15 pic.twitter.com/IwW7tXPTcv

— Jukka Niiranen (@jukkan) March 16, 2015

New Nav Bar

Yes the NAV bar has been updated, this looks a lot more user-friendly.  It’s a big improvement because it shows all the options on one screen, so you don’t have to scroll about to try and find the option you want.  Well done to Microsoft to listening to the feedback and improving the CRM 2015 navigation

The new Nav Bar for #CRM2015 Spring Release looks a lot more user friendly, don't you think? #MSDYNCRM #UX #Conv15 pic.twitter.com/hncjHm9nQW

— Jukka Niiranen (@jukkan) March 16, 2015

Solution packaging

I like the sound of packaging data inside a solutoin

Solution + data + import actions

Whats New in 6.1 ("Leo") #MSdynCRM #Conv15 pic.twitter.com/YznesujFvR

— Mark Smith (@nzCRMguy) March 18, 2015

Unmanaged and managed solutions

The order matters and unmanaged customizations can be overwritten by a managed solution in some circumstances.  To be honest I’m not quite sure what this means but what I did think was this doesn’t sound good

Unmanaged and managed together in CRM #MSdynCRM #Conv15 pic.twitter.com/964gElE4co

— Mark Smith (@nzCRMguy) March 18, 2015

Hosk CRM DEV Tip – Always filter your queries

Is important to keep good habits and keep your CRM solutions zipping along and in most CRM projects there will lots of queries retrieving records related to the main record.

CRM queries should like Bruce Lee one inch punch.  Mean and Lean with no wasted actions

The one inch punch is so awesome it has it’s own wiki page

The one-inch punch is a punching exercise from Chinese martial arts (kung fu) performed at a range of 0–15 cm (0–6 in). The one-inch punch was popularised by actor and martial artist Bruce Lee. It is designed to improve punching power and technique.

Your CRM code should be as simple as possible 

CRM code and CRM queries should be as simple as possible but not simpler

Last year I was doing some optimization and one of the main culprits of poor performance was due to queries not filtering and returning all rows.  There were examples of no filtering in OData in Javascript and plugins.  You can read more about my investigation into CRM performance here

What to look for

• new ColumnSet(true))
• Odata queries with no “filter=”

what are the consequences of not filtering your queries, apart from being on Hosk’s naughty list

Poor performance

The downside of not filtering your queries is you are returning fields you don’t need, this will cause the query to take longer to run and bring down more data for every row returned in your query.

The bottom line is your queries are going to take longer and the more rows you return the worse the performance.

Updating all fields which can trigger more actions

When a query has selected all the fields for an entity another mistake the CRM developer can make is to update the record which updates all the fields in the record.  This can

• Creating confusing audit trails with fields being updated but not changed
• trigger workflows and other plugins

I have had some conversations with customers asking why the audit record was saying a field had been updated but no one had changed the field.

The triggering of other plugins/workflows can not only have contribute to poor performance but also trigger new records and values being changed.

Code review shaming

Peer reviews are a great way of stopping poor code like this entering your code.  If the CRM Developer knows the code is going to be code reviewed they are less likely to take shortcuts, write poor code because they know it will be found in a code review.

If a CRM developer does write queries without filters then the code reviewer knows they need to be watched because they are a lazy coder.

Lazy coding

In my blog code Bad code is like a virus, don’t get infected I mention the broken code theory.

If the no poor code had been checked in, the CRM developer would see the code checked in is a high standard, the developer understands the code in this project should be a high standard and will follow the herd checking in high-quality code

If the code repository has been infected with bad code the CRM developer will see it’s OK to check in poor quality code, the easiest action for the CRM developer to take is the quick and easy fix, which is of lower quality and will cost you more time in the long run and make it harder to change the code in the future.

I believe you need to keep the coding standards of a project as high as you can and ensure CRM developers adhere to best practise.  Once bad code gets into source control then you will soon find it starts to grow as other CRM developers check in similar quality code.

Finally

There is no excuse to not filter your queries so don’t do it.

 

Why all developers should be friends with a cardboard developer

I read an article  about a development team who used a cardboard developer.  The team had acquired a life-size cardboard person who they welcomed into the development team.

If anyone in the team had some code which wasn’t working, before asking another developer to sit with them to look at the problem the person had to first get the cardboard developer, stand him next to them, explain the problem to the cardboard developer, run through the code with him to see if he could help see the problem.

I have also learnt this process is known as Rubber duck debugging from the excellent book

The Pragmatic Programmer

The funny thing about this story is quite often the cardboard developer would help resolve the problem.

How exactly does a cardboard cut out help solve development problems and why aren’t companies deploying armies of them.

Stop! walk through the process step by step

The truth is people can often solve their own problems, once they understand the problem and walk through it.

This is what I would term as

can’t see the wood for the trees

This is a saying which regularly gets said, but I’m not sure everyone understands what it really means

Here is an explanation

Meaning: If you can’t see the wood for the trees, you can’t see the whole situation clearly because you’re looking too closely at small details, or because you’re too closely involved.

In terms of CRM development you can get  absorbed in a problem, the methods you have already tried to resolve it, you can get to a point where the CRM developer stops thinking logically about the problem.  For coding problems in particular you can get too close to the problem you forget to use a systematic process of trying to resolve the problem.

A classic example of the cardboard developer – Grumpy IT person

I’m sure many people have called the IT person in their organisation only to find they have given him the role of cardboard cut out.  You calmly explain the problem to the IT person (who is usually grumpy grumpily) to come and try and solve your problem.

When the IT person comes to your desk you go through the steps and it works perfectly and the IT person grunts and goes back to his warm nest away from troublesome users.

Many times I have asked someone to look at a problem and then as I was explaining it to them I instantly knew the answer.  It’s a similar sensation to not hearing someone, saying pardon and then your brain belated tells you what they said.

Why does the Cardboard developer work?

The reason the cardboard developer or any inanimate object works (it helps if it resembles a person or you feel stupid explaining your problem to an apple) is when you explain the problem to someone/something you

• You have stepped back from the problem, you have stopped to think
• Go through step by step
• Explain what you want to happen
• Explain what is happening

Developers often have to do the same/similar tasks many times they often

• Engage autopilot
• Stop thinking and just do
• Miss steps/Take shortcuts
• rush

Why should you use the Cardboard developer?

The main reason you should try using the cardboard developer is so you stop wasting other developers time when you could resolve the problem yourself.

Developers need to concentrate for a prolonged uninterrupted section of time (hours) to create a coding solution, this process involves concentrating on a problem with lots of trial and error.  Breaking this concentration for a developer to come and stand by you whilst you resolve the problem yourself can be frustrating for the developer who you have walked round the office and embarrassing for yourself for wasting the developers time.

To avoid wasting developers time I would advise getting up from your desk, going for a walk at lunch, making a cup of tea.  The act of stepping away from your computer will allow you to look at the problem with fresh eyes.

Make sure you use the Cardboard developer to go through a problem first before asking someone else.  I’m not advocating you sit and suffer with a problem but you should make sure you can’t resolve the problem yourself first.

This blog describes why Developers should not be disturbed

Why programmers work at night

or this graphic shows the process which I got from here

Today I used the Cardboard developer

Everyone has to use the cardboard developer and today I should have used the cardboard developer but instead I brought over Sir Les (senior CRM Developer) over to my desk.

I was creating a new development organisation.  I had imported a number of managed and unmanaged solutions.

The next stage was to import some data, I selected the file, press next a few times but then was puzzled why the entities weren’t in the drop down list?

I couldn’t think of any reason why entities don’t appear in drop down lists for importing?

So I got senior developer over.

The act of having someone looking over your shoulder suddenly gets your brain working with more focus.

Have you guessed the problem yet?????

Yes, suddenly it came to me,  I had imported some unmanaged solutions.  Unmanaged solutions need to be published (managed solutions are published automatically).  To understand the intricacies of solutions read my blog post – Understanding how CRM solutions work

Sir Les of CRM Shire was thanked and sent back to his desk, he helped me resolve the problem without doing anything.

Next time I will try explaining it to the cardboard developer before wasting a real developers time.

Check out the Dando the box man adventures

Here and here