Невозможно отобразить список всех страниц directoryObject, принадлежащих домену, с domainNameReferences GraphAPI из-за отсутствия атрибута nextLink - PullRequest
Новая
       5

Невозможно отобразить список всех страниц directoryObject, принадлежащих домену, с domainNameReferences GraphAPI из-за отсутствия атрибута nextLink

0 голосов
/ 02 марта 2020

В настоящее время мы используем библиотеку msgraph-sdk- java версии 1.5.0 для интеграции с GraphAPI и пытаемся составить список объектов каталога в домене, используя domainNameReferences API , как описано в документации .

Наш тестовый домен имеет более 30 пользователей, плюс несколько групп и приложений, и, чтобы перечислить их все, мы запускаем следующий Kotlin фрагмент : 

var domainUsersPage:IDirectoryObjectCollectionWithReferencesPage? = graphClient.domains(domainId).domainNameReferences().buildRequest().select("id").get()
while(domainUsersPage != null) {
    domainUsersPage.currentPage.forEach {directoryObject -> println("Retrieved ${directoryObject.oDataType} object with id ${directoryObject.id}") }
    domainUsersPage = domainUsersPage?.nextPage?.buildRequest()?.get()
    domainUsersPage?.run { println("Next page of domain directory objects retrieved") } ?: run{println("No further directory objects")}
}

При его запуске все объекты каталога для домена находятся на одной странице: 

Retrieved #microsoft.graph.user object with id d856d8bd-1cba-4efa-acdd-2c8b2aa4be27
Retrieved #microsoft.graph.user object with id c503d392-b639-4e02-9392-54f32ced7292
Retrieved #microsoft.graph.user object with id e87c9e7d-0bb5-41f2-a6e8-a463d58d491a
Retrieved #microsoft.graph.user object with id 68b0b5c8-d485-4e24-b3c8-f2fa56f93ef4
...(30 more users are listed)
Retrieved #microsoft.graph.group object with id 993cd6ca-8889-4713-9927-48ac9d5e7495
Retrieved #microsoft.graph.group object with id 33305fc5-9e7b-4cb7-bc2f-cdbbe7b934cd
...(27 more groups are listed)
Retrieved #microsoft.graph.application object with id 73b9fe88-6269-456f-8b97-6e6a0bf16415
...(5 more applications are listed)
No further directory objects

Однако мы рассматриваем использование указанных c размеров страницы, так что согласно документации, мы используем поддержку top параметра запроса , чтобы установить размер страницы одним из наших удобных, поэтому, настраивая код, чтобы использовать размер страницы 3, мы получаем: 

var domainUsersPage:IDirectoryObjectCollectionWithReferencesPage? = graphClient.domains(domainId).domainNameReferences().buildRequest().top(3).select("id").get()
while(domainUsersPage != null) {
    domainUsersPage.currentPage.forEach {directoryObject -> println("Retrieved ${directoryObject.oDataType} object with id ${directoryObject.id}") }
    domainUsersPage = domainUsersPage?.nextPage?.buildRequest()?.get()
    domainUsersPage?.run { println("Next page of domain directory objects retrieved") } ?: run{println("No further directory objects")}
}

Выполнение этого не приведет к ожидаемой коллекции объектов каталога, так как указана только первая страница: 

Retrieved #microsoft.graph.user object with id d856d8bd-1cba-4efa-acdd-2c8b2aa4be27
Retrieved #microsoft.graph.user object with id c503d392-b639-4e02-9392-54f32ced7292
Retrieved #microsoft.graph.user object with id e87c9e7d-0bb5-41f2-a6e8-a463d58d491a
No further directory objects

Отладка ответа от клиентской библиотеки GraphAPI При просмотре rawObject кажется, что атрибут @odata.nextLink не существует: 

{
    "@odata.context": "https://graph.microsoft.com/v1.0/$metadata#directoryObjects(id)",
    "value": [
        {
            "@odata.type": "#microsoft.graph.user",
            "id": "d856d8bd-1cba-4efa-acdd-2c8b2aa4be27"
        },
        {
            "@odata.type": "#microsoft.graph.user",
            "id": "c503d392-b639-4e02-9392-54f32ced7292"
        },
        {
            "@odata.type": "#microsoft.graph.user",
            "id": "e87c9e7d-0bb5-41f2-a6e8-a463d58d491a"
        }
    ]
}

К сожалению, это мешает нам получить дополнительные страницы объектов каталога, принадлежащих домену, и в настоящее время мы не нашли других альтернатив, чтобы обойти это (мы попытались использовать параметр запроса $ skip , но он не поддерживается по этому API)

Кто-нибудь еще испытывал такое поведение? Это ожидается?

...