More About This Website

All information is provided "AS IS" with no warranties, and confers no rights

Login
Powered by Squarespace
Tuesday
Aug022011

OData/Silverlight–Issue with Relationships

A little while back I blogged about how when using the default behavior of OData from Silverlight all properties are sent with each server update by default.  I also included in that blog post a link to the CRM Team blog post with a work around you can find that here.

The workaround is designed to track properties that are changed on an entity and only ship those to the server during a create or update.  Turns out, the work around doesn’t appear to send N:1 relationships to the server depending on how you set or modify the value of the property.

Imagine you have an entity Book and the Book Entity had a N:1 relationship to Contact and a attribute crmbook_contactid was created on the entity.  If you set the value of this like the following:

bookInstance.crmbook_contactid = new EntityReference {id=idValue,Contact.LogicalName};

You will find this won’t send the value to the server. If you are curious, the id and logicalname properties are marked as changed in the tracking of what is dirty, but not the crmbook_contactid property.  What I have found to work is the following:

First, Create the entity Reference

var myRef = new EntityReference {id=idValue,Contact.LogicalName};

Then set the value

bookInstance.crmbook_contactid = myRef;

Setting it this way I found properly triggered the change notification for crmbook_contactid causing it to be marked as dirty and sent as part of the create or update.

Friday
Jul292011

Tales from the Sandbox–Constructor Exceptions

Sometimes when you play in the sandbox you can get sand kicked in the face.  That was the case with building this plug-in thought I would share the story with you in case it saves you a few minutes. 

You probably know by now that if you build a plugin that runs in the sandbox it is running in partial trust.  In fact you might have even had it kill your plug-in when you executed it due to a security violation.  Many times its really obvious what is going on, and then other times like this one it might be elusive what the problem is.

This story started with building a new plug-in and trying to run it.  All it would produce was a simple “Security Exception” message on invocation.  No trace, nothing.  This started in on-line so I took it on-premise, tried it there same thing.  Checked tracing log, nothing useful.

I then tried to see if I could reproduce the exception outside of CRM.  The quickest way I found to get a partial trust environment was a simple console application – go to security settings and turn on Click Once, and set it for partial trust.  By default this is pretty locked down so you might find it too restricting but for some scenarios I think it might be helpful.  In fact it did identify one small thing that was wrong, but in the end I still got the same Security Exception message.

After gutting the plugin to nothing much left and still getting the error it was obvious I was missing something obvious.  What I failed to reproduce and/or check was the constructor getting called that took the config/secure config and in this case that was causing an exception, that exception ultimately hit some non sandbox friendly code in the constructor and killed the execution.  The net result was the simple Security Exception message with no other details.  So if you get that simple message – check your constructor.

Monday
Jun202011

Don’t trip on your own feet when using OData

CRM 2011 exposes a REST endpoint using the OData prototcol for working with data from Web Resources.  When using the endpoint from Silverlight the most common way is to use the generated proxy classes that are produced when you add a reference to the endpoint or by running DataSvcUtil.  When working with these generated classes and the default behavior of the WCF Data Services client all fields are sent to the server when an update is done on an object instead of just the changed fields.  This has some undesired effects like auditing being updated more often then it should not to mention if you have workflows triggering on any of the fields they will detect the change as well even though your app may have only modified a single unrelated field.  A particularly nasty surprise can be found also when you later decide to turn on field level  security and the user doing the update doesn’t have access to the field all of a sudden you will get errors due to the update.

Not all is doom and gloom, you can fix this by a few tweaks to the generated data context to ensure that when changes are posted to the CRM server that only the modified fields are sent.  You can find details and the code to add on the CRM team blog here.

Monday
Mar142011

Collapse a Tab, It might stay that way

One of the things you might do when editing a form in CRM 2011 is collapse a tab to make room to edit another area. What you might not realize is the side effect of that change.  In case you haven’t seen how tabs are presented now in CRM 2011 here is an example of the General section on an entity.

image

By default this is expanded like you see in the image.  By simply clicking on the carrot next to the label (see the arrow) you can collapse the tab content.  Sometimes I’ve done this in the form editor and usually return it back to expanded before I save.  Initially, I thought this was just changing it for my form edit section but in reality it is actually changing the Tab Expand this by default property as you can see in the following image.

image

So this change that I originally thought was just a design time change turned out to become a runtime change after publish.  So the key message here is if you are collapsing stuff you might be surprised when your users wonder why they keep having to expand it!

If you haven’t tried the new layouts in CRM 2011 the new tabs (which really aren’t true tabs anymore) are nice.  That old limit of 8 or 9 tabs in prior versions is gone.  You also have more control to hide / show the tabs at runtime using the new Xrm.Page client side API.  That can all now be done using supported client side API calls.

Thursday
Jan272011

Book update CRM 2011

As I’ve been traveling around the world doing training events on CRM 2011, a lot of people have been asking about an update on the book and what our plans are for CRM 2011. In addition to being crazy busy with all the things leading up to the launch we have also been busy working on updating content for CRM 2011. We currently have two CRM 2011 books planned for release in the next few months and I wanted to share a little bit of information on the plans.

clip_image001

Using Silverlight with CRM 2011 – Target Release March 2011

One of the cool new things in CRM 2011 is its support for making Silverlight a first class way to extend the user experience. This book will focus on all the different ways you can extend CRM 2011 using Silverlight including on Forms, on the Dashboard and many other creative ideas. The book also includes enough basic Silverlight information so if you are new to Silverlight you can get started right away.

clip_image002

CRM 2011 as a Rapid Development Platform – Target Release May 2011

A lot has changed since 2008 when the book was first published for CRM 4.0. At the same time, CRM 2011 is even more compelling for building a wide variety of applications that aren’t just limited to CRM. In this update to the popular CRM 4.0 book we will be focusing on providing deep information that developers need to build applications with CRM 2011 and the xRM Application Framework.

In both cases stay tuned if you have purchased our prior books we want to make sure you also get some special offers for the new books as well. If you don’t have one of our books, make sure you register on the book site as a user – http://www.thecrmbook.com

For anyone that might be interested we are also in need of a small number of people to provide early reviews and feedback on the content. Ideally, this would be a mix of people who are new to the topics and some that have been heavily involved in CRM 2011 beta testing. If that is you and you are interested please contact me directly via my blog at http://crm.davidyack.com/send-me-e-mail/

Thursday
Jan062011

Solutions and Workflow Ownership

In Dynamics CRM 2011 workflows are one of the supported Solution components. Workflows are owned by a specific user that doesn’t have to be the one working with the solution. One of the questions I got recently was around how ownership was handled during import of a managed solution into a new organization.

For the purpose of this blog post, let’s assume User A, created Workflow 1 and activated it. In this case, User A would be the owner of the workflow.

Next, the System Admin user created a new solution and did an add existing component on the workflow to associate it with the solution. The solution is then exported and imported into a new organization. The question is who is the owner of the workflow after the import?

The answer is whoever ran the import will become the owner in the new organization by default. It is possible even though the workflow is a managed component to de-activate it in the new organization and assign it to another user but that must be done post import.

Keep in mind that for security purposes the workflow when activated and run as a result of any triggering event will run in the context of the owning user. In many cases for solution level workflows this isn’t a problem, but it is something to be aware of. If configured for On Demand, the workflow will run in the context of the user that starts it.

Sunday
Nov072010

CRM 2011 Leverages SQL Enterprise when available

In doing some testing last week I ran into an interesting challenge that turns out to highlight a CRM 2011 feature.  The feature is that when CRM 2011 detects SQL Server Enterprise edition it will take advantage of some of the features like partitioning for audit.  This is a good thing but there are some things to consider before just jumping in blindly. 

I found this feature by accident when I went to re-deploy an organization that was on Test Deploy 1 to Test Deploy 2.  It turned out Test Deploy 1 had SQL Server 2008 R2 Enterprise and Test Deploy 2 had only the standard edition.  During the restore process when it failed to start the database it became clear there was an issue.  Notice here the key word is it failed to start the database, not that it failed to restore the database.  This is the first key point to understand – it can’t detect the feature mismatch between SQL Standard and SQL Enterprise until the database has already been restored.  So for example if you happen to be restoring over the top of an existing database keep in mind it will wipe it out and restore the new copy that you will never be able to use.  When this happens you will get an error like “Database xyz_MSCRM cannot be started because some of the database functionality is not available in the current edition of SQL Server” at that point the database restore is complete but it isn’t usable.

In my case since I was just testing stuff I was able to upgrade that instance to enterprise to get the org working.  To do that, you can go to Maintenance on the SQL Server Install and there is an option for Upgrade Edition.  You type in the key for the enterprise SKU and then after a minute or so it’s done.  As soon as that was completed the database was not showing as available in SQL.

Ideally, I’d like to see CRM during the setup of the deployment or the organization prompt if you want features enabled that would impact portability of the database across different SQL Editions.   Keep this in mind if you setup a new org in a SQL Server Enterprise deploy that currently this opt-in is done automatically.  I haven’t tried seeing if I start the org in a standard deployment, then import it into a SQL Enterprise to see if those features are enabled but that might be once possible way to try if you want to keep it at the standard SKU feature set.

Monday
Sep202010

Exploring CRM 2011 Solution Framework Update Scenarios

In this blog post I’m going to explore some the different scenarios you might encounter with the solution framework in CRM 2011. This blog post is based on the beta of CRM 2011 version was released in September 2010. This is not an introduction to solutions, but rather an advance look at some of the different scenarios that might be encountered when using the solution framework. If you are new to solutions, you might just want to bookmark this blog post until you've looked at some of the basics first. I will also be doing some more basic introduction blog post in the future as well but since I was in the middle of testing these scenarios I thought I'd share them right away.

Test Baseline

The following establishes the solution to be used for the testing. Think of it as the 1.0.0.0 of the test product.

Created a new publisher

clip_image001

Created a new solution

clip_image002

Next I created two test entities A and B each having two string attributes.

clip_image003

And the journey begins by exporting the solution as a managed solution version 1.0.0.0 and importing data into a new organization has managed.

Simple Update, Add new Attribute to Entity A, change version number to 1.0.0.1.

clip_image004

All looks good – now we get the choice for maintain or overwrite, we will take maintain.

clip_image004[1]

Import an older version, in this case 1.0.0.0 when 1.0.0.1 is installed

clip_image005

It knows that the version number is different but it doesn't warn you that you're about to install an older version. Essentially the best way to think about version number is metadata.

Checking the attributes all 3 are still listed even though 1.0.0.0 only had two.

clip_image006

Trying to import a managed version on top of the unmanaged entities.

clip_image007

Nope, I knew it wouldn’t work, but wanted to make sure you knew.

Creating 1.0.0.2 and removing Test Entity A – Attribute 2

clip_image008

In the target Org, I added the entity to workspace, added the three fields to the form, and added a test record while we were doing the other tests.

clip_image009

Import worked fine just like before – and the 3 attributes were still in the target organization meaning it didn’t magically remove them

clip_image010

Install into a new clean organization of 1.0.0.2 only ends up with the 2 attributes

clip_image011

This means new customers installing a solution will not see the deleted attribute.

Create 1.0.0.3 – Remove Entity B and import to organization with 1.0.0.2 already installed

All worked ok, as you can see only Entity A was processed there is no mention of entity B

Looking into the installed solution we see that it still has Entity A and B

clip_image013

So it seems the behavior is the same as attributes

Uninstalling a Solution – What happens to the Data and Your Customizations?

This is one to be careful with because it might not work the way you would want it to. First you see the following prompt.

clip_image014

In my case remember I had modified the default solution to add the fields to the form, and had created a single record of type Entity A. After this completed the site map change was gone, the entity and it’s data was gone. In some ways you can think of this no different than if you customized some other file for an installed application. Ideally, I would like the person removing to see a detailed list of data the will lose so they aren’t surprised or some other safeguards. For now though the important thing is to understand the current behavior so you aren’t surprised.

Wrap up

Hopefully that gives you helps explain some of the behaviors of the solution framework that is a part of CRM 2011. As you probably figured out by now solution can be either really simple or really complex depending on a particular application. They enable scenarios that we used to think weren’t possible before and it also creates scenarios that we might not fully understand yet. I'll try to do some more of these exploring the solution framework posts in the future. If you have ideas of things you'd like to see leave them in comments.