Solucionar problemas de la API de aprovisionamiento entrante

Introducción

En este documento, se describen los errores y problemas comunes con la API de aprovisionamiento de entrada y cómo solucionarlos.

Escenarios de solución de problemas

Formato de datos no válido

Descripción del problema

  • Recibe el mensaje de error Invalid Data Format con código de respuesta HTTP 400 (solicitud incorrecta).

Causas probables

  1. Está enviando una solicitud masiva válida según las especificaciones de la API de aprovisionamiento /bulkUpload, pero no ha establecido el encabezado de solicitud HTTP "Content-Type" en application/scim+json.
  2. Estás enviando una solicitud en bloque que no cumple con las especificaciones de la API de aprovisionamiento /bulkUpload.

Solución:

  1. Asegúrese de que la solicitud HTTP tenga el valor del encabezado de Content-Type establecido en application/scim+json.
  2. Asegúrese de que la carga útil de la solicitud masiva se ajuste a las especificaciones de la API de aprovisionamiento /bulkUpload.

No hay nada en los registros de aprovisionamiento

Descripción del problema

  • Envió una solicitud al punto de conexión de la API de aprovisionamiento /bulkUpload y obtuvo el código de respuesta HTTP 202, pero no hay datos en los registros de aprovisionamiento correspondientes a la solicitud.

Causas probables

  1. La aplicación de aprovisionamiento controlada por API está en pausa.
  2. El servicio de aprovisionamiento todavía tiene que actualizar los registros de aprovisionamiento con los detalles de procesamiento de las solicitudes masivas.
  3. El estado del agente de aprovisionamiento local es inactivo (Si está ejecutando el aprovisionamiento de usuarios entrantes controlado por API para Active Directory local).

Solución:

  1. Verifique que la aplicación de aprovisionamiento esté en ejecución. Si no lo está, seleccione la opción de menú Iniciar aprovisionamiento para procesar los datos.
  2. Cambie el estado de su agente de aprovisionamiento local a activo reiniciando el agente de aprovisionamiento local.
  3. Espere un retraso de 5 minutos a 10 minutos entre procesar la solicitud y escribir en los registros de aprovisionamiento. Si el cliente de API envía datos al punto de conexión de la API de aprovisionamiento /bulkUpload, incluya un retraso de tiempo entre la invocación de la solicitud y la consulta de aprovisionamiento de registros.

Código de respuesta 403 Prohibido

Descripción del problema

  • Enviaste una solicitud al extremo /bulkUpload de la API de aprovisionamiento y recibiste el código de respuesta HTTP 403 (Prohibido).

Causas probables

  • El permiso de Graph SynchronizationData-User.Upload no está asignado a su cliente de API.

Solución:

  • Asigne el permiso SynchronizationData-User.Upload de Graph al cliente de API y vuelva a intentar la operación.

Demasiadas solicitudes de código de respuesta 429

El punto de conexión de la API de bulkUpload aplica los siguientes límites y devuelve un código de respuesta 429 si se infringen estos límites.

  • 40 llamadas a la API cada 5 segundos: si el número de llamadas supera este límite en un rango de 5 segundos, el cliente recibe una respuesta 429. Una manera de evitar esto es velocidad el envío de solicitudes mediante retrasos en la lógica de envío de solicitudes de cliente. 

  • 6000 llamadas API durante un período de 24 horas: si el número de llamadas supera este límite, el cliente obtiene una respuesta 429. Una manera de evitar esto es asegurarse de que la carga masiva de SCIM está optimizada para usar el máximo de 50 registros por llamada API. Con este enfoque, puede enviar 300 000 registros cada 24 horas.

Código de respuesta 500: bucket lleno

Descripción del problema

  • El cliente SCIM obtiene HTTP 500 (error interno del servidor) con el mensaje: "El cubo que almacena los datos ingeridos está lleno, espere a que el servicio de sincronización procese los datos ingeridos y vuelva a intentar esta solicitud".
  • Puede que vea este error durante la sincronización inicial o en los ciclos de sincronización completa cuando se envían grandes volúmenes de datos de RR. HH. al punto de conexión de aprovisionamiento /bulkUpload.

Por qué se produce este problema

  • El bucket es la cola de ingesta temporal que utiliza el servicio de aprovisionamiento para almacenar en búfer las /bulkUpload cargas útiles entrantes antes de que se procesen.
  • Cada trabajo de aprovisionamiento controlado por API tiene una cola de ingesta dedicada.
  • El servicio de aprovisionamiento procesa continuamente las cargas en cola y, a continuación, elimina los datos procesados. Si este ciclo de procesamiento y eliminación se retrasa o se detiene, los datos en cola pueden acumularse hasta que el contenedor se llene.

Causas probables y resolución

Causa Resolution
El procesamiento de la carga útil falla debido a asignaciones incorrectas (por ejemplo, al intentar actualizar atributos de Microsoft Entra ID administrados por Active Directory local) o a datos no válidos. Las cargas útiles erróneas permanecen en la cola, lo que puede acabar llenando el bucket. Revise los registros de aprovisionamiento para identificar el procesamiento de solicitudes con errores, corregir problemas de asignación o datos, reiniciar el trabajo de aprovisionamiento y reenviar las solicitudes.
El trabajo de aprovisionamiento controlado por API está en estado Pausado o Detenido . Las solicitudes continúan en cola, pero el procesamiento no se ejecuta. Reanude el trabajo de aprovisionamiento para que pueda procesar y borrar las solicitudes en cola.
La tarea de aprovisionamiento basada en API permanece en estado En cuarentena durante un largo periodo. Las solicitudes continúan en cola, pero el procesamiento no se ejecuta. Reinicie la tarea de aprovisionamiento para quitar la cuarentena. Durante el reinicio, se borran los datos en cola existentes, lo que puede tardar tiempo. Espere unos 40 minutos y vuelva a enviar solicitudes SCIM /bulkUpload .
Los sistemas de origen envían datos SCIM más rápido de lo que la tarea de aprovisionamiento puede procesarlos. Espacia el envío de solicitudes. Después de cada carga masiva, compruebe el código de estado HTTP. Si obtiene un HTTP 500 con el mensaje de que el bucket está lleno, ponga en pausa el cliente (por ejemplo, durante 5 a 10 minutos) antes de volver a intentarlo.

Código de respuesta 401 No autorizado

Descripción del problema

  • Has enviado una solicitud al extremo de la API de aprovisionamiento /bulkUpload y has recibido el código de respuesta HTTP 401 (No autorizado). El código de error muestra "InvalidAuthenticationToken" con un mensaje que indica que el "Token de acceso ha expirado o aún no es válido".

Causas probables

  • El token de acceso ha expirado.

Solución:

  • Genere un nuevo token de acceso para el cliente de API.

El trabajo entra en estado de cuarentena

Descripción del problema

  • Acaba de iniciar la aplicación de aprovisionamiento y está en estado de cuarentena.

Causas probables

  • No ha establecido el correo electrónico de notificación antes de iniciar el trabajo.

Resolución: vaya al elemento de menúEditar aprovisionamiento. En Configuración, hay una casilla junto a Enviar una notificación por correo electrónico cuando se produzca un error y un campo para escribir el Correo electrónico de notificación. Asegúrese de activar la casilla, proporcione un correo electrónico y guarde el cambio. Haga clic en Reiniciar aprovisionamiento para sacar el trabajo de la cuarentena.

Creación de usuarios: UPN no válido

Descripción del problema Hay un error de aprovisionamiento de usuarios. Los registros de aprovisionamiento muestran el código de error: AzureActiveDirectoryInvalidUserPrincipalName.

Solución:

  1. Ha llegado a la página Editar asignaciones de atributos.
  2. Seleccione la asignación UserPrincipalName y actualícela para usar la función RandomString.
  3. Copie y pegue esta expresión en el cuadro para expresiones: Join("", Replace([userName], , "(?<Suffix>@(.)*)", "Suffix", "", , ), RandomString(3, 3, 0, 0, 0, ), "@", DefaultDomain())

Esta expresión corrige el problema anexando un número aleatorio al valor de UPN aceptado por Microsoft Entra ID.

Error de creación del usuario: dominio no válido

Descripción del problema Hay un error de aprovisionamiento de usuarios. Los registros de aprovisionamiento muestran un mensaje de error que indica domain does not exist.

Solución:

  1. Vaya a la página Editar asignaciones de atributos.
  2. Seleccione la asignación UserPrincipalName y copie y pegue esta expresión en el cuadro de entrada de expresiones: Join("", Replace([userName], , "(?<Suffix>@(.)*)", "Suffix", "", , ), RandomString(3, 3, 0, 0, 0, ), "@", DefaultDomain())

Esta expresión corrige el problema anexando un dominio predeterminado al valor de UPN aceptado por Microsoft Entra ID.

Limitación conocida: direcciones multivalor, correos electrónicos y números de teléfono

Descripción del problema

  • El aprovisionamiento controlado por API no procesa actualmente atributos SCIM de varios valores en addresses, emails y phoneNumbers cuando el valor de type es home o cualquier otro valor distinto de work.
  • Esta limitación se aplica a expresiones como addresses[type eq "home"], addresses[type eq "any-other-value"]y phoneNumbers[type eq "home"].

Comportamiento actual

  • Solo se procesan los valores addresses[type eq "work"], emails[type eq "work"] y phoneNumbers[type eq "work"].

Workaround

  • Envíe valores admitidos mediante el work tipo cuando necesite que el aprovisionamiento controlado por API procese el atributo.

Pasos siguientes

  • Last updated on