66826033 diseno-de-aplicaciones-gene xus-apunte-1

1
Herramientas y metodologías
HERRAMIENTAS Y METODOLOGÍAS:
Nuestra tarea como profesionales de la informática es desarrollar y mantener aplicaciones para
apoyar al usuario en su actividad final. Para realizar esta tarea se han instrumentado diferentes
herramientas y metodologías.
Con GeneXus se desarrollan aplicaciones aplicando una metodología que tiene un enfoque muy
diferente al de las metodologías mas comúnmente utilizadas.
Aprender a utilizado adecuadamente va más allá de conocer el lenguaje de especificación y lo
más importante es el aprendizaje de una nueva metodología de desarrollo.
El primer problema al que nos enfrentamos en el desarrollo de aplicaciones es la obtención del
conocimiento de la realidad.
Cómo obtener el conocimiento de la realidad en una forma lo suficientemente objetiva y detallada
al mismo tiempo, que nos permita construir un modelo corporativo.

2
Todos compartirán la afirmación de que cada usuario conoce muy bien los objetos con los que
trabaja cotidianamente, conoce claramente la información que se maneja en ellos, que reglas
deben seguirse y que cálculos deben realizarse. Por lo tanto, utilizar estas visiones de los objetos
de su realidad como fuente de información parece muy razonable.
Se ha demostrado con mucha rigurosidad que es posible obtener un modelo de datos a partir de la
síntesis de visiones, por lo que nuestro problema se ha reducido a un problema matemático ya que
si conseguimos describir adecuadamente estas visiones podremos obtener mediante Ingeniería
Inversa el modelo de datos. Este método que se conoce como síntesis de visiones canónicas.
Este es el punto de partida de la metodología de GeneXus: Describir las visiones de los usuarios
para modelar el sistema, y se construirá a partir de este modelo el soporte computacional (base de
datos y programas) para soportarlo.
COMPARACIÓN DE METODOLOGÍAS
Es bueno, para fijar ideas, comparar la metodología utilizada por GeneXus conocida como
Metodología Incremental con las metodologías tradicionales más utilizadas actualmente.
Algunos de los ejemplos de estas metodologías son: Análisis Estructurado, Ingeniería de la
Información, Análisis Escencial.
Estas metodologías son diferentes entre sí, pero en todos los casos, separan el análisis de los
datos del de los procesos.
Veremos un esquema general que podría aplicarse a cualquiera de éstas metodologías y
estudiaremos sus problemas.
Metodología Tradicional:
La primera tarea, generalmente, es el análisis de datos.

3
Se pretende analizar la empresa y dar como producto un modelo de datos con las Entidades y
Relaciones encontradas (Modelo ER).
Aquí se analiza la empresa desde el punto de vista de los objetos que existen en ella y sus
relaciones.
Construir un sistema integrado, que requiere un modelo de datos Corporativo de la empresa no es
una tarea simple debido a que el número de objetos y relaciones hacen que esta tarea sea
extremadamente compleja.
Debido a la complejidad de la construcción de un sistema integrado, lo que se hace normalmente
es dividirlo en módulos, y cada uno solucionará los problemas operativos de un área en particular
de la empresa. Simplificaremos notablemente la tarea de modelado ya que lo que precisamos
normalmente son 10 o a lo sumo 20 archivos para cada modelo.
Los módulos operan sin una real integración, lo que hace que exista información redundante y
como consecuencia todo intento de buscar información fuera del entorno de cada aplicación resulte
imposible o por lo menos peligroso.
En caso de que deseáramos posteriormente realizar la integración de esos módulos es necesario
realizar modificaciones al modelo de datos (lo que a pesar de la complejidad podríamos calificar
como posible), pero las modificaciones que deberemos realizar en los programas tienen un costo
tan grande que hacen inviable la realización de la integración.
La empresa tendrá de esta forma, resueltos sus problemas operativos, pero luego aparecerán con
mucha claridad los problemas de la carencia de información que permitan orientar la gestión y la
toma de decisiones de alto nivel, ya que la información que se necesita es en general de
naturaleza corporativa.
En la medida que nos orientamos cada vez más a las bases de datos corporativas, la cantidad de
objetos que integran la base de datos y sus relaciones se hacen más complejas. Esto lleva a que el
diseño de una base de datos corporativa sea una tarea muy complicada y en la que son muchos
los errores que se pueden cometer.
GeneXus apunta a la creación de sistemas corporativos, brindando herramientas y una
metodología que hagan posible la realización de esta tarea.

4
Continuando con el proceso de desarrollo en una metodología tradicional, luego de obtener el
modelo de datos se pasa a diseñar la base de datos.
Podemos ver que entre un buen modelo de datos, y el diseño de la base de datos necesaria para
soportarte, existe una transformación trivial. Por ello, para mayor claridad del dibujo, eliminaremos
la etapa intermedia y colocaremos directamente la base de datos.
Pero el modelo de datos no es suficiente para desarrollar los programas de aplicación, porque
describe los datos, pero no los comportamientos. Se recurre a una tarea generalmente llamada
Análisis Funcional, donde se estudia la empresa desde el punto de vista de las fundones y que
tiene como resultado una Especificación Funcional.
El producto de la función anterior es la Especificación Funcional. Sería deseable que esta
Especificación Funcional fuera independiente de la Especificación de Datos. Pero esto no es lo
común en las metodologías estudiadas.
Las especificaciones producidas son "file dependents" y, en consecuencia, modificaciones en el
diseño de la base de datos, implican la necesidad de revisar las especificaciones funcionales.
Esta es la causa fundamental de los grandes costos de mantenimiento que deben soportar las
empresas.
Entre las alternativas más usadas se destacan la programación en lenguajes de 3a. generación, y
en lenguajes de 4a. generación.
Lenguajes de 3a. Generación:
Lenguajes de bajo nivel como pueden ser COBOL, RPG. C, PASCAL, ADA, FORTRAN.
Lenguajes de 4a. Generación:
Lenguajes de programación de alto nivel como pueden ser CA IDEAL. INFORMIX 4GL. NATURAL
2, PROGRESS, etc.
Desde un punto de vista conceptual, ambos casos son idénticos. En ambos el analista debe
estudiar el problema, transformarlo en un algoritmo y codificar dicho algoritmo en el lenguaje de
programación.
Sin embargo, existe una fuerte diferencia: en los lenguajes de 4a. generación se escribe mucho
menos (probablemente 10 veces menos) y, como consecuencia, la productividad es mucho mayor
y el número de errores cometidos es mucho menor.
Podría argumentarse en contrario, que se pierde flexibilidad con estas herramientas, lo que es
cierto en términos teóricos, pero es irrelevante en términos prácticos, dado que hoy estas
herramientas están dotadas de primitivas que permiten complementar su código, por lo que su
aplicabilidad ha crecido mucho.
El problema visto, de que las descripciones de los procesos dependen de la base de datos, afecta
a ambos por igual. Como consecuencia, los lenguajes de 4a. generación permiten aumentos de
productividad muy grandes sobre los de 3a., en la tarea de desarrollo, pero ayudan bastante poco
en la de mantenimiento.
Otra alternativa es la utilización de un "generador" que es una herramienta que puede interpretar la
especificación funcional, (que obviamente debe ser totalmente rigurosa), y producir
automáticamente los programas.

5
Aquí existe una diferencia conceptual muy grande con el caso anterior. En este caso el analista
describe el problema de una forma declarativa (no existe algoritmo ni codificación procedural
alguna).
Algunos ejemplos son ADELIA, AS/SET. LANSA, SYNON. TELÓN. etc. Existe otra categoría de
herramientas conceptualmente idéntica: la de aquellas que, simplemente, interpretan la
especificación, como por ejemplo: MAGIC y SAPIENS.
La programación en ambos casos es totalmente automática, por lo que el aumento de
productividad sobre las herramientas de 3a. generación es muy grande.
Podría argumentarse en contrario, como a menudo se ha hecho con las herramientas de 4a.
generación, que se pierde flexibilidad con estas herramientas, lo que es cierto en términos teóricos,
pero es irrelevante en términos prácticos, dado que, hoy, estas herramientas están dotadas de
Lenguajes de Diagramas de Acción, (en la práctica lenguajes de 4a. generación), que permiten
complementar su código, por lo que su aplicabilidad ha crecido mucho.
El problema visto, de que las descripciones de los procesos dependen de la base de datos, afecta
también a las aplicaciones generadas mediante estas herramientas. Como consecuencia, los
Generadores y los Interpretadores (como los lenguajes de 4a. generación) ayudan bastante poco
en la tarea de mantenimiento.
Resumiendo aquí las tres opciones vistas:
Lenguajes de 3a. Generación Baja productividad en el desarrollo
Lenguajes de 4a. Generación Buen aumento de productividad en el desarrollo sobre L3G.
Generadores Buen aumento de productividad en el desarrollo sobre L3G y L4G.
Desde el punto de vista del mantenimiento, ninguna de las herramientas ayuda mucho dado que,
en todas ellas, se utilizan descripciones de procesos que pueden perder su validez cuando existen
modificaciones de archivos y que, por ello, deben ser revisadas y mantenidas manualmente.
Existe, sin embargo, un postulado cuyo cumplimiento evitaría este problema:
PUEDE OBTENERSE UNA BASE DE DATOS ESTABLE.
Lamentablemente, este postulado es falso, y sobran los contraejemplos que lo demuestran.
METODOLOGÍA CENEXUS:
Los fundadores de ARTech han desarrollado una amplia actividad de consultaría internacional en
diseño de grandes bases de datos.
Cuando se comenzaron a utilizar verdaderos modelos corporativos, que normalmente poseen
cientos de tablas, les quedó claro que no debía perderse más tiempo buscando algo que no existe:
las bases de datos estables.
Luego de importantes investigaciones, desarrollaron una teoría, organizaron una metodología e
implementaron una herramienta para posibilitar el desarrollo incremental y permitir la convivencia
con las bases de datos reales (inestables), a costo mínimo.

6
Desarrollo con GENEXUS:
Utilizando GENEXUS, la tarea básica del analista es la descripción de la realidad. Sólo el hombre
podría desarrollar esta tarea, ya que sólo él puede entender el problema del usuario.
Desde luego que esto modifica la actividad del analista e, incluso, su perfil óptimo, ya que lo
transforma en un "Business Analyst".
Ahora trabaja en alto nivel, discutiendo problemas con el usuario y probando con él las
especificaciones a nivel de prototipo, en vez de desarrollar su actividad a través de tareas de bajo
nivel como son: diseñar archivos, normalizar, diseñar programas, programar, buscar y eliminar los
errores de los programas.
Al crear un nuevo sistema o proyecto Genexus, se crea una nueva Base de Conocimiento. Una
vez creada la nueva Base de Conocimiento, el siguiente paso es empezar a describir los objetos de
la realidad mediante objetos Genexus.
A partir de los objetos definidos en la Base de Conocimiento, GENEXUS genera automáticamente
tanto los programas de creación / reorganización de la base de datos como los programas de la
aplicación.

7
El término Base de Conocimiento hace referencia a la capacidad de reutilizar en forma automática
el conocimiento almacenado y sobre todo a la capacidad de realizar inferencias que permiten
obtener más conocimiento.
Como se ha visto, existen varios caminos para la implementación de aplicaciones:
1. PROGRAMACIÓN UTILIZANDO LENGUAJE DE 3A. GENERACIÓN.
2. PROGRAMACIÓN UTILIZANDO LENGUAJES DE 4A. GENERACIÓN
3. GENERACIÓN / INTERPRETACIÓN AUTOMÁTICA DE LA ESPECIFICACIÓN FUNCIONAL.
4. DESARROLLO INCREMENTAL.
La productividad en el desarrollo de aplicaciones aumenta de arriba a abajo. Disminuir en gran
forma el mantenimiento de las aplicaciones (datos y programas), sólo se consigue con el desarrollo
incremental.
La primera tarea que hay que realizar es pasar a describir los objetos de la realidad, mediante
objetos Genexus.
Para ello existen 5 objetos básicos:
Transacciones:
Las transacciones permiten definir los objetos de la realidad. La mayor parte de las transacciones
pueden ser identificadas prestando atención a las entidades que el usuario menciona (por eje.
Clientes, Proveedores, Artículos). A partir de las transacciones Genexus infiere el diseño de la
base de datos.

8
Procedimientos:
Procesos no interactivos de actualización de la base de datos (procesos baten).
Reportes:
Recuperan información a partir de los datos almacenados y no los alteran. Los reportes son lo que
conocemos habitualmente como listados.
Paneles de trabajo:
Permite definir consultas interactivas a la base de datos. Es un objeto muy flexible que se presta
para múltiples usos.
Menúes:
Objetos organizadores del resto.
Sistematización del conocimiento:
Veamos ahora con más detalle el proceso de desarrollo de una aplicación con GeneXus.
GeneXus captura el conocimiento que reside en los objetos descritos y lo sistematiza en una base
de conocimiento.
GENEXUS funciona basado en su capacidad de inferencia. Así infiere, por ejemplo:
En el modelo de datos: las tablas, las restricciones de integridad y los índices necesarios.
Los programas de creación y/o de reorganización de la base de datos.
Los programas de la aplicación.
Los análisis de impacto de los cambios.

9
A partir del conocimiento especificado a través de las transacciones, GENEXUS diseña el modelo
de datos normalizados (en 3ª Forma normal).
GENEXUS genera automáticamente los programas necesarios para crear la base de datos, y la
crea mediante ellos.
GENEXUS genera automáticamente, a partir de la base de conocimiento, los programas de la
aplicación.

10
En este estado, la aplicación está lista.
Como se ha dicho, durante el ciclo de vida de la aplicación, existen muchas modificaciones.

11
Ante cambios en las visiones de usuarios, GENEXUS diseña la nueva base de datos.
Algunas veces, la nueva base de datos coincide con la anterior, en cuyo caso, todos los programas
existentes seguirán siendo válidos.
Otras veces, existen cambios en la base de datos. El análisis de impacto de los cambios nos
informa si debe reorganizarse la base de datos, cómo debe ser hecha esa reorganización y, los
eventuales problemas que esa reorganización podría ocasionar.
Una vez analizado el análisis de impacto, el analista resolverá efectuar la reorganización o
renunciar a ella volviendo a la situación anterior.
Si el analista ha dado el visto bueno a la reorganización, GENEXUS genera automáticamente los
programas necesarios para esa reorganización.
GENEXUS, considerando la base de conocimientos nueva y la vieja, estudia el impacto de los
cambios sobre los programas actuales y produce un informe sobre el tema. La reorganización

12
consiste entonces, en ejecutar esos programas. En realidad es de esperar que tengan muchas
tablas comunes, que no se modificarán en la reorganización.
GENEXUS genera / regenera automáticamente los programas necesarios.

13
Ahora se tienen las nuevas aplicaciones. El ciclo de mantenimiento está completo.
Múltiples Plataformas de ejecución a partir de una única especificación.
ARQUITECTURAS CENTRALIZADAS
Plataforma Lenguaje Generado
AS/400 COBOL/ 400, RPG/400
ARQUITECTURAS FILE SERVER
DOS Foxpro, Clipper DBF
WINDOWS Foxpro for Windows DBF
Visual Basic Access
Visual Fox DBF
ARQUITECTURAS CLIENT/ SERVER
FOXPRO FOR WIN, VB, VFP ORACLE Unix, NT
MS SQL SERVER Alfa, Windows NT y 95
INFORMIX Unix, NT
DB2 Common Servers RS6000, OS2
DB2/ 400 AS400
La construcción automática de la Base de Datos y programas a partir de una única fuente de
especificación permitirá a GENEXUS aplicar una metodología de desarrollo que podríamos llamar
"Metodología Incremental", ya que el proceso se realiza mediante aproximaciones sucesivas.

14
En cada momento desarrollamos la aplicación con el conocimiento que tenemos y luego cuando
pasamos a tener más (o simplemente diferente) conocimiento, GENEXUS se ocupará de hacer
automáticamente todas las adaptaciones en la base de datos y programas.
El incrementar una aplicación implica cambios en la base de datos y programas. Los cambios en la
base de datos pueden tener un costo aceptable, pero el alto costo de las adaptaciones de los
programas harían inviable la aplicación de este método si no fueran resueltos automáticamente.
Ciclos Diseño-Prototipo y Diseño-Producción
El trabajo consiste de dos ciclos: el Ciclo de Prototipación y el Ciclo de Producción.
Ciclo de Prototipación:
El diseñador recorrerá repetidamente el bucle Diseño-Prototipo durante la fase de diseño,
construyendo y probando sucesivos prototipos del modelo.
Ciclo de Producción:
Por el contrario, pasará menos frecuentemente al bucle de Diseño-Producción, ya que la
generación del sistema se realiza solamente cuando el prototipo ha sido totalmente aprobado, o
luego de haber instrumentado y probado algún cambio.
Prototipación Integral en PC:

15
La construcción automática del soporte computacional nos dará la gran posibilidad de crear
prototipos. Verdaderos prototipos, ya que estos tendrán un funcionamiento equivalente al del
sistema en producción real, permitiendo que se pruebe hasta el último detalle de la aplicación.
Los resultados que todos quieren ver, están en forma de programas ejecutando, lo que no es
posible sin la utilización de prototipos.
Ventajas de la Prototipación:
• Permite ver resultados en forma temprana
• Permite el seguimiento de los requerimientos del usuario
• Detección de errores en forma temprana
• Logra el compromiso de los usuarios con el desarrollo
• Sistemas de mejor calidad
Toda comunicación es suceptible de errores:
•El usuario olvida ciertos detalles.
•El analista no toma nota de algunos elementos.
•El usuario se equivoca en algunas apreciaciones.
•El analista interpreta mal algunas explicaciones del usuario.
Pero, además, la implementación del sistema es, habitualmente, una tarea que consume bastante
tiempo. Como muchos de estos problemas sólo son detectados en las pruebas finales del sistema,
el costo (tiempo y dinero) de solucionarlos es muy grande y la realidad cambia, por lo que no es
razonable pensar que se pueden mantener las especificaciones mientras se implementa el
sistema. La consecuencia de mantener las especificaciones, es que se acaba implementando una
solución relativamente insatisfactoria.
El impacto de estos problemas disminuiría mucho si se consiguiera probar cada especificación,
inmediatamente, y saber cual es la repercusión de cada cambio sobre el resto del sistema. Una
primera aproximación a esto, ofrecida por diversos sistemas, es la posibilidad de mostrar al usuario
formatos de pantallas, informes, etc. animados por menúes. Esto permite ayudar al usuario a tener
una idea de qué sistema se le construirá pero, al final, siempre se presentan sorpresas.
Una situación bastante diferente sería la de poner a disposición del usuario para su ejecución,
inmediatamente, una aplicación funcionalmente equivalente a la deseada, hasta en los mínimos
detalles. Esto es lo que hace GeneXus: Un prototipo GeneXus es una aplicación pronta,
funcionalmente equivalente a la aplicación de producción.
La diferencia entre prototipación y producción consiste en que la primera se hace en un ambiente
de PC, mientras que la producción se realiza en el ambiente objeto del usuario (AS/400, PC o
redes de PC).
El prototipo permite que la aplicación sea totalmente probada antes de pasar a producción. Durante
estas pruebas, el usuario final puede trabajar con datos reales, o sea que prueba, de una forma
natural, no solamente formatos de pantallas, informes, etc. sino también fórmulas, reglas del
negocio, estructuras de datos, etc.
Problema: Analizar un proceso de emisión de las facturas en una empresa:
Ahora vamos a concentramos en cuál es la forma práctica utilizada por GeneXus, para la captura
de la realidad de la que tanto hablamos.
Jean Dominique Wamier y Ken Orr, formularon una teoría acerca de cómo puede ser construida
una aplicación de procesamiento de datos. Algunos de sus enunciados fueron los siguientes:

16
• Los datos y los procesos están estructurados.
• Todos los procesos son subdivididos en subconjuntos partiendo del nivel más alto y
empleando reglas de subdivisión adecuadas (de manera Jerárquica).
• Todo Proceso tiene un Comienzo, un Cuerpo, y un Final. Esta regla se aplica a la
organización de datos y resultados.
Resolución:
Tenemos en este proceso 5 niveles, distinguiendo en cada nivel, los conjuntos repetitivos de lo que
está presente una sola vez. Vemos que la gestión jerárquica de los datos hace aparecer relaciones
entre los conjuntos definidos en los distintos niveles.
Existe entonces una ley de correspondencia: Un elemento de un conjunto de un nivel inferior,
se corresponde con uno del nivel superior, si esta incluido en él.
Todo conjunto de nivel inferior se llama Conjunto de Partida y todo conjunto de nivel superior se
llama Conjunto de Llegada.
En el momento de jerarquizar procesos y datos, sería muy bueno que obtuviera este tipo de
relaciones. El no observar esta ley es fuente de confusión, eliminando la claridad y la simplicidad
de la organización de los datos tanto como la de los procesos.
DISEÑO DE TRANSACCIONES
Notación GeneXus para Transacciones:
Ejemplo: Proceso de Emisión de Facturas
FacNro* Código de la factura
CliCod Código del cliente
CliNom Nombre del cliente
FacFch Fecha de la factura
(ProdCod* Código del producto
ProdNom Nombre del producto
ProdPre) Precio del producto

17
El siguiente paso es encontrar una forma de notación adecuada para GeneXus. Por ejemplo, una
transacción de emisión de Facturas tendrá la siguiente notación. Cada nivel definirá un conjunto de
atributos que deben operar en conjunto. Se ingresarán, eliminarán o modificarán conjuntamente en
la base de datos.
Precisamos entonces encontrar un conjunto de atributos que actúe como identificador de cada
instancia de este conjunto. Notaremos a estos atributos con un asterisco. Este es en definitiva el
concepto de clave primaria por lo que en la elección de estos atributos debemos atender a todas
las reglas correspondientes a su definición.
El conjunto de atributos entre paréntesis representa la ocurrencia de varios para cada instancia del
nivel anterior. En el ejemplo, una factura tiene varios productos.
Definición del diseño de Base de Datos en 3era Forma Normal
para soportar las transacciones definidas.
Veamos el proceso de obtención de una base de datos en 3a Forma normal a partir de las
especificaciones de transacciones.
Para esto utilizaremos como ayuda las dependencias funcionales que se derivarían de la definición
de la transacción.
La definición de esta primera transacción a determinado las siguientes dependencias funcionales.
FacNro CliCod
FacNro CliNom
FacNro FacFch
Por lo que se definirá una tabla con el siguiente diseño
FacNro*
CliCod
CliNom
FacFch
Tenemos además las siguientes dependencias funcionales determinadas por el 2do nivel de la
transacción.

18
FacNro, ProdCod ProdNom
FacNro, ProdCod ProdPre
FacNro, ProdCod FacLinCnt
FacNro, ProdCod FacLinImp
Que definirán una tabla con el siguiente diseño
ProdCod*
ProdNom
ProdPre
FacLinCnt
FacLinImp
La definición de dos nuevas transacciones: Clientes y Productos han determinado la aparición de
nuevas dependencias funcionales.
GeneXus diseñará las nuevas tablas que correspondan (Clientes y Producto) y realizará las
modificaciones necesarias en las ya existentes (Factura y Factura1) para considerar el conjunto
total de dependencias funcionales.
CliCod CliNom
ProdCod ProdNom, ProdPre
La siguiente dependencia funcional
FacNro CliNom
Se ha vuelto transitiva a partir de la existencia de las dependencias funcionales.
FacNro CliCod
CliCod CliNom
Por lo que deberá modificarse la tabla Factura. Análogamente con la tabla Factura1 y las
dependencias funcionales
FacNro, ProdCod ProdNom, ProdPre
ProdCod ProdNom, ProdPre

19
Es conveniente usar padrones para los nombres de atributos.
• Facilitan la tarea de darle nombre a un atributo dentro de las reglas establecidas
• Facilitan la tarea de integración de bases de conocimiento
ARTech ha definido un Standard para la nomenclatura de atributos, el GIK (GeneXus Incremental
Knowledge Base).
Puede gustarnos más o menos que otros. Lo importante es que es el utilizado por la comunidad de
usuarios GeneXus.
Esto viabiliza reutilización de conocimiento entre ellos.
Nombre de atributo Objeto + Categoría + Calificador
Objeto, Es el nombre de la transacción a la que pertenece el atributo.
Categoría, Es la categoría semántica del atributo.

20
Calificador, Puede existir uno o dos calificadores.
Ejemplo: de Nomenclatura GIK
Objeto Categorías Calificador
Cli Cod
Cli Nom
Cli Fch Ini
Cli Fch Fin
FacVta Nro
FacCmp Nro
Tipos de Datos:
• Numeric, Character, Date
• Long Varchar
• VarChar
- Equivalente al Character, salvo en la forma en que se almacena en la BD.
• DateTime
- Los valores de M y N no afectan la forma de almacenar el tipo de datos, sino la
forma de aceptar o mostrar su contenido.
Long Varchar: Permite almacenar una cantidad de caracteres indefinida. Se utiliza normalmente
para almacenar textos, descripciones, comentarios, etc. El largo que se le asigna es considerado el
largo máximo (la implementación depende de la plataforma).
VarChar: Permiten almacenar texto de largo variable. Su función, en contraposición al character,
es la de optimizar el almacenamiento en la base de datos.
Definición: Varchar(M, N)
M: Es el largo máximo posible que dependerá del DBMS. Si el largo asignado al atributo es mayor que
el soportado por el DBMS se utilizará el máximo soportado.
N: Es el largo promedio. Se utiliza para optimizar los accesos a disco en algunos DBMSs.
La idea es que si el valor de un atributo varchar es menor o igual que N, se almacenan N
caracteres (rellenados con blancos) en el registro del archivo y se utiliza un único acceso a disco
para leerlo o grabarlo.
En caso que el valor del atributo varchar sea mayor que N, se almacenan los primeros N en el
registro del archivo y el resto en un área de overflow para lo cual es necesario un acceso adicional
tanto para lectura como para escritura.
Se le pueden aplicar todas las funciones y operadores existentes para el tipo de datos character. El
tipo de datos Varchar es equivalente al tipo Character en todos los sentidos salvo en la forma en
que se almacena en la base de datos. Para los DBMS que no soportan este tipo de dato se crean
como Character.
DateTime: Permite almacenar una combinación de fecha y hora (hasta el segundo).
DateTime(M. N)
M = Largo de la fecha. Valores posibles: 0, 8 y 10.
N = Largo de la hora. Valores posibles: 2, 5 y 8.

21
Los valores de M y N, no afectan la forma de almacenar el tipo de datos sino específicamente a la
forma de aceptar o mostrar su contenido.
En caso que M sea 0 (no se considera la fecha) para un campo que ha de ser ingresado, el valor
de fecha a asignar será el mínimo soportado por el DBMS y reconocido como fecha vacía o nula en
GeneXus.
En caso que N sea distinto de 8 para un campo que ha de ser ingresado, los valores no aceptados
(minutos o minutos y segundos) serán considerados en cero.
Dominios:
Cuando debemos usar dominios?
• Atributos con la misma definición
• No existe relación entre ellos
Ejemplo:
Dirección Char30
Dirección del Cliente
Dirección del Banco
El objetivo de los dominios es permitir usar definiciones de atributos genéricos y luego poder
asociar un atributo con su correspondiente dominio.
En el ejemplo, el dominio Dirección es definido como Char de 30. Los atributos dirección del banco
y del diente son asociados a él. Por lo tanto, si en el futuro se cambia la definición de este dominio,
los cambios van a ser automáticamente propagados a todos los atributos que pertenezcan a éste.
De esta forma los dominios permiten un mayor nivel de abstracción en la definición de la
aplicación.
Reglas:
• Se utilizan para definir el comportamiento de las transacciones.
• Algunas reglas
- Defáult, Error, Ask, Msg, Asignación, Add, Subtract, etc.
• Default(FacFch, &today);
• Error('No se permiten clientes sin nombre')
ifnull(CliNom);
• Pueden incluir: atributos, variables, constantes y funciones.
• Las reglas son LOCALES a la transacción.
• Programación DECLARATIVA
Según el Análisis Orientado a Objetos, para cada objeto del sistema se debe definir cual es su
estructura y su COMPORTAMIENTO.
En el caso de las Transacciones, el comportamiento se define mediante el uso de Reglas (Rules).
Algunas reglas:
Defáult: Se utiliza para definir los valores por defecto de algunos atributos.
Error: Es para definir los controles que deben cumplir los datos, por ejemplo si no queremos
permitir que queden ingresados clientes sin nombre:
Dominio
Atributos

22
Error('No se permiten clientes sin nombre')ifnull(CliNom);
Cuando se cumple la condición ( null(CliNom) ) se despliega el mensaje ('No se permiten clientes
sin nombre') en pantalla y no se permite continuar hasta que el usuario ingrese un nombre sobre el
campo CliNom.
Asignación: Dentro de las reglas de la transacción se permiten definir asignaciones a atributos,
dicha asignación implica una actualización en la tabla base del nivel o en alguna de las tablas que
pertenecen a la tabla extendida del nivel.
Una asignación en las reglas es LOCAL (vale solo para la transacción en la cual fue definida).
Orden de evaluación:
La definición de reglas es una forma DECLARATIVA de definir el comportamiento de la
transacción. El orden en el cual fueron definidas no necesariamente indica que ese sea el orden en
que se encuentran en el programa generado. GeneXus se encarga de determinar el orden correcto
según las dependencias de atributos existentes (en este tema entraremos en detalle mas
adelante).
Tool Bars de Controles:
Usados en el diseño de Pantallas:
• Atributo / Variable
• Recuadro
• Botón
• Bitmap
• Tab Control
• PrintBIock
•Se utiliza para diseñar la pantalla (form) en forma gráfica. Mientras se está diseñando un form (de
TRN's, WKP's o Reports) está disponible la tool bars de Controles que contiene los tipos de
controles que se pueden agregar al form que se está editando.
Tab Control:
• Permite definir varios controles dentro de un Tab Control.
• Tiene una o varias páginas.
- Defáult: Dos páginas
- Agregar o eliminar páginas:
• Botón derecho sobre el Tab Control
- Página
• Título
• Área útil
- Check Box de Hide Tabs Para diseño de Wizards
(Recuadro al cambiar de pantalla)
• Sólo para los generadores visuales.

23
Un Tab Control tiene una o varias páginas (por defecto tiene dos). Cada página tiene un título y un
área útil, es decir donde se ponen los controles de esa página. Sólo una de las páginas puede
estar activa a la vez y es la que se puede ver. Del resto sólo se verá su título.
Las opciones Edit/Add Tab Page y Edit/Remove Tab Page son para agregar y eliminar páginas
respectivamente. Puede accederse también a estas opciones con botón derecho sobre el Tab
Control.
Hide Tabs: Para mostrar sólo la página activa y no mostrar los tabs. Útil para la definición de
Wizards.
Generación de HELP Tipo Windows:
• Es necesario generar y compilar el Help.
- Opción: Build/Generate Help
- El compilador viene con el Visual Basic/Foxpro/Visual FoxPro
• Disponible solamente en los generadores windows.
• Esto es para los generadores Windows.
•Se genera un .HLP compatible con el Help de Windows.
•El compilador de Help como se mencionó más arriba viene con el Visual
Basic/FoxproA/isual FoxPro y se requiere como mínimo la version3.10.505.
• Botón de Help:
- Llama al help del objeto.
• F1:
- Llama al help del atributo en donde se encuentra el cursor.
• Si ese atributo no tiene help se llama al help del objeto.
INTEGRIDAD REFERENCIA:
Diagrama de Bachean:
Las reglas de integridad referencial permiten asegurar la consistencia entre los datos de las
distintas tablas. El diagrama anterior se ha inspirado en los conocidos Diagramas de Bachman, y
tiene la virtud de explicitar la integridad referencial del modelo de datos.

24
En el ejemplo, existe una relación entre la tabla Clientes y Departamentos y también entre Clientes
y Categorías. La relación entre dos tablas se determina analizando los atributos que tienen en
común.
Por ejemplo, entre las tablas Clientes y Categorías tenemos que el atributo común es el código de
la categoría, que es la clave primaria de la tabla Categoría. Decimos que la relación entre ambas
tablas es 1-N, que indica que un cliente tiene una categoría y una categoría tiene N clientes.
También es usual decir:
. La tabla Categorías está Superordinada a la tabla de Clientes
. La tabla de Clientes está Subordinada a la tabla de Categorías
Esta relación implica que la información contenida en ambas tablas no es independiente, por lo que
es necearlo realizar controles para que la información sea consistente.
A estos controles se les llama de Integridad Referencial y básicamente son los siguientes:
• Cuando se crean registros en la tabla subordinada (Client), debe existir el registro
correspondiente en la tabla superordinada (Catego).
• Cuando se elimina un registro en la tabla superordinada (Catego), no deben existir el
registros correspondientes en la tabla subordinada (Client).
Definición de índices:
Tabla Indice
Tipo Composición
Catego PK CatCod
Depart PK DtoCod
Client PK
FK
FK
CliCod
DtoCod
CatCod
Definición de índices:
Para hacer eficiente los controles de Integridad, GeneXus crea automáticamente índices, que son
vías de acceso eficientes a las Tablas. Existen tres tipos de índices: Primarios, Extranjeros y del
Usuario.
Índice Primario (PK):
El índice primario es el que se define para la Clave Primaria, se utiliza para el control de unicidad
de los registros y para el control de que cuando se crean registros en la tabla subordinada (Client),
debe existir el registro correspondiente en la tabla superordinada (Catego). Con GeneXus todos los
índices primarios son definidos automáticamente a partir de los identificadores de las
transacciones.
Índice Extranjero (FK):
Los índices extranjeros son utilizados para hacer eficientes los controles de integridad inter-tablas.
También son definidos automáticamente. Cuando se elimina un registro en la tabla superordinada
(Catego), no deben existir registros correspondientes en la tabla subordinada (Client).
Índice del Usuario:
Los índices del usuario se definen, fundamentalmente, para recorrer los datos por determinado
orden de una forma eficiente. Por ejemplo, en la tabla Client se puede definir un índice por CliNom,
que es muy útil para los listados ordenados por nombre.

25
Los índices del usuario NO son definidos automáticamente ya que no se usan para los controles de
integridad.
En una Base de Datos Relacional los índices se utilizan sólo por problemas de performance, pero
siempre es posible acceder a los datos de la tabla por cualquiera de los atributos de la misma.
CONCEPTO DE TABLA EXTENDIDA:
Definición de Tabla Extendida:
Dada una tabla de la base de datos, se denomina tabla extendida de la misma al conjunto de
atributos conformado por:
- Atributos que pertenecen a la tabla.
- Atributos que tengan una relación N-1 con la tabla extendida determinada hasta el
momento.
Los criterios de normalización del diseño de la base de datos apuntan a minimizar la posibilidad de
inconsistencia en los datos. Una base de datos diseñada de esta manera tiene una serie de
ventajas importantes (tal es así que actualmente la normalización de datos es un standard de
diseño), pero se deben tener en cuenta también algunos inconvenientes.
El inconveniente más notorio es que los datos se encuentran dispersos en muchas tablas, y por lo
tanto cuando se quieren hacer consultas más o menos complejas a la base de datos se debe
consultar una cantidad importante de tablas. Así, por ejemplo, para listar las facturas sería
necesario consultar las tablas Cabezal y líneas de Facturas, Clientes, Categorías y Productos.
Para simplificar esta tarea GeneXus utiliza el concepto de tabla extendida.
Tabla Base Tabla Extendida
Categoría Categoría
Cliente Cliente
Categoría
Factura Factura
Cliente
Categoría
Factura1 Factura1
Producto
Factura

26
Cliente
Categoría
Producto Producto
ATRIBUTOS FORMULAS:
Características:
• Relación entre Atributos, Constantes o Funciones.
• Definición Global, definidas a nivel del modelo.
• Atributo Virtual (No se almacena en la tabla).
• Son calculadas siempre que se hace referencia al atributo.
Un atributo es una fórmula si su valor se puede calcular a partir del valor de otros atributos.
En cada transacción se puede definir qué atributos son fórmulas, pero esta definición es global (no
es local a la transacción), es decir toda vez que se necesite el atributo se calcula la fórmula, tanto
en transacciones como en los otros objetos GeneXus.
Existe una similitud entre fórmulas y asignaciones (regla), incluso la sintaxis de definición es
similar. La diferencia entre ambas es que una fórmula es GLOBAL (vale para todos los objetos
GeneXus que la utilicen), mientras que una asignación en las reglas es LOCAL (vale sólo para la
transacción en la cual fue definida).
Cuando un atributo es fórmula, éste no está almacenado (a no ser que se lo defina como
redundante) y cuando es una Asignación, por ser esta local, si esta almacenado.
Clasificación:
Horizontales:
Una o varias expresiones aritméticas condicionales.
Verticales:
SUM
COUNT
Aggregate / Select:
Select
Max, Min, Find
Aggregate
Sum, Count, Set
Fórmula Horizontal: Los atributos involucrados en la misma deben pertenecer a la tabla extendida
del atributo definido como fórmula.
Fórmula Vertical: Los atributos involucrados deben pertenecer a la tabla directamente
subordinada del atributo definido como fórmula. Son incondicionales.
Aggregate / Select: Pueden navegar sobre cualquier tabla del modelo. Son condicionales.
Fómulas Horizontales:
Atributo = <Expresión> if<Condición>;
<Expresión> if<Condición>;
<Expresión> Otherwise;

27
<Expresión>: es una expresión aritmética que puede involucrar atributos, constantes y funciones.
Los atributos que participan de la expresión deben pertenecer a la tabla base y/o a tablas que
están en una relación N para 1 con la tabla sobre la que se define la fórmula (es decir, a la tabla
extendida del atributo definido como fórmula). El atributo fórmula deja de estar almacenado en la
tabla y decimos que es un atributo virtual.
<Condición>: Es la condición de disparo de la fórmula. Cuando se define una fórmula horizontal,
GeneXus sabe cual es la tabla extendida del atributo que se está definiendo como fórmula, y
controla que todos los atributos utilizados en dicha fórmula se encuentren en ella.
Fórmulas Horizontales:
Ejemplo:
TRANSACCIÓN TABLA
CliCod* CliCod*
CliNom CliNom
CliTotCmp CliTotCmp
CliTotPgo CliTotPgo
CliSdo = CliTotCmp - CliTotPgo
Un atributo puede definirse como fórmula cuando su valor se obtiene siempre de un cálculo que
puede involucrar atributos, constantes y/o funciones. Por ejemplo, el saldo del cliente es siempre la
diferencia entre el total de compras y el total de pagos.
Diferencias entre Fórmulas y Reglas:
•Fórmula: La fórmula es una definición global ya que está a nivel del modelo de datos, su valor
será calculado cada vez que se utilice en cualquier objetó GeneXus ya que el atributo no está
almacenado en la tabla.
•Regla: La regla está definida a nivel local en la transacción. Cada vez que se mencione el
atributo, su valor no se calculará, sino que se tomará directamente de la tabla.

28
En el ejemplo, definimos al importe del producto en la factura (FacLinImp) como una fórmula
horizontal, por lo cual dicho atributo no está almacenado en la tabla Factura1.
Fórmulas Verticales: SUM - COUNT
Sintaxis:
- AtriFla = SUM(Att)
- AtriFla = COUNT(Att)
Características:
- Att debe pertenecer a una tabla directamente subordinada a la tabla en la
que se encuentra AtriFla.
- Son incondicionales.
- Navegación vertical – Performance
Características de las Fórmulas Verticales:
SUM: Suma un atributo perteneciente a una tabla directamente subordinada.
COUNT: Cuenta las filas de una tabla directamente subordinada.
Se utilizan cuando el valor de un atributo se obtiene sumando o contando filas de una tabla que
está directamente subordinada.
La tabla está en una relación 1 a N.
Se consideran todas las filas que pertenecen a la relación ya que no se pueden establecer
condiciones. Se resuelve mediante una navegación vertical, de ahí el nombre Fórmulas Verticales.
Performance:
El hecho que la fórmula no esté almacenada puede ocasionar problemas de performance, debido
al tiempo que puede demorar el recálculo.
Para evitar este inconveniente se puede definir la fórmula como REDUNDANTE. En este caso la
fórmula se almacena en la Base de Datos y no es necesario recalcularla cada vez que se use.
Profundizaremos en este tema más adelante.

29
Precisamos calcular ahora el subtotal de las líneas de la factura, que hemos llamado FacSubTot.
Este atributo está en el cabezal de la factura y el atributo a ser sumado en las líneas. Estas tablas
están en una relación de 1 a N. por lo que no podemos utilizar una fórmula horizontal.
Precisamos una fórmula que recorra todas las líneas de la factura y las sume, utilizamos para esto
una fórmula SUM( ) perteneciente a las llamadas Fórmulas Verticales. Se puede decir que un SUM
redundante es equivalente a la regla ADD.
Fórmulas Verticales:
Sólo se puede definir entre atributos de tablas directamente subordinadas. Dentro de una
fórmula vertical no se puede mencionar directa o indirectamente una fórmula
AGGREGATE/SELECT.
El atributo mencionado en la fórmula COUNT no puede formar parte de ninguna clave. El atributo
mencionado en la fórmula SUM puede ser fórmula. Para fórmulas de fórmulas GeneXus determina
cuál es el orden de evaluación correspondiente.
Fórmulas Aggregate/Select:
Son fórmulas que permiten buscar, sumar, contar atributos que cumplan determinadas
condiciones, en cualquier tabla del modelo.
Aggregate
- Sum
- Count
- Set
Select
- Max
- Min
- Find
Fórmulas Aggregate:
Sum: Suma condicionalmente atributos de cualquier tabla del modelo.
Count: Cuenta condicionalmente filas de cualquier tabla del modelo.
Set: Imprime instancias de un atributo en determinadas condiciones.

30
Fórmulas Seiect:
Find: Buscar el valor de un atributo en determinadas condiciones.
Max: Buscar el máximo valor de un atributo en determinadas condiciones.
Min: Buscar el mínimo valor de un atributo en determinadas condiciones.
Sintaxis:
- atrib = Sum | Count (<att>, <cond. búsq.>, <def>)
- atrib = Set(<Att>, <Cond>, <Def>)
- atrib = Max | Min(<att>, <cond. búsq. >, <def>, <ret>)
- atrib = Find(<att>, <cond. búsq.>, <def>)
atrib: es el atributo que se define como fórmula.
Sum: (atributo a ser sumado, condiciones que debe cumplir, valor por defecto)
Set: Selecciona las primeras ocurrencias (hasta 50) del atributo <att> que cumplen la condición
<cond.>, y las manipula como si fueran un solo atributo. Si no se especifica ninguna condición, las
primeras 50 ocurrencias serán seleccionadas.
<def>: Es el valor por defecto devuelto cuando ningún registro cumple la condición <cond>. Si no
se menciona nada en <def> se devuelve el nulo del tipo de datos de <att>.
Max: (atributo a maximizar. condiciones de maximizadón, valor por defecto en
caso de no encontrar quien cumpla con las condiciones, valor de retomo en
caso de encontrar)
Find: (atributo a buscar, condiciones de búsqueda, valor por defecto en caso de no encontrar quien
cumpla con las condiciones).
Fórmulas Aggregate:
.Sum() Aggregate
.Count() Aggregate
Se utilizan cuando el valor de un atributo se obtiene sumando o contando filas de cualquier tabla
del modelo que cumplan una determinada condición.
Atributo = Sum | Count (<Atributo Sumado o Contado>,<Condición para sumar o
contar> , <valor de retomo por defecto) IF <Condición de disparo>
A diferencia de las Fórmulas SUM y COUNT Verticales no es necesario que estén en una relación
de subordinación.
NOTA: Para distinguirlas en los listados:
Verticales: SUM y COUNT todas las letras en mayúsculas.
Aggregate - Sum y Count: Sólo la primera letra con mayúscula
Los siguientes ejemplos de fórmulas Aggregate y fórmulas Select, se incluyen como
documentación y no necesariamente se harán ejemplos en el curso, salvo que los alumnos lo
pidan.
Ejemplo de Count Aggreaate:
Total de productos con descuento en la factura:
Factura
FacNro*
FacFch

31
CliCod
FacTotArtDscto = Count(ProdCod, FacDscto > 0)
Factura1
FacNro*
ProdCod*
FacLinCnt
FacDscto
FacLinImp
FacNro ProdCod FacDscto
1 1 10
1 2 0
1 3 20
1 4 0
FacTotArtDscto = 2
Find:
Se utiliza para obtener el valor de un atributo que está en cualquier tabla del modelo, pudiendo
establecerse relaciones con cualquiera de los atributos de la tabla.
Sintaxis:
Atributo=Find(<Atributo a buscar>, <Condición de búsqueda>, <Valor por defecto>)
IF <Condición de disparo)
Ejemplo de uso de Find ():
El atributo DocCotDolar obtiene la cotización del dólar del día. La tabla de cotizaciones no tiene
ninguna relación con la de documentos.
Documentos Cotizaciones
DocNro* MonCod*
DocFch MonFch*
Docimp MonCot
DoclmpDolar = Doclmp / DocCotDolar
DocCotDolar = Find(MonCot, MonCod = 'U$S' .and. MonFch = DocFch)
Max:
Esta función determina el máximo valor de un atributo en una tabla. Obtenido este valor, que
corresponderá a una determinada fila, la función devuelve el valor de cualquier atributo de dicha
fila.
Sintaxis:
MAX(<Atributo a Maximizar>, <Condición de Maximización>, <Valor por defecto,
<Atributo a Devolver>) IF <Condición de ejecución>
Atributo a Maximizar: Debe estar almacenado en la tabla en la que se busca (Tabla de llegada),
es decir no puede ser un atributo fórmula o pertenecer a su tabla extendida.

32
Condición de búsqueda: Se pueden mencionar atributos almacenados o virtuales de la tabla
base y de la tabla extendida de la tabla de partida. Se pueden mencionar atributos almacenados de
la tabla en la que se realiza la búsqueda (Tabla de llegada).
Atributo a devolver: Atributo a devolver para asignar al atributo fórmula, debe estar almacenado
en la tabla de búsqueda.
Condición de disparo: Se pueden mencionar atributos almacenados o virtuales de la tabla base y
de la tabla extendida de la tabla de partida.
Ejemplo de uso del Max:
Obtener la última (máxima) cotización del dólar anterior a la fecha del documento.
DocNro* MonCod*
DocFch MonFch*
DocImp MonCot
DoclmpDolar
DocCotDolar
Atributo a maximizar... MonFch
Condición……......................... MonCod = U$S y el máximo valor de MonFch debe ser menor o
igual a la fecha de documento.
Atributo a devolver…............... MonCot
Valor por defecto..................... 0
Ejemplo de uso del Max:
DoclmpDolar = Doclmp / DocCotDolar
DocCotDolar = Max(MonFch, MonCod = 'USS’ .and. MonFch <= DocFch. , MonCot)
Fecha del Documento 15/01/94, le corresponde la cotización del día 13/01/94.
MonFch MonCot
10/01/94 100
11/01/94 110
12/01/94 112
13/01/94 115
16/01/94 117
Min:
Atributo = Min(<Atributo a Minimizar>, <Condición de minimización>, <Valor por defecto>,
<Atributo a Devolver>) IF <Condición de disparo>
Esta función determina el minino valor de un atributo en una tabla. Obtenido este valor, que
corresponderá a una determinada fila, la función devuelve el valor de cualquier atributo de dicha
fila.
Ejemplo de uso de la función Min:
Se quiere obtener la cotización del dólar para el día de la fecha y en caso de que no exista, la
inmediatamente posterior.

33
DocNro* MonCod*
DocFch MonFch*
DocImp MonCot
DocImpDolar = DocImp / DocCotDolar
DocCotDolar = Min(MonFch, MonCod = ‘U$S' .and. MonFch >= DocFch, , MonCot)
Fecha del Documento 15/01/94, le corresponde la cotización del día 16/01/94.
MonFch MonCot
10/01/94 100
11/01/94 110
12/01/94 112
13/01/94 115
16/01/94 117
17/01/94 118
Consideraciones aplicables a todas las fórmulas Aggregate/Select:
Atributo = Find(<Atributo a buscar>, <Condición de búsqueda>, <Valor por
defecto>) IF <Condición de disparo>
En la definición de la fórmula intervienen atributos de varias tablas:
La tabla en la que está definido el atributo fórmula (tabla de partida).
La tabla extendida de la tabla de partida.
La tabla en la que se busca (tabla de llegada).
IMPORTANTE: No se pueden utilizar atributos de la tabla extendida de la tabla de llegada:
(Tabla de partida) (Tabla de llegada)
Consideraciones de performance:
Tanto las fórmulas Verticales como las fórmulas Agregate/Select, implican la realización de
navegaciones en la Base de Datos, por lo que es importante considerar la forma en que esto es
realizado.
Las fórmulas Verticales pueden almacenarse en forma redundante y GeneXus se encargará de
mantenerlas actualizadas.
Uso de la fórmula MAX():
Ejemplo: Buscar el precio del producto según la fecha de la Factura.
Transacción Productos Transacción Factura
ProdCod* FacNro*
ProdDsc CliCod
(ProdFch* FacTot
ProdPre) FacFch
(ProdCod'*
FacProdPre
FacLinCnt
FacLinImp)

34
Atributo = MAX(Atributo a Maximizar), (Condición de Maximización), (Valor por defecto),
(Atributo a devolver) IF (Condición de ejecución)
Uso de la Fórmula Max( ) para buscar el precio del producto según la fecha de la factura.
Definimos la transacción de productos de tal forma de guardar el histórico de precios, con la fecha
de aumento de precio asociada.
Con la fecha de la factura buscaremos el precio del producto correspondiente.
Por ejemplo: Fecha de Factura: 10/10/93
Precio producto correspondiente: 220 correspondiente al 3/10/92
Incluiremos en las líneas de la factura el atributo ProdCod. No podemos incluir ProdFch debido a
que no podríamos saber que valor darle a la fecha para poder heredar directamente el ProdPre.
Definimos el atributo FacProdPre y buscaremos con una fórmula el precio correspondiente de
acuerdo a la fecha de factura. Buscaremos el precio de fecha máxima anterior a la fecha de
factura.
La fórmula quedaría:
FacProdPre = Max (ProdFch, ProdFch <= FacFch. 0, ProdPre)
Atributo a Maximizar…………….. ProdFch
Condición…………………………. Factura1.ProdCod = Producto1.ProdCod (cond. implícita).
El máximo valor de ProdFch <= FacFch (cond. explícita).
Atributo a devolver………………. ProdPre
Valor por defecto………………… 0, si no se encuentra ningún registro que cumpla la
condición.
Ejemplo:
Hacer lo siguiente:
A. Buscar la cotización de la moneda para la fecha del asiento
B. En caso de que no exista, dar un aviso y buscar la última ingresada a la fecha del asiento.

35
Transacción de Cotizaciones
MonId*
CotMes*
MonDsc
(CotDia*
CotImp)
Transacción de Asientos:
AsiNro*
AsiFch
AsiMes
AsiDia*
(AsiIidLin*
MonId
AsiImpME
AsiImpNS
AsiTipDH
CtaId
AsiFndCot)
Solución:
A • Transacción de Cotizaciones:
MonId*
CotMes*
MonDsc
(CotDia*
CotImp)
Transacción de asientos:
AsiNro*
AsiFch
AsiMes =Month(AsiFch)
AsiDia =Day(AsiFch)
(AsiIdLin*
MonId
AsiImpME
AsiImpNS
AsiTipDH
CtaId
AsiFndCot) =Find(CotImp, CotMes=AsiMes .and. CotDia =AsiDia)
ifMonId<’NS';
1 otherwise;
B • Transacción de Asientos:
AsiNro*
AsiFch
AsiDia Day(AsiFch)
(AsiIdLin*
MonId
AsiImpME
AsiImpNS = AsiImpME* AsiFndCot if AsiFhdCot <>0;

36
AsiImpME* AsiMaxCot ifAsiMaxCot <> 0;
1 otherwise;
AsiTipDH
CtaId
AsiFndCot a = Find(CotImp, CotMes = AsiMes .and. CotDia =AsiDia)
ifMonId <> “NS";
1 otherwise;
AsiMaxCot) = Max(CotDia, CotMes = AsiMes .and. CotDia <=AsiDia, 0 , CotImp)
if null (AsiFndCot);
0 otherwise;
Rules: Msg ("No existe Cotización, se toma la última ingresada")
if null (AsiFndCot) .and. MonId <> “NS";
1. Condiciones involucradas en una Fórmula Aggregate Select:
Condición de Búsqueda: Es la condición a la cual está sujeta la búsqueda.
Condición de Disparo: Es la condición que determina si la fórmula se ejecuta.
2. Inferencias en el caso de una Fórmula Aggregate Select:
La condición de búsqueda queda determinada por:
- La condición explicitada como segundo parámetro.
- Atributos que quedan instanciados por el ambiente en el que se dispara la Fórmula:
Intersección de la tabla extendida del atributo definido como fórmula (tabla
de partida) y la tabla sobre la cual se está resolviendo la fórmula (tabla de
llegada).
En el ejemplo:
Transacción de Cotizaciones:
Monid*
CotMes* Given: MonId
MonDsc
(CotDia*
CotImp)
Transacción de Asientos:
AsiNro*
AsiFch
AsiDia =Day(AsiFch)
(AsUdLin*
MonId
AsiImpME
AsiImpNS
AsiTipDH
CtaId
AsiFndCot) = Find(CotImp, CotMes = AsiMes .and. CotDia = AsiDia)
if MonId <> “S";
1 otherwise;
En la fórmula AsiFndCot, está implícita la condición de que Asiento1.MonId = Cotizad .MonId

37
Esto se refleja en la navegación como "Given: MonId"
1. Cómo se determina la tabla sobre la cual efectuar la búsqueda (tabla de llegada)
• Atributo de Búsqueda
• Atributos que están en la condición y que no pertenecen a la tabla extendida del Atributo Fórmula
• Atributo de Retomo
De otra forma:
<Atr.Fórm.> - Fórmula Inválida
Es importante aclarar que los atributos involucrados en la fórmula agrégate select y pertenecientes
a la tabla de llegada, deben estar ALMACENADOS en la misma. Es decir, que no pueden ser
fórmula ni pertenecer a la tabla extendida de la tabla de llegada.

38
4. Fórmulas Aggregate Select no pueden participar en fórmulas SUM y COUNT simples:
No se permite definir una fórmula SUM que suma un atributo que es una Aggegate/Select o
depende de ella.
Ejemplo:
FacProdPre = fórmula MAX
FacLinImp = FacLinCnt * FacProdPre
FacSubTot = SUM (FacLinImp)
Para resolver esto, se debería almacenar el valor de FacProdPre en otro atributo, pues las
Fórmulas Aggregate Select NO PUEDEN SER DEFINIDAS REDUNDANTES. O utilizar la regla
ADD en lugar del SUM vertical.
5. Dependencia física de las fórmulas Aggregate Select:
Las Fórmulas Aggregate Select dependen de la inserción, actualización o eliminación física del o
los registros que involucran.
EJEMPLO:
Transacción de Asientos
AsiNro*
AsiFch
AsiTotDeb = Sum(RengImp, RengTipDH="D", 0)
AsiTotHab = Sum(RengImp, RengTipDH="H", 0)
(Rengid*
MonCod
RengInpNS
RengImp
RengTipDH
CtaCod)
Dependen de la inserción: El COUNT vertical en caso de agregar o borrar una línea no recorre
toda la tabla de nuevo a diferencia del Count Aggregate/Select. Las fórmulas verticales cuentan o
suman los valores que están en "memoria". Las aggregate/select no.
Diferencias entre fórmulas aggregate select y fórmulas verticales:
1. Las fórmulas agg/sel actúan sobre cualquier tabla de la base de datos y las fórmulas verticales
solamente sobre tablas directamente subordinadas.
2. En las fórmulas agg/sel se pueden especificar condiciones de búsqueda. En las verticales no.
3. Las fórmulas verticales cuentan o suman los valores que están en “memoria”. Las aggregate/
select no.
4. Las fórmulas verticales cuentan o suman atributos que pueden ser fórmulas (pero esta fórmula
no puede ser agg/ sel ni involucrar en su definición una fórmula agg/sel).
Los atributos mencionados en las fórmulas aggregate/ select y pertenecientes a la tabla de llegada
deben estar ALMACENADOS FÍSICAMENTE en la tabla de llegada.
5. Las fórmulas agg/sel no se pueden definir como redundantes. Las verticales si.

39
COMINICACIÓN ENTRE OBJETOS:
Comunicación entre objetos GeneXus:
Una de las características importantes de los objetos de GeneXus es poder comunicarse entre
ellos o con otros programas externos. Un objeto GeneXus puede llamar o ser llamado por otro
objeto, intercambiando información entre ellos a través de parámetros que se declaran en cada
uno.
Reglas y Comandos para implementar la comunicación:
• CALL
• UDP (User defined Procedure)
• UDF (User defined Function)
Para implementar la comunicación entre objetos GeneXus (y "no GeneXus", es decir programas
externos) se disponen de los siguientes comandos o reglas:
CALL: Llama a un objeto o programa externo, permitiéndose pasar parámetros si éstos son
necesarios. Los parámetros especificados son de entrada/salida.
UDP, UDF: Se llama a un objeto GeneXus o a un programa externo, al cual se le pasarán los
parámetros necesarios y retomará un valor, que es resultado de la ejecución de dicho objeto o
programa.
La diferencia entre los UDP y UDF es que los programas llamados por la función UDF no deben
abrir ninguna tabla, mientras que los llamados por la función UDP sí lo hacen.
Esta diferencia existe SOLAMENTE en el generador Fxp 2.6 v VFP (en los demás generadores no
existe diferencia entre los udp y udf), las UDF al regresar no reabren/reposicionan las tablas, por lo
tanto no soportan que el programa llamado abra tablas. Por otro lado, el Call es un poco más
rápido. Las UDP restauran las tablas al volver y se usan para llamar a programas que abren tablas.
Cuál es la convención usada para el nombre de los objetos GeneXus en las llamadas?
Objeto Prefijo El nombre se trunca a:
Transacción T 7 caracteres
Procedimiento P 7 caracteres
Reportes R 7 caracteres
Work Panel W 7 caracteres
Menú M 7 caracteres
WebPaneIs H 7 caracteres
Los programas llamados con las reglas o comandos mencionados pueden ser cualquier objeto
GeneXus (Transacciones, Procedimientos, etc.), o un programa externo escrito por el usuario.
El nombre de dichos objetos a utilizar en la llamada (call, udp) se forma por un prefijo (identificando
el tipo de objeto) seguido por el nombre del objeto truncado de acuerdo a la tabla de más arriba.
En caso de que el objeto llamado sea un programa externo, debe mencionarse el nombre del
programa entre comillas; en caso de ser un objeto GeneXus va sin comillas.

40
Ejemplo:
Por ejemplo, si luego del ingreso de una Factura se quiere un listado de la misma, lo que habría
que poner en las Rules de la Transacción Factura es:
call(RlmpFac, FacNro) if insert .and. after(TRN);
Donde ImpFac es el nombre del Report que imprime la factura recibida como parámetro.
Call:
Sintaxis:
En regla de Transacciones:
call(nom-prog, par1,...,par2) if (condición);
En layout de los reports, program source de los procedures, eventos de Work Panel y eventos de
Transacciones:
if (condición)
call(nom-prog, par1,...,par2)
endif
La regla o comando Cali ejecuta el programa 'nom-prog', donde 'nom-prog' es el nombre de un
objeto GeneXus o un programa externo escrito por el usuario (según sea el caso hay que poner o
no al nombre entre comillas).
El momento del disparo del cali va a depender del lugar donde se encuentra. Si el call está en las
reglas de la transacción, se va a tomar en cuenta en el árbol de evaluación de las reglas. Si está en
el layout o program source de un reporte o procedimiento, o en los eventos (tanto de transacciones
como work-panels) se va a ejecutar proceduralmente en el lugar donde fue escrito.
Cali - Regla Parm:
La regla PARM tiene como función declarar los parámetros en el objeto llamado.
Sintaxis: Parm(atributo/ variable);
Ejemplo: call(PAltaCli, par1,... ,parn);
En las Rules de PAltaCli poner:
parm(par1,..., parn);
NOTA: Si en la regla parm se recibe en un atributo, se instancia el valor y no es posible cambiarlo
(noaccept implícito)
Con la regla PARM se declaran los parámetros que recibe un objeto GeneXus, estos parámetros
son posicionales, se deben escribir en el mismo orden, la misma cantidad y el mismo tipo que los
indicados en el CALL.
Los parámetros especificados en la regla parm, cuando se está invocando al objeto con el CALL,
son de entrada/salida.

41
Udp:
Sintaxis:
En reglas de Transacciones
<Att|&var> = Udp(nom-prog, par1,...,parm) if (condición);
En Fórmulas:
<Att> = Udp(nom-prog, parl,...,pam) if (condición);
En el layout de los reportes, y en los eventos de Work Paneis o Transacciones:
<&var> = Udp(nom-prog, par1,... ,pam)
En el program source de un procedimiento:
if (condición)
<Att|&var> = Udp(nom-prog, par1,.. .,parm)
endif
La Udp ejecuta el objeto o programa 'nom-prog' que retomará un valor que será asignado a un
atributo o a una variable dependiendo del caso.
Udp - Regla Parm:
El último parámetro en la regla parm es el valor de retorno.
Ejemplo:
parsal = udp(PA1taCli, par1,... , parn)
En las Rules de PA1taCli poner:
parm(par1,..., parm, parsal);
Al igual que en los programas llamados con call, en los programas llamados por UDPs se debe
declarar los parámetros con la regla Parm. A diferencia con los calls, el programa llamado siempre
va a tener un parámetro como mínimo (el parámetro de retomo).
Ejemplo:
Tenemos un procedimiento que calcula la calificación de un funcionario:
FunValCalificacion = Udp(PCalif,FunId, FunFchIngreso);
En el procedimiento PCalif, tenemos la siguiente regla parm:
parm( &funid, &funfching, &ValorRetorno );
Al terminar el cálculo, en el program source del procedimiento se asigna a la variable
&ValorRetorno el valor de la calificación del funcionario, y dicho valor es el devuelto por la llamada
y asignado al atributo FunValCalificacion.

42
Ejemplo:
FacImpDesc = udp(‘Tcaldto’, FacTot, FacCat)
En procedimiento PCaldto:
parm(&tot, &cat, &desc);
Parámetro de retorno
Los programas llamados se pueden considerar como funciones, ya que al ser llamados utilizando
UDP van a retomar un valor. Este valor que retoman es el último parámetro en la regla parm del
objeto llamado y no debe ser especificado en la invocación de la UDP.
En el ejemplo, se utiliza una función externa (por ser externa es que el nombre se pone entre
comillas) para calcular el descuento dado el total de una factura y la categoría del cliente.
Las Udps pueden ser utilizadas en las reglas de los objetos, en las fórmulas, en el program source
de procedimientos, en el layout de reportes, y en los eventos de transacciones o work-panels.
SUBRUTINAS:
Comando SUB:
Sintaxis:
Sub ‘RoutineName’
//cuerpo de la subrutina
EndSub
• No se permite el pasaje de parámetros.
• Todas las variables del programa fuente pueden ser usadas en la rutina 'RoutineName', es decir
que son globales.
• Disponible en Transacciones, Work Paneis, Reportes y Procedures.
Comando DO:
Sintaxis:
Do 'RoutineName’
Ejecuta la rutina 'RoutineName'.
Disponible en Transacciones, Work Paneis, Reportes y Procedures.

43
ÁRBOL DE EVALUACIÓN Y EVENTOS:
Árbol de Evaluación:
El conjunto de reglas y fórmulas han sido definidas sin especificar su secuencia de ejecución; pero
en el momento de generar el programa GeneXus deberá determinar esta secuencia.
GeneXus determina las dependencias existentes entre estas reglas y fórmulas, construyéndose
lógicamente un árbol de dependencia que determinará la secuencia de evaluación. Podemos
imaginar que el árbol se ejecuta de abajo hacia arriba, cada vez que cambia algún valor de un
atributo, se ejecuta todo lo que depende de este atributo.
Por ejemplo, si cambió la Cantidad se redispara el Importe de la línea, y a partir de esto el Sub-
Total, y el Descuento y el Total y la actualización del Total de compras del cliente. También
vinculado con la cantidad está el Stock, y se disparará también el Subtract correspondiente.
El árbol muestra claramente que debe especificarse:
error(‘No hay Stock Suficiente') if ArtStk < 0 ;
No es correcto definir:
error('No hay Stock suficiente') if FctCnt > ArtStk;
Esto no es correcto, pues decíamos que primero se dispara el SUBTRACT y luego el ERROR, o
sea que al momento de considerar el error, ya se disparó el subtract, y se disminuyó el stock.
Es importante mencionar que cuando se encuentra un error se desarma el Árbol de Evaluación,
dejándose todo en el estado anterior a producirse el error. El error detiene cualquier actualización a
la base de datos.
El árbol es en realidad una red pero donde no pueden haber ciclos, si los hubiera en algunos casos
se dispara con el valor anterior. Ejemplo: A = 1/A, se ejecuta en realidad con el valor anterior de A.
A = 1 / Old(A)

44
Alteraciones del orden de disparo de las Reglas:
En la mayoría de los casos el orden de ejecución de las reglas definido por GeneXus a partir de
nuestras especificaciones es el deseado. Pero en algunos casos puedo querer cambiar el
momento de disparo de una Rule.
Por ejemplo:
En las facturas que recibimos de nuestro proveedor queremos controlar que el total que viene
impreso en la factura (FctTotIng) sea correcto, por lo que lo calculamos nuevamente (FctTotCalc),
y emitimos un error si no es así.
Si construimos el árbol de evaluación vemos que las dependencias entre las reglas y fórmulas
determinan que cada vez que cambie el importe, se cambiará el total calculado que es parte de la
condición de la regla Error.
Esta condición se va a cumplir (total calculado o total ingresado) ya para la primera línea ingresada
en la factura y se va a disparar el error en ese momento y no podré seguir adelante.
En este caso la inferencia del árbol de evaluación no me sirve, lo que quiero en realidad es que se
me dispare el error cuando termine de ingresar las líneas (a la salida del nivel).
Entonces le marco el evento de disparo After(level(ArtCod))
Error('EI total ingresado no coincide con el total calculado') if (FctTotCalc <>
FctTotIng) .and. after(level(ArtCod));
Es importante mencionar que cuando se encuentra un error se desarma el Árbol de Evaluación,
dejándose todo en el estado anterior a producirse el error. El error detiene cualquier actualización a
la base de datos.
Estos casos no son muy frecuentes, pero se dan y hay que conocerlos.

45
A continuación se describirán cada una de estas funciones que permiten resolver casos como este,
en el que el momento que GeneXus definió para ejecutar la regla no es el deseado.
// INCORRECTO
Error('EI total de la factura no coincide con el ingresado') if FctTotIng <> FctTotCalc;
// CORRECTO
Error('EI total de la factura no coincide con el ingresado') if FctTotIng <> FctTotCalc .and.
after(level(ArtCod));
Funciones booleanas que permiten cambiar el momento de disparo de una regla:
Level( Atributo) Inserí
After( Atributo ) Update
After(Insert) Delete
After(Update)
After(Delete)
After(Confirm)
After(Level(Atributo))
After(Tm)
Son funciones lógicas que devuelven .T. or .F.
Level:
Sintaxis:
Level(Atributo)
Retoma True o False dependiendo del nivel en que se encuentre en la estructura el atributo
especificado.
Ejemplo: Call(‘Pxxx') if Insert .and. level(CliCod);
Si se mencionara un atributo como parámetro no sería necesario especificar el nivel ya que se
tomaría el nivel del parámetro.
Ejemplo: Call(‘Pxxx, CliCod') if Insert ;
After:
Sintaxis:
After(<Event>)
Donde <Event> puede ser:
<Att> | <Action> | Level(<Att>) | Tm | Confirm
After(Attribute):
Ejemplo:
A=B*C if After(C);
Ejecuta la regla después de aceptar el valor del atributo C.

46
La condición After(Att) tiene el mismo efecto que la condición Level(Att) en el entorno AS/400, ya
que la transmisión es a pantalla completa y no atributo a atributo como en PC.
Insert, Update, Delete:
Para condicionar el modo de disparo
After(Confirm):
Dispara la regla después de haber confirmado los datos del nivel asedado pero antes de haber
realizado la actualización.
After(lnsert)
After(Delete)
After(Update)
Se dispara después de haber insertado, actualizado o eliminado el registro de la tabla base del
nivel.
Ejemplo:
La siguiente transacción llama a un procedimiento que realiza la impresión de los datos de un
cliente. El procedimiento seteará el atributo CliSts, para indicar que se realizó la impresión.
Transacción Clientes:
CliCod* Código de Cliente
CliNom Nombre de Cliente
Clisés Status cliente
Llamadas al Procedimiento: es necesario precisar en que momento se debe disparar el llamado al
procedimiento.
Llamadas Incorrectas:
Caso 1:
Call('pficha', CliCod) if Insert .and. After(Confirm);
El cliente no existe, por lo que falla la lectura.
Caso 2:
Call(‘pficha', CliCod) if Update .and. After(Confirm);
El cliente ya existe, pero aún no se han grabado las modificaciones.
Llamadas Correctas:
call('pficha', CliCod) if After(lnsert);
call('pficha', CliCod) if After(Update);
call('pficha', CliCod) if After(Tm);
El cliente ya existe o ya se han grabado las modificaciones.
After(Tm):
Dispara la regla después de procesar todos los datos de la transacción, es decir, el primer nivel y
todos los subordinados.
En el AS/400 la regla es disparada después del commit.

47
Reglas que ocurren en el mismo evento:
Son disparadas en el orden en que fueron definidas
Ejemplo:
call(' ') if After(Tm);
call(' ') if After(Tm);
Ejemplo:
Call(‘pgmname’, CliCod, &flag) if After(Confirm);
Error(‘ ‘) if After(Confinn) .and. &flag = ‘N’;
Para CALLs, ERRORs, y MSGs, cuando se marca el evento de disparo, si dos Reglas ocurren en
el mismo evento y no dependen entre sí, vale el orden en el cual se definieron.
Ejemplo 1: Se ejecuta un Call y luego el otro
Ejemplo 2: Se quiere llamar a un procedimiento que realiza determinada validación, y que retorna
en la variable &flag, el resultado (S o N). En caso de que el resultado sea negativo se quiere
mostrar un mensaje de error.
call(pgmname, CliCod, &flag) if After(Confirm);
error(' ') if After(Confirm) .and. &flag = 'N';
Importante: Si se invierte el orden de estas reglas, y la validación resulta negativa, el error no se
dispara. Si en vez de ser un call fuera un udp donde el campo de salida fuera &flag, sí se
dispararía.
Ejemplo de transacción de dos niveles:
Level CabFac
Reglas stand-alone
Trasmit Screen
Evaluación de reglas y fórmulas según árbol
Confírm Screen
Reglas after(confirm)
Insert/Updatc/DeIcte
Reglas after(insert/update/delete)
Level LinFac
Trasmit Screen
Evaluación de reglas y fórmulas según árbol
Confinn Screen
after(confirm) .and. level( <att de 2do. Nivel>)
Insert/Update/Delete
Reglas after(insert/update/delete) .and. level(<att de 2do. Nivel>)
EndLevel
after( level (<att de 2do. Nivel>))
Commit
Evaluación de reglas after (tm)
EndLevel
Eventos en las Transacciones:

48
El código permanece ocioso hasta que ocurre un evento al cual está relacionado
Evento = Acción reconocida por un objeto y a la cual se le puede asociar un código ejecutable
Programación Dirigida por Eventos:
En las transacciones se permite la Programación Dirigida por Eventos, que es un estilo de
programación en el que existe código que permanece ocioso, hasta que es llamado para responder
a eventos, provocados en nuestro caso por el usuario, o por el sistema.
Los eventos son acciones que pueden suceder o no. Nosotros tendremos un código asociado a
cada evento posible, el cual se disparará sólo si el evento se produce. Por ejemplo, puede haber
un código asociado al evento de presionar una tecla (Por ejemplo <Enter>), que se activará cuando
el usuario decida presionar esa teda.
La programación dentro del evento sigue un estilo procedural.
Eventos explícitos en las Transacciones:
Evento Start
Evento ‘User-Event’
Evento AfterTrn
Evento Exit
Start: Es un evento del sistema y se da al comienzo del programa. Es normalmente usado para
asignar valores a variables.
User Defined Event: Es un evento definido por el usuario, que es activado una vez que se
selecciona una opción del menú o se presiona una tecla de función/botón.
After Tm: Es un evento del sistema y es activado una vez que la transacción ha terminado. Es
similar a la regla AFTER(TRN) usada en las transacciones.
Exit: Es un evento del sistema y es activado cuando el usuario abandona el programa.
Evento Start:
Sintaxis:
Event Start
EndEvent
Se ejecuta al principio del programa.
Ejemplo: Guardar el inicio de ejecución del programa
Event Start
&entrada=Time()
EndEvent
Generalmente es utilizado para la asignación de variables y parámetros que interesa evaluar una
sola vez en la ejecución del programa.

49
Ejemplo:
1.- Event Start
&Mes1= 'Enero'
EndEvent
2. - En el Evento Start de la transacción de Facturas:
Event Start
call(PFindCli,&today, CliCod)
EndEvent
Se instancia el Cliente. Se accede sólo a las Facturas de ese Cliente.
Si en el Evento Start de una transacción hay un call, los atributos que están en el call tienen el
mismo comportamiento que si se recibieran como parámetros. Es decir, que funcionan también
como filtro (se instancia).
En el ejemplo 2, al pasar como parámetro al CliCod se pueden ver sólo las Facturas del CliCod
pasado como parámetro. Queda instanciado el Cliente.
Eventos del Usuario:
Sintaxis:
Event 'User-event-name' <Key>
Level <att>
Endevent
Ejemplo:
Event 'Deuda Cliente' 2
Level FacId
if .not. null(CliId)
call(wdeucli, CliId)
endif
Endevent
Se ejecuta cuando el usuario presiona la tecla de función asociada o el botón correspondiente.
Level <att> - El evento se activa sólo si se encuentra en el nivel definido por el atributo.
Evento After Trn:
Sintaxis:
Event After tm
EndEvent
Ejemplo:
Event After tm
Retum
EndEvent

50
Equivalente a la función After(tm), pero permite agrupar todas las acciones que se deseen evaluar
en el after(tm) sin tener que condicionarlas por separado (rules).
Ejemplo:
Event After tm
retum
Endevent
Abandonar el programa una vez que se ejecutó un ciclo completo de la transacción.
Evento Exit:
Sintaxis:
Event Exit
………..
EndEvent
Se activa cuando el usuario abandona el programa.
Ejemplo:
Llamar a un procedimiento que graba la hora de entrada y salida del programa para cada
usuario en una tabla de control.
Event Exit
&user = userid()
&salida = Time()
call(‘pcontrol', &entrada, &salida, &user)
EndEvent
Rules / Eventos:
En caso de conflicto de evaluación entre reglas y eventos de una transacción, la regla se evalúa
primero.
Eventos: Rules:
Event After tm call(tvenfac,FctCod) if after(tm);
…….
return
End event
Ésta convención toma efecto cuando se presenta un conflicto en el momento de evaluación de las
reglas y eventos. Sólo el evento after trn presenta ese caso. El evento Start no entra en conflicto
con las reglas llamadas stand-alone ya que conceptualmente su evaluación son en diferentes
momentos. Las reglas stand-alone se evalúan en el primer nivel antes del despliego de la pantalla.
El evento Start se evalúa al comenzar el programa.
Ejemplos de uso de Eventos en las Transacciones:
1. Desplegar el nombre de la organización en la pantalla al comienzo de la transacción:

51
Event Start
&0rgnom = udp(PNombre, Orgcod)
Endevent
2. Imprimir una factura al presionar F7 o presionar el botón correspondiente.
Event 'Imprimir Factura’ 7
call(RPFac, FacNro)
Endevent
3. Podemos querer retomar al programa llamador una vez que la transacción haya sido ingresada:
Event After tm
Retum
Endevent
4. Para contar la cantidad de veces que una transacción ha sido invocada durante una sesión,
podemos programar los siguientes eventos:
Event Start
&Veces = 0
Endevent
Event After tm
&Veces = &Veces + 1
Endevent
Event Exit
&Msg = 'El número de transacciones grabadas:' + str(&Veces)
msg(&Msg)
Endevent
5. Por ejemplo, supongamos que en la transacción de facturas queremos dar la opción de
visualizar otras compras del cliente.
Definimos entonces un evento del usuario:
Event "Ver otras compras" 4
Call(wVerComp, CliCod)
Endevent
Cuando el usuario presione la tecla F4, llamaremos al work panel VerCompras' que mostrará las
otras compras del cliente.
Consideraciones:
• No se permite asignar valor a los atributos.
• Start-Exit Sin tabla base
• User Event-After(tm)—> Con tabla Base
Restricciones:
• No se permiten comandos asociados a otros eventos existentes en los work panels (load,
refresh, etc.).

52
A parte de estas restricciones, hay que tener en cuenta que los momentos de evaluación no están
asociados a modos de evaluación activos por lo que no son válidas tampoco las funciones
asociadas a los modos activos como Insert, Update , Delete y After(Event).
Para condicionar el disparo de eventos a los modos de ejecución activos debemos utilizarlos en
combinación con reglas.
Recomendaciones:
•Controlar mediante variables seteadas en las reglas que los eventos de usuario hagan calls en
situaciones válidas.
•Los eventos de usuario pueden evaluarse en cualquier momento, sin tener en cuenta el modo en
que está la transacción.
•Los atributos pasados como parámetros en los calls que se ejecutan en los eventos, son de
entrada/salida, por lo tanto pueden cambiar su valor instanciándose con el valor devuelto por el
programa llamado.
REPORTES Y PROCEDIMIENTOS:
Reportes y Procedimientos:
Reportes:
• Procesos no interactivos de consulta de la base de datos. Es decir, procesos no
interactivos de extracción de datos. Usualmente un reporte es un listado que se
envía a la impresora, aunque también puede ser visualizado por pantalla.
Procedimientos:
• Procesos no interactivos de actualización de la base de datos y subrutinas de uso
general. Podemos decir que son un superset de los reportes, ya que pueden hacer
todo lo que estos hacen y además actualizar la base de datos.
Características:
• Definición Procedural:
A diferencia de las transacciones donde las especificaciones se realizan en forma declarativa y
GeneXus resuelve en el momento de generar el programa la secuencia de ejecución, en los
reportes las especificaciones son realizadas en forma procedural.
• Definición sobre la Base de Conocimiento:
La gran potencia del lenguaje de reportes/procedimientos es que las definiciones se hacen sobre la
Base de Conocimiento y no directamente sobre el modelo físico. Esto nos permite utilizar
automáticamente todo el conocimiento ya incorporado o generado por GeneXus a partir de las
especificaciones realizadas. Por ejemplo el concepto de tabla extendida, que es posible porque
GeneXus conoce las relaciones entre las tablas de la Base de Datos. Otro ejemplo claro, es el caso
de los atributos fórmulas, donde aprovecharemos que GeneXus sabe como calcular el valor para
este atributo.
• Independencia de la Base de Datos, definición a nivel de atributos:
La definición de Reportes y Procedimientos se hace a nivel de atributos, en ningún momento
decimos qué tablas se deben recorrer ni qué índices se deben utilizar, sino que esto es
determinado por GeneXus en base a las especificaciones realizadas.

53
De esta manera logramos una real independencia de la base de datos, ya que en cualquier cambio
en las tablas será manejado automáticamente por GeneXus.
Comando For Each:
Sintaxis:
For Each [Order] [ Atr.. .Atr]
Where <Condition>
….
Where <Condition>
Defíned by <Attribute List>
….
Endfor
Toda la definición del acceso a la base de datos y la estructura del reporte o procedimiento se
realizan sólo con este comando. El acceso a la base de datos queda especificado por los atributos
que son utilizados dentro de un grupo FOR EACH - ENDFOR.
Order: Lista de atributos indicando el orden de recorrida de la tabla base. Sólo pueden
mencionarse atributos almacenados en la tabla base. El Order es opcional, en caso de no
especificarse se asume el orden de la clave primaria de la tabla base (si es que el for each no está
anidado a otro for each).
Elección del índice: GeneXus elige automáticamente el índice a utilizar para satisfacer el
orden, en caso de que no exista ninguno se crea uno en forma temporal.
Where: Establecen condiciones de filtro en la recorrida de la información. Se pueden mencionar
atributos de la tabla base y/o de la tabla extendida.
Defíned by: En el caso de que no se mencione ningún atributo secundario dentro del For Each,
debe utilizarse esta cláusula (mencionando algún atributo secundario de la tabla base que se
desea recorrer) para que GeneXus pueda determinar la tabla base a utilizar.
Debe quedar claro que el/los atributos mencionados en el defined by " participan" en la
determinación de la tabla base, así como también participan los atributos mencionados en todo el
For Each. Lo que ocurre es que si se utiliza cuando realmente es necesario, entonces dichos
atributos son los que determinan la tabla base.
Inferencia de las tablas utilizadas en el For Each:
• Determinadas automáticamente a través de los atributos del grupo For Each (Order , where,
defined by y cuerpo del For Each).
• GeneXus después de definir los atributos que participan determina una Tabla Base y su Tabla
Extendida.
• A partir de esto define la navegación.
GeneXus infiere la tabla base del for each, por los atributos mencionados en el order, where,
defined by y en el cuerpo del for each.
Tomemos como ejemplo un reporte con la siguiente definición:

54
En base a la definición realizada para el reporte, GeneXus genera el programa correspondiente
determinando automáticamente lo siguiente:
1. Que las tablas que el programa debe utilizar en el reporte son Client y Depart.
2. Que la tabla que debe recorrerse es Client.
3. Que debe accederse a la tabla Depart para complementar la información (obtener DptNom).
4. Que el orden de recorrido es CliCod y que el índice que debe usarse es el índice IClient.
Todo esto en base a una especificación que sólo incluirá los atributos a listar.
1. Cómo pudo GeneXus determinar qué tablas se utilizarán en el reporte ?
Para esto se debe determinar en que tablas están los atributos que se han mencionado dentro del
comando FOR EACH.
Con la base de datos en 3era Forma Normal podemos definir dos conceptos, atributos primarios y
secundarios:
Atributo Primario: Es aquel atributo que es parte de la clave primaria de alguna tabla del modelo.
El atributo puede pertenecer a varias tablas, como un atributo común o como parte de la clave. Por
ejemplo DptCod que es un atributo primario, está en las tablas de Client y Depart.
Atributo Secundario: Es aquel atributo que no es parte de la clave primaria de ninguna tabla del
modelo. El atributo puede pertenecer solamente a una tabla del modelo. Por ejemplo los atributos
secundarios CliNom, CliDir solo están almacenados en la tabla Client y DeptoNom solo está
almacenado en la tabla Depart.
Por esta razón, se puede determinar en que tabla está un atributo si es un atributo secundario.
Dado que en el FOR EACH hemos mencionado atributos secundarios de dos tablas Client y
Depart, éstas son las que deben usarse en el reporte, con lo cual hemos respondido la interrogante
planteada.
2. Cómo pudo GeneXus determinar qué tabla debe recorrer y qué otras tablas debe acceder para
complementar la información ?

55
GeneXus ha determinado que debe recorre la tabla Client y acceder a la tabla Depart para
complementar la información, lo que se informa en el diagrama de navegación del reporte.
Client (CliCod)
Depart (DptoCod)
Esto se puede realizar porque GeneXus, utilizando la base de conocimientos, puede saber cuales
son las relaciones que existen entre las tablas de la base de datos. Estamos en definitiva utilizando
nuevamente los conceptos de tabla base y tabla extendida.
El comando FOR EACH define una tabla base y una tabla extendida; en el ejemplo diremos que la
tabla de Client es la Tabla Base del FOR EACH y Depart pertenece a la Tabla Extendida de dicha
tabla base.
La tabla base es en definitiva la que se recorre y la tabla extendida a la que se puede acceder para
obtener otra información.
Repasemos los conceptos de tabla base y tabla extendida:
Toda tabla del modelo (tabla base), tiene información que le permite acceder a todas las tablas del
modelo con las cuales está relacionada. La Tabla Base define su Tabla Extendida con todas las
tablas que estén en una relación de cardinalidad N para 1 con dicha tabla. Es decir que para cada
instancia de la tabla base existe una única instancia de cada tabla de la tabla extendida.
Aplicando estos conceptos al ejemplo, vemos que la tabla de Clientes está en una relación de N
para 1 con la tabla de Departamentos:
Clientes Departamentos
Es decir que para cada instancia de la tabla de Clientes (Tabla Base) existe solo una instancia
correspondiente en la tabla de Departamentos, por lo que dicha tabla pertenece a su extendida.
Por el contrario, si consideramos como tabla base a la de Departamentos, para cada instancia de
esta tabla existen posiblemente varios Clientes (N) asociados. Entonces la tabla de Clientes no
pertenece a la extendida de Departamentos.
Es claro entonces que si mencionamos atributos de la tabla de Clientes y de la tabla de
Departamentos y tomando en cuenta la relación existente entre estas, (N para 1), la tabla elegida
como tabla base será Clientes.
GeneXus puede determinar esto automáticamente porque conoce la relación entre las tablas, y
puede entonces además saber cuales son las navegaciones válidas entre estas.
3. Qué orden y qué índices deben utilizarse?
El reporte se hará ordenado por Código de Cliente (CliCod) utilizando el índice IClient.
FOR EACH Client
Order: CliCod
índex: IClient
En la definición del listado se asume que será ordenado por la clave primaria de la tabla elegida
como tabla base del FOR EACH.

56
GeneXus conoce los índices de las tablas de la Base de Datos, y entonces puede elegir el índice a
utilizar para satisfacer este orden.
Es posible listar en un orden diferente utilizando la palabra clave Order del FOR EACH.
When None:
• Ejecutar determinado código, cuando en un For Each no se encuentra ningún registro.
• Sintaxis:
For each //clientes
Where (condiciones de filtro)
(proceso el cliente)
When none
Msg("ningún cliente cumple condiciones")
Endfor
El Msg se ejecuta sólo cuando no se entra en el For Each.
También se aplica a For Each [Selected] Line, XFor Each y XFor First, los cuales veremos más
adelante.
Importante: Si se incluyen For Eachs dentro del When None no se infieren Joins ni filtros de ningún
tipo con respecto al For each que contiene el When None ya que son considerados dos For Each
paralelos.
Report Wizard:
• Permite diseñar el layout de un reporte (o procedimiento) de una forma mucho más fácil.
• Se define a partir de una estructura de datos muy similar a las transacciones.
•El diseño del layout consiste en dos pasos:
1.- Requiere de una estructura de datos en la cual hay que incluir atributos definidos en las
transacciones. Dicha estructura es muy similar a la usada en las transacciones, sin
embargo, los paréntesis se usan para indicar niveles de For Each (en vez de niveles de
una transacción) y el asterisco (*) se usa para indicar el orden deseado (y no para indicar la
unicidad como en las transacciones). Las reglas que son usadas para definir la estructura
de una transacción también se aplican al describir la estructura del layout.

57
Una vez que se definió correctamente la estructura, se presiona el botón de "Next" para
pasar al siguiente paso.
2.- Permite definir otras características del layout. Se permite elegir los fonts para
representar los atributos o textos, también se permite definir si los cabezales de los
atributos para cada uno de los niveles se despliegan horizontalmente o verticalmente.
Presionando el botón de "Finish” se graban las definiciones para el paso actual y se sale
del diálogo del Report Wizard.
•El Wizard permite que los niveles tengan o no orden. El atributo que indica el orden no tiene
porqué ser el primero del nivel.
•Una vez que todas las opciones del Wizard fueron aceptadas, se genera el layout del reporte, el
cuál puede ser modificado como cualquier otro reporte. También es posible editar el Wizard
mediante la opción: Edit / Report/Proc. Wizard.
Los For Each se pueden definir en forma paralela o anidada. En el ejemplo hemos definido dos for
eachs paralelos. El primero recorrerá todas las facturas y el segundo todos los recibos.
For Each anidados:
Tres Casos:
• Tabla Base de los For Each distintas pero relacionadas por uno o varios atributos.
• Tabla Base de los For Each distintas y no existe ningún atributo relación entre las tablas
extendidas de los For Each.
• Tabla Base de los For Each es la misma: Corte de Control.
La tabla base queda determinada estudiando los atributos utilizados en el cuerpo del For Each en
el caso de los For Each principales (no anidados).
Para el caso de los For Each subordinados la tabla base queda establecida por los atributos
utilizados en el cuerpo del For Each siempre y cuando estos atributos no estén contenidos en la
tabla extendida del For Each principal. Si el conjunto de atributos utilizados en el For Each están
contenidos en la extendida ya calculada, el for each anidado tendrá la misma tabla base del for

58
Each principal. Este caso se distingue en el diagrama de navegación utilizando BREAK en lugar de
For Each para todo grupo For Each subordinado que no defina una nueva tabla base.
For Each Anidados (Caso 1):
Cuando se definen For Each anidados GeneXus intentará establecer que atributos en común
tienen ambas tablas extendidas (dándole prioridad a los atributos de la tabla base), y definirá que
estos atributos actuarán como condiciones de filtro en la recorrida de la tabla anidada.
En este ejemplo, la tabla base del primer for each es la de clientes, y la del segundo, la de facturas.
Ambas tablas están relacionadas por el atributo CliCod.
FOR EACH Client
Order: CliCod
Index: I00101
Navigation filters:
Start from: First record
Loop while: Not end of table
Client (CliCod)
FOR EACH Factur
Order: CliCod
Index: I00402
Navigation filters:
Start from: CliCod = CliCod
Loop while: CliCod = CliCod
Factur (FacNro)
ENDFOR
END FOR
For Each anidados (Caso 2):
Cuando tenemos que la tabla base de los For eachs son distintas y no existe ningún atributo que
las relacione, el resultado que obtenemos es el Producto Cartesiano de dichas tablas.

59
Producto Cartesiano: Para cada registro de la tabla base del primer For Each se recorre toda la
tabla asociada al For Each anidado.
Corte de Control (Caso 3):
Procesar información por grupos.
Ejemplo: Procesar facturas por cliente. Cada vez que cambia el cliente se define un nuevo grupo.
For Each Orden CliCod
(tabla Factura) orden - determina
For Each corte de control
(tabla Factura)
EndFor
EndFor Defined by, Print if detail
Corte de Control:
La resolución de este reporte puede hacerse accediendo únicamente a las facturas, recorriendo la
tabla ordenada por cliente. En este caso imprimiríamos solo aquellos clientes que tienen facturas.
De todas maneras es necesario utilizar dos for eachs, ya que se necesita una instancia de corte, es
decir un momento en el que se cambia de cliente y se puede operar en consecuencia, por ejemplo
imprimir el total facturado al cliente.
Lo interesante del caso dos for eachs tendrán como tabla base la tabla de facturas. Para lograr
esto se puede utilizar la cláusula DEFINED BY del For each o el comando PRINT IF DETAIL.
En el ejemplo podríamos mencionar un atributo de la tabla de facturas en el Defined by , con lo que
estaríamos diciendole explícitamente a GeneXus que utilizara esta tabla.
Si utilizamos Print if detail debemos definirlo en el primer For Each.
Se debe definir además en el orden de recorrida del primer for each (cláusula ORDER), los
atributos por los que se quiere realizar el corte (en el ejemplo CLICOD). Este es un requerimiento
debido a que GeneXus no podría saber cual es el criterio de agrupación que queremos ya que en
una misma tabla pueden ser varios, por ejemplo podríamos querer realizar el corte de control por
Fecha de factura, totalizando el total facturado cada día.
Debido a esto es que la definición de la cláusula Order es necesaria.
Para resumir, un corte de control queda definido de la siguiente manera:
Existen dos grupos FOR EACH anidados sobre la misma Tabla Base, los atributos de corte quedan
definidos por el conjunto de atributos especificados en el comando ORDER.
Para hacer un corte de control, necesitamos hacer una navegación de Facturas por Fecha.
Cuando ejecutemos este reporte, generará un índice temporal por fecha, sobre la tabla Facturas.
La navegación de un corte de control es la siguiente:
FOR EACH Factur
Order: CliCod
Navigation filters:
Start from:
First record

60
Loop while:
Not end of table
Factur (FacNro)
Client (CliCod)
BREAK Factur
Order: CliCod, FacNro
Navigation filters:
Loop while:
CliCod = CliCod
FacNro = FacNro
Factur (FacNro)
END BREAK
END FOR
La particularidad de esto es que el segundo For each se muestra como un BREAK.
Filtros en la navegación:
• Where
• Condition
• Parm(Atr... Atr) - Atributos recibidos como parámetros
Como filtrar la información a recuperar de la base de datos:
Muchas veces es necesario filtrar la información a incluir en el reporte, por ejemplo supongamos
que el reporte deberá listar sólo aquellos clientes cuyo código esté comprendido en un rango
determinado.
Para resolver esto, tenemos dos opciones:
* El uso de condiciones (ítem Conditions)
* El uso de la cláusula where en el FOR EACH
La única diferencia entre usar Conditions o la cláusula Where, es que la primera es global para
todos los FOR EACH que definamos en el layout y la segunda se cumple sólo para el FOR EACH
donde fue definida. La performance es la misma en ambos casos. Debemos escoger una de las
dos opciones.
La regla PARM( ):
La utilización de atributos en la regla PARM( ) determina una condición por igual global para todo el
reporte o procedimiento.
Ejemplo: PARM(CliCod).
For Each
[CliCod] [CliNom]
Endfor
El reporte sólo podrá acceder al cliente cuyo código sea igual al recibido como parámetro.

61
Diseño de la salida:
MT [nlínea]: nlíneas es el número de línea en el que se quiere empezar a imprimir el listado. En
caso de no especificarse un valor se asume el valor por defecto que es 0.
MB [nlínea]: nlíneas es el número de líneas que se desea dejar como margen inferior. En caso de
no especificarse un valor se asume el valor por defecto que es 6.
PL [nlínea]: Setea el largo de página. El número de líneas que será impreso es el número
especificado menos el margen de abajo (valor por defecto es 6).
Ejemplo: PL 66
Setea el largo de página a 66 líneas, aunque sólo 60 líneas serán impresas en el
form, con un margen inferior de 6 líneas.
CP [nlínea]: Si queda en la página actual un número de líneas mayor o igual al número
especificado, continúa imprimiendo en la misma página. De lo contrario, pasa a imprimir en la
próxima página (fuerza a un salto de página).
Lineno [nlínea]: Define el número de línea donde va a ser impresa la siguiente línea. Si el número
de línea actual es mayor al número especificado, entonces, la línea será impresa en la próxima
página.
Eject: Fuerza a un salto de página.
Noskip: Tiene que estar inmediatamente después de un printblock. Si el comando se encuentra
entre dos líneas, este comando las imprimirá en la misma línea.
Report Viewer:
• Permite:
- Imprimir
- Visualizar el reporte mientras se está generando
- Paginado

62
- Zoom
- Salvado a un archivo
- Find
• En las preference del modelo se indica si se desea o no utilizar el report viewer.
Los listados se pueden salvar a archivos, almacenándose en archivos de extensión *.gxr.
Para visualizar reportes anteriores se debe invocar al Report Viewer para poder desde éste hacer
un File/Open del archivo que contiene el reporte listado anteriormente.
El Report Viewer se abre automáticamente cuando se ejecuta cualquier reporte, o se puede
ejecutarlo Standalone ejecutando el utilitario GxRView.
PROCEDIMEINTOS:
Inserción de registros:
Ejemplo: Inserción en tabla de resumen de ventas anuales
Tabla: CliCod*
VtaAno*
VtaTot
New
CliCod = &CIiCod
VtaAno = &Ano
VtaTot = &Total
When Duplicate
For each
VtaTot = VtaTot + &Total
Endfor
EndNew
New: Permite dar altas en una tabla de la base de datos. Siempre se ejecuta por clave primaria.
Cuando hacemos una inserción en una tabla, GeneXus controla que no hayan claves duplicadas.
Si quisiéramos aplicar un tratamiento especial para estos casos, podemos usar el comando When
Duplícate para decir que acción tomar cuando se detecta que el valor de la clave en un alta ya
existe en la tabla correspondiente.
Actualización:
For Each
Atr = <Exp> Actualiza atributo de la tabla extendida
............
Endfor
La actualización se realiza en el EndFor.
Los atributos actualizables dentro de un grupo For Each, son todos los pertenecientes a la tabla
extendida.
La actualización física se realiza cuando se encuentra el EndFor del grupo For Each
correspondiente.

63
Delete:
For Each
defined By FacFch
Delete sólo Tabla Base
endFor
La ejecución real del comando se produce cuando se encuentra el Delete y no cuando se llega al
EndFor.
La eliminación de registros de la tabla base dentro de un grupo For Each se hace mediante el
comando DELETE.
Restricciones:
• No se realiza control de integridad referencial
• No Actualiza atributos definidos como redundantes
En los procedimientos, el control de Integridad Referencial queda a cargo del diseñador, lo que no
ocurre en las transacciones.
Las fórmulas redundantes no se actualizan, hay que calcularlas y actualizarlas en forma manual.
Consideraciones:
•Si no incluimos la clave primaria en el New, ese New se realiza con valor nulo de clave.
•Si no incluimos atributos secundarios pueden pasar dos cosas:
1. Estos quedan nulos, en caso de no estar anidado el New…
2. Si el New está dentro de un For Each con la misma tabla base del New, los atributos
instanciados por el For Each y no mencionados en el New son inferidos para la inserción
del registro.
WORK PANELS:
Work Panels:
• Definir consultas interactivas a la base de datos.
• Es muy flexible por lo que se presta para múltiples usos.
Es especialmente útil para usuarios que usan el computador para tomar decisiones
Diferentes tipos de Paneles:
- Entry Panel
- Display Panel
- Single Choice Selection List
- Múltiple Choice Selection List
- Action List

64
Las normas Common User Acces de IBM definen diversos tipos de pantallas, estandarizando los
diálogos con el usuario.
Entry Panel - Panel de Entrada (Paneles de Entrada):
Son paneles de entrada/salida. A través de ellos se aceptan y se despliegan valores. Por ejemplo,
un panel de entrada puede ser una pantalla previa a una impresión, donde se piden los parámetros
necesarios para la misma y luego se llama a un Report.
Display Panel - Panel de Salida (Paneles de Despliegue):
Son un caso particular de Paneles de Entrada, donde los datos pueden ser solamente exhibidos.
Un panel de despliegue puede ser una pantalla plana o puede mostrar una cantidad variable de
datos. Esto último, consiste en mostrar varias líneas por pantalla permitiendo que el usuario se
desplace hacia arriba y hacia abajo (scrolling).
Selección Única/Selección Múltiple/Listas de Acción:

66826033 diseno-de-aplicaciones-gene xus-apunte-1

66826033 diseno-de-aplicaciones-gene xus-apunte-1

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (9)

Similar a 66826033 diseno-de-aplicaciones-gene xus-apunte-1

Similar a 66826033 diseno-de-aplicaciones-gene xus-apunte-1 (20)

Último

Último (16)

66826033 diseno-de-aplicaciones-gene xus-apunte-1