2016-05-17 10 views
0

В настоящее время у меня есть код, который использует http-патч для отправки данных Microsoft CRM через веб-api 2016. Когда моя полезная нагрузка содержит текстовый или внутренний тип данных, она работает нормально, но когда полезная нагрузка содержит запись поиска, я не могу получить ответ за 400 запросов.Неисправность обновления поля поиска типа с помощью Microsoft API CRM 2016 Web API

Ниже приведен некоторые из примеров полезной нагрузки, что я пытался (с sentitive данных измененных)

payload = {"new_lastweblocation": "Midlothian" } 
payload = {"[email protected]" : "https://crmnaorgXXXX.crm.dynamics.com/api/data/v8.0/new_locations(1234578-a588-e511-8105-c4346bace18c)"} 
payload = {"[email protected]" : "https://crmnaorgXXXX.crm.dynamics.com/api/data/v8.0/new_locations(1234578-a588-e511-8105-c4346bace18c)"} 

По существу я пытался проходящим открытым текстом, Guid к записи GUID, к отношениям , guid, связанный через odata.bind ... и т. д. Очевидно, что мой подход к дробовикам наряду с ошибкой 400 означает, что я принципиально неправильно понимаю, как обрабатываются объекты в веб-афике 2016 года. Дайте мне знать, если у вас есть предложения.

ответ

2

В итоге я использовал this request. Основная проблема, которую я испытывал, заключается в том, что я не знал, что такое однозначное свойство навигации. Чтобы найти, что я закончил с использованием this request. Я изменил избранных в URL, чтобы быть выбраны = «*»

Оригинальный URL

GET [Organization URI]/api/data/v8.1/incidents(39dd0b31-ed8b-e511-80d2-00155d2a68d4)?$select=title,customerid_value&$expand=customerid_contact($select=fullname) 

Мой URL

GET [Organization URI]/api/data/v8.1/incidents(39dd0b31-ed8b-e511-80d2-00155d2a68d4)?$select=* 

При использовании запроса GET, чтобы попытаться найти однозначную навигации свойство обязательно добавьте 'Prefer':'odata.include-annotations"*". Я не мог получить заголовок preference, пока я не поставил его перед моим заголовком авторизации.

Наконец, как только я получил ответ от запроса на получение, я искал переменную, которую я искал с @Microsoft.Dynamics.CRM.associatednavigationproperty в конце ее, и использовал значение, связанное с этим. В моем случае имя поля было new_lastweblocation, но однонаправленное навигационное свойство было new_LastWebLocation

3

Подход, указанный в MSDN для associating entities on create, также работает при обновлении. Я тестировал следующий запрос в 2016 демонстрационной среде без проблем (где GUID, были заменены на существующие счета и контактных GUIDs, соответственно):

PATCH [Organization URI]/api/data/v8.0/accounts/(00000000-0000-0000-0000-000000000001) HTTP/1.1 
Content-Type: application/json; charset=utf-8 
OData-MaxVersion: 4.0 
OData-Version: 4.0 
Accept: application/json 

{ 
"name":"Sample Account", 
"[email protected]":"/contacts(00000000-0000-0000-0000-000000000001)" 
} 

могли бы начать с проверки того, что это вне коробки работает ли до начала отладки вашей конкретной проблемы с поиском пользовательского объекта?

+0

После прочтения документации я попробовал несколько вещей и в итоге оказался вынужденным использовать однозначное свойство навигации – mucle6

 Смежные вопросы

  • Нет связанных вопросов^_^