orquestador/examples/postman/README.md

66 lines
3.9 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. Para la POC con `compose.mock.yaml`, colocar en `accessToken` el token fijo
`ORCHESTRATOR_DEMO_TOKEN` o, si no lo definiste, el valor de `MOCK_ADMIN_TOKEN`.
No anteponer Bearer. No requiere Keycloak. Ver [POC_AUTH](../../specs/POC_AUTH.md).
3. Dejar vacíos `editorToken`, `publisherToken`, `adminToken` y `operatorToken`
para reutilizar accessToken. El servidor asigna usuario poc-user, ámbito demo
y roles de la POC. El ámbito debe estar en ADMIN_BUSINESS_SCOPES.
4. En modo normal sin demo-token, accessToken sí debe ser un JWT válido de Keycloak,
con issuer/audiencia/roles/business_scope configurados. Guardar cualquier token
solo localmente y no compartir una exportación con secretos.
## 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 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.