Errors and Warnings
|
|
Título del Test:![]() Errors and Warnings Descripción: Errors and Warnings |



| Comentarios |
|---|
NO HAY REGISTROS |
|
¿Para qué sirve el método addAdvice() en la Arquitectura APX?. Para hacer rollback automático de la transacción. Para registrar un aviso (notice) o error controlado asociado a la transacción o librería. Para cambiar el código HTTP de la respuesta. Para lanzar una excepción de tipo runtime. ¿Dónde se puede invocar addAdvice() según el material?. Solo en el front-end. Solo en la transacción. En la transacción y en las librerías de aplicación. Únicamente en las librerías de infraestructura. ¿Quién debe determinar la severidad final (OK, Warning, Error…) de la ejecución de una transacción?. Cada librería de forma independiente. El conector APX que se invoque. El servidor de aplicaciones. La propia transacción (Tx), que tiene el contexto completo. ¿Qué afirmación es correcta sobre addAdvice() y la severidad?. addAdvice() fija siempre la severidad a ERROR. addAdvice() fija la severidad a partir del código HTTP. setHttpResponseCode. addAdvice() actualiza automáticamente la severidad según el tipo de aviso. El código de retorno de transacción “06” (ENR) significa: OK + código de aviso. Rechazada + código de error, sin rollback. Rechazada + código de error, con rollback. Error fatal + código de error. ¿Cuál es la diferencia principal entre los códigos de retorno ENR (“06”) y EWR (“08”)?. ENR es de warning y EWR es de error. ENR va con HTTP 500 y EWR con HTTP 404. ENR no hace rollback y EWR sí hace rollback. ENR es solo para arquitectura y EWR solo para aplicaciones. ¿Qué combinación HTTP code – Severidad es correcta según la tabla?. 200 → Severity.ERROR. 409 → Severity.ENR. 404 → Severity.WARN. 500 → Severity.OK. Sobre la severidad ERROR (“12”), ¿qué afirma el documento?. Puede usarse libremente por cualquier aplicación. Solo se usa para avisos (warnings). Es de uso exclusivo de la Arquitectura; las aplicaciones no pueden usarla. Solo se usa para errores de validación de negocio. ¿Qué operaciones se pueden realizar en la APX Operation Console respecto a los errores?. Registrar, modificar y consultar errores. Solo registrar errores. Solo consultar errores. Eliminar errores de otras UUAAs. ¿Qué excepciones NO puede manejar el código de aplicación según las consideraciones del documento?. Ninguna excepción puede manejarse en el código. Solo se pueden manejar excepciones RuntimeException. No se pueden manejar las lanzadas por conectores APX, productos de terceros ni las que heredan de RuntimeException. No se pueden manejar excepciones checked (Exception) pero sí las runtime. |





