Question Status

Verified
Chris - New to CRM asked a question on 8 Mar 2013 12:25 AM

Hi,

As my name suggests, I am very new to CRM so please bear with me if my terminology is wrong.

I am attempting to utilise the webservices provided by the CRM 2011 SDK to write some data to entities. At the moment, I am merely testing the capabilities, but there are various things I find perplexing.

One is the fact that when a field on an entity is marked as "Business Required", I can create an entity via the webservice SDK without having to provide a value. I can see via this link that this seems to be how it is supposed to work, however, I can't understand why this would be.

I thought that the idea behind the SDK was that it was a consistent mechanism of accessing Entity data and therefore any "constraints" provided on the entity would then be enforced no matter what the mechanism of access (ie. SDK webservice, data import, workflow etc). 

The reason I wanted to test this was in my quest to work out the best way of enforcing transactional behaviour for CRM access via the webservices. I came across a post indicating that the use of the Entity.RelatedEntities property would help with this. I assumed by creating a "Buiness Required" field and then not providing data would be a good test, but it let the data through. In addition to that, I was using late bound methods of access in the form of;

Entity newEntity = new Entity("my_entity");

newEntity.Attributes["my_field1"] = "ShouldFail2";
newEntity.Attributes["my_name"] = "ShouldFail2";

Entity child = new Entity("my_child");
child.Attributes["my_name_that_does_not_exist"] = "Child name2"; // this attribute actually doesn't exist as a field against the CRM entity.
child.Attributes["my_requiredfield"] = "Child Required Field2";

newEntity.RelatedEntities.Add(new Relationship("my_entity_child"),
                                                       new EntityCollection
                                                               {
                                                                 EntityName = "my_child",
                                                                 Entities = { child }
                                                                });

service.Create(newEntity);

The code above worked fine, even though the attribute I set didn't exist on the entity. Further to that, the field that was defined as the primary field on my Child entity was left blank. I've tried similar things with early bound entities in the hope that there might be some additional properties showing if an entity field was required or not (it certainly limits the fields I can set as they are all properties of my entity). I haven't managed to find anything as of yet.

Given all that, my questions are;

- Can anyone explain why this would have been designed this way ?  (Is there a good reason why the constraint on the required field should only be applicable when using a CRM form)

- Is this behaviour documented anywhere (both the required field and the ability to ignore the primary field and also the ability to assign a value to a attribute that doesn't exist and have the entity save without any error)? I'd be keen to find out any other oddities from the outset.

Any help you can provide in my understanding as to why  CRM allows this is much appreciated.

Thanks,

Chris

Reply
Jason Lattimer responded on 8 Mar 2013 6:30 AM

I not sure this is documented anyplace - but my opinion is that you are allowed to create records where required fields are not populated is because the interface for controlling the entity's attributes is through the GUI and not code. What I mean is in a given organization there could very likely be more people who can update entity fields than have access to any custom code that is deployed. A CRM admin can go in at anytime and flag a field as business required. Image if the SDK was bound to this and if you had other critical processes running that suddenly started failing because this new field was not populated. I can see in some instances, yes you might prefer to have the process fail but in others you still might want it to continue. I'm sure in many companies the process of having to update and re-deploy code can be painful. I think as a whole the system is more flexible toward developers if it works this way. There are also probably valid arguments/business cases that could be presented for creating new records if missing required fields - really just depends on an organization's specific requirements. I personally lean toward having the "more flexible" approach.

Jason Lattimer
My Blog -  Follow me on Twitter -  LinkedIn

Reply
Chris - New to CRM responded on 9 Mar 2013 7:46 PM

I can understand what you are saying, but in our situation, there is likely going to be a whole lot of integration with other systems, and the only way to get data into CRM is via the web services or data load (which apparently don't restrict by mandatory fields). Personally, I am much more interested in the overall integrity of the data, and that is what I had hoped the entity configuration would help to achieve.

Oddly, it seems as though while the webservice access isn't affected by mandatory fields, it is constrained by things like field length settings on attributes. I would have thought that if constraints such as field length affected access via SDK (and I am assuiming data load/import), then the a mandatory setting on an attribute would affect it also.

I am hoping that there can be something done with early bound classes that will allow me to determine if a field is considered madatroy on the CRM side of things. The problem here is, I'd need to regenerate this and rebuild any code that was reliant on these to get any benefit.

Ideally, I'd prefer something that enforced data integrity right at the point of data access. If that can't be in SQL Server, then I figured it'd be the entity definitions. That way, my critical process (ie. access via webservices) could fail, and I'd know that I hadn't corrupted the CRM database with non compliant data.

I'd still love to hear others opinions or suggestions on how this could be done.

Reply
Verified Answer
Jason Lattimer responded on 9 Mar 2013 8:04 PM

What you would probably need to do then is examine the Entity Metadata associated with the entity you are updating. Get a list of the of the fields in the entity and check their requirement level. Then in your code before you perform your create/update, iterate through the fields and ensure any that are flagged as required indeed have a value. You would need to retrieve and compare the metadata each time your process runs but doing so ensures any changes that might have been made in the UI to the required level are taken into account. You should also still be able to do this using the late bound method of development. 

Extend the Metadata Model for Microsoft Dynamics CRM

Sample: Dump Entity Metadata to a File

Jason Lattimer
My Blog -  Follow me on Twitter -  LinkedIn

Reply
Chris - New to CRM responded on 11 Mar 2013 1:18 AM

Thanks. This isn't the answer I was hoping for :), but it'll have to do. I wonder how we go about making a feature request to MS regarding this.

For example, they could have a radio button on entity creation that allowed you to enforce constraints no matter how data is accessed (ie. SDK webservices, CRM form etc) OR be flexible.

Reply
Jason Lattimer responded on 11 Mar 2013 4:07 AM

Feature requests can be made on the Microsoft Connect site.

Jason Lattimer
My Blog -  Follow me on Twitter -  LinkedIn

Reply
Verified Answer
Jason Lattimer responded on 9 Mar 2013 8:04 PM

What you would probably need to do then is examine the Entity Metadata associated with the entity you are updating. Get a list of the of the fields in the entity and check their requirement level. Then in your code before you perform your create/update, iterate through the fields and ensure any that are flagged as required indeed have a value. You would need to retrieve and compare the metadata each time your process runs but doing so ensures any changes that might have been made in the UI to the required level are taken into account. You should also still be able to do this using the late bound method of development. 

Extend the Metadata Model for Microsoft Dynamics CRM

Sample: Dump Entity Metadata to a File

Jason Lattimer
My Blog -  Follow me on Twitter -  LinkedIn

Reply