Udostępnij przez

Rozwiązywanie problemów z interfejsem API aprowizacji ruchu przychodzącego

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 specyfikacjami interfejsu API aprowizacji /bulkUpload , ale nie ustawiono nagłówka żądania HTTP "Content-Type" na application/scim+jsonwartość .
  2. Wysyłasz żądanie zbiorcze, które nie jest zgodne ze specyfikacjami interfejsu API aprowizacji /bulkUpload .

Rozwiązanie:

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

W dziennikach aprowizacji nie ma nic

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 aprowizacji oparta na interfejsie 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 uruchomiona, wybierz opcję menu Rozpocznij aprowizację , aby przetworzyć dane.
  2. Włącz stan lokalnego agenta aprowizacji, uruchamiając ponownie agenta lokalnego.
  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, aby tego uniknąć, jest pacing żądania przesyłania przy użyciu opóźnień w logice przesyłania żądań klienta. 

  • 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 zapobiegania temu jest upewnienie się, że ładunek zbiorczy SCIM jest zoptymalizowany pod kątem używania maksymalnie 50 rekordów na wywołanie interfejsu API. Dzięki temu podejściu można wysyłać 300 000 rekordów co 24 godziny.

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łowa nazwa UPN

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

Rozwiązanie:

  1. Przejdź do strony Edytowanie mapowań atrybutów .
  2. UserPrincipalName Wybierz mapowanie i zaktualizuj je, aby użyć RandomString funkcji .
  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 zaakceptowanej przez identyfikator Firmy Microsoft Entra.

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

Opis problemu: Wystąpił błąd aprowizacji użytkownika. Dzienniki aprowizacji wyświetla komunikat o błędzie informujący domain does not existo błędzie.

Rozwiązanie:

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

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

Następne kroki

  • Last updated on