Questions on Microsoft Dynamics CRM solutions and environments

The art and science of asking questions is the source of all knowledge.

Thomas Berger

I was asked some questions about solutions in Microsoft Dynamics CRM, I decided to answer using a blog post so other CRM developers could benefit.  If one person is asking the question there are probably many more people thinking it.

Posting the answer to a question on my blog means other people who are having the same problem can find the answer.

Solutions

Understanding solutions is a something a CRM developer must master,  getting it wrong can cause problems deploying and managing your customizations.

The blogs below will give you a good understanding of Solutions, how they work and many of the common problems you experience with solutions (usually managed solutions)

Here are the questions

Q.  All changes made to any (unmanaged) solution are applied to the default solution.

A.  All changes to an unmanaged solution are applied to the default solutio,  you can’t undo the changes except by importing an older unmanaged solution, which is like rolling back those customizations.

Importing an unmanaged solution will overwrite any of the customizations included in the unmanaged solution (assuming the system only includes unmanaged solutions)

Q.  Multiple developers are able to work in parallel on the same entities as all changes are applied to the default solution. Everyone has sight of all changes at all times.

A.  If you are working on the same CRM environment, changes  will be visible instantly to all developers but only published changes will be visible to customers.

  • Fields, views, new entities will be visible instantly
  • Form changes will be visible when the developer publishes the solution

Code changes are different due to the way CRM developers work e.g. CRM developers tend to download a copy of the code (Javascript or plugin) work on the code and then upload when ready.

Developers usually get the latest code from TFS or the source control used in the project rather than getting the latest code Javascript from the CRM form.  This process can result in developers overwriting changes if they are both working on the same Javascript or plugin at the same time because they work offline whilst coding.  You can work around this by setting up processes and source control is your friend.

This blog post discuses multiple developers working on web resources

How do multiple developers work on a web resource within the CRM environment

Q.  Removing the unmanaged solution does not remove the changes in the default solution – these have to be removed manually (or the default solution can be restored (snapshot tools like Cobalt look good and free? Can they be used to perform a rollback in Dynamics online?)

A unmanaged solution is a wrapper to move your customization’s between CRM environments.  When imported it imports those changes into the default solution, overwriting any existing changes.  Deleting the unmanaged solution will delete the solution but not delete the customizations.

Managed solutions can be thought of as read only to the customer.  You cannot modify any of the managed components (unless they are the default CRM fields).  Deleting a managed solution will delete the customizations and the data.

To remove unmanaged customizations you must delete them manually.  Solutions are additive which means they don’t remove customizations.  You can use unmanaged solutions to change the customizations back to previous state.

I haven’t used Dynamics CRM Snapshot from Cobalt but looking at the page it seems to snapshot the data not the solution and customizations

You can create snapshots of your customizations by keeping the solution files so you can import them to roll them back.  Remember to use version numbers otherwise it’s difficult to manage and keep track of the CRM solutions, particularly if you have to move the solutions through multiple CRM environments.

Version numbers are mentioned in the blog post CRM 2015 – Best practices for CRM Deployments

Q.  Managed solutions are essentially a container for any changes you want to move to a new environment. Care must be taken to ensure that all of the relevant changes to entities are pulled into a release. It will become clear when the solution enters UAT if dependencies have been missed.

I have written about Managed solutions CRM 2013 – Managed solution problems with out of sync solutions.   Only a solution from the same publisher can update the customizations in a managed solution

Why use managed solutions

Choosing your solution strategy is an important because it can be difficult to swap back from a managed solution to an unmanaged solution.  There is anxiety before you make the decision and push the button and import a managed solution.

There are many choices you have to make in CRM which are very hard to undo like

CRM Entity ownership – How do you decide?

I have talked to CRM developers who hate managed solutions and only deploy unmanaged solutions. I have been asked numerous times why anyone would use a managed solution, so lets investigate the reasons.

The logic behind a managed solution is two fold

  1. Managed solutions are read only to protect the customization creator from users and CRM developers taking and changing the customizations
  2. Stopping users from changing the customizations which could result in the customizations not working or working incorrectly.

Managed solutions are great for CRM resellers who created a solution for CRM which acts like a products.  E.g. an Autonumber solution.  They can sell the Autonumber solution, it’s gets deployed and the users can’t change any of the code to stop it working and other CRM developers can look at the code to steal the code/ideas.

This scenario is ideal for managed solutions because if the users change their mind and don’t want to use the solution they can uninstall it and it removes all traces of the solution and its data.

Q.  If managed solutions are removed from an environment any data would be removed as well – so we should NEVER remove a managed solution but instead apply a new managed solution on top.

When you remove a managed solution it removes everything

  • Customizations
  • Data

Once the data is gone you can’t get that back, which is why you need to think carefully if using managed solutions are the right choice.

I know many CRM developers who refuse to use managed solutions due to

  • Build problems
  • unable to edit production/live system without importing a new solution
  • Solution dependencies

Unmanaged solutions will give you an easier life but it will potentially let end user modify live customizations which could break the solution and with no easy way to know what had been changed.

CRM 2016 has added patched solutions

Solution patching allows you to release smaller solutions, creating smaller solutions and reducing conflicts and problems when deploying the patch solution.

I haven’t used patch solutions so I don’t know if the theory works in practice.

Q.  Environments setup question

Dev – unmanaged default solution with project related solutions.
UAT – Test environment that managed solutions are deployed into.
Live – managed solutions transition to prod when successfully passed UAT.

There is no right answer for the number of environments, it depends on the development and testing schedules you are doing, how you work with the customer.

The number of environments can reflect the different phases of a project,  you can often have testing and development phases running at the same time.

Ask yourself what is the purpose of each environment.

I would add a preproduction environment, an environment which is hosted on the customers site or a sandbox instance if using Microsoft Dynamics CRM online.  This environment has exactly the same customizations and similar data to the production environment.  It allows the customer to test near production environment and is useful for investigating live issues.

For on premise development it’s common to have a development environment and internal QA/UAT environment for non developers to test fixes.  Developers are terrible at testing their own fixes

The usually test as CRM Admin role – The System Administrator role is a benefit and a curse to CRM developers

They often only test the happy path –Don’t just test the happy path

Development environments have development data – How to create realistic Test Data for your CRM Project and why you should

Here is some final reading on CRM environments for you – The pain of setting up CRM Dev environments

Why isn’t code reused in Microsoft Dynamic CRM projects?

Microsoft Dynamic CRM code and customizations are rarely reused between projects and few companies create solutions to share between projects. This means CRM companies need to rewrite the same code again for each project but is there an alternative method.

CRM projects focus on delivering solutions but don’t to reuse solution and code.  In many companies CRM developers can create different versions of the same solution.

When developers work on projects they are focused on delivering a solution to meet the customers requirements.  If time the developer will

  • Improve code design
  • Refactor code
  • Reduce technical debt
  • Unit test code
  • Update documentation

The tasks mentioned focus on long term benefits and the reason they are often omitted.  Improving code design and refactoring make code easy to understand, extend, debug and maintain, these steps are unnecessary but make a huge different in maintaining the code.

The difference between good and average CRM developers can’t be seen in functionality delivered to the customer because they will be the same.

This posts

Why your CRM code and customizations should be simple

The problems with complex code and complex CRM Customizations

It’s difficult to simply code, refactor and improve the design, a reason average developers omit those steps.  Explained beautifull by Martin Fowler

“Any fool can write code that a computer can understand. Good programmers write code that humans can understand.

Martin Fowler

Simple code reduces time spent debugging, maintaining, understanding and interacting with the code e.g. further phases of development.  This explains why failures in CRM projects often occur after the first release of a CRM solution when the CRM developers struggle with a messy solution.

Other signs you CRM project is doomed can be found in this article 13 signs your CRM project is doomed

I have worked on a project where a plugin had a method which was over 1000 lines long.  This method became a bottleneck in the project because developers struggled to understand what it did or how it worked.  Small changes took hours whilst developers tried to understand the code, work out where to put their fix and testing the fix hadn’t broken existing code was impossible because the code was to complex to unit test.

Custom code

Most CRM projects will have custom entities which exist only in the individual project to either make the customers business processes or needed to deliver the required functionality.

Writing bespoke projects often preclude the project code and customizations being reused because the customers requirements are not needed in other projects.

CRM developers who don’t use solid principles to reduce coupling in their code are unlikely to be able to reuse code.

Code cannot always be be reused because of unique requirements, most of the time CRM developers don’t think about reusing the code or writing it to enable reuse.

New project, new code

Before software can be reusable it first has to be usable.”
– Ralph Johnson (computer scientist)

Reusing code is a great, you can add code which has already been written and tested.  It takes more effort to write reusable code, to write code in a generic way ensuring there are no dependencies on the current project.

Developers are not rewarded for code reuse or encouraged to write reusable code and customization’s by their employers.  Without motivation or reward why would developers go to the extra effort of writing code which benefits developers/company in the long term?

To write of reusable code you need skilled developers, sometimes called craftsman.  Highly skilled developers, take pride in their work and consider long-term implications of their code and who look to reuse code.

Most CRM projects are run with short-term goals in mind, answer these questions about Microsoft Dynamics CRM projects you have worked on?

  • How often do CRM developers reuse code from earlier projects?
  • Do CRM developers know what earlier projects did to understand if any of the code or customizations could be reused?
  • How many projects is the code good enough to be reused?
  • Does anyone look at previous projects to see if they could create a generic reusable project?

Companies don’t reuse code or catalog CRM projects.  CRM professions and CRM developers move companies often, most existing and new developers didn’t work on earlier projects and are ignorant of them.

Interaction with historic projects usually occurs when a bug is raised or through a change request.  If you are unluckily enough to be dragged into an old project, they are legacy projects with code and customizations arranged in a baffling structure taking days to decipher even the simplest of bugs.

Is there another way?

Wouldn’t it be great if new CRM projects were created by plugging together small separate solutions.  It would be quicker to create solutions like this and the code would have already been tested.

CRM developers could look at old projects for common functionality that could be reused in different projects.

Identifying functionality which could converted into a generic reusable solutionIf the solution was useful it could be sold but at a least it could speed up development on new projects needing that functionality.

This would involve taking a long term view of CRM development and ensuring their CRM developers are writing quality code and customizations.

Why doesn’t code get reused

Code reuse has many advantages but I haven’t seen any examples of code reuse in the projects I have worked on. I have listed some potential reasons for this below

Developers

A lot of developers don’t love writing code and to them it’s just a job, this shows in the quality of their code.  They are not passionate about it and certainly wouldn’t classify themselves as craftsman.  I don’t enjoy decorating, I take shortcuts and aim to paint a room as fast as possible.  The lack of enthusiasm and passion for decorating the room, shows in the finished product, I spot bits I missed and drip marks.

The same result can happens with the code of people who don’t enjoy developing,

To write simple code you will have need to want to improve, the best way is to have a mentor but you can get a paper/electronic mentor by reading classic books on programming or have a mentor to teach you.  I recommend

CRM companies have s high churn rate, offering small payment increases to staff based on their current salary.  LinkedIn pressures this model with recruitment agencies offering CRM professionals the current market rate for their skills and experience, more than the current salary plus inflation.

The regular movement of CRM developers leads to a lack of long term thinking and planning.  Why write code with long term benefit if you are not going to be there to gain from it.

Development standards and way of working need a consistent workforce to implement and developers adhere to them.

Project view

CRM solution providers organise effort at a project level, gearing everything around projects.   The approach is understandable because customers pay for projects and effort is focused on money.

Creating reusable code and solutions is an activity which needs to be done around or outside of delivering a project.  It may involve going back and identifying reusable/generic solutions or taking a little bit longer to write reusable code.

Maturity of Microsoft Dynamics CRM

I’m not sure about this but I wonder if creating reusable code/solutions is something which will occur with maturity of companies and developers.

Will companies get tired of recreating everything on each project?

Versions

Microsoft Dynamics CRM currently has a major release every year, this adds a significant challenge to creating reusable solutions and code.

A solution created today could become standard functionality in the next release of Microsoft Dynamics CRM or your solution might not work, with a need to upgrade the solution to be compatible with the new versions of Microsoft Dynamics CRM.

Microsoft Dynamics CRM online is increasing in popularity, CRM online projects use a different architecture than CRM on premise.  This provides a barrier to reusable CRM on premise solutions because those solutions won’t work with the limitations of CRM online.

The long term view I have is CRM providers will create micro services in azure which will integrate with CRM online services, this architecture allows one service to be used on many CRM Online projects.  This architecture model is being used by FieldOne and their autorouting service, which is hosted in Azure.

Size of CRM companies

Small CRM solution providers whose model doesn’t afford to spend time on non project work.  Bigger companies should have an advantage over smaller companies by creating resusable code and solutions but I’m not sure many larger CRM companies do this at the moment.

Summary

It’s easy to point out the problem of lack of code reuse, it’s harder to pinpoint the steps to overcome this.

The CRM project mentality creates project focused code, not reusable or often known about by other developers in a company.

The 10 most popular Hosk CRM blog posts in 2015

It’s Christmas, a time where terrestrial TV shows greatest hits and compilations.  Instead of spending time crafting new exciting CRM blog posts I will do my own version of greatest hits by listing the most popular Hosk CRM blog posts of 2015

The most clicked on blog posts in 2015

  1. CRM 2013 – Step by Step Update Plugin Tutorial using the CRM 2013 Development Toolkit
  2. CRM 2013 – Understanding Solutions and how they work
  3. MB2-703 – CRM 2013 Customization and Configuration Certification Information
  4. CRM 2011 – Javascript Xrm.Page Basics
  5. CRM 2013 – Setting up Visual Studio with the Developer Toolkit for Microsoft Dynamics CRM
  6. CRM 2011 – Javascript and Subgrids code example
  7. What are the limitations of Microsoft Dynamics CRM Online and how do you work with them?
  8. CRM 2013 – Javascript to get id of current record
  9. CRM 2013 – quick way to get the guid on a form
  10. CRM 2011 – Quick tip – Javascript to stop a form saving

It seems most readers are still developing with CRM 2013 and CRM 2011, it would be interesting to see the number of CRM deployments and versions.

Most clicked articles written in 2015

  1. What are the limitations of Microsoft Dynamics CRM Online and how do you work with them?
  2. Understanding Plugin sandbox mode
  3. Where is the CRM Developer toolkit for CRM 2015?
  4. CRM 2015 – Why filtered views are useful
  5. Getting the CRM Developer toolkit working with Visual Studio 2013
  6. Why .NET developers struggle with CRM Development
  7. CRM 2015 – how to find Statecode value
  8. What’s new in CRM 2015 SP1 for developers, customizers and admins
  9. CRM 2013 – Understanding SystemJobs and Async Plugins
  10. CRM 2015 – Understanding CRM Metadata

Thanks for everyone who has read and commented on my Hosk CRM blog posts, I look forward to creating interesting content next year.

Blogging is a great way to help learn Microsoft Dynamics CRM, if you haven’t got a CRM blog then I recommend you start writing one NOW.

If you have enjoyed reading my blog posts this year please leave a comment.

CRM 2015 – How to diagnose plugin errors

failure-to-diagnose

This blog talks about a plugin error which I have seen a number of times when using the Plugin Developer Toolkit, it will discuss how to diagnose plugin errors in general.

Before I talk about plugins can I encourage people to vote on the connect item to get the CRM Developer toolkit working with Visual studio 2013, if you can’t wait for Microsoft to fix it then read my blog post CRM Developer Toolkit Alternatives

Hosk CRM Brain

I like to think of my blog as my CRM brain uploaded to the internet, so whilst reading this you are currently crawling through my CRM brain.  This allows me to search my CRM brain when my real brain forgets how I resolved a problem, actually sometimes I even forget I have experienced a problem and get pleasantly suprised when I have found not only did I have the problem before but I blogged the solution.

The benefit of me blogging about CRM is I benefit and other people who read and search my blog.

My goal in writing articles focused on errors is not only to write about how to resolve the issue but additionally look into the cause of the problem and , the WHY.

Knowledge helps when things go wrong

There is always a difference between theoretical knowledge and practical knowledge.   You can learn the theory of something but find it’s different when you try to use the theory in practical use (e.g. after reading about plugins you then try to write a plugin) you there are gaps in knowledge which you quickly find.

When developers start to plugins they usually go through

  • learn to write plugin code, find lots of errors
  • try to deploy plugin, error haven’t signed the plugin, error permissions etc.
  • Slowly but surely the developers experience fewer problems or problems they know how to resolve

Indepth knowledge of how Microsoft Dynamics CRM works and the underlying plugin infrastructure becomes extremely important when things go wrong.  When errors appear and hold up development, developers need to understand the cause of the error but why it’s complaining, the answer is usually understandable if you understand

  • how the CRM developer toolkit works
  • The various parts of the CRM Developer toolkit
  • The CRM plugin execution framework
  • The roles and privileges needed to deploy plugins

Some useful Hosk Plugin blog posts

The CRM developer toolkit is great (which is why I get annoyed it hasn’t been updated because it automates a lot of the repetitive actions needed to deploy a plugin using the plugin registration tool.) but I feel CRM Developers should learn how to use and deploy plugins using the plugin registration tool.

I use the plugin registration tool to inspect what plugins and steps are deployed and the ability to change the view to see what plugins are deployed for each entity is really useful when investigating bugs on CRM solutions you are not familiar with.

Most of the time you don’t want to mix using the plugin registration tool and the CRM developer toolkit because the CRM developer toolkit will overwrite the changes you make manually next a developer uses it to deploy CRM customizations.

The plugin registration tool is great for viewing the plugins deployed and its portability allows you to use it in customer environments.

If the CRM Developer toolkit gets in a mess you might need to use the plugin registration tool to quickly update or deploy a plugin whilst you fix the plugin developer toolkit.

I had an error previously but the problem was the CRM developer toolkit had got out of sync and I struggled to resolve this problem.  You can read about my frustrations with the CRM Developer toolkit

Dealing with Plugin errors

If When you experience a plugin error I would recommend you first read my blog on common problems because I cover the most common errors.

If you don’t find the answer then stop and think about the potential cause of the problem.  Many developers can go into a mild panic mode when they encounter an error, instead of logically thinking about the problem they instantly go and get a senior developer to help them.

Then when the senior developer is at their desk, they explain the problem.  The process of explaining the problem to the developer, the solution to the problem can become clear.  This is known as rubber ducking or I call this Cardboard developer

When you encounter a plugin problem or CRM developer problems, follow these steps

  1. Stop
  2. Engage Brain\Think
  3. What’s happening?
  4. What should happen?
  5. Make a list of the possible causes of the problem
  6. Investigate your list

If you can’t resolve the problem, you can then at tell the developer what you know, what you have tried.

I don’t encourage any developers to suffer in silence but it’s more beneficial for you own personal learning if you try to understand and resolve problems yourself.  The major benefit of trying to resolve the problem yourself is you get in the habit and become less dependent on the help of your colleagues.

Don’t Assume, know

Don’t Assume, Know is a Hosk mantra I tell myself when investigating problems or debugging.  I have wasted many hours investigating problems and looking for solutions based on an incorrect assumption.  When dealing with problems don’t assume anything, check assumptions and cross them off.  Lots of times you will find the problem.

Plugin Error Messages

The error messages Microsoft Dynamics CRM throws are a mixture of a confusing statement with a nugget of truth tucked inside.  To developers new to CRM development they are just unhelpful messages.

As your experience and knowledge of CRM development increases you will find they often point you in the right direction but you need to have built up a map of the CRM landscape, so you know where to go and check.

Plugin Error Example

This is common error I have experienced a few times but I was trying to deploy a plugin using the CRM developer toolkit and I got this error

Error registering plugins and/or workflows. Plug-in assembly does not contain the required types or assembly content cannot be updated.

Lets break down the message to try and decify the problem

  1. It can’t register the plugin/workflow
  2. Plugin Assembly does not contain required types or the assembly cannot be updated.
  3. So we know the plugin assembly (the DLL) exists but it cannot update it.

The first thing to do is know not assume.  So I opened the Plugin Registration tool and found the DLL.  I could see it had three steps.

I then looked at the RegisterFile.crmregister file and found this had two steps.

The problem was because we were trying to update an assembly with 2 steps but the assembly had 3 steps.  It couldn’t update the assembly because it was too different and this error message was letting us know (in a slightly confusing way).

I have experienced this problem before and the solution to the problem is to unregister the Assembly and install it again.

This problem has occurred when I have created new plugins and sometimes when I have updated a plugin maybe in a different solution but for some reason I couldn’t update the DLL.

In this case how the extra step got into the assembly was a complete mystery but it’s OK to delete the plugin assembly because I knew I was going to deploy it again and install a new version of the Plugin assembly.

CRM 2013 – Workflow error AccessCheckEx

I was investigating a bug on CRM 2013 , I got the exception below

Unhandled Exception: System.ServiceModel.FaultException`1[[Microsoft.Xrm.Sdk.OrganizationServiceFault, Microsoft.Xrm.Sdk, Version=6.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35]]: SecLib::AccessCheckEx failed. Returned hr = -2147187962, ObjectID: f115e97d-8e19-e511-80ca-000c292122be, OwnerId: 89ed0bdd-7ecd-e411-80c7-000c292122be,  OwnerIdType: 9 and CallingUser: 2ed69167-0bcf-e411-80c7-000c292122be. ObjectTypeCode: 4200, objectBusinessUnitId: 5f964320-05f4-e411-80c9-000c292122be, AccessRights: WriteAccess Detail:
<OrganizationServiceFault xmlns:i=”http://www.w3.org/2001/XMLSchema-instance&#8221; xmlns=”http://schemas.microsoft.com/xrm/2011/Contracts”&gt;
  <ErrorCode>-2147220891</ErrorCode>
  <ErrorDetails xmlns:d2p1=”http://schemas.datacontract.org/2004/07/System.Collections.Generic”&gt;
    <KeyValuePairOfstringanyType>
      <d2p1:key>OperationStatus</d2p1:key>
      <d2p1:value xmlns:d4p1=”http://www.w3.org/2001/XMLSchema&#8221; i:type=”d4p1:string”>0</d2p1:value>
    </KeyValuePairOfstringanyType>
    <KeyValuePairOfstringanyType>
      <d2p1:key>SubErrorCode</d2p1:key>
      <d2p1:value xmlns:d4p1=”http://www.w3.org/2001/XMLSchema&#8221; i:type=”d4p1:string”>-2146233088</d2p1:value>
    </KeyValuePairOfstringanyType>
  </ErrorDetails>
  <Message>SecLib::AccessCheckEx failed. Returned hr = -2147187962, ObjectID: f115e97d-8e19-e511-80ca-000c292122be, OwnerId: 89ed0bdd-7ecd-e411-80c7-000c292122be,  OwnerIdType: 9 and CallingUser: 2ed69167-0bcf-e411-80c7-000c292122be. ObjectTypeCode: 4200, objectBusinessUnitId: 5f964320-05f4-e411-80c9-000c292122be, AccessRights: WriteAccess </Message>
  <Timestamp>2015-06-23T10:02:24.458209Z</Timestamp>
  <InnerFault i:nil=”true” />
  <TraceText>

[Microsoft.Crm.ObjectModel: Microsoft.Crm.ObjectModel.SyncWorkflowExecutionPlugin]
[0dac4467-fb18-e511-80ca-000c292122be: ]
Starting sync workflow ‘Task-Workflow’, Id: 04ac4467-fb18-e511-80ca-000c292122be
Entering ConditionStep1_step: If  Process contains data and is active
Entering SetStateStep4_step: Change record status to completed
Sync workflow ‘Task-Complete’ terminated with error ‘SecLib::AccessCheckEx failed. Returned hr = -2147187962, ObjectID: f115e97d-8e19-e511-80ca-000c292122be, OwnerId: 89ed0bdd-7ecd-e411-80c7-000c292122be,  OwnerIdType: 9 and CallingUser: 2ed69167-0bcf-e411-80c7-000c292122be. ObjectTypeCode: 4200, objectBusinessUnitId: 5f964320-05f4-e411-80c9-000c292122be, AccessRights: WriteAccess ‘
</TraceText>
</OrganizationServiceFault>

Initial thoughts on the Error

I got this error and there were a few things I found interesting

This error was surprisingly informative

The error was thrown by a non code workflow but the cause of the error was thrown by a GUI workflow which was being triggered when a workflow tried to assign an activity.

I was impressed by the level of logging which was generated by a GUI/non code workflow.

I had never thought about it but this line

Microsoft.Crm.ObjectModel: Microsoft.Crm.ObjectModel.SyncWorkflowExecutionPlugin

indicates CRM runs the GUI workflows using code, which must translate the actions into code. This is obvious but I hadn’t thought about it, until seeing the error.

You can use the callerid to find what user is doing the update and check what security roles the user has.

EntityTypeCode

In the error message you can see it mentions ObjectTypeCode

CRM 2011/2013 – Javascript to get the object type code of an entity

Each entity has an individual typecode, this CRM SDK page shows you the values of the default entities

Entity Type Code 4200 is ActivityPointer, which is interesting because the problem was being caused by an update to a task record.

Clues

AccessCheckEx failed – AccessCheckEx is something to do with security and access

In the error message you can see

AccessRights: WriteAccess

This is clearly telling us the user doesn’t have Write access, e.g. the user isn’t allow to update a certain

What was the cause

This bug was partly caused by the complexity of the CRM solution and the different customizations.

Solution complexity refer to not only the customizations which exist in the solution but the number of different customizations.  When a CRM solution has lots of different customizations e.g. workflows, plugins, business rules being triggered at the same time it makes it difficult to understand what is changing a value.

Below is what was happening

  1. A task was updated then saved
  2. This triggered a pre plugin on the task entity
  3. The plugin assigns the case record
  4. A plugin was triggered on assign of the case, which assigned all the open tasks to the new case owner
  5. The plugin(s) finished
  6. A workflow was triggered, which tried set the task to complete.

The error was thrown because the workflow was trying to update the task but the user only had privileges to update tasks they owned.

The reason this bug suddenly appeared was because the assign plugin was added and it wasn’t picked up in DEV testing because developers tested the code using users with System Admin privileges, which I have talked about before

The System Administrator role is a benefit and a curse to CRM developers

It’s tricky to test the effect of adding plugins

Having lots of different types of customizations adds to the complexity of your CRM solution, complex solutions are difficult to debug, understand and extend.

The Solution

Usually with bugs where the user doesn’t have the right security privilege the easy answer is to give the user role those security privileges.

For this bug it wasn’t the correct solution because the users only had access to tasks they owned and we didn’t want to suddenly give them permissions to update tasks they didn’t own.

The plugin code was running in a PRE plugin, so I couldn’t move the task completing code into this plugin.

The bug was becoming more tricky because I did want to keep the case assigning code in their but I didn’t want the assigning case plugin to run and assign the task to the new case owner because the task was about to completed.

My solution was to stop the assign plugin being triggered if was called by another plugin

Read how to do that in the blog below

CRM Plugins – Stopping infinite loops and understanding PluginExecutionContext.Depth

I then created a post task plugin to complete the task.  I didn’t need to do this but it seemed it would be easy to understand if all the changes were made by plugins.

There was an unsuccessful fix when I used impersonation to close the task as System Admin but the users didn’t like the tasks being closed by System Admin, they wanted the user who updated the task to complete the task.

You can read about Impersonation in plugins in the blog post below

CRM 2015 – Understanding impersonation in plugins and knowing when to use it

How to find classes

This is the 3rd part of my trilogy of blogs on classes and code quality in plugins, the previous two parts are

  1. Are your CRM plugins creating technical debt?
  2. Are CRM Developers are afraid of creating classes?

I have written an increasing number of articles focusing on the quality and design of code, which you can find Hosk’s CRM Developer Articles

To summarise the first blog discusses the effects of creating plugins and putting the code into the plugin.

  • Complex code
  • Hard to read
  • No code reuse
  • Difficult to debug
  • Writing unit tests is hard so most CRM developers don’t bother
  • Creates duplicate code

The second blog post discusses the benefits of creating classes and using abstractions, it allows the developer to manage the effects of change whilst cr

The role of classes

  • Removes duplicate code
  • Modelling real world and abstract ideas
  • Reduces complexity
  • Manages the effects of change
  • Information hiding
  • Create reusable code

The benefits of classes

  • The code is created from many simple classes and methods
  • The code is easy to unit test
  • Well designed classes have minimal dependencies
  • Well designed classes should be able to be reused
  • Classes and method can make the code easier to understand
  • Good abstractions can be used in different projects

You should now be convinced creating classes is the way to go, so how do you find classes

Finding classes

The benefits of creating classes have been outlined above but finding classes and abstractions can be tricky.  Numerous times I have created some initial classes only to find my one class could then be broken into two or three separate classes.

The design of code emerges overtime with unit tests allowing developers to change the code and test it still works.  Development tools can help refactor the code but there is an overhead to changing existing code and tests.

The earlier you can successfully identify classes/abstractions the less time you can spend refactoring your code, so it’s worth improving the methods you use to find classes.

There are some common methods to help developers find classes which I will outline below.

NOUNS = Class, Verbs = Methods

CRM developers usually get a requirements document/functional spec.  It’s good practise to create a use case document to see what steps the end user will go through using the functionality (This will find the different paths through the customization).

The requirements document/use case can be used to find nouns and verbs to help you creates classes and methods.   Nouns give you the classes and Verbs give you the methods.

Nouns – Person/Place/Things
Verbs – Methods/Behavior/action

Using the nouns/verbs method gives you a good start identifying classes but it’s far from fool proof and will miss some classes and create duplicates.

When using this method be aware classes are not always specified as nouns, you may need to look a bit harder.

The nouns/verb method of finding classes and methods is a good start point for finding classes/methods.  When using the process keep in mind you are trying to find abstractions and common functionality in the requirements, design is an iterative process which involves understanding the problem and solution, uncovering more details as you go.

It’s common in use case to use different nouns whilst referring to the same abstraction, so you will find duplicate nouns and part of the process will involve getting rid of duplicates and merging some of the nouns together.

Code Complete 2 gives a clear definition of what an abstraction is

abstraction is the ability to view a complex operation in a simplified form.  A class interface provides an abstraction of the implementation that’s hidden behind the interface

A good way to think about classes as an interface, methods are the actions performed.  Inside a class you have hidden variables.

Finding classes, designing the methods before you start coding helps give a developer a more holistic top down view of the design.  Once a developer starts coding the perspective tends to shift more towards a bottom up approach of the functionality required.

Relationships

After identifing a list of potential classes a good method to find the relationships between those classes is to do a quick Conceptual object of those classes

Object-modeling technique

This helps to identify the interactions between classes, the goal of this task is to highlight any missing classes.

This will show you the behaviour of the classes and what classes will interact with other.  Some of these behaviours will have been found when you looked at the adjectives in the use case.

Responsibilities

It’s interesting to think about the responsibilities your classes are going to have, which class is responsible for certain data

Responsibilities can be

  • Knowledge/state an object maintains
  • Actions/methods an object will perform
  • Services/functionality provided by an object

It can be useful to CRC models

CRC models shows the Colloborators and Responsiblities of a class, below is a useful video

https://www.youtube.com/watch?v=5IpsMwxL37k&list=PLqlI1RpjIS59ziAx7YBqQ0rtyAcpgdsjm&index=25

Find Common Functionality

Classes are also in common functionality and actions used by other classes.

It can help to create class diagrams to see the classes and the interactions between classes.  This can help you find missing classes.

The next stage is create the classes, code and unit tests.  Once the code is working you can think about refactoring/tidying the code and thinking about apply SOLID principles

A good way of finding 2 or more classes within one class is to check the class is focused and doing one thing e.g. The Single Responsibility principle.

A quick way to check if a class is doing more than one thing is the name of the class.  The class should clearly describe what it is/what it does.  Badly named classes often are badly named because they are doing more than one thing.

Actions, manager, Super

Class smells

Here is a list of class smells which often indicate the class is doing to much and could be split into more separate classes

  • Difficult to name the class?  This is usually a sign the class is doing more than one thing
  • Cohesive.  Are all class variables used by most methods, do some methods not use certain variables.  A lack of cohesion is usually a sign a class can be broken out.
  • To many methods.  A high number of methods usually means high complexity, indicating the class is a candidate for refactoring to simplify the code
  • Method length (in lines) – a class bigger than 200 or 300 hundred lines is to big

When checking classes you are often checking for cohesion and if the class can be broken into smaller more cohesive classes.

Cohesion when used to describe design can confuse some readers, so here is wiki’s definition of cohesion

In computer programming, cohesion refers to the degree to which the elements of a module belong together.  Thus, it is a measure of how strongly related each piece of functionality expressed by the source code of a software module is.

Cohesion is the concept all the variables and methods in the class fitting together under the name and purpose of the class.  A class should have a single responsibility, a single purpose.  If a class has more than one purpose then it should be split up.

Example

Here is a quick example

ATM Machine

A bank customer must be able to make withdrawals from the ATM machine using their card.  The card must be validated before the ATM will give money.

ATM machine will check the user has at least the amount of money to be withdrawn in the account.

The bank customer can make a balance enquiry.

Nouns

  • Customer
  • ATM Machine
  • Card
  • money

verbs

  • withdrawn
  • check
  • validated

Further reading

OOSC-2: HOW TO FIND THE CLASSES

From the awesome Bertrand Meyer.  I found the article above very useful

Are CRM Developers are afraid of creating classes?

I have seen lots of CRM code and my initial thoughts are CRM developers don’t seem to create many classes or spend much time designing their code.  In this blog post I will discuss the effects of not creating classes and explain the benefits of classes and abstractions.

Are CRM Developers afraid of creating classes?

The problem seems to be self reinforcing.  Previous CRM projects contain few classes and most of the code exists in the plugin, this sets an unspoken standard which encourages developers to not create classes.

This is a mixture of a safety in numbers/wisdom of crowds approach, it could be seen as consistency and a standard approach to CRM development is good.  Consistency in CRM development helps developers maintain, debug and extend CRM projects.

In the case of putting code in the plugin and not creating classes I think it’s bad practise and every plugin you add creates more technical debt for the CRM project and CRM projects quickly resemble legacy projects with complex CRM customizations

The end result is complex code doing lots of things and impossible to reuse and extremely difficult to work with (maintain, debug, read, etc).

To not use classes and put all or the bulk of the code in the plugin class

  • makes it impossible to reuse code
  • create complex code which does many things
  • creates duplicate code
  • create code which is hard to understand
  • Code is very difficult to test

CRM plugins are often small, focused code but to not create classes or abstractions is to create a code base technical debt.  This debt is paid back when CRM developers take longer to interact with the code in the future.

Plugins with few or no classes results in each developer creating new code every time because it’s impossible to reuse any of the code in the other plugins.

If CRM developers are not creating classes they are creating legacy code and plugins contain monster methods – Hosk

Boy Scout rule

The focus when creating code should be to keep the quality high, test everything and keep code as simple as possible.

When you create plugins or every time you make a code change you make you should leave the code in better state than you found it.  Why you should write code and customizations like a boy scout

Quality of code is fundamental to the long term success of a CRM project and as soon as you lower your coding standards and let in bad code, it will soon spread Bad code is like a virus, don’t get infected

What is the role of Classes in programming

I advocate no code logic should be added to the plugin class except a call to a class passing in the entity, IOrganisationService, ITracing.

Putting logic in a plugin creates complex code, which is difficult to unit test but there are other reasons to create classes which are listed below

No Duplicate code

Duplicate code is one of the worst code smells and it has multiple bad side effects

  • More code = more potential bugs
  • duplicate code = bug fixing can result in multiple fixes
  • bug fix one set = miss out changing duplicate code, which one is right?

When ever you find duplicate code or are about to create duplicate code, take the opportunity to find the common behaviour and abstract it into a class.  This will enable you to reuse this single piece of code in many places.

Using classes and functions is the primary weapon against duplicate code because you are logically sorting code in logical class/method, which will allow developers to easily find and use it.

Modelling real world and abstract ideas

Classes allow you to model real world objects (account) and abstract concepts (printing, validating).  The benefit is you can split up the code into logical abstractions which give clarity to the intent of the code.

CRM out of the box models plenty of real world objects

  • Accounts
  • Contacts
  • Opportunities
  • Phone Calls

Abstract classes

  • Security role
  • Solution
  • Behaviours

You can create classes to model behaviours, this could be things like validating, printing, logging.  These behaviours can be use in composition and used in multiple classes.  The benefit of modelling behaviours is reuse

  • Create abstract objects
  • Create real world objects

Reduce complexity

Classes reduce complexity by splitting code into abstract or logical sections.  The term abstract can be confusing, instead replace it with logical groups.  Splitting code into logical groups organises the code into smaller/reusable sections.

Breaking the code into classes creates cohesive code and reducing dependencies between classes.

Creating well named classes with well named methods reduces complexity and makes the code using those methods and classes easier to read/understand.

Creating classes and methods allows you to create descriptive methods, e.g. call the a print method is easier to understand than reading all the lines of code needed to print.  At a high level you might not need to know all the details of printing.

Manage the effect of change

Classes help reduce the effects of change by removing dependencies between classes (assuming the classes are well designed).  Using abstract classes can remove the effects of change on the code using the abstract classes.

Well designed code can make it easy to add new types by encapsulating what varies and programming to interfaces.  Adding a new type should not effect the other types or the code using the abstract class.

Managing the effects of change can reduce dependences and stop changes in code unexpectedly breaking other parts of the system.  You could rename this to limiting the effects of change by reducing the ripple effect change has on badly designed code.

Information hiding

Read my blog post Good coding practices – Information hiding

hold data instead of lots of parameters

You can structure classes to hold the data instead of passing lots of variables between methods.  This makes the code easier to understand and interact with.

Create reusable code

Many CRM projects I have worked on/inspected have had almost no code reuse partly due to the lack of classes created.  Part of the reason is attitude, CRM developers don’t view creating reusable code as a priority.

CRM organised internal entities to make it easier to understand how it works.  If we take security roles as an example.

The security role entity contains the main privileges which have a value of TRUE or FALSE and one of the four access levels Global, Business Child, Business unit, user.

Every time we add a new entity, we can set privileges for Create, Read, Write, Delete, Append, Append To, Assign, Share.

Whilst thinking about the example above I would except Privilege to be a separate class but we can see understanding the data in this structure is easier.

The benefits of designing classes 

The clean coder has a good change on classes which talks about change isolating change

Needs will change, therefore code will change. We learned in OO 101 that there are concrete classes, which contain implementation details (code), and abstract classes, which
represent concepts only. A client class depending upon concrete details is at risk when those details change. We can introduce interfaces and abstract classes to help isolate the impact of those details.

Abstraction and modularity allows developers to work on separate parts of a system without having a detailed knowledge of the whole system.

Plugins allow developers to create new plugins without affecting other plugins.  The crm dev needs to check there are no other plugins being triggered on the same entity.  Good design of the code is based on on the plugin interface and not the concrete class e.g. your plugin.

Well designed classes have many benefits

  • The code is created from many simple classes and methods
  • The code is easy to unit test
  • Well designed classes have minimal dependencies
  • Well designed classes should be able to be reused
  • Classes and method can make the code easier to understand
  • Good abstractions can be used in different projects

Coding to an interface

The benefits of coding to an interface and using classes behind the interface is you limit the effects of change behind the interface.

You can add new types behind the interface without affecting any of the code which uses the interface.

A quick example is routing records to different users or teams, for this you could create an interface called Route and then concrete classes will contain the routing details and default value of the users/teams.

Route – Interface

  • RouteToTeam
    • RouteToDefaultTeam
    • RouteToSalesTeam
    • RouteToMarketingTeam
  • RouteToUser
    • RouteToSalesManager
    • RouteToCaseManager

The benefits of coding to an interface and using classes

  1. Any code using the Route interface will be unaware of what specific type of route they are using.
  2. The code calling the interface has no knowledge of what objects, variables are used to route, it calls the Route interface methods
  3. Its easy to add new Routes which will involve changing minimal amount of code
  4. The code using the Interface is decoupled from the concrete classes
  5. The effects of change are restrained by the interface
  6. Easy to test
  7. Selecting the type can be done dynamically at runtime

Dependency Inversion Principle (DIP)

Reading about the Dependency Inversion Principle (DIP) helped me understand abstractions and the benefits of using them.  To remind you what DIP is

Depend on abstractions, not on concretions.

Wiki adds two more points to help understand

A. High-level modules should not depend on low-level modules. Both should depend on abstractions.
B. Abstractions should not depend on details. Details should depend on abstractions.

I highly recommend you read Uncle Bobs article The Dependency Inversion Principle, where he explains it a lot better than me.

This article DIP in the Wild has a good example of using DIP which helps understand  the concept and it’s usage in developer life.

Abstract ideas can be tricky to understand, to make this easier to understand think of black boxes.

Black boxes are code which works but the user of the black box doesn’t know how the code works inside the black box.  The internal code can change but the consumers of the black box wouldn’t know.

Change has been isolated inside the black box, Interfaces and abstract classes operate as black boxes hiding the change behind them.   Any code which interacts with an interface/abstract class won’t need to change if the internal workings behind the interfaces/abstract classes change.

A good example is using the CRM SDK to interact with the CRM database.  Microsoft can change how the internal workings of the CRM SDK change and can change the CRM database structure (in CRM 2015 they removed CRM database extension table).

Microsoft removed a whole table but CRM developers who used the SDK wouldn’t have noticed any difference (I didn’t notice) but those who developed code/reports directly against the CRM table would suddenly find their code/reports no longer worked when they upgraded to CRM 2015.

The next blog in the series is how to find Classes