Невозможно получить имя поля поиска объекта ссылки (веб-API + FetchXml)

У меня есть файл fetchXml, который я выполняю через Dynamics CRM Web API. Запрос fetchXml построен так:

<fetch version="1.0" output-format="xml-platform" mapping="logical" distinct="false">
  <entity name="new_someEntityA">
    <attribute name="new_lookupForSomeEntityA" />
  <link-entity alias="new_someEntityB" name="new_someEntityB" from="entityBId" to="entityAId" visible="false" link-type="outer">
    <attribute name="new_lookupForSomeEntityB" />
  </link-entity>
  </entity>
</fetch>

Когда я отправляю этот запрос через веб-API, я получаю ответ, и значение «new_lookupForSomeEntityA» включает значение (GUID) и форматированное значение (его имя). Но ответ на «new_lookupForSomeEntityB» включает только GUID, и я не могу найти способ получить его GUID и значение. Я добавил запись заголовка для:

"Prefer": "odata.include-annotations=OData.Community.Display.V1.FormattedValue"

но это, кажется, просто дает мне форматированные значения для основного объекта, а не для объекта ссылки. Это ограничение веб-API или я что-то делаю не так? Любая помощь будет оценена по достоинству.


comment
Вы пытались добавить атрибут name к узлу <link-entity>?   -  person Henk van Boeijen    schedule 08.12.2016
comment
Да, я пробовал это. В SQL атрибутом является new_lookupForSomeEntityBName, и если я его добавлю, я получу ответ, в котором говорится, что этот атрибут не существует. Если я сделаю это с именем (в нижнем регистре), запрос вернется, но по-прежнему будет иметь только GUID, без имени для поиска.   -  person jmsims2    schedule 08.12.2016
comment
вам нужно указать имя атрибута имени на сущности new_someEntityB. Вы можете найти его в решении CRM на главной вкладке объекта. В SQL new_lookupForSomeEntityBName - это столбец отфильтрованного представления, который сопоставляется с именем основного поля фактической таблицы.   -  person Henk van Boeijen    schedule 08.12.2016
comment
Я изменил его на: <link-entity alias="new_someEntityB" name="new_someEntityB" name-attribute="new_name" from="entityBId" to="entityAId" visible="false" link-type="outer"> <attribute name-attribute="new_name" name="new_lookupForSomeEntityB" /> </link-entity> Когда я это сделаю, я получаю тот же идентификатор, что и возвращаемое значение, просто: new_someEntityB_x002e_new_lookupForSomeEntityBid: [GUID]   -  person jmsims2    schedule 08.12.2016
comment
Не используйте name-attribute атрибуты, а только <attribute name="new_name"/>.   -  person Henk van Boeijen    schedule 09.12.2016
comment
Прошу прощения, если я не понял, но поиск по объекту ссылки ведет к другому объекту в целом ... это не первичный ключ new_someEntityB, это поиск некоторого другого объекта, который хранится в new_someEntityB. Опять же, извините за путаницу.   -  person jmsims2    schedule 09.12.2016
comment
Думаю, это ограничение. Возможно, это полезно знать, но нечто подобное происходит, когда вы пытаетесь получить отформатированное значение связанного атрибута с именем, которое уже используется в атрибуте объекта. Так, например, когда ваши new_lookupForSomeEntityA и new_lookupForSomeEntityB имеют одинаковое имя, но вместо полей поиска используются поля даты (которые также имеют форматированное значение). Тогда только атрибут объекта получает форматированное значение.   -  person Skaj    schedule 12.12.2016


Ответы (1)


Вот код, который возвращает форматированные значения для наборов параметров объекта ссылки с помощью Web API + FetchXml.
Протестировано на API версии 8.2:

var oDataUrl = 'https://[your_org].crm4.dynamics.com/api/data/v8.2/';
var encodedFetchXml = encodeURI(`
<fetch top="10" no-lock="true" >
  <entity name="contact" >
    <attribute name="fullname" alias="contactName" />
    <link-entity name="incident" from="customerid" to="contactid" link-type="inner" alias="incident" >
      <attribute name="caseorigincode" alias="incidentOrigin" />
    </link-entity>
  </entity>
</fetch>
`);
$.ajax({
    type: "GET",
    contentType: "application/json; charset=utf-8",
    datatype: "json",
    url: `${oDataUrl}contacts?fetchXml=${encodedFetchXml}`,
    beforeSend: function (XMLHttpRequest) {
        XMLHttpRequest.setRequestHeader("Accept", "application/json");
        XMLHttpRequest.setRequestHeader("Prefer", "odata.include-annotations=OData.Community.Display.V1.FormattedValue");
    }
}).then(function (response) {
    // formatted value included in the response objects
    // [email protected]:"WhatsApp"
    console.dir(response); 
}); 

Это данные, которые возвращаются:
{ "@odata.context":"https://[your_org].crm4.dynamics.com/api/data/v8.2/$metadata#contacts(contactid)", "value":[{ "@odata.etag": "W/\"873006\"", "contactid": "ecfd1feb-d826-468a-bfe3-6ebd781c39f4", "contactName": "Ada Lovelace", "[email protected]": "WhatsApp", "incidentOrigin": 269420000 }] }

Он работает как с внутренними, так и с внешними типами ссылок.

Псевдоним атрибута Link-Entity, названный так же, как атрибут
Если вы сделаете псевдоним для атрибута связанной сущности таким же, как имя атрибута, то атрибут не будет возвращен вообще. Эта проблема возникает для всех атрибутов сущности ссылки.

<fetch top="500" no-lock="true" >
<entity name="contact" >
    <attribute name="fullname" alias="contactName" />
    <link-entity name="incident" from="customerid" to="contactid" link-type="inner" alias="incident" >
    <attribute name="caseorigincode" alias="caseorigincode" />
    </link-entity>
</entity>
</fetch>

Отсутствие псевдонима атрибута связанного объекта
Если вы не укажете псевдоним для атрибута связанного объекта, он будет возвращен с ужасным именем:

<fetch top="500" no-lock="true" >
<entity name="contact" >
    <attribute name="fullname" alias="contactName" />
    <link-entity name="incident" from="customerid" to="contactid" link-type="inner" alias="incident" >
    <attribute name="caseorigincode" />
    </link-entity>
</entity>
</fetch>

У возвращенных объектов есть такое поле:
incident_x002e_caseorigincode@OData.Community.Display.V1.FormattedValue:"WhatsApp"

Возможно, проблема, с которой вы столкнулись, была решена в версии 8.2.

person Bvrce    schedule 24.01.2017