Buenas prácticas APX

Según los lineamientos generales de APX, ¿en qué idioma deben definirse todas las clases, métodos, variables y comentarios del código?. Es indiferente, siempre que sea consistente dentro del proyecto. En Inglés para el código y el idioma local para los comentarios. En el idioma local del país donde se desarrolla (ej. Español para España/México). En Inglés.

¿Cuál es la práctica correcta respecto a la gestión de logs en las aplicaciones APX?. Utilizar siempre las utilidades provistas por la Arquitectura (SLF4J) y nunca generar ficheros de log propios. Usar System.out.println para trazas rápidas y ficheros propios para logs complejos. Usar el nivel DEBUG para toda la información de monitoreo en producción. Capturar todas las excepciones con catch (Exception e) y logarlas como ERROR.

¿En qué componente APX debe residir exclusivamente el acceso a datos y qué tecnología se recomienda usar?. En las Librerías, utilizando JPA con caché de segundo nivel. En las Librerías, utilizando JDBC. En los DTOs, utilizando conexiones directas a DataSource. En las Transacciones, utilizando JPA.

¿Por qué las Librerías y Transacciones APX deben ser 'Stateless' (sin estado)?. Porque se instancian como Singleton y las variables miembro serían compartidas entre todas las ejecuciones concurrentes. Porque OSGi no permite variables estáticas. Porque consumen demasiada memoria si guardan estado. No es obligatorio que sean Stateless, es solo una recomendación.

Con respecto a la gestión de hilos (Threads) en aplicaciones APX, ¿cuál es la directriz?. Se permite crear hilos siempre que se gestionen con un ThreadPoolExecutor. Se pueden usar hilos para operaciones de log asíncrono únicamente. La creación o gestión manual de hilos por parte de las aplicaciones está totalmente prohibida. Solo se permiten hilos en procesos Batch.

¿Qué práctica está prohibida al declarar dependencias en el archivo pom.xml?. Declarar dependencias con la etiqueta <optional>true</optional>. Declarar dependencias de prueba con <scope>test</scope>. Usar propiedades para definir las versiones (ej. ${apx.core.version}). Declarar dependencias de DTOs en una librería.

¿Quién es el responsable de realizar el commit o rollback en una Transacción Online APX?. La Arquitectura APX. El desarrollador, mediante código explícito en el método execute. El motor de base de datos automáticamente por cada sentencia. La librería que accede a la base de datos.

¿Cuál de los siguientes cambios en una Transacción Online se considera NO retrocompatible y requiere versionado?. Añadir un campo de entrada opcional. Añadir un campo de entrada obligatorio. Hacer opcional un campo que antes era obligatorio. Modificar la lógica interna sin cambiar la firma.

En cuanto a las dependencias entre componentes, ¿qué está absolutamente prohibido?. Las dependencias circulares (ej. LIB1 depende de LIB2 y LIB2 depende de LIB1). Que una librería de implementación dependa de una librería de interfaz. Que una transacción dependa de más de una librería. Que una librería dependa de un DTO.

Respecto al manejo de excepciones en el código de aplicación, ¿qué práctica es correcta?. Lanzar nuevas excepciones propias desde el método execute. Capturar RuntimeException para manejar errores imprevistos. Solo capturar excepciones de negocio específicas de APX (ej. BusinessException). Usar try-catch (Exception e) para evitar que la aplicación falle.

Un desarrollador desea utilizar anotaciones de Spring para inyectar dependencias en la clase de implementación de una librería APX. ¿Cuál es la directriz correcta al respecto?. Se pueden usar anotaciones solo si se añade la dependencia spring-boot-starter al pom.xml. Está prohibido usar anotaciones como @Component, @Service o @Repository en las clases de implementación. Es obligatorio usar @Component para que el contexto de Spring detecte la clase. Se permite el uso de @Service y @Repository siempre que no se use @Controller.

Según las reglas de versionado de Transacciones APX, ¿cuál de los siguientes cambios se considera NO retrocompatible y obliga a subir la versión?. Modificar la lógica interna de una librería invocada. Añadir un campo de entrada opcional. Añadir un nuevo campo de salida (output), aunque sea opcional. Hacer obligatorio un campo de salida que antes era opcional.

Para garantizar la portabilidad de la base de datos en APX, ¿qué tipo de sentencias SQL están explícitamente prohibidas?. Sentencias que incluyan atributos específicos del gestor de BBDD, como ROWNUM de Oracle. Sentencias que utilicen JOIN entre más de tres tablas. Consultas de tipo SELECT * en entornos de desarrollo. El uso de variables BIND en la cláusula WHERE.

Se detecta que una librería APX tiene un campo de entrada llamado action que acepta valores "C" (Create), "U" (Update) y "D" (Delete). ¿Qué antipatrón de diseño se está violando?. El antipatrón BLOB. El antipatrón Contenedor Mágico (Magic Container). El antipatrón de Dependencia Circular. El principio de Inversión de Dependencias.

Un desarrollador necesita modificar una variable de entorno de la JVM en tiempo de ejecución utilizando System.setProperty. ¿Es esto permitido?. No, está prohibido modificar variables de entorno o usar Locale.setDefault. Sí, pero solo en el método execute de la transacción. Sí, siempre que se restablezca el valor original en el bloque finally. Sí, si la variable es específica de la librería y no del sistema.

¿Cuál es la restricción respecto a la invocación de transacciones Mainframe (Host) desde una transacción APX?. Las invocaciones a Mainframe solo están permitidas en procesos Batch. Se pueden hacer tantas invocaciones como sea necesario siempre que sean de lectura. Se debe invocar un máximo de dos veces; si se requiere más, necesita validación de Arquitectura. No se permite ninguna invocación a Mainframe; todo debe migrarse a DB2.

¿Por qué está prohibido el uso de JPA (Java Persistence API) en las librerías APX?. Porque JPA requiere abrir conexiones manuales al DataSource. Porque JPA no es compatible con Java 8. Porque APX solo soporta consultas nativas SQL. Porque el caché de JPA puede provocar desincronización de datos al ser accedidos por sistemas externos.

En la definición de logs, ¿cuándo se debe utilizar el nivel WARN?. Para registrar el inicio y fin de las transacciones. Para información de muy bajo nivel útil solo en desarrollo. Para situaciones anómalas o imprevistas que la aplicación puede resolver o que no son críticas. Para errores críticos que impiden la ejecución de la transacción.

Si una librería A depende de una librería B, y B actualiza su versión añadiendo un nuevo método (cambio retrocompatible), ¿qué debe hacer la librería A?. Debe modificar su clase Abstract para incluir el nuevo método. Nada. Seguirá funcionando correctamente en tiempo de ejecución gracias a la resolución de versiones de OSGi. Debe actualizar su pom.xml inmediatamente para compilar con la nueva versión. Debe redesplegarse obligatoriamente para refrescar el contexto de Spring.

¿Qué restricción existe sobre el uso de System.out.println en el código APX?. Está totalmente prohibido; la escritura de logs debe hacerse vía la utilidad de Arquitectura (SLF4J). Está permitido si se usa dentro de un bloque try-catch. Está permitido solo en entornos de desarrollo (DEV). Está permitido para trazas rápidas, pero se recomienda borrarlo.