Résoudre des problèmes concernant l’API de provisionnement entrant

Présentation

Ce document décrit les erreurs et les problèmes fréquents liés à l’API de provisionnement entrant. Il explique également comment les résoudre.

Scénarios de résolution des problèmes

Format de données non valide

Description du problème

  • Vous obtenez le message d’erreur Invalid Data Format avec le code de réponse HTTP 400 (demande incorrecte).

Causes probables

  1. Vous avez envoyé une requête en bloc valide conformément aux spécifications de l’API de provisionnement /bulkUpload sans avoir défini l’en-tête de requête HTTP « Content-Type » sur application/scim+json.
  2. Vous avez envoyé une requête en bloc qui n’est pas conforme aux spécifications de l’API de provisionnement /bulkUpload.

Résolution :

  1. Vérifiez que l’en-tête Content-Type de la requête HTTP est défini sur la valeur application/scim+json.
  2. Vérifiez que la charge utile de requête en bloc est conforme aux spécifications de l’API de provisionnement /bulkUpload.

Les journaux de provisionnement sont vides

Description du problème

  • Vous avez envoyé une requête au point de terminaison de l’API de provisionnement /bulkUpload, et vous avez obtenu le code de réponse HTTP 202. Toutefois, les journaux de provisionnement ne comportent aucune donnée correspondant à votre demande.

Causes probables

  1. L’application de provisionnement pilotée par l’API est suspendue.
  2. Le service de provisionnement n’a pas encore ajouté les détails du traitement des requêtes en bloc aux journaux de provisionnement.
  3. L’état de votre agent d’approvisionnement local est inactif (si vous exécutez le provisionnement d’utilisateurs entrants pilotés par l’API sur Active Directory local).

Résolution :

  1. Vérifiez que l’application de provisionnement est en cours d’exécution. Si ce n’est pas le cas, sélectionnez l’option de menu Démarrer le provisionnement pour traiter les données.
  2. Activez l’état de votre agent de provisionnement local en redémarrant l’agent local.
  3. Attendez-vous à un délai de 5 minutes à 10 minutes entre le traitement de la demande et l’écriture dans les journaux d’approvisionnement. Si votre client d’API envoie des données au point de terminaison de l’API de provisionnement /bulkUpload, prévoyez un délai entre l’appel de la requête et la requête des journaux de provisionnement.

Code de réponse 403 : Interdit

Description du problème

  • Vous avez envoyé une requête au point de terminaison de l’API de provisionnement /bulkUpload et vous avez obtenu le code de réponse HTTP 403 (interdit).

Causes probables

  • L’autorisation SynchronizationData-User.Upload Graph n’est pas affectée à votre client API.

Résolution :

  • Attribuez l’autorisation Graph SynchronizationData-User.Upload au client de l’API et réessayez l’opération.

Code de réponse 429 : Trop de requêtes

Le point de terminaison de l’API BulkUpload applique les limitations suivantes et retourne un code de réponse 429 si ces limites sont dépassées.

  • 40 appels d’API toutes les 5 secondes – si le nombre d’appels dépasse cette limite dans un intervalle de 5 secondes, le client obtient une réponse 429. Pour éviter cela, régulez l’envoi des requêtes en utilisant des délais dans la logique d’envoi des requêtes client. 

  • 6 000 appels d’API sur une période de 24 heures : si le nombre d’appels dépasse cette limite, le client obtient une réponse de 429. Vérifiez également que votre charge utile en bloc SCIM est optimisée pour utiliser les 50 enregistrements maximum par appel d’API. Cette méthode vous permet d’envoyer 300 000 enregistrements toutes les 24 heures.

Code de réponse 500 : compartiment plein

Description du problème

  • Le client SCIM obtient HTTP 500 (erreur de serveur interne) avec le message : « Le compartiment qui stocke les données ingérées est plein, attendez que le service de synchronisation traite les données ingérées et réessayez cette requête ».
  • Cette erreur peut s’afficher lors de la synchronisation initiale ou des cycles de synchronisation complets lorsque des jeux de données RH volumineux sont envoyés au point de terminaison d’approvisionnement /bulkUpload .

Causes du problème

  • Le « bucket » est la file d’attente d’ingestion temporaire utilisée par le service de provisionnement pour tamponner les données /bulkUpload entrantes avant leur traitement.
  • Chaque travail d’approvisionnement piloté par l’API a une file d’attente d’ingestion dédiée.
  • Le service d’approvisionnement traite en permanence les charges utiles mises en file d’attente, puis supprime les données traitées. Si ce cycle de traitement et de suppression prend du retard ou s’arrête, les données en attente peuvent s’accumuler jusqu’à ce que le bucket soit plein.

Causes et résolution probables

Cause Résolution
Le traitement de charge utile échoue en raison de mappages incorrects (par exemple, en essayant de mettre à jour des attributs Microsoft Entra ID gérés par Active Directory local) ou des données non valides. Les charges ayant échoué restent dans la file d’attente, ce qui peut finir par remplir le bucket. Passez en revue les journaux d’approvisionnement pour identifier les échecs de traitement des demandes, résoudre les problèmes de mappage ou de données, redémarrer le travail d’approvisionnement et renvoyer les demandes.
Le travail d’approvisionnement piloté par l’API est à l’état Suspendu ou Arrêté . Les demandes continuent à se mettre en file d’attente, mais le traitement ne s’exécute pas. Reprendre le travail d’approvisionnement afin qu’il puisse traiter et effacer les demandes en file d’attente.
Le travail d’approvisionnement piloté par l’API reste dans un état mis en quarantaine pendant une longue période. Les demandes continuent à se mettre en file d’attente, mais le traitement ne s’exécute pas. Redémarrez le travail d’approvisionnement pour effacer la quarantaine. Pendant le redémarrage, les données mises en file d’attente existantes sont effacées, ce qui peut prendre du temps. Attendez environ 40 minutes, puis renvoyez les requêtes SCIM /bulkUpload.
Les systèmes sources envoient des données SCIM plus rapidement que le travail d’approvisionnement peut le traiter. Soumission de la demande Pace. Après chaque chargement en bloc, vérifiez le code d’état HTTP. Si vous obtenez un code HTTP 500 avec un message indiquant que le compartiment est plein, mettez le client en pause (par exemple, pendant 5 à 10 minutes) avant de réessayer.

Code de réponse 401 : Non autorisé

Description du problème

  • Vous avez envoyé une requête au point de terminaison de l’API de provisionnement /bulkUpload et vous avez obtenu le code de réponse HTTP 401 (Non autorisé). Le code d’erreur affiche « InvalidAuthenticationToken » avec un message indiquant « Le jeton d’accès a expiré ou n’est pas encore valide ».

Causes probables

  • Votre jeton d’accès a expiré.

Résolution :

  • Générez un nouveau jeton d’accès pour le client de l’API.

Le travail est mis en quarantaine

Description du problème

  • Vous venez de démarrer l’application de provisionnement, qui est en quarantaine.

Causes probables

  • Vous n’avez pas défini l’e-mail de notification avant de commencer le travail.

Résolution : accédez à l’élément de menu Modifier le provisionnement. Sous Paramètres, vous trouverez une case à cocher à côté de Envoyer une notification par e-mail en cas de défaillance ainsi qu’un champ de saisie pour l’e-mail de notification. Vérifiez que la case est cochée, indiquez une adresse e-mail et enregistrez la modification. Cliquez sur Redémarrer le provisionnement pour sortir le travail de la mise en quarantaine.

Création d’utilisateur : UPN non valide

Description du problème Le provisionnement de l’utilisateur a échoué. Les journaux de provisionnement affichent le code d’erreur AzureActiveDirectoryInvalidUserPrincipalName.

Résolution :

  1. Accédez à la page Modifier les mappages d’attributs.
  2. Sélectionnez le mappage UserPrincipalName et modifiez-le pour utiliser la fonction RandomString.
  3. Copiez et collez l’expression Join("", Replace([userName], , "(?<Suffix>@(.)*)", "Suffix", "", , ), RandomString(3, 3, 0, 0, 0, ), "@", DefaultDomain()) dans la zone d’expression.

Cette expression permet de résoudre le problème en ajoutant un nombre aléatoire à la valeur UPN acceptée par Microsoft Entra ID.

Échec de la création d’utilisateur : domaine non valide

Description du problème Le provisionnement de l’utilisateur a échoué. Les journaux de provisionnement affichent un message d’erreur indiquant domain does not exist.

Résolution :

  1. Accédez à la page Modifier les mappages d’attributs.
  2. Sélectionnez le mappage UserPrincipalName, puis copiez et collez l’expression Join("", Replace([userName], , "(?<Suffix>@(.)*)", "Suffix", "", , ), RandomString(3, 3, 0, 0, 0, ), "@", DefaultDomain()) dans la zone de saisie d’expression.

Cette expression permet de résoudre le problème en ajoutant un domaine par défaut à la valeur UPN acceptée par Microsoft Entra ID.

Limitation connue : adresses, e-mails et numéros de téléphone à valeurs multiples

Description du problème

  • Le provisionnement piloté par l’API ne traite actuellement pas les attributs SCIM à valeurs multiples dans addresses, emails et phoneNumbers lorsque la valeur type est home ou toute autre valeur non-work.
  • Cette limitation s’applique aux expressions telles que addresses[type eq "home"], addresses[type eq "any-other-value"]et phoneNumbers[type eq "home"].

Comportement actuel

  • Seules les valeurs addresses[type eq "work"], emails[type eq "work"] et phoneNumbers[type eq "work"] sont traitées.

Workaround

  • Envoyez des valeurs prises en charge à l’aide du work type lorsque vous avez besoin que l’attribut soit traité par le provisionnement piloté par l’API.

Étapes suivantes

  • Last updated on