# 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.