Operación

IZ-CentralForms se encuentra actualmente en ambiente local de desarrollo. Por lo tanto, no existe todavía una operación productiva activa con monitoreo formal, backups, alertas, rotación de logs o soporte 24/7.

Esta página define:

• lo que aplica actualmente en local;
• lo que debe validarse durante pruebas;
• lo que aplicará después de un despliegue en QA, staging o producción.

Estado operativo actual

Área	Estado	Observación
Ambiente local	Aplica	La API se ejecuta localmente y se valida con Swagger, SDK o requests manuales.
Operación productiva	No aplica todavía	No hay servidor productivo desplegado.
Monitoreo formal	No aplica todavía	Se definirá al existir QA/staging/producción.
Backups operativos	No aplica todavía	LocalDB es entorno de desarrollo.
Alertas automáticas	No aplica todavía	Pendiente de infraestructura.
Revisión de logs productivos	No aplica todavía	No hay IIS productivo ni monitoreo centralizado.
Validación funcional	Aplica	GET formulario, POST submission, submissions e integration logs.

Alcance actual

Mientras el sistema esté solo en local, la operación se limita a validación funcional, revisión de errores durante desarrollo y comprobación de persistencia e integraciones.

Controles operativos mínimos

Cuando exista un ambiente desplegado, los controles mínimos serán:

Control	Fuente	Frecuencia sugerida	Aplica hoy
Disponibilidad API	GET /health	Diaria / automática	Sí, local
GET formulario	API pública	Por despliegue o cambio	Sí
POST submission	API pública	Por despliegue o cambio	Sí
Persistencia	SQL / Admin endpoint	Por prueba funcional	Sí
IntegrationLogs	SQL / Admin endpoint	Por prueba funcional	Sí
SMTP	Mailpit / proveedor SMTP	Por prueba de email	Sí, local
Webhook	IntegrationLogs / sistema externo	Por prueba de integración	Si hay destino
Backups SQL	Job / política DBA	Producción	No todavía
Certificado SSL	Monitoreo certificado	QA/Producción	No todavía
Logs IIS	IIS / Event Viewer	QA/Producción	No todavía

Endpoints operativos

Método	Endpoint	Uso	Seguridad
GET	/health	Verificar disponibilidad de la API.	Sin header
GET	/api/admin/submissions	Listar submissions.	X-Admin-Key
GET	/api/admin/submissions/{submissionId}	Consultar detalle de una submission.	X-Admin-Key
GET	/api/admin/integration-logs	Listar logs de email/webhook.	X-Admin-Key
GET	/api/admin/integration-logs/{integrationLogId}	Consultar detalle de un integration log.	X-Admin-Key

Endpoints funcionales a validar

Método	Endpoint	Uso	Headers
GET	/api/forms/{consumerCode}/{formCode}	Obtener formulario y CSRF.	X-Api-Key; Origin esperado en navegador
POST	/api/forms/{consumerCode}/{formCode}/submit	Enviar submission.	X-Api-Key, X-CSRF-Token, Content-Type; Origin esperado en navegador

Flujo de validación operativa

1. Ejecutar GET /health.
2. Ejecutar GET /api/forms/demo/contacto.
3. Copiar csrfToken.
4. Ejecutar POST /api/forms/demo/contacto/submit.
5. Confirmar respuesta 200 OK con submissionId.
6. Validar registro en Submissions.
7. Validar resultado de destinos en IntegrationLogs.
8. Revisar Mailpit, Mailtrap, SMTP o sistema webhook si aplica.

POST exitoso

Un 200 OK del POST significa que la submission fue validada y persistida. No confirma por sí solo que email o webhook hayan terminado correctamente. Eso se revisa en IntegrationLogs.

Consultas SQL útiles

Últimas submissions:

SELECT TOP 10 *
FROM Submissions
ORDER BY CreatedAt DESC;

Últimas integraciones:

SELECT TOP 10 *
FROM IntegrationLogs
ORDER BY StartedAt DESC;

Estados de IntegrationLogs

Estado	Significado	Acción
Pending	Destino tomado para ejecución.	Revisar si permanece demasiado tiempo.
Succeeded	Destino ejecutado correctamente.	Sin acción.
Failed	Destino ejecutado con error.	Revisar ErrorMessage, StatusCode y configuración.
Skipped	Destino omitido por configuración inválida o tipo no soportado.	Corregir destino o tipo.

Diagnóstico rápido

Síntoma	Causa probable	Acción
GET devuelve 401	API Key ausente o inválida.	Validar X-Api-Key y hash del consumer.
GET devuelve 401	Consumer inactivo, API Key ausente o API Key inválida.	Validar consumer y hash de API Key.
GET devuelve 403	Origin no autorizado cuando el header fue informado.	Validar AllowedOrigins.
GET devuelve 404	Consumer o formulario inexistente.	Validar consumerCode, formCode y seed/demo data.
POST devuelve 400	Campos requeridos faltantes o formato inválido.	Revisar body data y definición del formulario.
POST devuelve 401	API Key ausente o inválida.	Validar header y hash almacenado.
POST devuelve 403 Origin	Dominio no autorizado cuando el header fue informado.	Registrar Origin exacto, sin path.
POST devuelve 403 CSRF	Token expirado, reutilizado o incorrecto.	Ejecutar GET nuevamente y usar nuevo csrfToken.
POST devuelve 429	Rate limit superado.	Esperar la ventana de rate limit o revisar tráfico.
POST devuelve 200 pero no llega email	SMTP o destino email incorrecto.	Revisar FormDestinations, configuración Email e IntegrationLogs.
POST devuelve 200 pero webhook falla	URL destino inválida o sistema externo caído.	Revisar IntegrationLogs, status code y error.
Swagger no carga JSON en IIS	Ruta base incorrecta bajo aplicación virtual.	Usar ruta relativa v1/swagger.json.
API falla en IIS con LocalDB	LocalDB no disponible para Application Pool.	Migrar a SQL Server real.

Severidades

Severidad	Criterio	Acción
Alta	API caída o submissions no se guardan.	Atención inmediata por responsable técnico e infraestructura.
Media	Email o webhook fallan, pero submissions se guardan.	Revisar configuración e IntegrationLogs.
Baja	Ajustes de formulario, origins, documentación o pruebas.	Planificar según prioridad del equipo.

Tareas recurrentes

Tarea	Aplica hoy	Aplica en producción
Validar /health	Sí	Sí
Revisar submissions de prueba	Sí	Sí
Revisar IntegrationLogs	Sí	Sí
Validar SMTP	Sí, con Mailpit/Mailtrap	Sí, con proveedor real
Validar webhook	Si hay destino configurado	Sí, si aplica
Validar backups SQL	No	Sí
Revisar certificados SSL	No	Sí
Revisar logs IIS	No	Sí
Revisar alertas automáticas	No	Sí, cuando existan

Guion de prueba end-to-end

1. Obtener formulario

GET /api/forms/demo/contacto
X-Api-Key: demo-api-key
Origin: https://localhost:7122

Resultado esperado:

• 200 OK
• Respuesta con fields
• Respuesta con csrfToken

2. Enviar formulario

POST /api/forms/demo/contacto/submit
X-Api-Key: demo-api-key
X-CSRF-Token: TOKEN_DEL_GET
Origin: https://localhost:7122
Content-Type: application/json

Body:

{
  "data": {
    "nombre": "Usuario Demo",
    "email": "demo@interzone.net",
    "mensaje": "Prueba de CentralForms"
  }
}

Resultado esperado:

• 200 OK
• success: true
• submissionId

3. Validar trazabilidad

GET /api/admin/submissions
X-Admin-Key: demo-admin-key

GET /api/admin/integration-logs
X-Admin-Key: demo-admin-key

Flujo de prueba en Swagger

1. Ejecutar GET /health.
2. Autorizar ApiKey con demo-api-key.
3. Ejecutar GET /api/forms/demo/contacto con Origin.
4. Copiar csrfToken.
5. Autorizar CsrfToken.
6. Ejecutar POST /api/forms/demo/contacto/submit.
7. Autorizar AdminKey con demo-admin-key.
8. Ejecutar GET /api/admin/submissions.
9. Ejecutar GET /api/admin/integration-logs.

Troubleshooting local frecuente

Síntoma	Acción recomendada
Build falla por DLL bloqueada	Cerrar la API o ejecutar Get-Process dotnet | Stop-Process -Force, luego dotnet clean y dotnet build.
EF Core no encuentra el proyecto	Ejecutar comandos desde la raíz del repositorio y usar --project con Infrastructure y --startup-project con Api.
API Key demo inválida	Confirmar que Consumers.ApiKeyHash tenga el SHA-256 de demo-api-key.
Origin no autorizado	Verificar que AllowedOrigins.OriginUrl coincida exactamente con el header Origin.
CSRF inválido	Repetir GET formulario y usar el nuevo csrfToken; los tokens son de un solo uso.
No llega email a Mailpit	Validar Mailpit en localhost:8025, SMTP en localhost:1025, destino email activo e IntegrationLogs.
Webhook no llega	Validar destino webhook activo, URL externa y StatusCode en IntegrationLogs.
Rate limit 429	Esperar la siguiente ventana o revisar tráfico de prueba.

No aplica todavía

Mientras no exista un ambiente desplegado fuera de local, no aplican formalmente:

• monitoreo 24/7;
• alertas automáticas;
• SLA operativo;
• rotación formal de logs IIS;
• política productiva de backups;
• revisión de certificados SSL;
• hardening de servidor;
• runbooks de incidente productivo;
• escalamiento con proveedor de infraestructura.

Futuro operativo

Cuando exista QA, staging o producción, esta página debe actualizarse con responsables, frecuencia real de monitoreo, rutas de logs, política de backup, alertas y procedimiento de incidentes.