orquestador/examples/postman/README.md

65 lines
3.8 KiB
Markdown

# Pruebas desde Postman
Importar `Orquestador-NMP.postman_collection.json` con **Import > Files**.
La variable de colección `baseUrl` ya apunta a `http://server02:8787`.
Ejecutar solicitudes individualmente; no ejecutar toda la colección con Runner.
Publicar, activar, crear solicitudes y enviar eventos modifican datos.
## Primera prueba
1. Ejecutar la carpeta **01**: salud/readiness/liveness deben devolver 200 UP;
la petición sin token debe devolver 401.
2. En Variables de la colección, colocar un access token de Keycloak vigente en
`accessToken`, sin el prefijo Bearer. Guardarlo solo localmente; no compartir
una exportación con tokens. Debe tener el issuer y audiencia configurados,
`sub`, expiración y el claim `business_scope` no vacío.
3. Para administración se pueden configurar `editorToken`, `publisherToken` y
`adminToken` por separado. Si están vacíos se usa `accessToken`. Roles:
FLOW_EDITOR para crear/simular; FLOW_PUBLISHER para publicar; FLOW_ADMIN para
activar. El business_scope debe estar en ADMIN_BUSINESS_SCOPES.
## Simulación sin llamadas a proveedores
- Requiere FLOW_ADMIN_ENABLED=true, credenciales DB de runtime restringidas y
migración separadas, y catálogo compatible con
`examples/integrations/publication-catalog.json`. El catálogo vacío inicial
de `config` no contiene los contratos de la demo.
- Ejecutar **02 / Crear borrador** una vez: el JSON de crédito v1 está incluido.
La respuesta guarda `flowId` y `flowRevision`. Si ya existe ese flujo, usar
su ID conocido en las variables. Validar y revisar el informe, incluso con 200.
- Ejecutar las cuatro peticiones de **03**: score 71 lleva a PASO_N; 70 y 61 a
PASO_M; 60 a REVISION_MANUAL. La pestaña Test Results comprueba estos resultados.
No requiere publicar/activar, solicitudes, documentos ni rutas de proveedores.
## Recorrido persistente
Solo en entorno de demo con proveedores mock configurados. La colección no
levanta mocks ni configura Keycloak, roles DB, contratos o tipos de solicitud.
1. Habilitar REQUEST_API_ENABLED y WORKER_ENABLED con el runtime DB restringido.
Configurar rutas HTTP de proveedores de demo. El tipo CREDITO debe existir;
no hay endpoint para crearlo ni para consultar su revisión. Obtener su
revisión actual del administrador y asignarla a `typeRevision` (0 solo si
es nuevo). Mantener `typeKey=CREDITO` para este ejemplo.
2. Publicar y activar mediante **04**, únicamente tras validar sin errores.
3. **05 / Crear NUEVA solicitud** genera una clave de idempotencia y guarda ID
y revisión. La petición siguiente reutiliza clave/cuerpo y verifica el mismo
ID; no cambiar el usuario, tipo ni cuerpo entre ambas.
4. Consultar eventos disponibles. En **06** enviar solo el evento que corresponda
al estado actual. Cada envío nuevo conserva clave, cuerpo y revisión para
permitir el replay del último evento. No editar esas variables para el replay.
5. Consultar ejecución hasta SUCCEEDED; después consultar solicitud y eventos
disponibles para refrescar la revisión antes del siguiente evento. HTTP 202
acredita aceptación, no terminación. No hay sondeo automático.
6. Para registrar documentos, asignar `documentId` de un documento sintético
existente en el proveedor mock y perteneciente a la solicitud. Usar el documento
correspondiente a cada tarea. No subir documentos personales ni conectar
un buró real para esta demo.
7. Consultar historial. Métricas requiere EXECUTION_OPERATOR y ámbito administrativo;
se puede configurar `operatorToken` o reutilizar accessToken.
401: revisar token/issuer/audiencia/expiración. 403: revisar rol y ámbito.
404: revisar flags, ID y propiedad del recurso. 412: refrescar revisión.
422: revisar cuerpo, contrato y catálogo. Las respuestas incluyen correlationId
para contrastar con los logs. La colección no sustituye la suite integral T16.