Asynchronous transactions execution

Por qué la Arquitectura desaconseja el uso de transacciones asíncronas?. Porque consumen más CPU que las síncronas. Porque no permiten enviar cabeceras HTTP. Porque se pierde el control de la ejecución y el consumidor no sabe si terminó en commit OK o rollback KO. Porque no se pueden monitorizar desde la consola.

¿En qué tipo de casos se pueden usar transacciones asíncronas según la Arquitectura?. Siempre que se quiera mejorar el rendimiento. Solo cuando la operación no es crucial para el proceso de negocio. Solo para operaciones de escritura en BBDD. Solo para transacciones de lectura.

¿Qué paso organizativo es obligatorio antes de registrar un consumo asíncrono de una transacción APX?. Abrir un ticket a Sistemas para aumentar memoria del servidor. Informar al equipo de Local Governance y actualizar las plantillas de servicio ASO. Enviar un correo al Product Owner. Crear un log específico en la aplicación.

¿Quién debe validar cada consumo asíncrono de una transacción?. El responsable funcional del negocio. El equipo de QA. El responsable del proyecto en el equipo de Arquitectura. El administrador de BBDD.

¿Cuál es la clase que encapsula la información necesaria para invocar una transacción de forma asíncrona?. ApxAsyncInvoker. ApxTransactionInvokerInfo. ApxAsyncMessage. ApxTransactionAsyncBody.

¿Qué elementos se indican en el constructor de ApxTransactionInvokerInfo para una invocación asíncrona?. Body, código HTTP, severidad y país. Body, cabeceras, código de retorno y fecha. Body, nombre de la transacción, versión y país (geografía actual). Nombre de la transacción, usuario y código de error.

¿Cómo se informa al contexto de ejecución de que queremos hacer una invocación asíncrona?. Usando setAsync(true) sobre la transacción. Llamando a addAsyncTransactionInvokerInfo(ApxTransactionInvokerInfo t) en la librería. Llamando directamente a invokeAsyncTransaction() sin parámetros. Configurando una propiedad en el application.properties.

Si queremos lanzar la transacción asíncrona explícitamente durante la ejecución de la librería, ¿qué método debemos usar?. executeAsyncTransaction(trxInfo). invokeAsyncTransaction(). runAsyncTransaction(). fireAsyncTransaction(trxInfo).

¿Qué ocurre si no se llama explícitamente a invokeAsyncTransaction() tras haber usado addAsyncTransactionInvokerInfo(...)?. No se invoca nunca la transacción asíncrona. Se lanza una excepción en tiempo de ejecución. La transacción asíncrona se invocará automáticamente al final de la transacción invocante. La invocación se descarta silenciosamente.

¿Cómo se representa el body de la transacción en el invocador asíncrono?. Como un String JSON plano. Como un InputStream binario. Como un Map<String, Object> donde cada entrada es un parámetro. Como una lista de DTOs serializados.

En el invocador asíncrono, ¿cómo se modela un parámetro complejo (tipo tabla de parámetros) en el body?. Como una cadena CSV. Como una lista de String. Como un objeto ParameterTable añadido al Map<String,Object>. Como un List<Map<String,String>>.

Según el documento, ¿qué ocurre con las cabeceras (headers) al usar el invocador asíncrono?. No se propaga ninguna cabecera a la transacción asíncrona. Se pueden escribir libremente cabeceras QP06 desde el invocador. No se permite escribir cabeceras QP06; se propagan las existentes salvo que se sobreescriben los datos propios de la transacción invocada. Solo se propagan cabeceras definidas por el usuario.