Cola de concurrencia de la API de Consulta del operador original para cuentas compartidas
Guía práctica sobre la cola de concurrencia de la API de Consulta del operador original para equipos de datos, con límites documentados y pasos de revisión.
Una cola de concurrencia para la API de Consulta del operador original debe coordinar a todos los trabajadores que utilizan una misma cuenta, en lugar de permitir que cada proceso intente adivinar su propia capacidad disponible.
Una cola de concurrencia para la API de Consulta del operador original debe coordinar a todos los trabajadores que utilizan una misma cuenta, en lugar de permitir que cada proceso intente adivinar su propia capacidad disponible. CarrierLookup documenta las ranuras (slots) simultáneas en tiempo real y una puerta de acceso independiente para solicitudes múltiples por cuenta. Envíe las solicitudes individuales y las múltiples síncronas a través de un controlador a nivel de cuenta, preserve el orden de entrada para cada solicitud múltiple y libere una ranura solo después de que finalice dicha solicitud. Estos controles gestionan el trabajo simultáneo; no constituyen una cuota por minuto ni una promesa sobre el tiempo de respuesta.
Modele la cuenta, no al trabajador de una aplicación individual
La Consulta del operador original devuelve el contexto de asignación original del número: el operador originalmente asignado, el operador subyacente, el tipo de número y la geografía de asignación. No informa sobre el operador actual tras una portabilidad ni sobre si un número puede recibir una llamada o mensaje. En este contexto, "tiempo real" se refiere al flujo de trabajo de solicitud y respuesta, no a una sonda de red en vivo. La página del producto de la API de Consulta del operador original es la página relevante, y la documentación de la API debe seguir siendo la fuente para los detalles de integración actuales.
Cuando varios servicios comparten una cuenta de API, un semáforo por proceso es insuficiente. Dos trabajadores web, una importación en segundo plano y una herramienta de análisis pueden creer, cada uno por su cuenta, que la cuenta dispone de ranuras libres. Las reglas públicas documentadas describen cinco ranuras simultáneas en tiempo real y una solicitud múltiple por cuenta. Por lo tanto, un controlador del lado del cliente debe utilizar un coordinador único a nivel de cuenta, u otro mecanismo que proporcione a todos los trabajadores participantes una visión coherente de las llamadas pendientes. La tecnología exacta de almacenamiento o cola es una elección de implementación del cliente.
La cola debe contener un sobre de solicitud con el identificador o identificadores E.164 enviados, el modo de solicitud, la referencia del trabajo de la aplicación y la hora en que el equipo lo puso en cola. Estos son campos propuestos propiedad del cliente, no una afirmación sobre el esquema de respuesta de CarrierLookup. Evite registrar números completos o credenciales a menos que la política de la organización lo requiera y los proteja.
Asigne puertas independientes para llamadas individuales y múltiples
Una consulta individual acepta un número E.164. La consulta múltiple síncrona acepta de 1 a 100 números E.164 y devuelve un resultado ordenado en una sola respuesta. Ambas son comprobaciones en tiempo real, pero la ruta múltiple también tiene una restricción de una solicitud a la vez por cuenta. Diseñe dos puertas: un contador de capacidad compartida para todas las solicitudes en tiempo real en curso y una puerta exclusiva para las solicitudes múltiples. Una llamada múltiple debe adquirir la capacidad que necesita bajo las reglas de cuenta documentadas y la puerta exclusiva para múltiples; la implementación debe liberar ambas juntas tras una respuesta completada o un fallo terminal.
No trate una solicitud múltiple como una tarea de archivo masivo asíncrono. El producto independiente de Consulta de operador global acepta archivos TXT o CSV, prepara los identificadores y posteriormente genera un CSV. Pertenece a un flujo de trabajo diferente. La página sobre cómo funciona CarrierLookup ayuda a los lectores a distinguir estos modos. Si la aplicación tiene un trabajo de archivo grande, elija deliberadamente el producto masivo documentado en lugar de enviar un archivo a la cola síncrona.
El coordinador también necesita equidad. Un flujo constante de solicitudes individuales no debería dejar sin recursos a una solicitud múltiple ya en cola, mientras que una importación grande no debería bloquear indefinidamente las comprobaciones interactivas pequeñas. Una regla de programación propiedad del cliente podría reservar turnos por orden de llegada o utilizar una política de prioridad limitada. Esta es una recomendación de flujo de trabajo, no una garantía de programación del proveedor.
Gestione el tiempo de espera y el fallo del trabajador como eventos terminales de la cola
Una solicitud individual y una solicitud múltiple tienen límites de tiempo de espera documentados en la API pública. Utilice la documentación actual de la API para conocer los valores exactos y el contrato de respuesta en lugar de asumir un tiempo de finalización normal. Un tiempo de espera del lado del cliente puede dejar incertidumbre sobre si el servidor completó la llamada, por lo que un controlador debe registrar esa incertidumbre por separado de un resultado de operador completado. Para la consulta múltiple síncrona, el producto documenta que un tiempo de espera en la solicitud múltiple invalida toda la solicitud sin resultados parciales y devuelve el importe total. No fabrique éxitos a nivel de fila a partir de una respuesta incompleta.
Cada arrendamiento de cola necesita una ruta de liberación incluso si un trabajador de la aplicación falla. El controlador del cliente puede marcar el trabajo como incierto, liberar la capacidad local una vez que se sepa que el trabajador ha desaparecido y pasar la solicitud a una política de revisión o de reintento cuidadosamente controlada. No sature automáticamente el servicio con reintentos tras un incidente de red. Si se elige un reintento, preserve la referencia original del trabajo de la aplicación y distinga la observación posterior del intento incierto anterior.
Una consulta completada puede contener campos de operador vacíos y seguir siendo un resultado completado y facturable. Eso no es un tiempo de espera y no debería consumir un reintento simplemente para forzar un operador no vacío. Por el contrario, un formato de entrada rechazado no es un resultado de "sin operador". La cola registra el estado de la solicitud; no reinterpreta el significado de la consulta.
Supervise la cola sin inventar un límite de tasa
Las métricas útiles del lado del cliente incluyen las consultas individuales en curso, si una solicitud múltiple está activa, la antigüedad en cola por clase de trabajo, las respuestas completadas, los rechazos de formato, los tiempos de espera y los resultados de transporte inciertos. Estas muestran si la aplicación está respetando la concurrencia y si los usuarios están esperando a un trabajador controlado por el cliente. No implican un límite fijo de solicitudes por minuto o diario, lo cual no está establecido en los hechos públicos.
Antes del lanzamiento, pruebe con dos trabajadores web enviando solicitudes a la vez, una solicitud múltiple en cola mientras las individuales están activas, la salida de un trabajador antes de la respuesta y un tiempo de espera. Confirme que no haya más de una solicitud múltiple activa para la cuenta y que todas las puertas locales adquiridas se liberen finalmente. Verifique que el resultado coincida con el número canónico enviado y que las filas múltiples ordenadas se reconcilien antes de actualizar los registros de contacto.
Una nota operativa final debe explicar que el operador devuelto describe la asignación original. Una cola rápida aún necesita una etiqueta precisa para la asignación del operador original. Almacénela con una fuente y hora de comprobación, mantenga la región y ciudad de asignación separadas de la ubicación de una persona, y utilice otras pruebas para cuestiones de contactabilidad o identidad.
Preguntas frecuentes
¿Cómo deben coordinar los equipos a varios trabajadores utilizando una cuenta de CarrierLookup?
Utilice un controlador a nivel de cuenta que compartan todos los trabajadores, con una puerta de capacidad compartida en tiempo real y una puerta exclusiva para solicitudes múltiples síncronas.
¿La regla de concurrencia documentada crea una cuota por minuto?
No. Limita el trabajo simultáneo en curso y no establece un número fijo de solicitudes por minuto.
¿Puede una solicitud múltiple con tiempo de espera agotado ser aceptada parcialmente?
El tiempo de espera documentado para solicitudes múltiples invalida toda la solicitud sin resultados parciales. Manténgalo como un fallo a nivel de solicitud y no invente filas exitosas.
¿Deberían los campos de operador vacíos activar un reintento automático?
No por sí mismos. Una consulta completada con campos de asignación vacíos sigue siendo un resultado completado; el equipo debe preservar ese resultado con precisión.
Más información
Elija la información del producto que se ajuste al siguiente paso en su flujo de trabajo.