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