CRM web api расширяется вместе с фильтром - внутреннее соединение или левое соединение?

Я пытаюсь использовать веб-запрос api, и без fetchxml мне удалось создать эту конечную точку, но набор результатов ведет себя как LEFT OUTER JOIN, но мне нужно INNER JOIN.

new_demo выполняет поиск new_currentappointment (здесь собрана самая последняя запись из списка подсеток), new_currentappointment выполняет поиск new_user.

Мне нужен список new_demo с new_currentappointment_lookup, где new_user_lookup - фильтр.

https://crmdev.crm.dynamics.com/api/data/v9.1/new_demo?$select=new_attribute_one&$expand=new_currentappointment_lookup($select=new_attribute_two;$filter=_new_user_lookup_value eq <guid>)

В результате получается каждый new_demo в системе, но фильтр расширения приводит только к нулю. Как удалить отфильтрованный нулевой результат из развернутой сущности в основном результате?

"value": [
    {
      "@odata.etag": "W/\"608177550\"",
      "new_attribute_one": "Demo 1",
    
      "new_currentappointment_lookup": {
        "new_attribute_two": "testing comments",
        "_new_user_lookup_value": "guid",
      },
    },
    {
      "@odata.etag": "W/\"608177790\"",
      "new_attribute_one": "Demo 2",
      
      "new_currentappointment_lookup": null,
    }
  ]

Этот результат объяснен в документации по веб-API ASP.NET. это то, что я ищу, но мне не удалось найти его для веб-API Dynamics CRM. Любой другой простой способ мне не хватает?


person Arun Vinoth    schedule 24.08.2020    source источник
comment
Продолжается обсуждение проблемы с github - github.com/MicrosoftDocs/powerapps-docs/issues/1692 < / а>   -  person Arun Vinoth    schedule 25.08.2020


Ответы (1)


Из Отзыв из документа: веб-API CRM расширяется вместе с фильтром - внутреннее присоединение или левое присоединение?

Это эквивалентный запрос для вашего сценария:

{{webapiurl}}incidents?$select=title
&$expand=customerid_account($select=name;
$expand=primarycontactid($select=fullname;
$filter=contactid eq '384d0f84-7de6-ea11-a817-000d3a122b89'))

$ Filter просто контролирует, будет ли запись расширена или нет.

В этом разница:

{
    "@odata.etag": "W/\"31762030\"",
    "title": "Sample Case",
    "incidentid": "d3d685f9-cddd-ea11-a813-000d3a122b89",
    "customerid_account": {
        "name": "Fourth Coffee",
        "accountid": "ccd685f9-cddd-ea11-a813-000d3a122b89",
        "primarycontactid": {
            "fullname": "Charlie Brown",
            "contactid": "384d0f84-7de6-ea11-a817-000d3a122b89"
        }
    }
}

И это:

{
    "@odata.etag": "W/\"31762030\"",
    "title": "Sample Case",
    "incidentid": "d3d685f9-cddd-ea11-a813-000d3a122b89",
    "customerid_account": {
        "name": "Fourth Coffee",
        "accountid": "ccd685f9-cddd-ea11-a813-000d3a122b89",
        "primarycontactid": null
    }
}

См. этот пример (Ctrl + F вложенный фильтр в развернутом виде), где все люди возвращаются, но раскрываются только поездки, соответствующие фильтру $.

Таким образом, поведение $ filter в раскрытии будет просто контролировать, будет ли возвращена деталь или нет. Это не поведение INNER JOIN. Для этого вам нужно будет использовать FetchXml.

person Jim Daly -MSFT-    schedule 25.08.2020
comment
Да, похожая структура. Если это можно протестировать с этой схемой, она может вести себя так же. Вы хотите, чтобы я проверил? - person Arun Vinoth; 25.08.2020
comment
Спасибо, что прояснили это как ожидаемое поведение. И FetchXml - единственный способ внутреннего соединения. - person Arun Vinoth; 31.08.2020