Megosztás a következőn keresztül:


Bejövő kiépítési API-problémák elhárítása

Bevezetés

Ez a dokumentum a bejövő kiépítési API gyakori hibáit és problémáit, valamint a hibaelhárításuk módját ismerteti.

Hibaelhárítási forgatókönyvek

Érvénytelen adatformátum

Probléma leírása

  • A hibaüzenet Invalid Data Format a HTTP 400 (Hibás kérés) válaszkóddal jelenik meg.

Valószínű okok

  1. Érvényes tömeges kérelmet küld a kiépítési /bulkUpload API-specifikációknak megfelelően, de nem állította be a "Content-Type" application/scim+jsonHTTP-kérelem fejlécét.
  2. Olyan tömeges kérelmet küld, amely nem felel meg a kiépítési /bulkUpload API-specifikációknak.

Megoldás:

  1. Győződjön meg arról, hogy a HTTP-kérelem fejléce Content-Type az értékre application/scim+jsonvan állítva.
  2. Győződjön meg arról, hogy a tömeges kérelem hasznos adatai megfelelnek a kiépítési /bulkUpload API-specifikációknak.

Nincs semmi a kiépítési naplókban

Probléma leírása

  • Kérelmet küldött a kiépítési /bulkUpload API-végpontnak, és http 202-es válaszkódot kapott, de a kiépítési naplók nem felelnek meg a kérésnek.

Valószínű okok

  1. Az API-alapú kiépítési alkalmazás szüneteltetve van.
  2. A kiépítési szolgáltatás még nem frissíti a kiépítési naplókat a tömeges kérésfeldolgozás részleteivel.
  3. A helyszíni kiépítési ügynök állapota inaktív (ha a /API-vezérelt bejövő felhasználókiépítést futtatja helyi Active Directory).

Megoldás:

  1. Ellenőrizze, hogy fut-e a kiépítési alkalmazás. Ha nem fut, válassza a kiépítés indítása lehetőséget az adatok feldolgozásához.
  2. Kapcsolja aktívvá a helyszíni kiépítési ügynök állapotát a helyszíni ügynök újraindításával.
  3. 5–10 perces késés várható a kérés feldolgozása és a kiépítési naplókba való írás között. Ha az API-ügyfél adatokat küld a kiépítési /bulkUpload API-végpontnak, akkor a kéréshívás és a kiépítési naplók lekérdezése között időtúllépést kell bevezetnie.

Tiltott 403 válaszkód

Túl sok kérés 429 válaszkód

A bulkUpload API-végpont a következő szabályozási korlátokat kényszeríti ki, és egy 429-es válaszkódot ad vissza, ha ezek a korlátok túllépnek.

  • 40 API-hívás 5 másodpercenként – ha a hívások száma meghaladja ezt a korlátot egy 5 másodperces tartományban, akkor az ügyfél 429-es választ kap. Ennek elkerülésére az egyik módszer, ha késlelteti a kérések beküldését az ügyfélkérések beküldési logikájában. 

  • 6000 API-hívás 24 órás időtartamon keresztül – ha a hívások száma meghaladja ezt a korlátot, akkor az ügyfél 429-es választ kap. Ennek egyik módja annak biztosítása, hogy az SCIM tömeges hasznos adatai úgy legyenek optimalizálva, hogy az API-hívásonként legfeljebb 50 rekordot használjon. Ezzel a módszerrel 24 óránként 300 ezer rekordot küldhet.

Probléma leírása

  • Kérelmet küldött a kiépítési /bulkUpload API-végpontnak, és HTTP 403 (Tiltott) válaszkódot kapott.

Valószínű okok

  • A Graph-engedély SynchronizationData-User.Upload nincs hozzárendelve az API-ügyfélhez.

Megoldás:

  • Rendelje hozzá az API-ügyfelet a Graph-engedélyhez SynchronizationData-User.Upload , és próbálkozzon újra a művelettel.

Jogosulatlan 401-válaszkód

Probléma leírása

  • Kérelmet küldött a kiépítési /bulkUpload API-végpontnak, és http 401 (jogosulatlan) válaszkódot kapott. A hibakód az "InvalidAuthenticationToken" üzenetet jeleníti meg, amely szerint a "Hozzáférési jogkivonat lejárt vagy még nem érvényes".

Valószínű okok

  • A hozzáférési jogkivonat lejárt.

Megoldás:

  • Hozzon létre egy új hozzáférési jogkivonatot az API-ügyfélhez.

A feladat karanténba kerül

Probléma leírása

  • Most indította el a kiépítési alkalmazást, és karanténban van.

Valószínű okok

  • A feladat megkezdése előtt nem állította be az értesítési e-mailt.

Megoldás: Nyissa meg a Kiépítés szerkesztése menüelemet. Az Gépház alatt az E-mail küldése értesítés küldése hiba esetén jelölőnégyzet és egy mező található az értesítési e-mail beviteléhez. Jelölje be a jelölőnégyzetet, adjon meg egy e-mailt, és mentse a módosítást. Kattintson az Újraindítás kiépítés elemre a feladat karanténból való kiosztásához.

Felhasználó létrehozása – Érvénytelen UPN

A probléma leírása Felhasználói kiépítési hiba történt. A kiépítési naplók a következő hibakódot jelenítik meg: AzureActiveDirectoryInvalidUserPrincipalName.

Megoldás:

  1. Lépjen az Attribútumleképezések szerkesztése lapra .
  2. Válassza ki a leképezést UserPrincipalName , és frissítse a RandomString függvény használatához.
  3. Másolja és illessze be ezt a kifejezést a kifejezésmezőbe: Join("", Replace([userName], , "(?<Suffix>@(.)*)", "Suffix", "", , ), RandomString(3, 3, 0, 0, 0, ), "@", DefaultDomain())

Ez a kifejezés úgy oldja meg a problémát, hogy egy véletlenszerű számot fűz a Microsoft Entra ID által elfogadott UPN-értékhez.

A felhasználó létrehozása nem sikerült – Érvénytelen tartomány

A probléma leírása Felhasználói kiépítési hiba történt. A kiépítési naplók egy hibaüzenetet jelenítenek meg, amely azt jelzi domain does not exist, hogy .

Megoldás:

  1. Lépjen az Attribútumleképezések szerkesztése lapra .
  2. Jelölje ki a leképezést UserPrincipalName , és másolja és illessze be a kifejezést a kifejezés beviteli mezőjébe: Join("", Replace([userName], , "(?<Suffix>@(.)*)", "Suffix", "", , ), RandomString(3, 3, 0, 0, 0, ), "@", DefaultDomain())

Ez a kifejezés úgy oldja meg a problémát, hogy hozzáfűz egy alapértelmezett tartományt a Microsoft Entra ID által elfogadott UPN-értékhez.

Következő lépések