orquestador/examples/postman/README.md

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.