I am using the request to GET "/api/data/v9.0/EntityDefinitions" to list all the entities that are present in Dynamics and get basic information regarding them (EntityMetadata EntityType).
I know that some of the entities are standard, custom, non-createable, non-updateable, etc.
To check if an entity is a custom I can use a field named IsCustom from EntityDefinition and if it is true then the entity is custom. But for non-createable entities and others (I don't know how to call them properly) this approach is not applicable, because there is no such field.
For example, 'activitypointer' supports only GET operation (activitypointer EntityType). Records of this type cannot be created. But from the request above, I cannot get the correct information about that.
Can entities be distinguished?
P.S.: maybe I did something wrong and need to look elsewhere?
Related
I have entities of type account which when I look at it in Dyn365 it has a section containing a list view of related entities. How do i get these related entities from the OData API?
I can query api/data/v9.1/account but the related entities do not appear anywhere in the resulting json.
If I do the same for the related entities the account do not appear anywhere. How do I get the link between these two types of entities? using the OData API.
I've tried things like /accounts?$expand=contact($select=foo) but it just says contact property do not exist on the account entity, which is correct. But contact is not a property its an entity type.
Solution is to use the following url to get the names of all relationships.
https://<company>.crm.dynamics.com/api/data/v9.1/RelationshipDefinitions?$select=SchemaName
Result is an array of the following rows for each relationship.
{"#odata.type":"#Microsoft.Dynamics.CRM.OneToManyRelationshipMetadata","SchemaName":"aaa_bbb","MetadataId":"<guid>"},
Then use those names, specifically the SchemaName property in the $expand query parameter.
https://crmdev.crm.dynamics.com/api/data/v9.1/accounts?
$select=<whatever>&
$expand=aaa_bbb($select=<properties from linked entity>)
To figure out what relationship actually do what you need, you need to read in more then just the SchemaName if you can't guess what is what, or look it up in Dynamics through the GUI if you know how and have access. I don't.
The RelationshipDefinition contains other properties like ReferencedEntity ReferencingEntity that can be used to determine if you got the right relationship.
Probably, this is what you are looking for. The relationship for 1:N between account and contact is contact_customer_accounts
All accounts with its related contacts:
https://crmdev.crm.dynamics.com/api/data/v9.1/accounts?$select=name&$expand=contact_customer_accounts($select=fullname)
Particular account with related contacts:
https://crmdev.crm.dynamics.com/api/data/v9.1/accounts(73C84814-729B-EA11-A811-000D3A370DB6)?$select=name&$expand=contact_customer_accounts($select=fullname)
i am building my the model using ODataModelBuilder, i am trying to create navigation property however in the metadata i dont see any foreginkey indication, in my solution i am not using EF, so there is no foreignKey attribute, is it possible to add it by code?
As you clarified in your comment, the reason you want to add foreign key information is because your client application is not including related entities when you query the main entity. I don't think foreign keys are the problem here.
As an example, I'll use two entity types: Customer and Order. Every Customer has some number of associated Orders, so I have a navigation property on Customer called Orders that points to a collection of Orders. If I issue a GET request to /MyService.svc/Customers(1), the server will respond with all of the Customer's information as well as URLs that point to the related Order entities*. I won't, by default, get the data of each related Order within the same payload.
If you want a request to Customers(1) to include all of the data of its associated Orders, you would add the $expand query option to the request URI: /MyService.svc/Customers(1)?$expand=Orders. Using the WCF Data Services client (DataServiceContext), you can do this with .Expand():
DataServiceQuery<Customer> query = context.Customers.Expand("Orders");
However, WebAPI OData doesn't currently support $expand (the latest nightly builds do though, so this will change soon).
The other approach would be to make a separate request to fill in the missing Order data. You can use the LoadProperty() method to do this:
context.LoadProperty(customer, "Orders");
The LoadProperty approach should work with WebAPI as it stands today.
I know this doesn't answer your original question, but I hope addresses your intent.
*In JSON, which is the default format for WebAPI OData services, no links will show up on the wire, but they are still there "in spirit". The client is expected to be able to compute them on its own, which the WCF Data Services Client does.
I want to modify the view of 'Activity' entity, opened the view and try searching for edit filter criteria option and it's not available on view form.
please see below
Can you please help to advice me on how I can add filter criteria for this view above. Or how to make it visible the option 'Edit filter criteria' on the form of a view.
Any suggestion will be much appreciated. Welcome for any feedback...
I don't know any way to do that, but you can do your custom views and for example change the default view for that entity. With custom view you can change everything.
See here step by step: http://www.powerobjects.com/blog/2008/08/11/creating-and-editing-views/
What you want is impossible to achieve. Pedro's suggestion is your only option. Create your own Activity view, and then you can create your own filters. You definitely cannot create your own Associated Views. Public Views are the only ones you will have a hope of creating or modifying, and in this particular case, you are still restricted.
There are various places spread throughout CRM where you will run into problems like this, where an entity, view, or field is "locked down". This is the cost of starting with platforms like CRM which are a blackbox that only offer customization up to a certain point.
The problem in this specific case has to do with the nature of activities and the various activity types. Under the hood, there really is not a traditional record type for Activities. The Activity entity is really a "pointer entity" (note the internal name "activitypointer"). Activities really point to other entity types (in this case Activity Types) such as Email activities. The Email entity is more of a traditional entity which you can run standard queries against--but even still that is "locked down".
This additional layer of complexity makes dealing with Activities programmatically more difficult (ex. querying the data, modifying the data via a plugin/SQL, etc.) and, in this particular case, makes even the most basic customizations impossible.
In Microsoft Dynamics CRM 4.0, I want to be able to check if a record of any entity type is disabled. I think I can check the statecode. From the information I have seen, a value of zero means that the entity is enabled (editable in CRM) and any other value means disabled (for editing in CRM).
Is this assumption correct for all entities?
EDIT
If my assumption is correct, is it possible to create a QueryExpression for dynamic entities that does such a comparison, rather than using the text, "Active", which would be incorrect for quotes?
From what I've read, StateCode is not necessarily the same for every entity. It varies per entity.
I'm not aware of a way to disable an entity. I double checked our install, but don't see any option to disable. Google also yields no results to this end.
Do you mean perhaps individual entity records? If so, you'll have to check the StateCode for the entity you're looking at. I think most entities use StateCode as you describe, but for some entities, such as Activities, it seems to vary a little.
Here is some SQL I found to pull back the StateCode/StatusCode details of a particular entity:
select
AttributeName,
AttributeValue,
Value
from dbo.StringMap
where
(dbo.StringMap.AttributeName = 'statuscode'
or
dbo.StringMap.AttributeName = 'statecode')
and
dbo.StringMap.ObjectTypeCode = 1
ObjectTypeCode 1 maps to the Account entity.
Hope this helps.
EDIT: Just saw your addition. I think you'll be safe using StateCode in most instances. I personally use it in one of my projects to exclude disabled records on the Lead and Contact entities. Just double check the value mapping as I've described and then implement.
I've made a custom entity that will work as an data modification audit (any entity modified will trigger creating an instance of this entity). So far I have the plugin working fine (tracking old and new versions of properties changed).
I'd like to also keep track of what entity this is related to. At first I added a N:1 from DataHistory to Task (eg.) and I can indeed link back to the original task (via a "new_tasksid" attribute I added to DataHistory).
The problem is every entity I want to log will need a separate attribute id (and an additional entry in the form!)
Looking at how phone, task, etc utilize a "regardingobjectid", this is what I should do. Unfortunately, when I try to add a "dataobjectid" and map it to eg Task and PhoneCall, it complains (on the second save), that the reference needs to be unique. How does the CRM get around this and can I emulate it?
You could create your generic "dataobjectid" field, but make it a text field and store the guid of the object there. You would lose the native grids for looking at the audit records, and you wouldn't be able to join these entities through advanced find, fetch or query expressions, but if that's not important, then you can whip up an ASPX page that displays the audit logs for that record in whatever format you choose and avoid making new relationships for every entity you want to audit.
CRM has a special lookup type that can lookup to many entity types. That functionality isn't available to us customizers, unfortunately. Your best bet is to add each relationship that could be regarding and hide the lookups that aren't in use for this particular entity.