Felsök problem med API för inbound-etablering

Introduktion

Det här dokumentet behandlar vanligt förekommande fel och problem med API för inkommande provisionering och hur du felsöker dem.

Felsökningsscenarier

Ogiltigt dataformat

Problembeskrivning

• Du får felmeddelandet Invalid Data Format med HTTP 400-svarskoden (felaktig begäran).

Sannolika orsaker

1. Du skickar en giltig massförfrågan enligt API-specifikationerna för provisionering /bulkUpload, men du har inte ställt in HTTP-begäranderubriken 'Content-Type' på application/scim+json.
2. Du skickar en massförfrågan som inte uppfyller provisionerings-API:ets /bulkUpload-specifikationer.

Lösning:

1. Se till att HTTP-begäran har rubriken Content-Type inställd på värdet application/scim+json.
2. Se till att innehållet i massbegäran överensstämmer med API-specifikationerna för provisionerings-API:t /bulkUpload.

Det finns inget i etableringsloggarna

Problembeskrivning

• Du skickade en förfrågan till API-slutpunkten provisioning /bulkUpload och fick HTTP-statuskoden 202, men det finns inga poster i provisioneringsloggarna som motsvarar din förfrågan.

Sannolika orsaker

1. Din API-drivna provisioneringsapp har pausats.
2. Etableringstjänsten har ännu inte uppdaterat etableringsloggarna med information om bearbetning av massbegäranden.
3. Statusen för din lokala etableringsagent är inaktiv (om du kör den /API-drivna inkommande användaretablering till den lokala Active Directory).

Lösning:

1. Kontrollera att provisioneringsappen är igång. Om den inte körs väljer du menyalternativet Starta provisionering för att bearbeta data.
2. Ändra statusen för den lokala etableringsagenten till aktiv genom att starta om den lokala etableringsagenten.
3. Förvänta dig en försening på 5 till 10 minuter mellan bearbetningen av begäran och att skriva i etableringsloggarna. Om din API-klient skickar data till API-slutpunkten provisioning /bulkUpload ska du införa en tidsfördröjning mellan att begäran skickas och att provisioneringsloggarna frågas.

Förbjuden 403-svarskod

Problembeskrivning

• Du skickade en förfrågan till API-slutpunkten /bulkUpload för provisionering och fick HTTP-statuskoden 403 (Nekad).

Sannolika orsaker

• Graph-behörigheten SynchronizationData-User.Upload tilldelas inte till API-klienten.

Lösning:

• Tilldela API-klienten Graph-behörigheten SynchronizationData-User.Upload och försök igen.

För många begäranden 429-svarskod

BulkUpload API-slutpunkten tillämpar följande begränsningsgränser och returnerar en 429-svarskod om dessa gränser överskrids.

• 40 API-anrop per 5 sekunder – om antalet anrop överskrider den här gränsen inom ett intervall på 5 sekunder får klienten ett svar på 429. Ett sätt att undvika detta är genom att skicka begäranden med fördröjningar i logiken för att skicka klientbegäranden. 

• 6 000 API-anrop under en 24-timmarsperiod – om antalet anrop överskrider den här gränsen får klienten ett svar på 429. Ett sätt att förhindra detta är att se till att SCIM-massbegäransnyttolasten är optimerad så att den använder högst 50 poster per API-anrop. Med den här metoden kan du skicka 300 000 poster var 24:e timme.

Bucketen är full, svarskod 500

Problembeskrivning

• SCIM-klienten hämtar HTTP 500 (internt serverfel) med meddelandet: "Bucketen som lagrar inmatade data är full, vänta tills synkroniseringstjänsten bearbetar inmatade data och försök igen med den här begäran."
• Det här felet kan visas under den inledande synkroniseringen eller under fullständiga synkroniseringscykler när stora HR-datamängder skickas till slutpunkten för provisionering /bulkUpload.

Varför det här felet uppstår

• "Bucketen" är den temporära kö för inläsning som provisioneringstjänsten använder för att buffra inkommande /bulkUpload-payloads innan de bearbetas.
• Varje API-styrt provisioneringsjobb har en dedikerad inläsningskö.
• Provisioneringstjänsten bearbetar kontinuerligt köade payloadar och raderar sedan bearbetade data. Om den här process- och borttagningscykeln kommer efter eller stannar kan data köas upp tills lagringsbehållaren är full.

Sannolika orsaker och lösningar

Otillåten 401-svarskod

Problembeskrivning

• Du skickade en förfrågan till API-slutpunkten för provisionering /bulkUpload och du fick HTTP-svarskoden 401 (Obehörig). Felkoden visar "InvalidAuthenticationToken" med ett meddelande om att åtkomsttoken har upphört att gälla eller inte är giltig ännu.

Sannolika orsaker

• Din åtkomsttoken har upphört att gälla.

Lösning:

• Generera en ny åtkomsttoken för API-klienten.

Jobbet går in i karantänsläge

Problembeskrivning

• Du har precis startat provisioneringsappen och den är i karantän.

Sannolika orsaker

• Du har inte angett e-postmeddelandet innan du startar jobbet.

Lösning: Gå till menyalternativet Redigera provisionering. Under Inställningar finns en kryssruta bredvid Skicka ett e-postmeddelande när ett fel inträffar och ett fält för att ange din e-postavisering. Markera kryssrutan, ange ett e-postmeddelande och spara ändringen. Klicka på Starta om tillhandahållande för att få arbetet ur karantän.

Skapa användare – Ogiltigt UPN

Problembeskrivning Det finns ett användaretableringsfel. Etableringsloggarna visar felkoden: AzureActiveDirectoryInvalidUserPrincipalName.

Lösning:

1. Kom till sidan Redigera attributmappningar .
2. Välj mappningen UserPrincipalName och uppdatera den för att använda RandomString funktionen.
3. Kopiera och klistra in det här uttrycket i uttrycksrutan: Join("", Replace([userName], , "(?<Suffix>@(.)*)", "Suffix", "", , ), RandomString(3, 3, 0, 0, 0, ), "@", DefaultDomain())

Det här uttrycket åtgärdar problemet genom att lägga till ett slumpmässigt tal till DET UPN-värde som godkänts av Microsoft Entra-ID.

Det gick inte att skapa användare – ogiltig domän

Problembeskrivning Det finns ett användaretableringsfel. Etableringsloggarna visar ett felmeddelande som anger domain does not exist.

Lösning:

1. Gå till sidan Redigera attributmappningar .
2. Välj mappning UserPrincipalName och kopiera och klistra in det här uttrycket i indatarutan för uttrycket: Join("", Replace([userName], , "(?<Suffix>@(.)*)", "Suffix", "", , ), RandomString(3, 3, 0, 0, 0, ), "@", DefaultDomain())

Det här uttrycket åtgärdar problemet genom att lägga till en standarddomän till UPN-värdet som godkänts av Microsoft Entra-ID.

Känd begränsning: flervärdesadresser, e-postmeddelanden och telefonnummer

Problembeskrivning

• Etablering via API bearbetar för närvarande inte SCIM-attribut med flera värden i addresses, emails och phoneNumbers när värdet för type är home eller något annat värde än work.
• Den här begränsningen gäller för uttryck som addresses[type eq "home"], addresses[type eq "any-other-value"]och phoneNumbers[type eq "home"].

Aktuellt beteende

• Endast addresses[type eq "work"], emails[type eq "work"] och phoneNumbers[type eq "work"] värden bearbetas.

Workaround

• Skicka värden som stöds med typen work när du behöver att attributet bearbetas av API-styrd etablering.

Nästa steg

• Läs mer om API-driven inkommande etablering