Rozwiązywanie problemów z interfejsem API aprowizacji przychodzącej

Wprowadzenie

W tym dokumencie opisano często występujące błędy i problemy z interfejsem API aprowizacji dla ruchu przychodzącego oraz sposoby ich rozwiązywania.

Scenariusze rozwiązywania problemów

Nieprawidłowy format danych

Opis problemu

• Otrzymujesz komunikat Invalid Data Format o błędzie z kodem odpowiedzi HTTP 400 (nieprawidłowe żądanie).

Prawdopodobne przyczyny

1. Wysyłasz prawidłowe żądanie zbiorcze zgodnie ze specyfikacją interfejsu API udostępniania /bulkUpload, ale nie ustawiono nagłówka żądania HTTP „Content-Type” na wartość application/scim+json.
2. Wysyłasz żądanie zbiorcze, które nie spełnia specyfikacji interfejsu API aprowizacji /bulkUpload.

Rozwiązanie:

1. Upewnij się, że żądanie HTTP ma ustawiony nagłówek Content-Type na wartość application/scim+json.
2. Upewnij się, że treść żądania zbiorowego jest zgodna ze specyfikacją API aprowizacji /bulkUpload.

W dziennikach aprowizacji nie ma żadnych wpisów

Opis problemu

• Wysłano żądanie do punktu końcowego interfejsu API aprowizacji /bulkUpload i otrzymano kod odpowiedzi HTTP 202, ale w dziennikach aprowizacji odpowiadających żądaniu nie ma żadnych danych.

Prawdopodobne przyczyny

1. Aplikacja do aprowizacji sterowana przez interfejs API jest wstrzymana.
2. Usługa aprowizacji nie zaktualizowała jeszcze dzienników aprowizacji przy użyciu szczegółów przetwarzania żądań zbiorczych.
3. Twój agent aprowizacji lokalnej jest nieaktywny (jeśli uruchamiasz aprowizację użytkownika przychodzącego opartą na interfejsie API do lokalnego Active Directory).

Rozwiązanie:

1. Sprawdź, czy aplikacja aprowizacji jest uruchomiona. Jeśli nie jest uruchomione, wybierz z menu opcję Rozpocznij aprowizację, aby przetworzyć dane.
2. Zmień stan lokalnego agenta aprowizacji na aktywny, uruchamiając ponownie lokalnego agenta.
3. Możesz oczekiwać opóźnienia od 5 do 10 minut między przetwarzaniem żądania a zapisywaniem w dziennikach aprowizacji. Jeśli klient interfejsu API wysyła dane do punktu końcowego interfejsu API aprowizacji /bulkUpload, wprowadź opóźnienie czasu między wywołaniem żądania a zapytaniem dzienników aprowizacji.

Zabroniony kod odpowiedzi 403

Opis problemu

• Wysłano żądanie do punktu końcowego interfejsu API aprowizacji /bulkUpload i otrzymano kod odpowiedzi HTTP 403 (Zabronione).

Prawdopodobne przyczyny

• Uprawnienie SynchronizationData-User.Upload programu Graph nie jest przypisane do klienta interfejsu API.

Rozwiązanie:

• Przypisz klientowi interfejsu API uprawnienie SynchronizationData-User.Upload programu Graph i spróbuj ponownie wykonać operację.

Zbyt wiele żądań — kod odpowiedzi 429

Punkt końcowy interfejsu API bulkUpload wymusza następujące limity ograniczania przepustowości i zwraca kod odpowiedzi 429, jeśli te limity zostaną naruszone.

• 40 wywołań interfejsu API na 5 sekund — jeśli liczba wywołań przekracza ten limit w 5-sekundowym zakresie, klient otrzyma odpowiedź 429. Jednym ze sposobów uniknięcia tego jest rozłożenie w czasie wysyłania żądań przez zastosowanie opóźnień w logice klienta odpowiedzialnej za ich wysyłanie. 

• 6000 wywołań interfejsu API w okresie 24-godzinnym — jeśli liczba wywołań przekracza ten limit, klient otrzyma odpowiedź 429. Jednym ze sposobów, aby temu zapobiec, jest upewnienie się, że zbiorczy ładunek danych SCIM jest zoptymalizowany tak, aby wykorzystywać maksymalnie 50 rekordów w jednym wywołaniu API. Dzięki temu podejściu można wysyłać 300 000 rekordów co 24 godziny.

Kod odpowiedzi 500: bucket jest pełny

Opis problemu

• Klient SCIM pobiera protokół HTTP 500 (wewnętrzny błąd serwera) z komunikatem: "Zasobnik, który przechowuje pozyskane dane, jest pełny, poczekaj na przetworzenie pozyskanych danych przez usługę synchronizacji i ponów próbę wykonania tego żądania".
• Ten błąd może wystąpić podczas początkowej synchronizacji lub pełnych cykli synchronizacji, gdy duże zestawy danych HR są wysyłane do punktu końcowego aprowizacji /bulkUpload .

Dlaczego występuje ten błąd

• „Zasobnik” to tymczasowa kolejka przyjmowania danych używana przez usługę aprowizacji do buforowania przychodzących danych /bulkUpload przed ich przetworzeniem.
• Każde zadanie udostępniania sterowane przez API ma dedykowaną kolejkę przyjmowania danych.
• Usługa aprowizacji stale przetwarza ładunki w kolejce, a następnie usuwa przetworzone dane. Jeśli ten cykl przetwarzania i usuwania zacznie się opóźniać lub zatrzyma się, dane w kolejce mogą się gromadzić, aż bucket się zapełni.

Prawdopodobne przyczyny i rozwiązanie

Nieautoryzowany kod odpowiedzi 401

Opis problemu

• Wysłano żądanie do punktu końcowego interfejsu API aprowizacji /bulkUpload i otrzymano kod odpowiedzi HTTP 401 (Brak autoryzacji). Kod błędu wyświetla komunikat "InvalidAuthenticationToken" z komunikatem "Token dostępu wygasł lub nie jest jeszcze prawidłowy".

Prawdopodobne przyczyny

• Token dostępu wygasł.

Rozwiązanie:

• Wygeneruj nowy token dostępu dla klienta interfejsu API.

Zadanie przechodzi w stan kwarantanny

Opis problemu

• Właśnie uruchomiono aplikację aprowizacji i jest ona w stanie kwarantanny.

Prawdopodobne przyczyny

• Nie ustawiono wiadomości e-mail z powiadomieniem przed rozpoczęciem zadania.

Rozwiązanie: przejdź do elementu menu Edytuj aprowizację . W obszarze Ustawienia znajduje się pole wyboru obok pozycji Wyślij powiadomienie e-mail w przypadku wystąpienia błędu i pola umożliwiającego wprowadzenie wiadomości e-mail z powiadomieniem. Pamiętaj, aby zaznaczyć to pole, podać wiadomość e-mail i zapisać zmianę. Kliknij Rozpocznij ponownie proces, aby usunąć zadanie z kwarantanny.

Tworzenie użytkownika - nieprawidłowy identyfikator UPN

Opis problemu: Wystąpił błąd aprowizacji użytkownika. Dzienniki aprowizacji wyświetlają kod błędu: AzureActiveDirectoryInvalidUserPrincipalName.

Rozwiązanie:

1. Przejdź do strony Edycja mapowań atrybutów.
2. Wybierz mapowanie UserPrincipalName i zaktualizuj je tak, aby korzystało z funkcji RandomString.
3. Skopiuj i wklej to wyrażenie w polu wyrażenia: Join("", Replace([userName], , "(?<Suffix>@(.)*)", "Suffix", "", , ), RandomString(3, 3, 0, 0, 0, ), "@", DefaultDomain())

To wyrażenie rozwiązuje problem, dołączając losową liczbę do wartości UPN akceptowanej przez Microsoft Entra ID.

Tworzenie użytkownika nie powiodło się — nieprawidłowa domena

Opis problemu: Wystąpił błąd aprowizacji użytkownika. Dziennik aprowizacji wyświetla komunikat o błędzie o treści domain does not exist.

Rozwiązanie:

1. Przejdź do strony Edytowanie mapowań atrybutów .
2. Wybierz mapowanie UserPrincipalName i skopiuj, a następnie wklej to wyrażenie do pola wprowadzania wyrażenia: Join("", Replace([userName], , "(?<Suffix>@(.)*)", "Suffix", "", , ), RandomString(3, 3, 0, 0, 0, ), "@", DefaultDomain())

To wyrażenie rozwiązuje problem, dołączając domyślną domenę do wartości UPN akceptowanej przez Microsoft Entra ID.

Znane ograniczenie: adresy wielowartościowe, wiadomości e-mail i numery telefonów

Opis problemu

• Aprowizacja oparta na interfejsie API nie przetwarza obecnie wielowartościowych atrybutów SCIM w addresses, emails i phoneNumbers, gdy wartość type to home lub dowolna inna wartość różna od work.
• To ograniczenie dotyczy wyrażeń, takich jak addresses[type eq "home"], addresses[type eq "any-other-value"]i phoneNumbers[type eq "home"].

Bieżące zachowanie

• Przetwarzane są tylko wartości addresses[type eq "work"], emails[type eq "work"] i phoneNumbers[type eq "work"].

Obejście problemu

• Wyślij obsługiwane wartości przy użyciu work typu, gdy potrzebujesz atrybutu do przetworzenia przez aprowizację opartą na interfejsie API.

Następne kroki

• Dowiedz się więcej o aprowizacji przychodzącej opartej na interfejsie API