Problemen met de inkomende provisioning-API oplossen

Inleiding

In dit document worden veelvoorkomende fouten en problemen met de binnenkomende inrichtings-API beschreven en hoe u deze kunt oplossen.

Scenario’s voor probleemoplossing

Ongeldige gegevensindeling

Beschrijving van probleem

• U krijgt het foutbericht Invalid Data Format met HTTP 400-antwoordcode (Ongeldige aanvraag).

Waarschijnlijke oorzaken

1. U verstuurt een geldig bulkverzoek volgens de specificaties van de provisioning-/bulkUpload-API, maar u heeft de HTTP-requestheader 'Content-Type' niet ingesteld op application/scim+json.
2. U verstuurt een bulkverzoek dat niet voldoet aan de specificaties van de provisioning-/bulkUpload-API.

Oplossing:

1. Zorg ervoor dat de HTTP-aanvraag de Content-Type header heeft ingesteld op de waarde application/scim+json.
2. Zorg ervoor dat de payload van het bulkverzoek voldoet aan de specificaties van de provisioning-/bulkUpload-API.

Er staat niets in de provisioneringslogboeken

Beschrijving van probleem

• U hebt een aanvraag verzonden naar het inrichtings-/bulkUpload-API-eindpunt en u hebt http 202-antwoordcode ontvangen, maar er zijn geen gegevens in de inrichtingslogboeken die overeenkomen met uw aanvraag.

Waarschijnlijke oorzaken

1. Uw API-gestuurde provisioning-app is gepauzeerd.
2. De inrichtingsservice moet de inrichtingslogboeken nog bijwerken met de details van de verwerking van bulkaanvragen.
3. De status van de on-premises inrichtingsagent is inactief (als u de inrichting van binnenkomende gebruikers op basis van API uitvoert voor on-premises Active Directory).

Oplossing:

1. Controleer of uw inrichtings-app wordt uitgevoerd. Als dit niet actief is, selecteert u de menuoptie Inrichten starten om de gegevens te verwerken.
2. Zet de status van de On-premises-inrichtingsagent op Actief door de On-premises-agent opnieuw te starten.
3. Verwacht een vertraging van 5 tot 10 minuten tussen het verwerken van de aanvraag en het schrijven naar de inrichtingslogboeken. Als uw API-client gegevens naar het /bulkUpload-API-eindpunt voor provisioning verzendt, houd dan rekening met een tijdsvertraging tussen het verzenden van de aanvraag en het opvragen van de provisioninglogboeken.

Verboden 403-antwoordcode

Beschrijving van probleem

• U hebt een verzoek verzonden naar het API-eindpunt provisioning /bulkUpload en u hebt de HTTP-responscode 403 (Forbidden) ontvangen.

Waarschijnlijke oorzaken

• De Graph-machtiging SynchronizationData-User.Upload is niet toegewezen aan uw API-client.

Oplossing:

• Wijs uw API-client de Graph-machtiging SynchronizationData-User.Upload toe en voer de bewerking opnieuw uit.

Te veel aanvragen 429-antwoordcode

Het api-eindpunt bulkUpload dwingt de volgende beperkingslimieten af en retourneert een 429-antwoordcode als deze limieten worden overschreden.

• 40 API-aanroepen per 5 seconden: als het aantal aanroepen binnen een bereik van 5 seconden overschrijdt, krijgt de client een 429-antwoord. Een manier om dit te voorkomen, is door de indiening van de aanvraag te paceren met behulp van vertragingen in de logica voor het indienen van clientaanvragen. 

• 6.000 API-aanroepen gedurende een periode van 24 uur: als het aantal aanroepen deze limiet overschrijdt, krijgt de client een 429-antwoord. Een manier om dit te voorkomen, is ervoor te zorgen dat uw SCIM-bulkpayload is geoptimaliseerd voor het gebruik van de maximaal 50 records per API-aanroep. Met deze methode kunt u elke 24 uur 300.000 records verzenden.

500-responscode voor bucket vol

Beschrijving van probleem

• De SCIM-client ontvangt HTTP 500 (interne serverfout) met het bericht: 'De bucket waarin de opgenomen gegevens worden opgeslagen, is vol. Wacht tot de synchronisatieservice de opgenomen gegevens verwerkt en probeer deze aanvraag opnieuw.'
• Deze fout kan optreden tijdens de eerste synchronisatie- of volledige synchronisatiecycli wanneer grote HR-gegevenssets naar het inrichtingseindpunt /bulkUpload worden verzonden.

Waarom deze fout optreedt

• De "bucket" is de tijdelijke invoerwachtrij die door de provisioningservice wordt gebruikt om binnenkomende /bulkUpload payloads te bufferen voordat deze worden verwerkt.
• Elke API-inrichtingstaak heeft een toegewezen opnamewachtrij.
• De provisioningservice verwerkt continu payloads in de wachtrij en verwijdert vervolgens verwerkte gegevens. Als deze verwerkings- en verwijdercyclus achter raakt of stopt, kunnen gegevens in de wachtrij zich ophopen totdat de opslagbucket vol is.

Mogelijke oorzaken en oplossing

Niet-geautoriseerde 401-antwoordcode

Beschrijving van probleem

• U hebt een verzoek verzonden naar het API-eindpunt provisioning /bulkUpload en u hebt HTTP-responscode 401 (Onbevoegd) ontvangen. In de foutcode wordt 'InvalidAuthenticationToken' weergegeven met een bericht dat het toegangstoken is verlopen of nog niet geldig is.

Waarschijnlijke oorzaken

• Uw toegangstoken is verlopen.

Oplossing:

• Genereer een nieuw toegangstoken voor uw API-client.

De taak gaat in quarantaine

Beschrijving van probleem

• U bent net begonnen met de inrichtings-app en deze heeft de quarantainestatus.

Waarschijnlijke oorzaken

• U hebt de e-mailmelding niet ingesteld voordat u de taak start.

Oplossing: Ga naar het menu-item Inrichten bewerken . Onder Instellingen is er een selectievakje naast Een e-mailmelding verzenden wanneer er een fout optreedt en een veld voor het invoeren van uw e-mailmelding. Zorg ervoor dat u het selectievakje inschakelt, een e-mailbericht opgeeft en de wijziging opslaat. Klik op Inrichting opnieuw opstarten om de taak uit quarantaine te halen.

Gebruiker maken - Ongeldige UPN

Beschrijving van probleem Er is een fout opgetreden bij het inrichten van gebruikers. In de inrichtingslogboeken wordt de foutcode weergegeven: AzureActiveDirectoryInvalidUserPrincipalName.

Oplossing:

1. Ga naar de pagina Kenmerktoewijzingen bewerken.
2. Selecteer de UserPrincipalName-koppeling en pas deze aan zodat de RandomString-functie wordt gebruikt.
3. Kopieer en plak deze expressie in het expressievak: Join("", Replace([userName], , "(?<Suffix>@(.)*)", "Suffix", "", , ), RandomString(3, 3, 0, 0, 0, ), "@", DefaultDomain())

Met deze expressie wordt het probleem opgelost door een willekeurig getal toe te voegen aan de UPN-waarde die door Microsoft Entra-id is geaccepteerd.

Gebruiker aanmaken mislukt - Ongeldig domein

Beschrijving van probleem Er is een fout opgetreden bij het inrichten van gebruikers. In de inrichtingslogboeken wordt een foutbericht weergegeven waarin staat domain does not exist.

Oplossing:

1. Ga naar de pagina Kenmerktoewijzingen bewerken.
2. Selecteer de UserPrincipalName toewijzing en kopieer en plak deze expressie in het invoervak voor expressies: Join("", Replace([userName], , "(?<Suffix>@(.)*)", "Suffix", "", , ), RandomString(3, 3, 0, 0, 0, ), "@", DefaultDomain())

Met deze expressie wordt het probleem opgelost door een standaarddomein toe te voegen aan de UPN-waarde die door Microsoft Entra-id wordt geaccepteerd.

Bekende beperking: adressen met meerdere waarden, e-mailberichten en telefoonnummers

Beschrijving van probleem

• API-gestuurde provisioning verwerkt momenteel geen SCIM-attributen met meerdere waarden in addresses, emails en phoneNumbers wanneer de waarde van typehome is of een andere niet-work-waarde.
• Deze beperking is van toepassing op expressies zoals addresses[type eq "home"], addresses[type eq "any-other-value"]en phoneNumbers[type eq "home"].

Huidig gedrag

• Alleen addresses[type eq "work"]en emails[type eq "work"]phoneNumbers[type eq "work"] waarden worden verwerkt.

Workaround

• Verzend ondersteunde waarden met het type work wanneer u het kenmerk door API-gestuurde inrichting wilt laten verwerken.

Volgende stappen

• Meer informatie over API-gestuurde inkomende provisioning