Transacción de 2 niveles usada como Business Component y manejo de errores.

Transcripción

1 Transacción de 2 niveles usada como Business Component y manejo de errores. Ya hemos visto anteriormente el concepto general de Business Component y su aplicación en una transacción de un solo nivel. Veamos ahora qué sucede cuando nos enfrentamos a la declaración de una transacción de dos nieveles como Business Component. Analizaremos esta nueva situación a través de la implementación de una nueva funcionalidad en nuestra aplicación. Frecuentemente la Agencia organiza paquetes especiales para grupos reducidos de clientes, y les obsequia una excursión a elección, en este caso a una ciudad italiana. Veamos las transacciones involucradas: Si bien un cliente puede contratar varias excursiones y cada excursión puede ser contrada por varios clientes, en particular cada cliente puede participar solamente de una única excursión obsequiada por la Agencia (al menos por ahora). Cuando las excursiones se dan de alta, se especifica si son gratuitas o no. En tanto, en la transacción Customer hemos definido el atributo fórmula CustomerFreeTrips y la regla: Error( Customer already has registered a free trip. ) if CustomerFreeTrips > 1; para controlar que los clientes no puedan tener más de 1 excursión obsequiada. Ahora pasemos a ver el web panel WPTrips que hemos definido y a través del cual resolveremos el requerimiento solicitado: Page1

2 Este web panel muestra los clientes en un combo dinámico y las excursiones gratuitas a ciudades italianas en una grilla. Hemos declarado esta condición a nivel del grid, para filtrar las excursiones gratuitas y a ciudades del país Italia, cuyo identificador CountryId = 1: También hemos especificado la propiedad Allow Selection del grid, con el valor True, para que el usuario final, pueda seleccionar una línea del grid: La idea entonces es seleccionar un cliente en el combo, una excursión del grid, y que al presionar el botón Confirm dicha excursión se grabe como una línea del cliente, controlando siempre que solamente se registre una excursión gratuita para ese cliente. Qué nos ofrece GeneXus para resolver esto? Utilizaremos la transacción Customer como Business Component. Para eso, declaramos su propiedad Business Component con el valor True: Page2

3 Al grabar, sabemos que GeneXus creó el tipo de dato Customer asociado a la transacción. Pero como se trata de una transacción de dos niveles, creó también el tipo de dato Customer.Trip asociado a las líneas del segundo nivel, que en nuestro ejemplo corresponden a las excursiones del cliente. Bien. Volvamos al web panel. Definimos en este objeto una variable &Customer de tipo Customer, y una variable &onetrip de tipo Customer.Trip: En el evento Enter asociado al botón Confirm, lo primero que hacemos es recuperar de la base de datos toda la información del cliente seleccionado en el combo y la misma queda cargada en memoria en la variable &Customer. Observemos ahora la 2da línea de código: La variable &onetrip es del tipo de datos de una línea de la transacción Customer, es decir que corresponde a 1 excursión del cliente. O sea que esta variable es compuesta de varios miembros que almacenan datos. En particular le estamos asignando al identificador de la excursión, el identificador de la excursión seleccionada en el grid. Page3

4 En la siguiente línea de código estamos usando un método Add, el cual agrega a la lista de excursiones que ya tiene el cliente, la excursión que se le indica entre paréntesis O sea, la variable &onetrip que hemos cargado en la línea de código anterior. Hasta ahora hemos trabajado en memoria. Solamente hemos agregado 1 excursión a 1 cliente. Para realizar la actualización física en la base de datos declaramos el método Save y el comando Commit, necesarios al trabajar con Business Component. Qué sucede con el control de la cantidad de excursiones gratuitas por cliente? Si bien este control se dispara automáticamente al aplicar el método Save a la variable del Business Component, para que el usuario final se entere, debemos obtener y mostrar explícitamente los mensajes que se emitieron. A qué tipo de mensajes nos referimos? A los propios que emite GeneXus por controles de consistencia de los datos, unicidad de valores de llaves primarias, etc. y a los mensajes asociados a nuestras propias reglas Errror y Msg. Cómo hacemos entonces para recuperar los mensajes que ocurrieron? Utilizamos el Tipo de datos estructurado Messages que automáticamente define GeneXus al crear una nueva KB. La finalidad de este tipo de datos colección, es permitirnos acceder a los mensajes que se emiten en la ejecución de un Business Component. De modo que definimos 2 variables: &Messages (del tipo de datos Messages, colección) y &onemessage (del tipo de datos Messages.Message, que es 1 elemento de la colección). Page4

5 Aplicamos el método GetMessages a la variable &Customer y obtenemos la colección de mensajes que ocurrieron y por último, utilizando el comando For elemento in colección, recorremos cada mensaje de la variable colección de mensajes y desplegamos su descripción. Presionemos F5 y veamos cómo funciona. Ejecutamos el web panel WPTrips, elegimos al cliente Parker, seleccionamos la excursión a Roma y presionamos el botón. Vemos que se despliega el mensaje de GeneXus informando que se realizó el registro. Qué sucederá si intentamos asignarle también la excursión a Venecia? Probemos.. Page5

6 Vemos que se despliega el mensaje correspondiente a nuestra regla Error, que controla que el cliente solamente tenga asociada una excursión gratuita. Page6