Una pantalla puede ocultar varias operaciones relacionadas
Al analizar un programa transaccional, identificamos qué cambios deben aceptarse o cancelarse juntos. El hecho de que el usuario pulse una sola acción no significa que exista una única escritura. La modernización debe conservar o redefinir ese compromiso de forma explícita.
En Cantabria ofrecemos consultoría sobre el entorno que utilice el cliente. Si incluye CICS, se revisa su participación en el flujo y en el acceso a recursos. No se da por hecho que todas las aplicaciones COBOL sean transaccionales ni que utilicen esa plataforma.
El momento de confirmar cambia el resultado
Una operación puede registrar un dato y fallar antes de confirmar otro. Para diseñar una nueva capa necesitamos saber qué estado considera válido el negocio y cómo lo refleja el sistema actual. Esa definición permite preparar pruebas que descubran resultados parciales.
También revisamos el caso de una respuesta perdida. El consumidor puede creer que la operación ha fallado aunque el sistema la haya terminado. Se define cómo comprobar su estado y cómo tratar un nuevo intento.
Una interfaz .NET necesita un contrato operativo
Al crear un servicio en C# no basta con mapear campos de entrada y salida. Debe explicar cuándo una respuesta confirma el trabajo y qué errores pueden requerir intervención. La autenticación y los permisos se revisan con el cliente para no ampliar acceso de forma involuntaria.
Si la nueva arquitectura reparte la operación entre componentes, se evalúa cómo mantiene la coherencia. Esa decisión no se delega en una traducción automática de instrucciones COBOL.
IA para proponer pruebas de fallo
Claude de Anthropic o herramientas de OpenAI pueden ayudar a localizar rutas de error y sugerir escenarios. Verificamos las propuestas con el código y con el entorno de ejecución. Los detalles transaccionales dependen de la plataforma y de su configuración.
Las pruebas se preparan en un entorno autorizado, con operaciones que no afecten al negocio real. La IA no recibe acceso de producción para comprobar por ensayo y error una hipótesis sobre el programa.
Aceptar el cambio por su comportamiento completo
El entregable recoge los escenarios correctos, los fallos ensayados y las decisiones que sigue tomando el operador. Cuando una diferencia de comportamiento es deliberada, se documenta como tal y se valida con quien utiliza el proceso.
Por ejemplo, podría revisarse una operación de alta que también reserva una referencia. El análisis comprobaría qué ocurre si falla la segunda parte. Es un ejemplo técnico para explicar el servicio, no un caso comercial de Cantabria.