Should CRM services return an error for invalid attributes?

It turns out that I was always working with an altered version of the CRM platform which silently was ignoring invalid-for-create and more importantly invalid-for-update attributes. Why is this important? Well, my recommendations for creating a friendlier programming environment were missing a critical step which isn’t available to “outside” developers. This means that creating classes from the XRM entity XSD will only work for a subset of the core scenarios.

If you’re using the classes for data binding operations then you’ll quickly realize that a READ-EDIT-SAVE operation won’t always work. In fact, any time you run the READ-EDIT-SAVE loop on the same instance things will break. There are two options available for working around this problem. One of them puts the burden on the developer and still doesn’t solve the R-E-S scenario: create different schemas for each of the Read, Create, and Update operations, then create corresponding classes to use them. This doesn’t work well because you now really need to pay attention to which attributes are applicable. The second option is for us to take a design change (which probably won’t make into CRM 1.2, but it might be early enough to get it into CRM 2005) that makes the platform silently ignore “extra” attributes instead of returning an error.

Obviously I’m leaning toward the latter solution where we fix the problem… er, where we change the design. This isn’t a done deal though and there are strong feelings on both sides of the issue. So I’m asking the CRM development community (at least folks who read the stuff I write) for your opinion. Is it better to silently ignore attributes that don’t make sense for the operation or would you prefer the current behavior where we return an error?

Comments

• Anonymous
  February 10, 2005
  We are using the CRM SDK to perform some data import / integration. We rely on the errors returned to let us know about problems that have occurred in the data source or in the data mapping. We log the errors which can be fixed manually later.
  
  (We aren't using the DataMigrationFramework for this project because the code for the first-time import is almost identical to the code we will ultimately use for ongoing data sync with another system)
  
  So yeah, its a pain to get an error if a field name is misspelled or something, but its definitely important to know.
• Anonymous
  February 10, 2005
  Are you relying on the errors to catch bad attributes. That is, are you looking for an error which says that a specific attribute isn't defined for the entity? Or, are you using the errors to catch "state" validation issues where an attribute is defined on the entity but isn't available to be written at the time (create or update)? the former would not go away because knowing that you're supplying a "bad" attribute is a good thing and being told via an error means you know exactly what happened.
• Anonymous
  February 10, 2005
  The comment has been removed
• Anonymous
  February 10, 2005
  The comment has been removed
• Anonymous
  February 10, 2005
  The comment has been removed
• Anonymous
  February 21, 2005
  I vote for ignoring fields in the input that cannot be updated (option B). Developers should use automated unit testing (NUnit) to test their code, and this will help them discover that e.g. the fax number was not updated. Do not make the object model hard to use just to "help" people that do no apply professional testing.