Consulta: ante request, resolver SIM y retornar provider_id / integration_id vigentes. Actualización: si llega un cambio válido de binding (típicamente desde CAP-01), persistir el nuevo provider_id / integration_id. Si el binding cambió, emitir evento SimBindingInvalidated para que provider-service invalide caché. No ejecutar acciones técnicas.
esto esta mal, sim tiene provider_id / integracion_id? me parece que no
r sin modificar el estado administrativo ni dispa
ver quien escucha esto
Reconciliar
no reconciliar
estado observado
este es el estado de provider TECH_.... technical_sim_state
timeline administrativo asociado a la SIM (e
falta el paso de filtros. no relevar, proponer
lver SIM administrativa por iccid/sim_id y validar ownership.
no va esto
Retornar el detalle compuesto.
no va aca
estado, customer, alias
ver que filtros, recoerdmos que cliente y alias no tenemos
Validar permisos y scope de visibilidad (Vendor vs Cliente).
no va porque no entra vendor ni cliente
compuesta con datos técnicos observados y metadata externa solo para visualización.
esto no va en sim
identitarios básicos.
icc, imsi
cliente, alias
en fase 1 esto no
No inferir perfiles desde provider_profile_code.
no se que es
ChangeServiceProfile
en provider esto es el SimProfileChange
ncola y ejecuta la operación técnica (interno)
cuando lo decimos los cambios en service_profile? sim_profile_change
econdiciones administrativas.
cuales
registra discrepancias.
que significa
provider-service (cron/job) emite lotes de SIMs a una cola.
agrega a provider
metadata de otros dominios en
esto no seria asi, solo datos administrativos
Provider Integration Registry (read-only): consulta a provider-service el registro de integraciones habilitadas y capacidades soportadas, para ejecutar la importación.
me parece que esto salio
diagnóstico
attach / detach no se necesita guardar. es todo en tiempo real no va aca->analizar como resolver esto
Provider recibe
VA a provider porque solo escucha sms.
ónicos
en provider para el proceso tiene precondiciones->sim activo , ventana temporal, etc (verla)
ventana temporal.
hoy por sim recorre el mes, si esta guardado no lo toca sino sigo elcon el que sigue) -> analizar con ia como es mejor. de cada icc se pide el consumo por dia de todo el mes, lo ultimos dias del mes se hace pesado. todos los dias se rechequea. generalmente falla el dia de atras. se necesita cada 10 minutos
lemetry valida versión, tipo de evento e identificadores míni
la normalizacion gruesa de esto es de provider no?
e forma asíncron
ventana temporal tambien de esto? cron no? eficiente?
eventos en la cola telemetry-ingest.
varias colas una por proceso
construye eventos técnicos por SIM / período.
no hay construccion, q onda con esto?
Provider ejecuta un proceso batch consultando a la telco por una ventana temporal.
son 4: cdr, sms, location, eventos de red ( pasa algo con el sim:{ "_id": { "$oid": "68c9d39139836c2793527aa5" }, "iccid": "89444611503504960517", "current_country": "Argentina", "current_location": "722310", "current_network": "AMX Argentina S.A.", "domain": "S6a (4G)", "imsi": "204046848359268", "operation": "Location Update", "result": "success", "roaming_profile": "GREENFIVE", "timestamp": { "$date": "2025-09-11T17:18:46.000Z" }, "timestamp_str": "2025-09-11T17:18:46", "synced_at": { "$date": "2025-09-16T18:16:01.575Z" } }
ma asíncro
falta el paso de guardar
Telemetry valida versión, tipo de evento e identificadores mínimos. Resultado: Evento válido → aceptado para procesamiento posterior. Evento inválido → enviado a DLQ / parking-lot.
no va aca
n evento técnico desde la telco vía webhook.
sms recibido y iniciar y terminar sesion hoy se esta tomando con movistar.
Provider publica el evento en la cola telemetry-ingest usando un envelope versionado.
tipar la cola para que luego se banque otra cosa que no sea sms
SMS
x los dos
sesión
tampoco es por webhook pero si existe inicio y fin de sesion en algunos proveedores ->no entra en esta fase las sesiones
consumo
cdr -> consumo (no nos sirve por weebhook, porque el provider lo tira como quiere
sesión conocid
attach/dettach. es la ultima sesion attache. snapshot
o evento de SMS (si aplica).
no
a actividad técnica,
no
Construcción inicial de estado observado
algunas cosas son de esto y otras de provider, reanalizar. hoy getsim trae varios icc paginado.
Ordenamiento best-effor
no va, porque es mas para lo webhhook
tión de retenció
es importante
Persistencia de evento técnico observ
no tiene sentido
payload según el tipo de evento
no es de provider?
unidades de consumo (bytes, cantidad de SMS),
tiene sentido que este aca
dentificadores de SIM (ICCID/MSISDN/IMSI),
no lo hace provider esto?
de Uso Principales
en el inventario
Consultar Sesión Activa
attach/detach
Capacidades
ver que acumulados necesitamos y como los obtiene sim
Reset
este se sca y es sincronico y va junto con change_plan
Asignar/cambiar service_profile_id/versión y disparar reprovisionamiento async si aplica (sin “crear/editar” profiles).
esto esta relciona con esim y catalog (service-profile)
sincronización administrativa
ver si hay sincronizacion (cambios en el sim) el unico que tiene cambios es esim. con la unica capacidad de cambiar imcsi y imsi
Integra con eSIM vía eventos, sin implementar RSP ni SM
dar una vuelta a esto a ver si lo metemos en fase 1