Manual de Genexus

GeneXus

Visión General Modificado Febrero, 2003

Copyright 1989 – 2003 ARTech, all r ights reserved

MONTEVIDEO – URUGUAY Av. 18 de Julio 1645 P.4 - (5982) 402 2082 CHICAGO – USA 400 N. Michigan Ave. Suite 1600 - (1312) 836 9152 CIUDAD de MÉXICO – MÉXICO Mariano Escobedo 353 A Of. 701 - (5255) 5255 4733 SÃO PAULO – BRASIL Rua Samuel Morse 120 Conj. 141 - (5511) 5502 6722

Página 2 de 14

Tabla de Contenido I NTRODUCCI ÓN ........... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

EL PROBLEMA TEÓRI CO ........... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 METODOLOGÍ AS TRADI CI ONALES DE DESARROLLO Y PROBLEMAS ASOCI ADOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 METODOLOGÍ A I NCREMENTAL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

UNA I MPLEMENTACI ÓN DEL DESARROLLO I NCREMENTAL: GENEXUS . . . . . . . . . . . . . . . . . . . . . 6 DI SEÑO. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 PROTOTI PO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10 I MPLEMENTACI ÓN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11 MANTENI MI ENTO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11

I m pacto de los cam bios sobre la base de datos: ......... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11 I m pacto de los cam bios sobre los program as: ......... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12

DOCUMENTACI ÓN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12 CONSOLI DACI ÓN DE VARI AS APLI CACI ONES Y REUTI LI ZACI ÓN DE CONOCI MI ENTO. . . . . . . . . . . . . . . . . . . . . . . . . . .12

CARACTERÍ STI CAS ÚNI CAS DE GENEXUS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 3

¿QUI ÉNES SON LOS USUARI OS DE GENEXUS? ........... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 3

Página 3 de 14

Introducción

GeneXus es una herram ienta inteligente, desarrollada por ARTech , cuyo objet ivo es asist ir al analista y a los usuarios en todo el ciclo de vida de las aplicaciones.

El diseño y protot ipo son realizados y probados en un am biente Windows. Cuando el protot ipo es totalm ente aprobado por sus usuarios, la base de datos y los program as de aplicación son generados y/ o m antenidos en form a totalm ente autom át ica, para el am biente de producción.

La idea básica de GeneXus es autom at izar todo aquello que es autom at izable: norm alización de los datos y diseño, generación y m antenim iento de la base de datos y de los program as de aplicación. De esta m anera se evita que el analista deba dedicarse a tareas rut inarias y tediosas, perm it iéndole poner toda su atención en aquello que nunca un program a podrá hacer: entender los problem as del usuario.

Com o un subproducto, GeneXus ofrece una docum entación r igurosa, autosuficiente y perm anentem ente actualizada.

Este docum ento t iene com o objet ivo ilust rar al lector sobre GeneXus y los problem as que resuelve.

Contenido de las siguientes secciones:

• El problem a teórico - en este capítulo se hace una descripción com parada de las m etodologías t radicionales de desarrollo de sistem as y el desarrollo increm ental.

• Una im plem entación del desarrollo increm ental: GeneXus. • Característ icas únicas de GeneXus. • Quienes son los usuarios de GeneXus

Página 4 de 14

El problema teórico

Metodologías tradicionales de desarrollo y problemas asociados

La form a t radicional de desarrollar aplicaciones parte de una prem isa básica: es posible construir un m odelo de datos estable de la em presa . Basándose en esa prem isa, la prim era tarea que se encara es el análisis de datos, donde se estudia la realidad en form a abst racta y se obt iene com o producto el m odelo de datos de la em presa. La segunda tarea es diseñar la base de datos. Es m uy sencillo diseñar la base de datos part iendo del m odelo de datos ya conocido.

Una vez que se ha estudiado la realidad desde el punto de vista de los datos, se hace lo propio desde el punto de vista de las funciones (análisis funcional) . Sería deseable que el estudio de la realidad tuviera com o producto una especificación funcional que dependiera sólo de dicha realidad. Lo que se hace en las m etodologías m ás usadas, sin em bargo, es obtener una especificación funcional que se refiere a los archivos de la base de datos (o bien a las ent idades del m odelo de datos, lo que es esencialm ente equivalente) .

Una vez que se t iene la base de datos y la especificación funcional, se pasa a la im plem entación de las funciones, exist iendo t radicionalm ente para ello varias opciones ( lenguajes de 3ª . o 4ª generación, generadores, interpretadores) .

Sin em bargo, todas las form as de im plem entación vistas t ienen un problem a com ún: parten de la enunciada prem isa: es posible construir un m odelo de datos estable de la em presa , y esta prem isa es falsa .

Realm ente no es posible hacer, de una form a abst racta, un m odelo de datos detallado de la em presa y con el suficiente nivel de detalle y objet ividad, porque nadie la conoce com o un todo.

Por ello es necesario recurrir a m últ iples interlocutores, y cada uno de ellos proyecta sobre el m odelo, su propia subjet ividad. Una consecuencia de esto es que, durante todo el ciclo de vida de la aplicación, se producen cam bios en el m odelo.

Pero aún si se considerara la situación ideal, donde se conocen exactam ente las necesidades y, entonces, es posible definir la base de datos ópt im a, el m odelo no podrá perm anecer estát ico porque deberá acom pañar la evolución de la em presa

Todo esto sería poco im portante, si la especificación funcional y la base de datos fueran independientes. Sin em bargo, dado que la especificación funcional se refiere a la base de datos, las inevitables m odificaciones en ésta im plican m odificaciones (m anuales) en aquella.

La m ayor consecuencia de lo anterior está const ituida por los m uy altos costos de m antenim iento: en la m ayoría de las em presas que t rabajan de una m anera convencional se adm ite que el 80% de los recursos que teóricam ente están dest inados al desarrollo, realm ente se ut ilizan para hacer m antenim iento de las aplicaciones ya im plem entadas.

Cuando se t rata de aplicaciones grandes la situación es aún peor: este m antenim iento com ienza m ucho antes de la im plem entación, lo que hace que los costos de desarrollo crezcan en form a hiperlineal con respecto al tam año del proyecto.

Página 5 de 14

Dado que es m uy difícil, en este contexto, determ inar y propagar las consecuencias de los cam bios de la base de datos sobre los procesos, es habitual que, en vez de efectuarse los cam bios necesarios, se opte por int roducir nuevos archivos redundantes, con la consiguiente degradación de la calidad de los sistem as y el increm ento de los costos de m antenim iento.

Metodología incremental

Una m anera alternat iva de resolver el problem a pasa por la sust itución de la prem isa básica enunciada: asum ir que no es posible construir un m odelo de datos estable de la em presa y, en cam bio, ut ilizar una filosofía increm ental.

Un esquem a increm ental parece m uy natural: no se encaran grandes problem as, sino que se van resolviendo los pequeños problem as a m edida que se presentan.

¿Cuál será la repercusión de este t ipo de esquem a sobre los costos de m antenim iento?.

Si se ut ilizaran, con este enfoque, las m etodologías anteriorm ente reseñadas, esa repercusión sería m uy grande: el m odelo de datos se m odificaría constantem ente y los costos de m antenim iento serían aún m ucho m ayores que los enunciados.

Puede verse, sin em bargo, lo siguiente:

No se conoce la base de datos pero, cada usuario, conoce m uy bien las visiones de los datos que él ut iliza cot idianam ente.

Esas visiones de los datos pueden ser de varios t ipos: pantallas, listados, etc. que com ponen el aspecto exterior de la aplicación: Aquello que es tangible para el usuario.

¿Cóm o puede ayudar el conocim iento de estas visiones a obtener el m odelo de datos?

¿Puede t ransform arse el asunto en un problem a m atem át ico?. Si ello fuera posible, la m atem át ica podría brindar una am plia gam a de recursos para ayudar a resolverlo autom át icam ente y, com o consecuencia, se sim plificaría m ucho la tarea del analista. Una reflexión interesante es la siguiente: si se conociera la base de datos, las visiones de los datos que t ienen los diferentes usuarios deberían poder derivarse de ella. O, dicho de ot ra m anera, la base de datos debe sat isfacer a todas las visiones conocidas. Puede dem ost rarse que, dado un conjunto de visiones de datos de usuarios, existe siem pre una base de datos m ínim a que las sat isface, la cual, adem ás, es única. En este estado, el problem a se ha t ransform ado en un problem a m atem át ico y, entonces es preciso resolverlo, para hallar esa base de datos.

Pero, ¿cóm o se im plem enta esta teoría?.

Se t rata de capturar el conocim iento que existe en las visiones de los usuarios, y sistem at izarlo en una base de conocim iento. La característ ica fundam ental de esta base de conocim iento, que la diferencia de los t radicionales diccionarios de datos, es su capacidad de inferencia: se pretende que, en cualquier m om ento, se puedan obtener de esta base de conocim iento, tanto elem entos que se han colocado en ella, com o cualquier ot ro que se pueda inferir a part ir de ellos.

Página 6 de 14

Si este objet ivo se logra, la base de datos y los program as de aplicación pasan a ser t ransform aciones determ iníst icas de dicha base de conocim iento y ello perm ite:

x Generarlos autom át icam ente.

x Ante cam bios en las visiones de los usuarios:

Determ inar el im pacto de dichos cam bios sobre datos y procesos

Propagar esos cam bios generando:

⇒ los program as necesarios para convert ir los datos;

⇒ los program as de la aplicación afectados por los cam bios.

Una implementación del desarrollo incremental: GENEXUS

GeneXus im plem enta esta teoría.

Cuando una aplicación se desarrolla con GeneXus la prim era etapa consiste en hacer el Diseño de la m ism a regist rando las visiones de usuarios (a part ir de las cuales el sistem a captura y sistem at iza el conocim iento) .

Posteriorm ente se pasa a la etapa de Protot ipación en donde GeneXus genera la base de datos (est ructura y datos) y program as para el am biente de protot ipo. Una vez generado el Protot ipo debe ser puesto a prueba por el analista y los usuarios.

Si durante la prueba del Protot ipo se detectan m ejoras o errores se retorna a la fase de Diseño, se realizan las m odificaciones correspondientes y se vuelve al Protot ipo. Llam arem os a este ciclo de Diseño/ Protot ipo.

Una vez que el Protot ipo está aprobado, se pasa a la etapa de Im plem entación, en donde GeneXus genera, tam bién autom át icam ente, la base de datos y program as para el am biente de producción.

En resum en, una aplicación com ienza con un Diseño, luego se Protot ipa, luego se Im plem enta y en cualquiera de los pasos anteriores se puede regresar al Diseño para realizar m odificaciones.

Página 7 de 14

A cont inuación se detalla cada una de estas tareas:

Diseño Esta tarea es realizada conjuntam ente por el analista y el usuario, y consiste en ident ificar y describir las visiones de datos de los usuarios.

El t rabajo se realiza en el am biente del usuario. Este esquem a perm ite t rabajar con un bajo nivel de abst racción, ut ilizando térm inos y conceptos que son bien conocidos por el usuario final.

Una consecuencia m uy im portante, es que la act itud del usuario se t ransform a en francam ente part icipat iva. El sistem a pasa a ser una obra conjunta y, com o el usuario sigue perm anentem ente su evolución, su calidad es m ucho m ejor que la habitual.

De acuerdo a lo visto, GeneXus captura el conocim iento por m edio de visiones de objetos de la realidad del usuario.

Los t ipos de objetos soportados por GeneXus son: Transacciones, Reportes, Procedim ientos, W ork Panels, W eb Objects, Menúes, Data View s, Styles y Transacciones de Data W arehouse .

La tarea de diseño consiste, fundam entalm ente, en ident ificar y describir estos objetos. A part ir de estas descripciones, y autom át icam ente, GeneXus sistem at iza el conocim iento capturado y va const ruyendo, en form a increm ental, la Base de Conocim iento.

Esta Base de Conocim iento es un repositorio único de toda la inform ación del diseño, a part ir de la cual GeneXus crea el m odelo de datos físico ( tablas, at r ibutos, índices, redundancias, reglas de integridad referencial, etc.) , y los program as de aplicación.

Así, la tarea fundam ental en el análisis y diseño de la aplicación se cent ra en la descripción de los objetos GeneXus.

Veam os en detalle las clases de objetos GeneXus m ás im portantes:

Transacciones

Página 8 de 14

Una t ransacción es un proceso interact ivo que perm ite a los usuarios crear, m odificar o elim inar inform ación de la base de datos.

Ejem plos:

Pantalla para crear, m odificar o elim inar los Clientes de la Em presa.

Pantalla de facturación: proceso que perm ite a un usuario crear facturas e incluso im prim ir las.

Una pantalla perm ite al usuario tom ar diferentes acciones com o insertar, actualizar, elim inar, im prim ir sin tener que volver al m enú para hacerlo.

Reportes Un inform e es un proceso que perm ite visualizar los datos de la base de datos. La salida del listado puede ser enviada a pantalla o a la im presora (y con ello tenem os un listado convencional) .

Con este objeto se pueden definir desde listados sim ples (por ejem plo, listar los clientes) hasta m uy sofist icados, en donde existan varios cortes de cont rol, m últ iples lecturas a la base de datos y param et rización.

Sin em bargo un Inform e no puede actualizar la base de datos.

Procedimientos Este objeto t iene todas las característ icas de los Reportes, y adem ás perm ite actualizar la base de datos. Los Procedim ientos son com únm ente usados para dos t ipos de procesos:

x Procesos batch de actualización. Por ejem plo: elim inar todas las facturas de fecha anterior a una fecha dada y que ya fueron pagadas.

x Subrut inas de uso general. Por ejem plo: rut ina de m onto escrito en donde, dado un im porte se devuelve un literal con el im porte en let ras (1010 = > 'Mil diez')

x Procesos a ejecutar en un servidor de aplicaciones o servidor de base de datos: procesos (generalm ente escritos en C/ SQL, Java o .NET) para una Mult i Tier Architecture, para ser ejecutados en un servidor de aplicaciones o de bases de datos.

Work Panels Un Work Panel es una pantalla que perm ite al usuario realizar consultas interact ivas a la base de datos. Cuanto m ás los usuarios ut ilizan el com putador para su t rabajo, se torna m ás necesaria la ut ilización de diálogos sofist icados, que le perm itan sentarse a pensar frente al m ism o.

Los work panels perm iten diseñar este t ipo de diálogos del usuario.

Por ejem plo: Un work panel que m uest ra la lista de clientes y que perm ite (a elección del usuario) ver cuales son sus facturas o su deuda.

Web Objects Son sim ilares al conjunto de Work Panels y Transacciones, pero son usados en browsers en am biente Internet / I nt ranet / Ext ranet .

Menúes

Página 9 de 14

Un m enú es una pantalla que cont iene una serie de opciones fij as que el usuario selecciona para ejecutar.

Data Views Perm iten considerar correspondencias ent re tablas de bases de datos preexistentes y tablas GeneXus y t ratar aquellos con la m ism a inteligencia com o si fueran objetos GeneXus.

Styles El estandarizar lo m ás posible una aplicación es un reconocido buen criterio de diseño. En part icular, la interfaz de usuario de una aplicación resulta crít ica para const ruir sistem as am igables. Cuanto m ás estándar sean los diálogos, m ás fácil de usar será la aplicación.

Los Styles const ituyen un t ipo de objeto GeneXus orientado a la definición de interfaces de usuario y estándares de program ación. Los Styles ofrecen una serie de m ecanism os para definir form atos de pantallas, reglas del negocio y eventos que serán ut ilizados luego por GeneXus en form a autom át ica, obteniendo sistem as de m ayor calidad y dism inuyendo sensiblem ente los t iem pos de desarrollo.

GeneXus trabaja con el conocimiento puro Part iendo de los objetos descritos, el m odelo de datos físico es diseñado con base en la Teoría de Bases de Datos Relacionales, y asegura una base de datos en tercera form a norm al (sin redundancia) . Esta norm alización es efectuada autom át icam ente por GeneXus.

El analista puede, sin em bargo, definir redundancias que, a part ir de ello, pasan a ser adm inist radas (cont roladas o propagadas, según corresponda) , autom át icam ente por GeneXus.

El repositorio de GeneXus m ant iene las especificaciones de diseño en form a abst racta, o sea que no depende del am biente objeto, lo que perm ite que, a part ir del m ism o repositorio, se puedan generar aplicaciones funcionalm ente equivalentes, para ser ejecutadas en diferentes plataform as.

Múltiples Plataformas / Arquitectura de Múltiples Capas Com o consecuencia de lo anterior es posible, por ejem plo, que un usuario de una aplicación IBM AS/ 400 cent ralizada desarrollada 100% con GeneXus, pueda hacerla funcionar total o parcialm ente en un am biente JAVA o .NET sin tener que m odificar los objetos originales.

Por ot ra parte, las especificaciones funcionales son totalm ente independientes de la base de datos, por lo que se m ant ienen válidas aún luego de cam bios en ésta. Esta propiedad perm ite que GeneXus pueda m antener autom át icam ente todos los program as que genera.

Página 10 de 14

Hoy es com ún que una m ism a aplicación debe tener algunas partes corriendo en una plataform a y alguna en ot ras, y que todas se puedan com unicar correctam ente.

El desarrollo con GeneXus perm ite que una aplicación pueda ser dividida para ser ejecutada en diferentes plataform as y generada, para cada una, en el lenguaje m ás adecuado, obteniendo así arquitecturas de m últ iples partes (m ult i- t ier) y que hagan un m ejor uso de los recursos disponibles.

Prototipo En las tareas de diseño están im plícitas las dificultades de toda com unicación hum ana:

x El usuario olvida ciertos detalles;

x El analista no tom a nota de algunos elem entos;

x El usuario se equivoca en algunas apreciaciones;

x El analista interpreta m al algunas explicaciones del usuario.

Pero, adem ás, la im plem entación de sistem as es, habitualm ente, una tarea que insum e bastante t iem po, por lo que:

x Com o m uchos de estos problem as sólo son detectados en las pruebas finales del sistem a, el costo ( t iem po y dinero) de solucionarlos es m uy grande;

x La realidad cam bia, por ello, no es razonable pensar que se pueden congelar las especificaciones m ient ras se im plem enta el sistem a;

x la consecuencia de la congelación de las especificaciones, es que se acaba im plem entando una solución relat ivam ente insat isfactoria.

El im pacto de estos problem as dism inuiría m ucho si se consiguiera probar cada especificación, inm ediatam ente, y saber cual es la repercusión de cada cam bio sobre el resto del sistem a.

Una prim era aproxim ación a esto, ofrecida por diversos sistem as, es la posibilidad de m ost rar al usuario form atos de pantallas, inform es, etc. anim ados por m enúes. Esto perm ite ayudar al usuario a tener una idea de qué sistem a se le const ruirá pero, posteriorm ente, siem pre se presentan sorpresas.

Una situación bastante diferente sería la de poner a disposición del usuario para su ejecución, inm ediatam ente, una aplicación funcionalm ente equivalente a la deseada, hasta en los m ínim os detalles.

Esto es lo que hace GeneXus: Un protot ipo GeneXus es una aplicación pronta, funcionalm ente equivalente a la aplicación de producción.

La diferencia ent re protot ipación y producción consiste en que la prim era se hace en un am biente de m icrocom putador, m ient ras que la producción se realiza en el am biente objeto del usuario ( IBM iSeries, Cliente / Servidor, JAVA, .NET) .

El protot ipo perm ite que la aplicación sea totalm ente probada antes de pasar a producción. Durante estas pruebas, el usuario final puede t rabajar con datos reales, o sea que prueba, de una form a natural, no solam ente form atos de pantallas, inform es, etc. sino tam bién fórm ulas, reglas del negocio, est ructuras de datos, etc.

La filosofía de GeneXus es de desarrollo increm ental. Cuando se t rabaja en un am biente t radicional, los cam bios en el proyecto hechos durante la im plem entación y, sobre todo, aquellos que son necesarios luego de que el sistem a está im plantado, son m uy onerosos. GeneXus resuelve este problem a: const ruye la aplicación con una m etodología de

Página 11 de 14

aproxim aciones sucesivas que perm ite, una vez detectada la necesidad de cam bios, protot iparlos y probarlos inm ediatam ente por parte del usuario, sin costo adicional.

Implementación GeneXus genera autom át icam ente el código necesario para:

x Crear y m antener la base de datos;

x Generar y m antener los program as para m anejar los objetos descritos por el usuario.

Los am bientes y lenguajes actualm ente soportados son:

Múlt iples plataform as:

� Servidores con Sistem as Operat ivos: IBM OS/ 400, UNIX, LINUX, Windows NT/ 2000 Servers.

� Sistem as de Gerencia de Base de Datos: IBM DB2 UDB, Inform ix, Oracle, Microsoft SQL Server.

� Lenguajes: Java, C# , Visual Basic, C/ SQL, RPG, etcétera.

� I nternet : C# , JAVA, Visual Basic (ASP) , C/ SQL, HTML.

� W eb Servers: Microsoft I IS, Apache, WebSphere.

Múlt iples arquitecturas: Cent ralizada ( iSeries) , Cliente/ Servidor de dos o t res capas, Sistem as dist r ibuidos en m últ iples capas en .NET, Mult i Servidor orientada a Internet , I nt ranet , Ext ranet , Data Warehouse y Workflow para todos los servidores soportados.

Nuevas plataform as de ejecución : JAVA, Microsoft .NET.

Mantenimiento Esta es quizás la característ ica m ás im portante de GeneXus, y la que lo diferencia de m anera m ás clara de sus com pet idores: el m antenim iento, tanto de la base de datos (est ructura y contenido) com o de los program as, es totalm ente autom át ico.

A cont inuación se explicará el proceso de m antenim iento, ante cam bios en la descripción de algún objeto GeneXus (visión del usuario) :

Impacto de los cambios sobre la base de datos:

Análisis de im pacto:

Una vez descritos los cam bios de las visiones de usuarios, GeneXus analiza autom át icam ente cual es el im pacto de los m ism os sobre la base de datos y produce un inform e donde explica com o debe hacerse la conversión de los datos y, si cabe, qué problem as potenciales t iene esa conversión ( inconsistencias por viejos datos ante nuevas reglas, etc.) . El analista decide si acepta el im pacto y sigue adelante o no.

Página 12 de 14

Generación de program as de conversión:

Una vez que los problem as han sido solucionados o bien se ha aceptado la conversión "default " , que GeneXus realiza en form a estándar, se generan autom át icam ente los program as para hacer la conversión (est ructura y contenido) de la vieja base de datos a la nueva.

Ejecución de los program as de conversión:

A cont inuación, se pasa al am biente de ejecución que corresponda (protot ipo, producción Internet , producción Cliente / Servidor, etc.) y se ejecutan los program as de conversión.

Impacto de los cambios sobre los programas: Análisis de im pacto:

A cont inuación, GeneXus analiza el im pacto de los cam bios sobre los program as, y produce un diagnóst ico inform ando qué program as deben generarse o re-generarse y proporcionando tam bién, para el nuevo program a, o bien el diagram a de navegación o bien un pseudo-código, a elección del analista.

Generación de nuevos program as:

A cont inuación el sistem a genera o regenera autom át icam ente todos los program as.

Documentación Todo el conocim iento provisto por el analista, o inferida por GeneXus, está disponible en un repositorio act ivo, que const ituye una m uy com pleta docum entación online, perm anentem ente actualizada.

Consolidación de varias aplicaciones y reutilización de conocimiento. Varias aplicaciones pueden ser diseñadas y protot ipadas sim ultáneam ente, por diferentes equipos, ut ilizando GeneXus. Estos equipos pueden intercam biar especificaciones de diseño ut ilizando el m ódulo KNOWLEDGE MANAGER.

Esto perm ite una flexibilidad ideal: el analista t rabaja con entera libertad en un am biente de protot ipo, con una pequeña base de conocim iento y, sólo cuando su aplicación está pronta desde el punto de vista del usuario, debe tom arse en cuenta la base de conocim iento corporat iva, que generalm ente será m uy grande.

En ese m om ento, con poderosas ayudas autom át icas, se establece el im pacto que tendrá la nueva aplicación, o la m odificación de la preexistente, sobre el m odelo corporat ivo y, si es el caso, se hacen los cam bios para asegurar la consistencia, de una m anera m uy sim ple.

Con este esquem a es posible reut ilizar, por ejem plo, Bases de Conocim iento licenciadas de terceras partes (Véase Catálogo de Bases de Conocim iento ht tp: / / www.genexus.com / catalogo2001) .

Página 13 de 14

Características únicas de GENEXUS

GeneXus t iene algunas característ icas únicas que lo dist inguen de sus com pet idores. Ent re ellas pueden destacarse:

x I nteract ivo: El punto de part ida es la descripción natural del usuario de los objetos.

x La descripción de cada objeto es totalm ente independiente de la de los dem ás por lo que, en el caso de que se deba m odificar la descripción de uno, ello no im plicará la necesidad de m odificar m anualm ente la descripción de cualquier ot ro. Esta característ ica exclusiva de GeneXus es la que perm ite un m antenim iento totalm ente autom át ico de las aplicaciones.

x La curva de aprendizaje es corta.

x Diseño, creación y m antenim iento de la base de datos son totalm ente autom át icos.

x La aplicación (base de datos y program as) t iene siem pre, sean cuales sean las m odificaciones que haya sufr ido, la m ejor calidad:

La base de datos es siem pre la ópt im a,

No se m odifican program as: cuando ya no son adecuados, se generan ot ros nuevos, ópt im os y no rem endados, que los sust ituyen.

x Lenguajes poderosos y de m uy alto nivel para la definición de PROCESOS, WORK PANELS y WEB OBJECTS, así com o una definición de MENUES m uy sim ple. En estos lenguajes las descripciones de los procesos se hacen sin referirse a los archivos involucrados, los que son inferidos autom át icam ente en t iem po de generación. Esta característ ica perm ite una total independencia ent re los datos y dichas especificaciones. Com o consecuencia, las especificaciones de alto nivel de GeneXus no necesitan m odificaciones de la base de datos.

x Ut ilización los archivos o bases de datos preexistentes com o propios de GeneXus.

x Mantenim iento 100% autom át ico: El conjunto de estos elem entos perm ite a GeneXus generar y m antener autom át icam ente el 100% de los program as en aplicaciones norm ales de t ipo com ercial, adm inist rat ivo, financiero o indust r ial.

x GeneXus funciona en PC’s, dejando el com putador de producción totalm ente libre para el procesam iento de las aplicaciones.

x Fácil dist r ibución del conocim iento corporat ivo para facilitar el desarrollo de nuevas aplicaciones.

x Sim ple y poderosa solución para Data Warehousing.

x Verificación autom át ica de consistencia, y consolidación, ent re aplicaciones desarrolladas separadam ente.

x I ndependencia de plataform a y arquitectura.

x Sim plicidad: GeneXus ut iliza los recursos m ás avanzados de la inteligencia art ificial para que el analista y los usuarios, puedan usarlo de una form a m uy sim ple.

¿Quiénes son los usuarios de GENEXUS? GeneXus es dist r ibuido en toda Am érica, España, I talia, Sudáfrica, China y Taiwan y t iene en la actualidad, m ás de 4000 clientes que han cont ratado unas 25000 licencias.

Página 14 de 14

Ent re los clientes existen em presas de todo t ipo y área de act ividad. Los clientes generalm ente desarrollan con GeneXus grandes aplicaciones corporat ivas de m isión crít ica. Generalm ente desarrollan con GeneXus el 100% de las m ism as. Existen m ás de 1.000 casas de software, en todo el m undo, que desarrollan sus aplicaciones 100% con GeneXus, lo que representa algunos m iles de clientes indirectos que usan aplicaciones GeneXus.

GeneXus and ARTech are trademarks or registered trademarks of ARTech Consultores S.R.L. ARTech recognizes that all other trademarks contained herein are property of their respective holders

GENEXUS

Diseño de Aplicaciones

Copyright ARTech Consultores 1988-1999. All rights reserved.

TABLA DE CONTENIDO

INTRODUCCIÓN............................................................................................................ 1

DESARROLLO DE UNA APLICACIÓN ..................................................................... 3

SISTEMA DE COMPRAS PARA UNA CADENA DE FARMACIAS. ......................... 3DEFINIR EL OBJETIVO ...................................................................................................... 3DEFINIR EL EQUIPO DE TRABAJO ...................................................................................... 4OBTENER UNA IMAGEN GLOBAL ...................................................................................... 4DEFINIR EL ALCANCE DE LA APLICACIÓN ......................................................................... 5MANTENER EL DISEÑO SIMPLE......................................................................................... 5ORIENTARSE A LOS DATOS .............................................................................................. 5

DISEÑO DE TRANSACCIONES................................................................................... 7

ESTRUCTURA DE UNA TRANSACCIÓN............................................................................... 9Atributos ................................................................................................................... 10Dominios .................................................................................................................. 11Atributos Clave......................................................................................................... 11Relación entre la estructura y el modelo de datos ................................................... 12Tipos de controles .................................................................................................... 14Definición de la transacción de pedidos .................................................................. 16Niveles de una transacción....................................................................................... 18Tipos de relación entre los objetos........................................................................... 22

FORM DE UNA TRANSACCIÓN ........................................................................................ 23Diálogo full-screen................................................................................................... 24Diálogo campo a campo .......................................................................................... 25Barra o Botones de Menú......................................................................................... 25Atributos de entrada y atributos de salida ............................................................... 26Facilidad de Prompt................................................................................................. 26Diálogo para transacciones con varios niveles ....................................................... 27

FORM EDITOR ............................................................................................................... 29Form Edition Controls ............................................................................................. 29Paleta de herramientas ............................................................................................ 30Uso de las Herramientas .......................................................................................... 31Toolbar..................................................................................................................... 31Propiedades de los controles ................................................................................... 32Editor de Propiedades, Métodos y Eventos.............................................................. 35

FÓRMULAS .................................................................................................................... 36Fórmulas Horizontales............................................................................................. 37Fórmulas Verticales ................................................................................................. 38Fórmulas y Redundancia ......................................................................................... 39

Fórmulas de Fórmulas ............................................................................................. 40REGLAS ......................................................................................................................... 41

Default...................................................................................................................... 41Error......................................................................................................................... 41Asignación................................................................................................................ 41Add y Subtract .......................................................................................................... 42Serial ........................................................................................................................ 43Orden de evaluación ................................................................................................ 44Call y función After .................................................................................................. 45

PROPIEDADES ................................................................................................................ 46

DISEÑO DE REPORTES.............................................................................................. 48

LAYOUT ........................................................................................................................ 48Comando FOR EACH .............................................................................................. 51Reportes con varios FOR EACH.............................................................................. 60Otros comandos........................................................................................................ 67

CONDICIONES ................................................................................................................ 73REGLAS ......................................................................................................................... 74

Default...................................................................................................................... 74Parm......................................................................................................................... 75

REPORT WIZARD ........................................................................................................... 76PROPERTIES................................................................................................................... 78

DISEÑO DE PROCEDIMIENTOS .............................................................................. 80

Modificación de datos .............................................................................................. 80Eliminación de datos................................................................................................ 81Creación de datos..................................................................................................... 81

CONTROLES DE INTEGRIDAD Y REDUNDANCIA............................................................... 82

DISEÑO DE PANELES DE TRABAJO ...................................................................... 83

EJEMPLO ....................................................................................................................... 84FORM DEL WORK PANEL............................................................................................... 86

Subfile....................................................................................................................... 87EVENTOS....................................................................................................................... 89

Evento Start .............................................................................................................. 90Evento Enter............................................................................................................. 90Eventos definidos por el usuario (User Defined Events).......................................... 91Evento Refresh.......................................................................................................... 91Carga de datos en el Panel de Trabajo.................................................................... 92

CONDICIONES ................................................................................................................ 93REGLAS ......................................................................................................................... 95

Order ........................................................................................................................ 95

Noaccept................................................................................................................... 95Search....................................................................................................................... 95

BITMAPS........................................................................................................................ 97Fixed Bitmaps........................................................................................................... 97Dynamic Bitmaps ..................................................................................................... 97

GRÁFICAS...................................................................................................................... 99PROPERTIES................................................................................................................. 103

Generar como una ventana Popup......................................................................... 103DIÁLOGOS OBJETO-ACCIÓN ........................................................................................ 104

DISEÑO DE MENÚES ................................................................................................ 106

CALL BROWSER .......................................................................................................... 108

ANEXO A. MODELOS DE DATOS RELACIONALES.......................................... 110

Tablas..................................................................................................................... 110Clave primaria y Claves candidatas ...................................................................... 111Indices .................................................................................................................... 112Integridad Referencial............................................................................................ 112Normalización ........................................................................................................ 114Tabla extendida ...................................................................................................... 115

ANEXO B. FUNCIONES, REGLAS Y COMANDOS.............................................. 118

Todos los nombre de productos mencionados en este documento son marcas de susrespectivos dueños.

DISEÑO DE APLICACIONES CON GENEXUS

COPYRIGHT ARTech Consultores SRL. 1988 - 1999.Queda prohibida cualquier forma de reproducción, transmisión o archivo en sistemasrecuperables, sea para uso privado o público por medios mecánicos, electrónicos,fotocopiadoras, grabaciones o cualquier otro, total o parcial, del presente ejemplar, con osin finalidad de lucro, sin autorización expresa de ARTech.

GENEXUS- DISEÑO DE APLICACIONES

1

INTRODUCCIÓN

El presente documento es una introducción al desarrollo de aplicaciones utilizandoGENEXUS. Está dirigido a profesionales de informática que se inician en el uso deGENEXUS.GENEXUS es una herramienta para el desarrollo de aplicaciones. Su objetivo es ayudar alos analistas de sistemas a implementar aplicaciones en el menor tiempo y con la mejorcalidad posible.A grandes rasgos, el desarrollo de una aplicación implica tareas de análisis, diseño eimplementación. La vía de GENEXUS para alcanzar el objetivo anterior es liberar a laspersonas de las tareas automatizables (por ejemplo, la implementación), permitiendolesasí concentrarse en las tareas realmente difíciles y no automatizables (análisis y diseño).Desde un punto de vista teórico, GENEXUS es más una metodología de desarrollo deaplicaciones que una herramienta de software. Como metodología, tiene algunos puntosde contacto con las metodologías tradicionales, pero también aporta enfoques bastantediferentes en otros.En común con las metodologías tradicionales, se mantiene la importancia del análisis ydiseño de la aplicación sobre la implementación. Quizás con GENEXUS este enfoque seresalta más aún, ya que el usuario de GENEXUS estará la mayor parte del tiemporealizando tareas de análisis y GENEXUS, en sí, tareas de implementación (por ejemplo,normalización de la base de datos, generación de programas, etc.).Por otro lado, algunos de los enfoques metodológicos son bastante diferentes que loshabituales, como, por ejemplo, el comenzar el análisis de la aplicación por la interfase delmismo con el usuario, la casi nula referencia a la implementación física del sistema, etc.Para presentar estos nuevos conceptos, y a los efectos de no realizar una presentacióndemasiado abstracta del tema, se ha elegido una aplicación que se irá desarrollando através de los distintos capítulos.El primer capítulo presenta la aplicación y los aspectos iniciales de un desarrollo conGENEXUS.El segundo capítulo trata el diseño de Transacciones, el tercero de Reportes, el cuarto deProcedimientos, el quinto de Paneles de Trabajo y por último se trata el diseño deMenúes.Debido a que en todos los capítulos se asume cierto conocimiento sobre Bases de DatosRelacionales, se ha incluido un anexo sobre el tema que describe los conceptos necesariospara este documento. Se recomienda su lectura antes de leer el segundo capítulo.Por razones didácticas, en este documento no se tratan los siguientes temas:

• Ciclo de vida de una aplicación: Una aplicación tiene un ciclo de vida, quecomienza cuando se planifica la misma y termina cuando la aplicación sale deproducción. GENEXUS acompaña todo este ciclo. Este tema es tratado en eldocumento Visión General, que recomendamos leer previamente.

GENEXUS DISEÑO DE APLICACIONES

2

• Uso de GENEXUS : Toda la información respecto a la operación de GENEXUS

en sí (manejo de teclas, edición de texto, etc.) se trata en el Tutorial GENEXUS,que sugerimos repasar posteriormente.


3

DESARROLLO DE UNA APLICACIÓN

La mejor forma de aprender a utilizar GENEXUS es realizando aplicaciones con él. Laaplicación que se ha elegido es una simplificación de una aplicación real.

SISTEMA DE COMPRAS PARA UNA CADENA DE FARMACIAS.

En una cadena de farmacias se desea implementar un sistema de compras que permita alos analistas de compras realizar dicha tarea con la mayor cantidad de informaciónposible. La función de un analista de compras es decidir los pedidos que se debenefectuar a los proveedores de los distintos artículos.

Funcionamiento del sistema:Se desea que el analista de compras utilice el computador para definir los pedidos a losdistintos proveedores. Una vez que el pedido este hecho y aprobado, se quiere que elcomputador emita las ordenes de compra. En el momento de hacer un pedido es necesariohacer varias consultas, por ejemplo cuanto hay en stock, cual fue el precio de la últimacompra, etc.Los siguientes puntos describen los pasos seguidos para el desarrollo de esta aplicación.

Definir el objetivo

No se debe olvidar que los computadores son meras herramientas. Los usuarios de lossistemas tienen objetivos específicos. Ellos esperan que la aplicación los ayude aalcanzarlos mas rápido, mas fácil, o a un menor costo. Es parte del trabajo de análisis, elconocer esos propósitos y saber por medio de que actividades los usuarios quierenalcanzarlos.Este objetivo debe poder ser expresado en pocas palabras (uno o dos párrafos) y serconocido por todas las personas involucradas con el sistema.En el ejemplo, alguno de los propósitos posibles son:

• "El sistema de compras debe disminuir la burocracia existente para laformulación de un pedido."

• "El sistema de compras debe asistir a usuarios no entrenados en la formulaciónde pedidos de tal manera que su desempeño se asemeje al de un experto."

• "El sistema de compras debe permitir la disminución del stock existente en lasfarmacias."

De todos los objetivos posibles se debe elegir uno como el objetivo principal oprioritario. Esto es muy importante para el futuro diseño de la aplicación. Basta conobservar como los distintos objetivos anteriores conducen a diseños diferentes.


4

Para nuestro ejemplo elegiremos el primer objetivo, dado que en la situación real elanalista de compras no tenia toda la información que necesitaba. Por lo tanto, debíaconsultar una serie de planillas manuales y llamar por teléfono a los empleados deldeposito para que realizaran un conteo manual del stock.No se debe confundir el objetivo de la aplicación (el QUE) con la funcionabilidad de lamisma (COMO se alcanzará el objetivo).

Definir el equipo de trabajo

A continuación se debe definir cuál será el equipo de personas encargado de laimplementación del sistema. Dicho equipo debe tener como mínimo dos personas:

• El analista de sistemas.• Y un usuario.

Los analistas de sistemas que trabajen en el desarrollo de la aplicación deben cumplir doscondiciones:

• Haber sido entrenados en el uso de GENEXUS

• Tener una orientación a las aplicaciones.

Se recomienda que dichos analistas pasen algún tiempo trabajando con los usuarios en elcomienzo del proyecto a los efectos de familiarizarse con los conceptos, vocabulario,problemas existentes, etc.Como la aplicación se desarrolla de una manera incremental, es MUY IMPORTANTE laparticipación de los usuarios en todas las etapas del desarrollo. Se recomienda tener unusuario principal disponible para la prueba de los prototipos y tener acceso a los demásusuarios de una manera fluida.Dado que con GENEXUS los miembros del equipo estarán la mayor parte del tiempotrabajando en tareas de diseño y no de codificación, se debe tomar como criterio generalel trabajar en equipos PEQUEÑOS, por ejemplo, no más de cinco personas.

Obtener una imagen global

Se debe tener entrevistas con el nivel gerencial mas alto que se pueda, de modo deobtener información sobre la posición relativa (e importancia) de la aplicación dentro detoda la organización.


5

Definir el alcance de la aplicación

Luego de un estudio primario se debe decidir cuál será el alcance de la aplicación parapoder cumplir con el objetivo. Para ello se recomienda seguir el Principio deEsencialidad:

"Solo lo imprescindible, pero todo lo imprescindible"

En el ejemplo, una vez que una orden de compra es enviada a un proveedor, se debecontrolar como y cuando se fueron entregando efectivamente los productos. Sin embargovemos que esto no es imprescindible para cumplir el objetivo de la aplicación y por lotanto no será tratado.

Mantener el diseño simple

Se debe planificar pensando en un proceso de diseño y desarrollo incremental.Comenzando por pequeños pasos y verificando la evolución del modelo frecuentementecon el usuario.

Orientarse a los datos

En esencia, una aplicación es un conjunto de mecanismos para realizar ciertos procesossobre ciertos datos.Por lo tanto, en el análisis de la aplicación, se puede poner mayor énfasis en los procesoso en los datos.En las metodologías tradicionales -como el Análisis Estructurado- el análisis se basa enlos procesos. En general, este análisis es Top-Down; se comienza con la definición másabstracta de la función del sistema, y luego se va descomponiendo esta en funciones cadavez más simples, hasta llegar a un nivel de abstracción suficiente como para poderimplementarlas directamente.Sin embargo, este enfoque tiene ciertos inconvenientes:

Las funciones de un sistema tienden a evolucionar con el tiempo, y por lo tanto, un diseñobasado en las funciones será más difícil de mantener.La idea que una aplicación se puede definir por una única función es muy controvertidaen aplicaciones medias o grandes.Frecuentemente se descuida el análisis de las estructuras de datos.No facilita la integración de aplicaciones.

Si, por el contrario, el diseño se basa en los datos, se puede obtener las siguientesventajas:


6

Más estabilidad. Los datos tienden a ser más estables que los procesos y en consecuenciala aplicación será más fácil de mantener.

Facilidad de integración con otras aplicaciones. Difícilmente una aplicación estotalmente independiente de las otras dentro de una organización. La mejor forma deintegrarlas es tener en cuenta los datos que comparten. Incluso es posible que en un futuroel propio concepto de aplicación evolucione hacia el concepto de objeto, en donde losusuarios pedirán que se implementen nuevos objetos y no nuevas aplicaciones.

Sin embargo, si bien vemos que orientarse a los datos es beneficioso, la pregunta es comoanalizar los datos?. La respuesta de GENEXUS es analizar directamente los datos que elusuario conoce, sin importar como se implementarán en el computador.El diseño comienza -como veremos más en detalle en el siguiente capítulo- estudiandocuales son los objetos que el usuario manipula. Para cada uno de estos objetos se definecual es su estructura de datos y posteriormente cual es su comportamiento.De esta manera se alcanzan dos objetivos importantes: el análisis se concentra en hechosobjetivos, y este puede ser evaluado directamente por los usuarios, utilizando la facilidadde prototipación de GENEXUS.


7

DISEÑO DE TRANSACCIONES

El análisis mismo de la aplicación comienza con la definición de las transacciones. Decualquier manera es importante tener en cuenta que todo el proceso de desarrollo esincremental y por lo tanto no es necesario definir en esta etapa todas las transacciones ycada una de ellas en su mayor detalle. Por el contrario lo importante aquí es reconocer lasmas relevantes y para cada una de ellas cual es la estructura mas adecuada.Para poder definir cuales son las transacciones se recomienda estudiar cuales son losobjetos (reales o imaginarios) que el usuario manipula. Afortunadamente es posibleencontrar la mayor parte de las transacciones a partir de:

La descripción del sistema. Cuando un usuario describe un sistema se puedendeterminar muchas transacciones si se presta atención a los sustantivos que utiliza. Enel ejemplo:

Analistas de comprasPedidosProveedoresArtículosOrdenes de Compra

Formularios existentes. Por cada formulario que se utilice en el sistema es casiseguro que existirá una transacción para la entrada de los mismos.

Para cada transacción se puede definir:

EstructuraDe que atributos (campos en la metodología tradicional) esta compuesta y querelación tienen entre si.

Pantalla o FormCual es el form que tiene. Esto se realiza con un editor especializado.

FórmulasQue atributos se calculan a partir de otros atributos. Por ejemplo: Valor = Cantidad *Precio.

Reglas


8

Conjunto de reglas que debe cumplir la transacción. Por ejemplo cuales son losvalores por defecto de los atributos, cuales son los controles en los datos que hay querealizar, etc.

EventosLas transacciones soportan la programación dirigida por eventos. Este tipo deprogramación permite el almacenamiento de código ocioso el cual es activado luegode ciertos eventos - provocados por el usuario o por el sistema.

PropiedadesReglas que definen el comportamiento general de la transacción.

Form ClassesCada objeto puede tener asociado mas de un form que pertenece a una determinadaForm Class. Existen dos Form Classes predefinidas: Graphic y Text. Tipicamente laForm Class Graphic se usa para los ambientes graficos (por ejemplo: Windows) y laform class Text se usa para los ambientes que trabajan en modo texto (por ejemplo:AS/400) El combo box que se muestra en la siguiente figura permite seleccionar unform (de determinada Form Class) de los que se hayan asociado al objeto.

Style AsociadoStyles son básicamente objetos GENEXUS (su forma de definición es similar a losotros objetos), pero no son tenidos en cuenta en la normalización o generación deprogramas; sólo se utilizan para definir estándares. Un ejemplo puede aclarar la idea:supongamos que se quiere definir las transacciones con botones con bitmaps en vez delos usuales de texto. Cuando se crea una transaccion se puede asociar un style en elcual se basara la transaccion.

AyudaTexto para la ayuda a los usuarios en el uso de la transacción.

DocumentaciónTexto técnico que se incluye para ser utilizado en la documentación del sistema.


9

Fast Access Toolbar

Cuando se bare un objeto esta toolbar se habilita con las siguientes opciones:

Estructura de una transacción

La estructura define que atributos (campos) integran la transacción y como estánrelacionados. En el ejemplo, la transacción de Proveedores posee los siguientesatributos:

PrvCod Código de proveedorPrvNom Nombre del proveedorPrvDir Dirección del proveedor

que componen la información que se quiere tener de un proveedor.

Form

Estructura

Reglas

Eventos

Propiedades

Variables

Forms

Help


10

Atributos

Para cada atributo se debe definir:

Name: Es el nombre del atributo. Se utiliza para identificar al atributo.

Title: Es un string que acompaña al atributo en los listados de documentación quetenemos disponibles y permite tener una descripción ampliada para éste. También seutiliza en los Forms de las transacciones y reportes que se crean por defecto.

Domain: Dominio en que se basa el atributo al definirlo.

Type: tipo de atributo (Numérico, alfanumérico, fecha, Long Varchar, Varchar oDateTime).


11

El tipo de dato Long Varchar (por Variable Character) permite almacenar unacantidad de caracteres indefinida. Se utiliza normalmente para almacenar textos, porejemplo notas, descripciones, comentarios, etc.

Length: largo del atributo.

Decimals: Número de posiciones decimales.

Picture - Formato del campo que permite una visualización en la entrada y salida, porejemplo: en campos caracter @! significa que todos los caracteres se aceptan ydespliegan en mayúsculas.

Value Range: Rango de valores válidos para el atributo.Por ejemplo: La siguiente definición:

1:20 30: significa que el valor debe estar entre 1 y 20 o ser mayor que 301 2 3 4 significa que el valor debe ser 1 o 2 o 3 o 4'S' 'N' significa que el valor debe ser 'S' o 'N'

Dominios

Es común cuando estamos definiendo la base de datos, tener atributos que compartendefiniciones similares, y que no se puede establecer ninguna relación directa entreellos. Por ejemplo, es común almacenar todos los nombres en atributos de tipocaracter y largo 25. El uso de dominios permite usar definiciones de atributosgenéricos. Por ejemplo en la transacción de proveedores tenemos el nombre(PrvNom) y mas adelante vamos a definir el nombre del analista, entonces podemosdefinir un dominio Nombres de tipo caracter con largo 25 y asociarlo a estos atributos.Por lo tanto si en el futuro cambia la definición de este dominio, los cambios seránpropagados automáticamente a los atributos que pertenecen a él.

Atributos Clave

También es necesario definir cual es el atributo o conjunto de atributos que identificana la transacción (es decir que los valores de los atributos identificadores son únicos),esto se hace poniendo un * al final del o los atributos:

PrvCod*PrvNomPrvDir

así se indica que no existen dos proveedores con el mismo Código de Proveedor.


12

Es importante notar que el concepto de identificador se refiere a la unicidad (si puedehaber o no dos proveedores con el mismo número) y no a como se debe acceder alarchivo donde se almacenan los proveedores.Reglas para los identificadores:

• Toda transacción debe tener un identificador.• Los identificadores tienen valor desde un principio (por ejemplo cuando se

crea un proveedor nuevo se debe saber cual será su PrvCod)• No cambian de valor. Por ejemplo al proveedor con código 123 no se lo puede

cambiar para 234.

En los casos en los cuales no se puede determinar un identificador se debe optar porcrear un atributo artificial (no existente en la realidad) y cuyo valor es asignadoautomáticamente por el sistema.

Relación entre la estructura y el modelo de datos

GENEXUS utiliza la estructura de la transacción para definir cual es el modelo de datosque se necesita. En particular de la estructura anterior GENEXUS infiere:

• No existen dos Proveedores con el mismo PrvCod.• Para CADA PrvCod existe solo UN valor de PrvNom y de PrvDir.

y con esta información va construyendo el modelo de datos. En este caso a latransacción de Proveedores se le asociara la Tabla:

Tabla: Proveedo

Atributos: PrvCod* (con * se indica clave primaria) PrvNom PrvDir

Indices: IPROVEED (PrvCod) Clave Primaria

el nombre de la tabla y el del índice son asignados automáticamente, pero luegopueden ser modificados por el analista).Diremos que la transacción de Proveedores tiene asociada la tabla PROVEEDO en elentendido que cuando se ingresen (o modifiquen, etc.) datos en la transacción estosserán almacenados en la tabla PROVEEDO.Otras transacciones simples de nuestro ejemplo son:


13

Analista de compra:

AnlNro* Numero de analistaAnlNom Nombre del analista

Artículos:ArtCod* Código de articuloArtDsc Descripción del articuloArtCnt Cantidad en StockArtFchUltCmp Fecha ultima compraArtPrcUltCmp Precio ultima compraArtUnidad Unidad del articuloArtSize TamañoArtDisponible Disponibilidad

Que tendrán asociadas las tablas ANALISTA y ARTICULO respectivamente.

Tabla: ANALISTA

AnlNro* AnlNom

Tabla: ARTICULO

ArtCod* ArtDsc ArtCnt ArtFchUltCmp ArtPrcUltCmp ArtUnidad ArtSize ArtDisponible

Veamos ahora la definición del form de artículos:


14

Los atributos ArtUnidad, ArtDisponible y ArtSize no aparecen en el form como losatributos convencionales (de edit). ArtUnidad se definió como un Combo Box,ArtSize como un Radio Buttom y ArtDisponible como un Check Box.

Tipos de controles

Edit

Normalmente los atributos tienen un rango de valores muy grande, (por ejemplo: unnombre, un precio, etc). En estos casos se le permite al usuario entrar el valor delatributo y el sistema se encarga de validarlo. A estos tipos de controles se los llama‘Edit Box’. En el ejemplo, Artcod, ArtDsc, etc.Sin embargo existen atributos que tienen un rango de valores muy pequeño y quepueden ser desplegados de antemano para que el usuario seleccione uno. De estaforma controlamos que ingresen solo valores válidos. Estos tipos de controles son losque veremos a continuación.

Check Box

Es usado para aquellos atributos que tienen solo dos posibles valores True o False(como en nuestro ejemplo para señalar si existe disponibilidad del artículo). Existe


15

una única descripción (Disponible) y en caso que este campo este seleccionado elvalor será True y en caso contrario será False.

Radio Buttom

Los ‘Radio Buttom’, en cambio, pueden tener mas de dos valores. Todos los valoresse despliegan en el form (en realidad se despliegan sus descripciones, el valor que sealmacena es manejado internamente) y solo se puede seleccionar uno. En el ejemploel tamaño del articulo lo definimos como un Radio Buttom.

Combo Box

Es generalmente usado para aquellos atributos que tienen un rango grande de valores,y que con un Radio Buttom no seria muy practico el manejo. Se despliega un campode tipo Edit y presionando un botón que se encuentra a la derecha del campo sedespliega una lista con todos los valores validos. No es recomendable usar este campocomo listas de selección de atributos que tienen valores que no pueden serdeterminados a priori, (que son leídos de una tabla). Para estos casos se usan losDynamic Combobox.

Dynamic Combobox

Un dynamic combobox es un tipo de control similar al combo box, la diferencia esque los valores posibles se leen de una tabla de la base de datos. La forma deoperación es similar a la del combo box, solo que los valores desplegados sondescripciones leídas de una determinada tabla.

List Box

Este tipo de control tiene asociada una colección de ítems. Cada ítem tiene asociadoun par <valor,descripción>. Existe la posibilidad de cargar la colección de ítems tantoen diseño como en runtime. El control da la posibilidad de seleccionar un solo ítem ala vez. El atributo o variable toma el valor en el momento que se selecciona el ítem.La selección se realiza dando click con el mouse en un ítem o con las flechas delteclado.

Dynamic List Box

Este tipo de control tene asociada una colección de ítems. Cada ítem tiene asociado unpar <valor,descripción>.


16

La colección de ítems se carga en runtime desde una tabla de la base de datos.También es posible agregar ítems en forma manual en runtime.En tiempo de diseño se asocian dos atributos al Dynamic List Box, uno al valor quetendrá el ítem y el otro a la descripción que éste tomará. Ambos atributos debenpertenecer a la misma tabla.En tiempo de especificación se determina la tabla desde la cual se traerán los valores ylas descripciones.

Definición de la transacción de pedidos

Consideremos ahora la transacción de Pedidos. El formulario preexistente de pedidoses:

Pedido : 1456 Fecha: 02/01/92Analista : 21 Pedro GomezProveedor : 125 ABC Inc.

Código Descripción Cantidad Precio Valor

321 Aspirinas 100 120 12000 567 Flogene 120 50 6000

Total 18000

Los atributos que integran la transacción son (dejando momentáneamente de lado lainformación de los Artículos del pedido):

PedNro* Numero del pedidoPedFch Fecha del pedidoPrvCodPrvNomAnlNroAnlNomPedTot Total del pedido

en donde PedNro es el identificador del mismo.Esta transacción tiene algunas características interesantes a destacar: tanto PrvCod yPrvNom, como AnlNro y AnlNom son atributos que están presentes en otrastransacciones. De esta manera estamos indicando que existe una relación entre los


17

Proveedores y los Pedidos y también entre los Analistas y los Pedidos, en particularaquí estamos indicando que un Pedido solo tiene UN Proveedor y solo UN Analista.Se tiene así que la forma de indicar a GENEXUS la relación entre las distintastransacciones se base en los nombres de los atributos.

Reglas para nombres de atributos

Se debe poner el mismo nombre al mismo atributo en todas las transacciones en quese encuentre, a no ser que ello no sea posible (es el caso de Subtipos que se detallaramas adelante). Por ejemplo al nombre del proveedor se le llama PrvNom tanto en latransacción de Proveedores como en la de Pedidos.Se debe poner nombres distintos a atributos conceptualmente distintos, aunque tengandominios iguales. Por ejemplo el nombre del proveedor y el nombre del analistatienen el mismo dominio (son del tipo Character de largo 30), pero se refieren a datosdiferentes, por lo tanto se deben llamar PrvNom y AnlNom.

Integridad referencial en las transacciones

Otra característica a destacar es que, cuando se define la estructura de una transacciónNO se esta describiendo la estructura de una tabla y SI los datos que se necesitan en lapantalla o en las reglas. Por ejemplo, que en la estructura anterior figure el PrvNom noquiere decir que este se encuentre en la tabla de Pedidos, simplemente indica que senecesita tener el PrvNom en la pantalla de Pedidos.La tabla asociada a el cabezal del Pedido será:

Tabla: PEDIDOS

PedNro*PedFchPrvCodAnlNroPedTot

Índices:

IPEDIDOS (PedNro) Clave PrimariaIPEDIDO1 (PrvCod) Clave ExtranjeraIPEDIDO2 (AnlNro) Clave Extranjera

Observar que PrvNom no se encuentra en la tabla PEDIDOS (diremos que fue'normalizado'). Y que existe una relación de integridad entre la tabla PROVEEDO,


18

que tiene a PrvCod como clave primaria, y la PEDIDOS que lo tiene como claveextranjera. La relación, que llamaremos de integridad referencial, es:

• Para insertar un registro en la tabla PEDIDOS debe existir el PrvCodcorrespondiente en la tabla PROVEEDO.

• Cuando se elimina un registro de la tabla PROVEEDO no debe haberregistros con el PrvCod a eliminar en la tabla PEDIDOS.

Estos controles de integridad son generados automáticamente por GENEXUS y, porejemplo, en la transacción de Pedidos cuando se digita el PrvCod se valida que esteexista en la tabla PROVEEDO e incluso se genera una subrutina que permitevisualizar los proveedores existentes y seleccionar el proveedor asociado al pedido.

Niveles de una transacción

Volviendo al ejemplo, para terminar de diseñar la transacción de Pedidos se debedefinir la información sobre los Artículos del pedido. Sin embargo no es posibledefinir la estructura de la siguiente manera:

PedNro*PedFchPrvCodPrvNomAnlNroAnlNomArtCodArtDscPedCnt Cantidad pedidaPedPre Precio pedidoPedImp Valor del articuloPedTot

porque esto significaría que para cada pedido existe solo UN articulo, lo que no secorresponde con el formulario. La estructura correcta es:


19

PedNro* PedFch PrvCod PrvNom AnlNro Nivel del AnlNom cabezal

( ArtCod* ArtDsc Nivel de las PedCnt líneas PedPre PedImp )

PedTot

donde el identificador es PedNro y para cada numero de pedido existe solo una fecha,un código y nombre de proveedor, un número y nombre del analista y un solo total,pero muchos Artículos, cantidades pedidas, precios y importes de la línea .Los paréntesis indican que para cada Pedido existen muchos Artículos. Cada grupo deatributos que se encuentra encerrado por paréntesis diremos que pertenece a unNIVEL de la transacción.Cabe notar que el primer nivel queda implícito y no necesita un juego de paréntesis.Así, la transacción de Pedidos tiene dos niveles: PedNro, PedFch, PrvCod, PrvNom,AnlNro, AnlNom y PedTot pertenecen al primer nivel y ArtCod, ArtDsc, PedCnt,PedPre y PedImp pertenecen al segundo nivel.Una transacción puede tener varios niveles y ellos pueden estar anidados o serparalelos entre si. Por ejemplo si el Pedido tiene varias fechas de entrega:

PedNro* PedFch PrvCod PrvNom AnlNro AnlNom ( ArtCod* ArtDsc PedCnt PedPre PedImp ) ( PedFchEnt* Fecha de entrega PedImpPag ) Importe a pagar PedTot


20

Con esta estructura se define que un Pedido tiene muchos Artículos y muchasEntregas, pero no hay relación directa entre ambas (a no ser el hecho de pertenecer almismo Pedido). Si por el contrario las fechas de entrega son por articulo (cadaarticulo tiene sus fecha de entrega particulares), la estructura correcta es:

PedNro* PedFch PrvCod PrvNom AnlNro AnlNom ( ArtCod* ArtDsc PedCnt PedPre PedImp ( PedFchEnt* PedImpPag ) ) PedTot

Así como la transacción tiene un identificador, cada nivel de la misma también debetener uno. Por ejemplo en el Pedido tenemos que el identificador del segundo nivel esArtCod. Con esto se indica que dentro de cada Pedido no existen dos líneas delPedido con el mismo ArtCod, y por lo tanto el siguiente Pedido no es valido:

Pedido : 1456 Fecha: 02/01/92Analista : 21 Pedro GomezProveedor : 125 ABC Inc.

Código Descripción Cantidad Precio Valor

321 Aspirinas 100 120 12000 321 Aspirinas 120 50 6000

Total 18000

porque existen dos líneas del Pedido con el mismo ArtCod.


21

Aquí también se deben tener en cuenta los criterios sobre identificadores que semencionaron previamente. En particular, es común definir atributos artificiales cuandono hay identificadores naturales, por ejemplo, para el caso en que si puede habervarias veces el mismo articulo en el pedido, se debe definir el Pedido como:

PedNro* PedFch PrvCod PrvNom AnlNro AnlNom ( PedLinNro* ArtCod ArtDsc PedCnt PedPre PedImp ) PedTot

en donde el PedLinNro lo puede digitar el usuario o se puede incluir una regla paraque lo haga automáticamente la transacción.

Cada nivel de la transacción tiene una tabla asociada:

Tabla: PEDIDOS PedNro* PedFch PrvCod AnlNro PedTot

Tabla: PEDIDOS1 PedNro* PedLinNro* ArtCod PedCnt PedPre PedImp

La clave primaria de las tablas asociadas a los niveles subordinados es laconcatenación de los identificadores de los niveles superiores (PedNro) mas losidentificadores del nivel (PedLinNro).


22

La elección de los identificadores es una tarea importante y que puede simplificar ocomplicar la implementación de un sistema. Supongamos por ejemplo, que en elPedido no se admite que haya dos líneas con el mismo ArtCod. La forma natural deimplementar esto es definiendo a ArtCod como identificador del segundo nivel. Ahorabien, si por alguna razón se definió a PedLinNro como el identificador, ya notendremos ese control automático y se debe escribir un Procedimiento para realizarlo.En otras palabras, cuanto mas reglas de la realidad se puedan reflejar en la estructura,menor será la cantidad de procesos que se debe implementar, ganando así ensimplicidad y flexibilidad.

Tipos de relación entre los objetos

Muchas veces cuando los usuarios están describiendo la aplicación, es comúnpreguntarles que tipo de relación existe entre los distintos objetos. Por ejemplo cual esla relación entre los proveedores y los pedidos:

Un proveedor tiene muchos pedidos (relación 1-N).Un pedido tiene un solo proveedor (relación N-1).

Como ya vimos, la relación 1-N se puede definir con la estructura:

PrvCod* PrvNom .... (PedNro* .... )

Y la relación N-1 como:

PedNro* .... PrvCod PrvNom ....

Vemos que generalmente para cada relación N-1 habrá una relación simétrica 1-N. Enestos casos se debe definir la estructura N-1 y no la 1-N.Otro caso muy común son las relaciones M-N, por ejemplo entre los pedidos y losArtículos:

Un pedido tiene muchos Artículos.


23

Un articulo puede estar en muchos pedidos.

En este caso las dos estructuras posibles son:

PedNro* PedFch PrvCod PrvNom AnlNro AnlNom ( ArtCod* ArtDsc PedCnt PedPre PedImp ) PedTot

o:

ArtCod* ArtDsc ( PedNro* PedFch PrvCod PrvNom AnlNro AnlNom PedTot PedCnt PedPre PedImp )

Se debe definir solo una de las dos estructuras, en este caso la correcta es la primera,porque el usuario ingresa los pedidos con sus Artículos y no para cada articulo quepedidos tiene.

Form de una transacción

Cada transacción puede tener varios forms asociados. Inicialmente GENEXUS crea unopor defecto partiendo de los atributos de la misma y luego se puede modificar. Se pueden


24

agregar o quitar forms a través de las opciones Edit/Add New Form o Edit/Select Forms.Tambien se puede seleccionar el form con el cual se desea trabajar seleccionándolo delcombo box que aparece en la toolbar.

También se puede asociar un style y aplicarlo. El style se asocia en cada objeto en laspropiedades del mismo.

Para los Proveedores la pantalla por defecto (en este caso en modo gráfico) es:

Utilizando solo esta pantalla el usuario final puede crear, modificar o eliminarproveedores. Para ello la pantalla tiene un Modo, que indica cual es la operación que seesta realizando (Insertar, Modificar, etc.) y el usuario puede pasarse de un modo a otro sintener que abandonar la pantalla.GENEXUS puede generar dos tipos de diálogo para las transacciones, full-screen o campoa campo.

Diálogo full-screen

Este tipo de diálogo se genera para las plataformas donde se utilizan terminales noprogramables, por ejemplo para el IBM AS/400.El funcionamiento básico del diálogo full-screen es:

1- Se aceptan todos los campos de la pantalla2- Se realizan todas las validaciones3- Si hubo error se muestran los mensajes de error y se vuelve al punto 1.4- Si no hubo error se pide confirmación, si no se confirma se vuelve a 1.

Atributos que seránaceptados o desplegadosen la pantalla


25

5- Si se confirma la operación esta es realizada y se vuelve a 1.

Este proceso tiene leves alteraciones según el modo (Insertar, Modificar, etc.), ya quesi se encuentra en modo Insertar se aceptan los identificadores, pero si se esta enmodo Modificar no, etc.El pasaje de un modo a otro se realiza presionando teclas de función. Por ejemplo conF6 se pasa a modo Insertar, con F11 a modo Modificar, etc.

Diálogo campo a campo

Para plataformas con terminales programables, como es el caso de PCs o LANs,GENEXUS genera las transacciones con una interfaz campo a campo.En este diálogo, cada vez que un campo es digitado inmediatamente se controla suvalidez.También trabaja con modos, pero con la diferencia que el modo es inferidoautomáticamente por el sistema. Por ejemplo cuando el usuario digita el PrvCod, sieste existe se pasa automáticamente a modo Modificar y si no existe se pasa a modoInsertar.

Barra o Botones de Menú

En ambos tipos de diálogo se encuentra disponible una Barra de Menú que tiene lasopciones para poder visualizar los distintos datos.

Por ejemplo, se puede elegir ver (para luego modificar) el primer proveedor , el

siguiente (a partir del que se esta mostrando en pantalla) o poder elegir uno en

particular .


26

Atributos de entrada y atributos de salida

Consideremos nuevamente la transacción de Pedidos pero sin sus Artículos. Lapantalla por defecto es:

Vemos que hay algunos atributos que deben ser digitados (son atributos de entrada),por ejemplo PedNro y PrvCod y otros que no, como ser PrvNom (son atributos desalida). GENEXUS automáticamente determina que atributos son aceptados y de cualessolo se muestra su valor, siguiendo las reglas:

• Solo pueden ser aceptados los atributos que se encuentran en la tablaasociada al nivel (en este caso son los atributos de la tabla PEDIDOS,PedNro, PedFch, PrvCod, AnlNro y PedTot).

• Los atributos definidos como fórmulas no son aceptados.• En modo Modificar no se aceptan los identificadores.• Los atributos que tienen una regla de Noaccept no son aceptados.

Facilidad de Prompt

Para los atributos que están involucrados en la integridad referencial de la tabla basedel nivel se genera la facilidad de Prompt que permite visualizar cual es el conjunto devalores validos para esos atributos. Por ejemplo, en la transacción de Pedidospresionando una tecla especial se puede visualizar cuales son todos los proveedores,con la siguiente pantalla:


27

en donde se puede seleccionar el proveedor. Observar que en la primera parte de lapantalla se permite digitar el PrvCod ,el PrvNom, o el PrvDir para poder posicionarseen la lista de proveedores. Esta lista es un work panel de GeneXus que puede sermodificado como cualquier otro objeto.

Diálogo para transacciones con varios niveles

Para el caso de transacciones con varios niveles se tiene un proceso de diálogo pornivel. Es decir se realiza la validación y la confirmación de los datos para cada uno delos niveles.Por ejemplo para la transacción de Pedidos (considerando ahora los Artículos delmismo) la pantalla por defecto es:


28

En ésta se aceptan primero los datos de entrada del primer nivel (los del cabezal delpedido: Numero, Fecha, Proveedor y Analista), posteriormente se validan y se pideconfirmación y luego se realiza el mismo proceso para cada una de las líneas delpedido.

Cuando se genera el form por defecto se diseña un subfile para el último nivel de latransacción, en el ejemplo las líneas del pedido.Trabajando con el form editor se puede transformar esta pantalla en la siguiente, quesimula mejor el formulario de pedidos:


29

Form Editor

Los objetos como las Transacciones o los Work Panels, tienen uno o varios Formulariosasociados. A los efectos de permitir modificar los Formularios que GENEXUS

automáticamente crea por defecto, se provee un Form Editor. Este Form Editor es igualpara todos los objetos que tienen Formularios.El Formulario está formado por un marco de ventana (frame) cuyo título es la descripciónde la transacción. Dentro de ella figurarán los distintos tipos de controles de edición delFormulario.

Form Edition Controls

En un Formulario se definen ‘controles’. Un control es una área del Formulario quetiene una forma y un comportamiento determinado. Existen los siguientes tipos decontroles:


30

Atributo. Se utiliza para representar atributos o variables.

Texto. Todo fragmento de texto fijo en la pantalla debe colocarse utilizando uno omás controles de este tipo.

Línea. Con este control se dibujan líneas horizontales o verticales.

Recuadro. Permite definir recuadros de distintos tamaños y formas.

SubFile. Permite definir SubFiles. La definición de los subfiles se vera mas adelanteen el capitulo de Work Panels.

Botón. Permite definir Botones (también llamados Command Buttons).

Bitmap. Permite definir bitmaps estáticos en la pantalla.Cada control tiene una serie de propiedades (ancho de línea, color, color de fondo,font, etc.), cuyos valores pueden fijarse en forma independiente.

Tab. Permite definir varios controles dentro de otro. Un Tab control tiene una ovarias Paginas y cada Pagina tiene un Title y un area util donde se ponen loscontroles de esa pagina. Solo una de las paginas puede estar activa a la vez y es la quese puede ver, del resto solo se vera su titulo. Esto es util para cuando se quiere dividirlos datos ingresados en la transaccion en distintos grupos de modo que las pantallasqueden diseñadas de forma amigable al usuario (transacciones con muchos atributos).

Paleta de herramientas

Mientras se está editando un Formulario, está disponible la paleta de herramientas, enla forma de una ventana adicional, con los botones que representan los tipos decontroles disponibles.


31

Uso de las Herramientas

Sobre los objetos seleccionados con el puntero vamos a poder realizar variasoperaciones:

• Cambiar el tamaño y forma de un control. • Edición de propiedades. • Move Forward, Move Back, Move to Front y Move to Back. Estas

operaciones nos van a permitir cambiar la capa en que se encuentra uncontrol. Cada control se encuentra en una capa distinta del Formulario,por lo que algunos están "más arriba" que otros. Cuando dos objetos sesuperpongan, el de más arriba será visible totalmente, mientras que elotro sólo en aquellos puntos en que no se encuentre "tapado".

• Move, Copy y Delete.

Toolbar

El Form Editor Toolbar nos permite ubicar los controles en el form, y copiar eltamaño de otros controles ya definidos:

Toolbar

Alinear a la izquierda. Separar horizontalmente.

Alinear a la derecha. Separar verticalmente.

Alinear al borde superior. Igualar ancho.

Alinear al borde inferior. Igualar altura.

Centrar verticalmente. Igualar tamaño.

Centrar horizontalmente. Mostrar Grid


32

Propiedades de los controles

Vamos a ver las principales propiedades de cada unos de los controles que podemosinsertar en un form.

Atributo

Name. En esta opción se permite ingresar un nombre al control que se esta editando.Este nombre será usado luego para asociarle propiedades o eventos al control.

Array Indices. En el caso de utilizarse variables que sean matrices, se habilitan estasopciones, donde se pueden indicar expresiones que definan la fila y la columna.


33

Frame. Se puede indicar que el atributo esté rodeado por un marco. Es posible indicarel tipo: None, Single o 3D; el ancho de la/s línea/s (Width), si se pinta dentro de él ono (Fill) y si el tamaño y forma deben determinarse a partir del atributo (Auto Resize).

Font. Permite seleccionar el font que se utilizará para el atributo en la pantalla.

Control Info

Control Type. En los Formularios generados el atributo podrá asociarse a distintostipos de controles Windows. Se puede seleccionar uno de los siguientes: Combo Box,Dynamic Combobox, Radio Button, Edit, List Box, Dynamic List Box y Check Box.El botón de Setup permite definir características propias a cada tipo de control.Dentro

Fore Color. Este botón es para seleccionar el color con el que se desplegará el valordel atributo y la/s línea/s del frame, si tuviera.

Back Color. Con este botón se puede seleccionar el color con el que se pinta el áreaasignada al atributo en la pantalla. Sólo tiene efecto si está presente la propiedad Fill.


34

Texto

Text. Indica el texto que se quiere insertar en la pantalla. Puede consistir de una o máslíneas.

Alignment. El texto puede estar justificado a la izquierda (Left), derecha (Right) ocentrado (Center).

Resto de las propiedades. Ver control de Atributo.


35

Recuadro

Del combo box se selecciona el tipo del borde del recuadro: single, none (sin borde) o3D.Para el resto de las propiedades ver la explicación en el control de Atributo.

Línea

Utiliza el mismo diálogo de edición de propiedades con la salvedad de que la opciónFill aparece deshabilitada.

Editor de Propiedades, Métodos y Eventos

A los controles (que tienen nombre asociado) que usamos en los forms se le puedenasociar propiedades, métodos o eventos, por ejemplo: cambiarle el font a un texto,hacer un texto visible o invisible, deshabilitar un botón, etc. El tipo depropiedades/eventos que se pueden asociar a un control depende del tipo de control.Para acceder al dialogo donde poder asociar propiedades a los controles se usa laopción de menú Insert/Property (o Insert/Event) cuando se esta editando los eventos,rules o subrutinas de la transacción. El dialogo que aparece es el siguiente:


36

Fórmulas

Se dice que un atributo es una fórmula si su valor se puede calcular a partir del valor deotros atributos.

En el ejemplo el atributo PedImp de la transacción de Pedidos se puede calcular a partirde la PedCnt y el PedPre:

PedImp = PedCnt * PedPre

En cada transacción se puede definir que atributos son fórmulas, pero esta definición esglobal, es decir toda vez que se necesite el atributo se calcula la fórmula, tanto entransacciones como en los otros objetos GENEXUS (reportes, Paneles de Trabajo, etc.).

Existen distintos tipos de fórmulas:

• Horizontales

• Verticales

• De agregación/selección


37

Fórmulas Horizontales

Una fórmula horizontal se define como una o varias expresiones aritméticascondicionales. Por ejemplo:

Descuento = PedTot * 0.10 if PedTot > 100 .and. PedTot <= 1000;

= PedTot * 0.20 if PedTot > 1000;

= 0 OTHERWISE;

En donde el Descuento será del 10% si el total del pedido esta entre 100 y 1000 y del20% si es mayor y en cualquier otro caso no hay descuento (en las fórmulas concondiciones es saludable definir siempre el OTHERWISE).

La expresión puede utilizar los operadores aritméticos (+. -, *, /, ^) y funciones (porejemplo 'today()' que devuelve la fecha del día), y para los casos en donde el calculoes muy complicado se puede llamar a una rutina que lo realice en vez de usarformulas:

Descuento = udf('Pdesc', PedTot);

En donde 'udf' viene de User Defined Function. 'Pdesc' es el nombre de la rutinallamada, que recibe como parámetro a PedTot y devuelve Descuento. Esta rutinapuede ser una rutina externa a GENEXUS o escrita con GENEXUS utilizando el objetoProcedure.El importe del pedido también es una fórmula horizontal:


Vemos que la forma de definirla involucra a dos atributos (PedCnt y PedPre), pero nose indica en que tablas de encuentran. GENEXUS se encarga de buscar la manera derelacionar PedCnt y PedPre para poder calcular la fórmula (en este caso es muy fácilporque PedCnt y PedPre se encuentran en la misma tabla). En los casos en que no esposible relacionar a los atributos GENEXUS da un mensaje de 'fórmula invalida'.Ahora bien, cuales son los atributos que pueden estar involucrados?. La respuesta es:en una fórmula horizontal todos los atributos de los cuales depende la fórmula debenestar en la misma tabla extendida que la fórmula (ver el concepto de tabla extendidaen el anexo sobre Bases de Datos Relacionales).


38

Cuando se define una fórmula horizontal GENEXUS 'sabe' cual es la tabla extendida ycontrola que todos los atributos utilizados se encuentren en ella.

Fórmulas Verticales

Consideremos ahora el Total del pedido (PedTot), este se debe calcular sumando losImportes (PedImp) de cada una de las líneas del Pedido. Esta fórmula se expresacomo:

PedTot = SUM( PedImp )

Y es un caso de fórmula vertical, que se define como el tipo de fórmula en que losatributos involucrados no se encuentran dentro de la misma tabla extendida que lafórmula. En el caso de PedTot, si observamos el modelo de datos (usando el diagramade tablas de GENEXUS ):

Tenemos que PedTot esta en la tabla PEDIDOS y PedImp en la PEDIDOS1 que esuna tabla subordinada a la PEDIDOS.Podemos utilizar también el Database Browser de GENEXUS para determinar quetablas están subordinadas y superordinadas a la de pedidos (eligiendo la opciónSuperordinated o Subordinated del dialogo del browser):

Tabla: PEDIDOS PedNro* PedFch PrvCod AnlNro PedTot

Tabla: PEDIDOS1 PedNro* PedLinNro* ArtCod PedCnt PedPre PedImp

1

N


39

Además de ver que tablas tiene subordinadas y superordinadas, podemos consultar laestructura de una tabla, que índices tiene (composición de los índices), fórmulas, etc.

Existen dos operadores para fórmulas verticales: SUM que suma todos los datos yCOUNT que cuenta cuantos datos hay.

Fórmulas y Redundancia

En base a los criterios de normalización y dado que por definición una fórmulasiempre puede ser calculada, no es necesario que la misma este almacenada y bastacon recalcularla cada vez que sea necesario.Sin embargo el hecho que la fórmula no este almacenada puede ocasionar problemasde performance, debido al tiempo que pueda demorar el recálculo.Para evitar este inconveniente se puede definir la fórmula como REDUNDANTE. Eneste caso la fórmula se almacena en la Base de Datos y no es necesario recalcularla

Tablassuperordinadas aPedidos


40

cada vez que se use. Una vez que la fórmula es definida como redundante, GENEXUS

se encarga de agregar todas las subrutinas de mantenimiento de redundancia a todaslas transacciones que utilicen esa fórmula.Tenemos entonces que la definición de fórmulas redundantes implica un balance deperformance por un lado y almacenamiento y complejidad de los programasgenerados en otro, que el analista debe decidir. Si bien en teoría esta decisión puedeser bastante difícil de tomar, en la practica vemos que la mayor parte de las fórmulasque se definen redundantes son las verticales (mas adelante veremos que hay unaforma muy fácil de hacerlo) y pocas veces las horizontales.La razón de esto es que el calculo de las fórmulas verticales pueden insumir unnúmero indeterminado de lecturas. Por ejemplo para calcular el PedTot se deben leertodas las líneas del pedido, que pueden ser una cantidad bastante grande.

Fórmulas de Fórmulas

Una fórmula se calcula a partir del valor de otros atributos. Dichos atributos puedenestar almacenados o ser otras fórmulas. Por ejemplo si en la transacción deProveedores definimos:

PrvTotPed = SUM( PedTot ) Total pedido del proveedor

tenemos que para calcularlo se necesita:

PedTot = SUM( PedImp )

que a su vez necesita:


Para fórmulas de fórmulas GENEXUS determina cual es el orden de evaluacióncorrespondiente:

PedImp = PedCnt * PedPrePedTot = SUM( PedImp )PrvTotPed = SUM( PedTot )


41

Reglas

Según el Análisis Orientado a Objetos, para cada objeto del sistema se debe definir cuales su estructura y cual su comportamiento. En el caso de las transacciones ya vimos ladefinición de la estructura. Para definir el comportamiento se usan las REGLAS.Usando reglas se definen valores por defecto, controles, etc. Veremos algunas de lasreglas:

Default

Se utiliza para definir los valores por defecto de algunos atributos, por ejemplo:

default( PedFch, today() );

El funcionamiento del default varia según el tipo de diálogo (full-screen o campo acampo). En el diálogo full-screen se asigna el valor por defecto si el usuario no digitonada en el campo. En el diálogo campo a campo primero se asigna el valor pordefecto y luego se permite modificarlo.

Error

Es la regla para definir los controles que deben cumplir los datos, por ejemplo siqueremos que el precio del articulo pedido sea siempre mayor que 100:

error( 'El precio debe ser mayor que 100') if PedPre <= 100 ;

Cuando se cumple la condición ( PedPre <= 100 ) se despliega el mensaje ( 'El preciodebe ser mayor que 100' ) en pantalla y no se permite continuar hasta que el usuarioingrese un valor correcto o abandone la transacción.

Una utilización relativamente común es incluir una regla de error() para prohibiralguna de las modalidades de la transacción:

error( 'No se permite eliminar Pedidos' ) if delete;

Con esta regla se prohibe que el usuario entre en el modo eliminación y así se prohibela eliminación de Pedidos.

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


42

las tablas que pertenecen a la tabla extendida del nivel. Veamos un ejemplo, en latransacción de Artículos:

Artículos: ArtCod* ArtDsc ArtCnt ArtFchUltCmp ArtPrcUltCmp

En el atributo ArtPrcUltCmp se desea almacenar cual fue el precio del último pedidorealizado para ese articulo, y en que fecha fue realizado en ArtFchUltCmp. Esto serealiza definiendo en la transacción de Pedidos las siguientes reglas:

ArtPrcUltCmp = PedPre if insert;ArtFchUltCmp = PedFch if insert;

Así cada vez que se ingrese una línea del pedido se actualiza la tabla de Artículos conla fecha y el precio correspondiente.

Existe una similitud entre fórmulas y asignaciones, incluso la sintaxis de definición essimilar. La diferencia entre ambas es que una fórmula es GLOBAL, es decir vale paratodos los objetos GENEXUS que la utilicen, mientras que una Asignación es LOCAL,vale solo para la transacción en la cual fue definida.Cuando un atributo es fórmula este no esta almacenado (a no ser que se lo definacomo redundante) y cuando es una Asignación, por ser esta local, si esta almacenado.

Add y Subtract

Las asignaciones que vimos en la sección anterior eran relativamente fáciles, peroexisten casos mas sofisticados. Por ejemplo en la misma transacción de Artículostenemos el atributo ArtCnt en donde se quiere mantener cual es el stock que tenemosde cada articulo.Sin duda la transacción de Pedidos debe modificar ese valor, porque cada pedidonuevo aumenta el stock. También existirá alguna otra transacción que hace disminuirel stock, que podría ser por ejemplo una transacción de Facturación que se realizacuando se vende el articulo. Como esta transacción esta fuera del alcance del proyectosolo estudiaremos la actualización del stock relacionada con la transacción dePedidos.

En dicha transacción se debe actualizar ArtCnt, esto se podría hacer con laAsignación:


43

ArtCnt = ArtCnt + PedCnt;

Pero no debemos olvidar que en la misma transacción se permite crear, modificar oeliminar un pedido, y la asignación anterior solo es correcta si se esta creando unonuevo, ya que si por ejemplo se está eliminando, la asignación correcta es:

ArtCnt = ArtCnt - PedCnt;

Entonces, para actualizar ArtCnt correctamente se necesitaría también considerar loscasos de modificación y eliminación, pero para evitar todo esto GENEXUS posee laregla add() que lo hace automáticamente:

add(PedCnt, ArtCnt);

Con esta regla si se esta insertando una línea del pedido se suma la PedCnt a ArtCnt,si se esta eliminando se resta y si se esta modificando le resta el valor anterior dePedCnt (que se define como old(PedCnt) ) y le suma el nuevo valor.Existe una dualidad entre la fórmula vertical SUM y la regla ADD, masconcretamente se puede decir que un SUM redundante es equivalente a la regla ADD.Por ejemplo el PedTot se puede definir como:

PedTot = SUM( PedImp ) y redundanteoadd( PedImp, PedTot );

Dado que es común que las fórmulas verticales tengan que estar redundantes paratener buena performance se recomienda el uso de la regla ADD y no la fórmula SUM.La regla SUBTRACT es equivalente pero realiza las operaciones contrarias, es decircuando se esta insertando resta, en caso de eliminación suma, etc.

Serial

Esta regla es útil cuando se quiere asignar automáticamente valores a algúnidentificador de la transacción. Por ejemplo en la transacción de Pedidos tenemos elPedLinNro y si queremos que este número sea asignado automáticamente por elsistema se puede usar la regla:

serial(PedLinNro, PedUltLin, 1);

En donde el primer parámetro define cual es el atributo que se esta numerando, elsegundo indica cual es el atributo que tiene el último valor asignado (aquí se trata delúltimo número de línea asignado) y el tercer parámetro el incremento (en este caso seincrementa de a uno). El atributo PedUltLin (Ultima línea asignada) debe ser incluido


44

en la estructura de la transacción en el nivel de PedNro (un pedido solo tiene UNAUltima línea asignada):

PedNro* .... PedUltLin ( PedLinNro* .... ) PedTot

De esta manera para cada nueva línea del pedido el programa asigna automáticamentesu número.En el diálogo campo a campo (donde la modalidad era inferida automáticamente), sedebe digitar un valor inexistente en PedLinNro (usualmente 0) y el programa asigna elvalor correspondiente.En el diálogo full-screen el valor se asigna cuando el usuario presiona Enter en modoInsertar.

Orden de evaluación

La definición de reglas es una forma DECLARATIVA de definir el comportamientode la transacción. El orden en el cual fueron definidas no necesariamente indica queese sea el orden en que se encuentran en el programa generado.GENEXUS se encarga de determinar el orden correcto según las dependencias deatributos existentes.

Veamos un ejemplo:

Supongamos que definimos en la transacción de Artículos un nuevo atributo:ArtCntMax, del mismo tipo que ArtCnt. Este atributo indicará el stock máximo quese desea tener de ese artículo.Cuando se ingresa un pedido debemos emitir un mensaje si se sobrepasa el stockmáximo de un artículo. Para ello definimos las siguientes reglas en la transacción depedidos:

msg( 'Se sobrepasa el stock máximo del artículo' ) if ArtCnt > ArtCntMax;


El orden de evaluación será:


45


msg( 'Se sobrepasa el stock máximo del artículo' )if ArtCnt > ArtCntMax;

Ya que la regla add() modifica ArtCnt y la regla msg() utiliza ese atributo.Esto implica que en la regla msg() se debe preguntar por ArtCnt mayor queArtCntMax y no por ArtCnt + PedCnt mayor que ArtCntMax.

Cada vez que se especifica una transacción se puede pedir la opción -"DetailedNavigation"- que lista cual es el orden de evaluación. En este listado se explícita enque orden se generarán (usualmente decimos 'se disparan'), no solo las reglas, sinotambién las fórmulas y lecturas de tablas.

Call y función After

Otra regla muy usada es CALL, con la cual se permite llamar a otro programa. Estepuede ser cualquier otro objeto GENEXUS, por ejemplo, de una transacción se puedellamar a un reporte o a otra transacción, o un programa externo.En el caso de la regla Call es necesario precisar en que MOMENTO se debe dispararel Call. Por ejemplo, si en la transacción de Pedidos se quiere llamar a un reporte queimprime el pedido que se acaba de ingresar, se utiliza la regla:

call('RIMPREC', PedNro) if after( trn ) ;

En donde 'RIMPREC' es el programa llamado y PedNro es el parámetro que se lepasa. Al tener after(trn), el Call se realizará después de haber entrado todo el Pedido.El uso de after() no es privativo de la regla Call y puede ser utilizado en otras reglas,como ser error o Asignación.Los after() existentes son:

Confirm

La regla se dispara después de haber confirmado los datos del nivel pero antes dehaber realizado la actualización. Se usa para algunos casos de numeración automáticacuando no se quiere utilizar la regla serial para evitar problemas de control deconcurrencia.


46

Insert | Update | Delete

Se dispara después de haber insertado, actualizado o eliminado el registro de la tablabase del nivel. Se usa fundamentalmente para llamar a procesos que realizanactualizaciones.

Level

Se dispara después de haber entrado todos los datos de un nivel. Se usa muchas vecespara controles de totales, por ejemplo, si cuando se entra el cabezal del Pedido sedigita un total (llamémosle PedTotDig) y se quiere verificar que este sea igual que eltotal calculado la regla es:

error( 'El total digitado no cierra con el calculado' ) if PedTotDig <>PedTot .and. after( level( ArtCod) );

En donde el control recién se realizará cuando se terminaron de entrar todas las líneasdel pedido.

Trn

Se dispara después de haber entrado todos los datos de una transacción. Se usafundamentalmente para llamar a programas que imprimen los datos o a otrastransacciones. En ambientes con integridad transaccional esta regla se dispara luegoque se realiza el commit de la transacción.

Propiedades

En el editor de propiedades de las transacciones se pueden definir reglas decomportamiento general. A continuación vemos la pantalla para la edición de las mismas:


47

Por ejemplo vamos a setear propiedades que estén asociadas con el manejo de laintegridad transaccional y con la interface. Podemos indicar si deseamos que latransacción haga un commit al final o que no deseamos que se pidan confirmaciones cadavez que se actualiza un nivel, etc.


48

DISEÑO DE REPORTES

Con Reportes se definen los procesos no interactivos de extracción de datos. Usualmenteun Reporte es un listado que se envía a la impresora, aunque también puede servisualizado en pantalla.

Es un proceso no interactivo, porque primero se extraen los datos y luego se muestran, nohabiendo interacción con el usuario durante el proceso de extracción, y es solo deextracción ya que no se pueden actualizar los datos leídos. Para consultas interactivas seutilizan los Paneles de Trabajo y para los procesos de actualización los Procedimientos.

Para cada Reporte se debe definir:

InformaciónDatos generales del Reporte, por ejemplo nombre, descripción, etc.

LayoutAsí como las Transacciones tienen una pantalla los Reportes tienen un layout de la salida.

CondicionesQué condiciones deben cumplir los datos para ser impresos.

Reglas - PropiedadesDefinen aspectos generales del Reporte.

AyudaTexto para la ayuda a los usuarios en el uso del Reporte.

DocumentaciónTexto técnico para ser utilizado en la documentación del sistema.

Layout

En el Layout se define simultáneamente la estructura de la navegación (que datos sequieren listar y en que orden) y el formato de la salida. Para ello se utiliza un lenguajeprocedural muy simple que describiremos brevemente a continuación.Comencemos por un Reporte para listar todos los proveedores:


49

En donde tenemos los comandos Header, End, For each y Endfor. Para describir másfácilmente el funcionamiento de estos comandos veamos el resultado de ejecutar elprograma generado correspondiente:

Literales

AtributosBloque decódigo

Bloque deimpresion


50

La definición de reportes se divide en uno o varios bloques. Estos bloques pueden ser decódigo o de impresión . En los bloques de impresión se diseña la salida queposteriormente será impresa. Cada bloque de impresión puede tener un conjunto decontroles (atributos, variables, textos, etc.). Podemos ver un bloque de impresión como unpedazo de papel. Los bloques de impresión (o Print Blocks) tienen asociadas ciertaspropiedades, que pueden seteadas desde un dialogo que se abre al hacer doble-click sobreel bloque de impresión, como ser: los colores a usar, el tipo de papel, el tipo de letra, etc.El dialogo es el siguiente

Para el diseño de los bloques de impresión tenemos disponible una paleta de herramientassimilar a las transacciones.


51

La cual permite insertar atributos, textos, líneas, recuadros, bitmaps y nuevos bloques deimpresión. Los controles son definidos de la misma forma en que se hace en el editor delform de las Transacciones (tipo de letra, color, tamaño, etc.).

Todos los bloques de impresión que se encuentren entre los comandos HEADER y ENDson las líneas que se imprimen en el cabezal de la pagina. También existe el comandoFOOTER que permite imprimir un pie de página en cada hoja.

El comando FOR EACH indica que se impriman todos los bloques de impresión que seencuentren entre el FOR EACH y el ENDFOR para cada uno de los datos que seencuentren en la base de datos. En este caso:

se debe imprimir para cada uno de los proveedores.

Comando FOR EACH

Este es, quizás, el comando más importante en los Reportes ya que toda la definicióndel acceso a la base de datos y la estructura del reporte se realizan solo con estecomando.Usando el FOR EACH se define la información que se va a leer de la base de datos,pero la forma de hacerlo se basa en nombrar los atributos a utilizar y NUNCA seespecifica de que tablas se deben obtener, ni que índices se deben utilizar. Por lotanto, con este comando se define QUE atributos se necesitan y en qué ORDEN sevan a recuperar, y GENEXUS se encarga de encontrar COMO hacerlo. Obviamenteesto no siempre es posible, y en estos casos GENEXUS da una serie de mensajes deerror indicando porque no se pueden relacionar los atributos involucrados.La razón por la cual no se hace referencia al modelo físico de datos es para que laespecificación del Reporte sea del mas alto nivel posible, de tal manera que antecambios en la base de datos la especificación del mismo se mantenga valida la mayorparte de las veces.El acceso a la base de datos queda especificado por los atributos que son utilizadosdentro de un grupo FOR EACH - ENDFOR. Para ese conjunto de atributos GENEXUS

buscará la tabla extendida que los contenga (el concepto de tabla extendida es muyimportante en este comando y sugerimos repasar su definición en el Anexo sobreModelos de Datos Relacionales).Por ejemplo, en el Reporte anterior dentro del FOR EACH - ENDFOR se utilizan losatributos PrvCod, PrvNom y PrvDir, GENEXUS 'sabe' que estos atributos seencuentran en la tabla PROVEEDO y por lo tanto el comando:

PrvCod PrvNom PrvDir


52

For each

Endfor

es interpretado por GENEXUS como:

For each record in table PROVEEDO

Endfor

Para clarificar el concepto hagamos un Reporte que involucre datos de varias tablas.Por ejemplo, listar el cabezal de todos los pedidos:

Fecha: 09/08/92 Listado de Pedidos

Número Fecha Nombre Proveedor Nombre Analista 321 02/02/92 ABC Inc. Juan Gomez 654 03/03/92 GXXXX Corp. Juan Gomez 987 03/03/92 ABC Inc. Pedro Perez




53

El layout para este listado es:

Si recordamos el modelo de datos definido en el capítulo Diseño de Transacciones, elDiagrama de Bachman es:


54

En el listado anterior se requieren datos de las tablas PROVEEDO (PrvNom),ANALISTA (AnlNom) y PEDIDOS (PedNro y PedFch). La tabla extendida dePEDIDOS contiene a todos estos atributos y por lo tanto el comando FOR EACH seinterpretará como:

For each record in table PEDIDOS Find the corresponding PrvNom in table PROVEEDO Find the corresponding AnlNom in table ANALISTA

Endfor

Cuando se especifica un Reporte, GENEXUS brinda un listado (que llamaremosListado de Navegación) donde se indica cuales son las tablas que se estánaccediendo, en este caso el listado es:

AnlNomPrvNomPedFchPedNro


55

FOR EACH PEDIDOS (Line 6) Order : PedNro Index : IPEDIDOS Navigation filters: Start from: First record Loop while: Not end of table

---->> PEDIDOS ( PedNro ) | +-----> ANALISTA ( AnlNro ) | +-----> PROVEEDO ( PrvCod )

END FOR

Donde la flecha doble ( --->> ) indica cual es la tabla base de la tabla extendida y laflecha simple ( ----> ) las tablas N-1 de la misma. Una interpretación muy práctica deeste diagrama es: para la tabla de la flecha doble se leen muchos registros y para cadatabla con flecha simple se lee un solo registro por cada registro leído en la tabla conflecha doble.

Orden

En los Reportes anteriores no se tuvo en cuenta en que orden se deben listar los datos.Cuando no se indica el orden, GENEXUS busca un orden que favorezca la performancedel Reporte.Para los casos en donde se quiere definir el orden de los datos de forma explícita seutiliza la cláusula ORDER en el comando FOR EACH, por ejemplo, para listar lospedidos ordenados por PrvCod:

For each ORDER PrvCod

Endfor

En este caso el índice a utilizar será el IPEDIDO2 (PrvCod) de la tabla PEDIDOS,que fue definido automáticamente por GENEXUS. La navegación para este reporte esla siguiente:


Tablas a las cualesaccede.


56

FOR EACH PEDIDOS (Line 6) Order : PrvCod Index : IPEDIDO2 Navigation filters: Start from: First record Loop while: Not end of table

---->> PEDIDOS ( PedNro ) | +-----> ANALISTA ( AnlNro ) | +-----> PROVEEDO ( PrvCod )

END FOR

Si al listado anterior lo queremos ordenar por PedFch:

For each ORDER PedFch

Endfor

Como no hay ningún índice definido en la PEDIDOS para PedFch, GENEXUS crearáun índice por PedFch cada vez que se ejecute el Reporte y lo eliminará al finalizar elmismo y en el Listado de Navegación indicará que esta creando un 'índice temporario'.

Navegación:A temporary index will be created for PedFch on table PEDIDOS

Obviamente este proceso es más lento si lo comparamos con el listado anterior endonde había un índice definido. Dada esta situación el analista debe tomar unadecisión:Crear un índice del usuario. En este caso el Reporte será bastante más eficiente, perose debe mantener un índice más (lo que implica mayor almacenamiento y mayorprocesamiento en las transacciones para mantener actualizado el índice).Dejar el Reporte con el índice temporario.


indiceseleccionado


57

No es posible recomendar, a priori, cual de las dos soluciones es la mejor, por lo tantose debe estudiar caso por caso la solución particular, siendo fundamental la frecuenciacon que se ejecutará el Reporte. De cualquier manera si al comienzo no se definió elíndice y posteriormente se decide cambiar y definirlo, alcanza con regenerar elReporte (sin modificar nada del mismo) y éste pasará a utilizarlo.Los criterios de ordenamiento utilizado por GENEXUS son:Cada grupo FOR EACH puede estar ordenado por CUALQUIER conjunto deatributos pertenecientes a la tabla base del grupo, pero no se puede ordenar poratributos que NO se encuentren en la misma. Por ejemplo el listado anterior no sepuede ordenar por PrvNom porque la tabla base del grupo es la PEDIDOS que notiene PrvNom.Si no existe un índice para el orden pedido se crea un índice temporario que seeliminará al finalizar el Reporte. Observar que este proceso es análogo a realizar unSORT cuando se trabajaba con archivos tradicionales.

Condiciones en el FOR EACH

Para restringir los datos que se quieren listar se utiliza la cláusula WHERE. Porejemplo, para listar sólo los pedidos de hoy:

For each WHERE PedFch = Today()

Endfor

Se puede definir varios WHERE dentro del FOR EACH:

For each WHERE PedFch = Today() WHERE PedNro > 100

Endfor

Que significa que se deben cumplir AMBAS condiciones, o sea que se interpretacomo que ambas cláusulas están relacionadas por un AND. Si se quiere utilizar un OR(es decir se desea que se cumpla alguna de las dos condiciones) se debe utilizar unsolo WHERE:

For each




58

WHERE PedFch = Today() OR PedNro > 100

Endfor

GENEXUS posee una serie de mecanismos para optimizar el Reporte en función delorden del FOR EACH y de las condiciones del mismo, pero estas se aplican sólo a lascondiciones que tienen la siguiente forma:

WHERE <atributo> <operador> <valor><código1>

WHEN NONE<código2>

Donde:<atributo> debe estar almacenado en la tabla base.<operador> debe ser = o >=.<valor> puede ser una constante o una variable.<código2> se ejecuta solo cuando no se entra en el For Each

En muchos casos es necesario ejecutar determinado código cuando en un For Each nose encuentra ningún registro. Para esto se usa el comando WHEN NONE. Esimportante aclarar que si se incluyen For Eachs dentro del When None no se infierenJoins ni filtros de ningún tipo con respecto al For each que contiene el When None.

Cuando la condición ha sido optimizada en el Listado de Navegación aparece como'Navigation Filter' y cuando no, como 'Constraint'.Tener en cuenta que cuando la condición tiene esta forma se realizara algún tipo deoptimización, pero no quiere decir que otras formas no sean válidas, al contrario, en elWHERE se pueden definir condiciones para atributos que son fórmulas, que no seencuentran en la tabla base, etc.

Determinación de la tabla extendida del grupo FOR EACH

Resulta muy útil saber cómo GENEXUS determina la tabla extendida que se debeutilizar. El criterio básico es:Dado el conjunto de atributos que se encuentran dentro de un grupo FOR EACH -ENDFOR, GENEXUS determina la MINIMA tabla extendida que los contenga.Consideremos nuevamente el listado:



59

For each

Endfor

Según ya vimos todos estos atributos se encuentran dentro de la tabla extendida dePEDIDOS, sin embargo, también se encuentran dentro de la tabla extendida dePEDIDOS1 (Línea del pedido), pero la tabla extendida de PEDIDOS está contenidaen la de PEDIDOS1 (porque justamente la de PEDIDOS1 contiene a la de PEDIDOSademás de otras tablas), y por lo tanto será la elegida por GENEXUS.Para que GENEXUS pueda determinar cual es la tabla extendida del grupo FOR EACHdebe haber por lo menos un atributo que pertenezca a la tabla base. Por ejemplo, en elReporte que estamos realizando hay dos atributos pertenecientes a la tabla basePEDIDOS (PedNro y PedFch), si ellos no estuvieran y el listado fuera:

For each

Endfor

se podría argumentar que la tabla extendida de PEDIDOS continúa siendo válida, sinembargo por razones de simplicidad GENEXUS en este caso indicará que no hayrelación entre estos dos atributos y será necesario que se utilice algún atributo de latabla PEDIDOS para poder generar el Reporte.También puede darse el caso que exista más de una tabla extendida mínima quecontenga a los atributos del grupo FOR EACH - ENDFOR. Ante esta ambigüedadGENEXUS escoge la PRIMERA tabla extendida que cumpla con las condicionesanteriores.Para resolver estos dos problemas (no hay ningún atributo de la tabla base y hay másde una tabla extendida mínima posible), se utiliza la cláusula DEFINED BY dentrodel comando FOR EACH, por ejemplo:

For each Defined by PedFch

Endfor

AnlNomPrvNom




60

En el DEFINED BY se debe hacer referencia a por lo menos un atributo de la tablabase que se quiere.Aún en los casos que no se dan ninguno de los problemas anteriores se recomienda eluso del DEFINED BY para Reportes más o menos complejos porque mejora bastanteel tiempo de especificación del Reporte.

Reportes con varios FOR EACH

For Each anidados

Hasta ahora hemos definido reportes en donde existía un solo FOR EACH, pero esposible utilizar mas de un FOR EACH para realizar Reportes más sofisticados.Supongamos que queremos listar para cada proveedor cuales son sus pedidos, porejemplo:

El layout que se debe definir es (sólo se muestran los grupos FOR EACH):


61

Si colapsamos todos los print blocks, queda mas claro como se definen los FOREACH anidados.


62

En este Reporte tenemos dos FOR EACH anidados. Si analizamos el primer FOREACH vemos que utiliza sólo los atributos PrvCod y PrvNom y por lo tanto su tablaextendida será la de la tabla PROVEEDO, el segundo FOR EACH utiliza los atributosPedNro y PedFch y su tabla extendida será la de PEDIDOS. Pero el segundo FOREACH se encuentra anidado respecto al primero y a su vez la tabla PEDIDOS estasubordinada a PROVEEDO (por PrvCod) por lo tanto GENEXUS interpretara elReporte como:

For each record in table PROVEEDO .... For each record in table PEDIDOS

with the same PrvCod .... Endfor .... Endfor

Y así se listarán, para cada registro en la tabla de proveedores, cuales son sus pedidosen la tabla de pedidos.Más formalmente, cuando hay dos FOR EACH anidados, GENEXUS busca cual es larelación de subordinación existente entre la tabla base del segundo FOR EACH y latabla extendida del primer FOR EACH (en el caso anterior la relación era que la tablaPEDIDOS estaba subordinada a la tabla PROVEEDO por PrvCod) y establece de estamanera la condición que deben cumplir los registros del segundo FOR EACH (en el


63

ejemplo: todos los registros de la tabla PEDIDOS con el mismo PrvCod leído en elprimer FOR EACH).

Puede darse el caso en que no exista relación entre ambos FOR EACH, por ejemplo:

La tabla base del primer FOR EACH es la PROVEEDO (porque los atributos sonPrvCod y PrvNom) y la del segundo FOR EACH es la ANALISTA (porque losatributos son AnlNro y AnlNom) y no existe relación entre estas dos tablas extendidas.En este caso GENEXUS da el mensaje 'No existe relación directa' y hará el productocartesiano entre los dos FOR EACH, es decir, para cada registro de la tablaPROVEEDO (proveedores) se imprimirán todos los registros de la tabla ANALISTA(analistas).


64

Cortes de Control

Un caso particular de FOR EACH anidados son los llamados cortes de control.Supongamos que queremos listar los pedidos ordenados por fecha:


65

El layout es:

La tabla base del primer FOR EACH es la PEDIDOS (por usar PedFch) y la delsegundo FOR EACH también (por usar PedNro y PrvNom). Este es un caso de cortede control sobre la tabla PEDIDOS y GENEXUS lo indica en el Listado de Navegacióncon la palabra BREAK en vez de FOR EACH. Los cortes de control pueden ser devarios niveles, por ejemplo, si quisiéramos listar los pedidos por fecha y dentro decada fecha por proveedor:

For each order PedFch .... For each order PrvCod .... For each order PedNro .... Endfor

Endfor

Endfor

Cuando se definen cortes de control es MUY IMPORTANTE indicar el ORDEN enlos FOR EACH ya que es la forma de indicarle a GENEXUS por qué atributos se estárealizando el corte de control


66

For Each paralelos

También se pueden definir grupos FOR EACH paralelos, por ejemplo, si se deseanlistar los proveedores y los analistas en el mismo listado:

Los listados con FOR EACH paralelos son muy prácticos cuando se quiere hacerlistados del tipo 'Listar toda la Información que se tenga sobre un Proveedor', endonde el Layout será del tipo:

For each ... //Información del Proveedor For each .... // Información sobre Pedidos Endfor For each .... // Información sobre Precios Endfor .... Endfor


67

Otros comandos

En el Layout se pueden utilizar otros comandos además de los ya vistos. Noslimitaremos aquí a ver solo los más significativos (para un repaso exhaustivo de losmismos sugerimos ver el Reference Manual).

Definición de Variables

Antes de describir los comandos en si es bueno detenernos en el concepto deVariable. Ya vimos que los datos se almacenan en la base de datos en atributos, peromuchas veces se necesita utilizar Variables, que se diferencian de los atributos por serlocales al Reporte y no estar almacenadas en la base de datos. Una Variable esreconocida por GENEXUS por ser un nombre que comienza con &, por ejemplo&Today o &Aux.Existen algunas Variables predefinidas, es decir que ya tienen un significado propio,por ejemplo el ya visto &Today que es una variable con la fecha de hoy o &Page queindica cual es la página que se está imprimiendo, etc.Se deben definir las características (tipo, largo, decimales, etc.) de las variables que seestén utilizando en el Reporte, con excepción de las predefinidas.


68

Las variables se pueden definir también en función de otros atributos, usando laopción de Based On. Se recomienda utilizar esta opción siempre que sea posible.

Asignación

Este comando permite asignar valores a variables. Por ejemplo si queremos mostrartotales en un listado:


69


70

El layout es:

Comandos de Control

Los comandos de control son IF-ELSE-ENDIF y DO WHILE-ENDDO. El comandoIF-ELSE-ENDIF es muy utilizado para impresión condicional, es decir, imprimir unalínea solo cuando se cumple alguna condición.


71

En el ejemplo anterior:

El comando DO WHILE-ENDDO es muy usado para imprimir varias vías, porejemplo si se quiere imprimir dos vías del Pedido.

FOR EACH order PedNro &I = 0 DO WHILE &I < 2 &I = &I + 1 // Imprimir pedido .... ENDDOENDFOR

Llamadas a otros Programas y a Subrutinas

Con el comando CALL se puede llamar a otro programa, éste puede ser otro programaGENEXUS o un programa externo. El formato del comando es:

CALL( Program_name, Parameter1, ..., ParameterN)

Donde Program_name es el nombre del programa llamado y Parameter1 aParameterN son los parámetros que se envían, estos parámetros pueden ser atributos,variables y constantes. Los parámetros pueden ser actualizados en el programallamado.Cuando desde un Reporte se llama a otro Reporte, que también imprime, esimportante pasarle como parámetro la variable predefinida &Line (que contiene elnúmero de línea que se está imprimiendo) para que el Reporte llamado no comienceen una página nueva.


72

Con el comando DO se llama a una subrutina que se encuentra dentro del mismoLayout. En este caso no son necesarios los parámetros porque están disponibles parala subrutina los mismos datos (variables) que están disponibles en el lugar donde sehace el DO.

.... DO 'Nombre-Subrutina' ....

Sub 'Nombre-Subrutina' .... EndSub

Print if detail

Volvamos al listado de Pedidos por Proveedor:

Recordemos que el primer FOR EACH tenía como tabla base la PROVEEDO y elsegundo la PEDIDOS.


73

Ahora bien, el primer FOR EACH es independiente del segundo y por lo tanto seimprimirán los datos del primer FOR EACH ANTES de determinar si hay datos en elsegundo nivel y como consecuencia se van a imprimir TODOS los proveedores,independientemente de si tienen o no pedidos.Si se quiere que SOLO se impriman los proveedores que sí tienen pedidos se debeusar el comando Print if detail:

Este comando define que el FOR EACH en donde se encuentre debe usar como tablabase la misma tabla base del siguiente FOR EACH. En el ejemplo el primer FOREACH pasará a estar basado en la tabla PEDIDOS y no en la PROVEEDO y por lotanto solo se imprimirán los proveedores que tienen pedidos.Se debe tener en cuenta que, al pasar a estar los dos FOR EACH basados en la mismatabla base, se está definiendo implícitamente un corte de control. Por lo tanto seDEBE definir explícitamente el ORDEN en el primer FOR EACH.Existen otros comandos como ser EJECT (salta de hoja), NOSKIP, etc. que sedetallan en el Reference Manual.

Condiciones

Aquí se definen las condiciones que se quiere imponer a los datos a listar.


74

Es equivalente a la cláusula WHERE del comando FOR EACH (incluso tienen la mismasintaxis), con la diferencia que el WHERE se aplica a un solo FOR EACH y lascondiciones definidas aquí se aplicarán a TODOS los FOR EACH que correspondan. Enel Listado de Navegación se indica a que FOR EACH se están aplicando.Muchas veces se requiere que las condiciones no sean con valores fijos, sino que elusuario elija los valores cuando se ejecuta el Reporte. Por ejemplo, si en el Reporte quelista proveedores deseamos que liste un rango de ellos:

PrvCod >= ask('Ingrese Proveedor inicial: '); PrvCod <= ask('Ingrese Proveedor final : ');

Cuando se ejecuta el Reporte aparece la pantalla:

Donde se acepta el rango de proveedores a listar. El valor digitado por el usuario sealmacena en las variables &ask1, &ask2, etc. según el orden de aparición de los ask() enlas condiciones. Estas variables son útiles para imprimir cual fue el valor digitado.

Reglas

Se utilizan para definir aspectos generales del listado. Algunas de las reglas para Reportesson:

Default

Define el valor por defecto de los ask(). En el ejemplo anterior:

default(&ask1, 1);

default(&ask2, 9999);


75

Las variables &ask1 y &ask2 deben definirse y el orden (1,2,... ) es el de definición enlas condiciones.

Parm

Es una lista de atributos o variables que recibe el Reporte como parámetros. Porejemplo, si hacemos un Reporte para imprimir un pedido inmediatamente después dehaberlo digitado, en la Transacción se utiliza la regla:

call('RIMPREC', PedNro) if after(trn);

y el Reporte será:

Layout FOR EACH // Imprime el cabezal del pedido .... FOR EACH // Imprime las líneas del pedido .... ENDFOR ENDFOR

Reglas Parm(PedNro);

Cuando en Parm() se recibe un atributo, automáticamente este se toma como unacondición sobre los datos. En el ejemplo, al recibir como parámetro PedNro el primerFOR EACH (que esta basado en la tabla PEDIDOS que contiene PedNro) tiene comocondición que PedNro sea igual al parámetro y no es necesario poner un WHERE. Sise hubiera recibido el parámetro como una variable, entonces sí es necesario definir elWHERE.

Layout FOR EACH WHERE PedNro = &Pedido .... ENDFOR

Reglas Parm(&Pedido);


76

Report Wizard

El Report Wizard permite realizar el diseño del layout de los Reportes y Procedimientosde manera mas sencilla. Diseñemos nuevamente el reporte de pedidos por proveedor.

El diseño del layout consiste en dos pasos.

Paso 1: Requiere que se provea de una estructura de datos. Notar que dicha estructura dedatos debe incluir atributos definidos en las transacciones. La estructura de datos usaráuna estructura sintáctica similar a la usada en las transacciones, sin embargo, losparéntesis se usan para indicar niveles de FOR EACH (en vez de niveles de unatransacción) y el asterisco (‘*’) se usa para indicar el orden deseado (y no para indicar launicidad como en las transacciones). Las reglas que son usadas para definir la estructurade una transacción también se aplican al definir la estructura del layout.

Para diseñar nuestro reporte definimos una estructura en donde en el primer nivel tenemoslos datos del proveedor y en el segundo los del pedido. Esto va a generar dos for eachanidados en donde el exterior va a estar ordenado por código de proveedor y el internopor numero de pedido.Una vez que se ha definido correctamente la estructura, se presiona el botón de Next parapasar al siguiente paso.


77

Paso 2: Permite definir otras características del layout. Se permite elegir los fonts pararepresentar los atributos o textos, también se permite definir si los cabezales de losatributos para cada uno de los niveles se despliegan horizontalmente o verticalmente.

El dialogo del paso 2 para la estructura de datos usada en el paso 1 se ve de la siguientemanera:

Como se puede ver, el nivel para el cual estamos definiendo el tipo del layout sepresenta en un color diferente. Para este nivel, seleccionaremos el tipo vertical de layout ypara el segundo nivel nos aseguraremos que el check box correspondiente al tipo delayout vertical no este marcado, de esta manera el display del nivel interior seráhorizontal. En nuestro ejemplo cambiamos los fonts de los títulos, mientras que los de losatributos dejamos el default.Presionando el botón de “Finish” se graban las definiciones para el paso actual y se saledel dialogo del Report Wizard.


78

El reporte generado es el siguiente:

Una vez que todas las opciones del Wizard fueron aceptadas, se genera el layout delreporte, el cual puede ser modificado como cualquier otro reporte. Vemos que el diseñodel layout es idéntico al que definimos anteriormente en forma manual.

Properties

En el editor de propiedades de los reportes podemos definir:

Report Output: Si el reporte va a salir solo por pantalla, impresora o se le pregunta alusuario en tiempo de ejecución.

Prompt for Confirmation: Si deseamos que se pida confirmación al usuario.


79

Allow User to Cancel Processing.

Footer on Last Page: Imprimir el footer en la última pantalla.


80

DISEÑO DE PROCEDIMIENTOS

Los Procedimientos son el objeto GENEXUS con el que se definen todos los procesos nointeractivos de actualización de la base de datos y las subrutinas de uso general.Este objeto tiene todas las características de los Reportes (cualquier Reporte se puederealizar como un Procedimiento) más algunas características particulares para laactualización de la base de datos. Por esta razón se recomienda haber leído previamenteel capítulo Diseño de Reportes.Vamos a ver entonces los comandos disponibles en los procedimientos para laactualización de la base de datos

Modificación de datos

La modificación de datos de la base de datos se realiza de forma implícita, ya que nohay un comando específico de modificación (como podría ser REWRITE), sino quebasta con asignar un valor a un atributo dentro de un For Each para queautomáticamente se realice la modificación.

Por ejemplo supongamos que queremos tener un proceso batch que actualiza elatributo ArtPrcUltCmp para adecuarlo según la inflación para todos los Artículosalmacenados:

Programa:

For each ArtPrcUltCmp = ArtPrcUltCmp * (1 + &Inf) Endfor

Reglas: Parm( &Inf );

Se puede modificar más de un atributo dentro del mismo FOR EACH, por ejemplo, sitambién queremos modificar el atributo ArtFchUltCmp, poniéndole la fecha de hoy:

For each ArtPrcUltCmp = ArtPrcUltCmp * (1 + &Inf) ArtFchUltCmp = Today( ) Endfor


81

La modificación en sí se realiza en el ENDFOR y no cuando se realiza la asignacióndel atributo.En estos dos ejemplos se modificaron atributos de la tabla base del FOR EACH, perotambién es posible actualizar atributos de las tablas N-1 (tabla extendida) con elmismo mecanismo de asignación de atributos.No todos los atributos pueden ser modificados. Por ejemplo, no se pueden modificarlos pertenecientes a la clave primaria de la tabla base del FOR EACH (en este casoArtCod). Tampoco se pueden modificar los atributos que pertenecen al índice (elorden) con el que se está accediendo a la tabla base.En el Listado de Navegación se informa cuales son las tablas que se estánactualizando marcando con un + estas tablas. Por ejemplo:

------>> + ARTICULO

Eliminación de datos

Para eliminar datos se utiliza el comando DELETE dentro del grupo FOR EACH-ENDFOR. Por ejemplo, si queremos eliminar todos los pedidos con fecha anterior auna fecha dada:

For eachwhere PedFch < ask('Eliminar pedidos con fecha menor') defined by PedFch For each defined by PedCnt

// Se eliminan todas las lineas del pedido DELETE Endfor // Después de eliminar las lineas se elimina el cabezal DELETEEndfor

Creación de datos

Para crear nuevos registros en la base de datos se usan los comandos NEW-ENDNEW. Tomemos por ejemplo un Procedimiento que recibe como parámetrosAnlNro y AnlNom e inserta estos datos en la tabla de analistas:


82

Programa:New AnlNro = &Nro AnlNom = &Nom Endnew

Reglas:Parm( &Nro, &Nom );

Con este procedimiento se pueden crear registros en la tabla de analistas utilizando unasubrutina.El comando NEW realiza el control de duplicados, y solo creará el registro si ya no seencuentra en la tabla. Con la cláusula WHEN DUPLICATE se programa la acción arealizar en caso de duplicados. Por ejemplo, en el caso anterior si se quiere que si elanalista ya estaba registrado se actualice el AnlNom:

NewAnlNro = &NroAnlNom = &Nom

When DuplicateFor each AnlNom = &NomEndfor

Endnew

Observar que para realizar la modificación de atributos las asignaciones se debenencontrar DENTRO de un grupo FOR EACH-ENDFOR.

Controles de integridad y redundancia

En los Procedimientos el único control de integridad que se realiza automáticamente es elde control de duplicados en el comando NEW.Pero NO se controla automáticamente la integridad referencial, por ejemplo, si hacemosun Procedimiento que crea automáticamente Pedidos, no se controlará que el PrvCod quese cargue exista en la tabla de proveedores. O cuando se elimina el cabezal de un pedido,se debe tener esto en cuenta para eliminar las líneas del mismo explícitamente.El mismo criterio se aplica para las fórmulas redundantes. Estas deben ser mantenidasexplícitamente con los comandos de asignación/update.


83

DISEÑO DE PANELES DE TRABAJO

Con Paneles de Trabajo (o Work Panels) se definen las consultas interactivas a la base dedatos. Si bien éste es un objeto muy flexible que se presta para múltiples usos, esespecialmente útil para aquellos usuarios que utilizan el computador para pensar o paratomar decisiones.La forma de programar los Paneles de Trabajo esta inspirada en la programación de losambientes gráficos, especialmente la programación dirigida por eventos.

Para cada Panel de Trabajo se debe definir:

InformaciónDatos generales del Panel de Trabajo, por ejemplo nombre, descripción, etc.

FormAl igual que las transacciones, se debe definir el form con el que interactuará el usuario.

EventosAquí se define la respuesta a los eventos que pueden ocurrir durante la ejecución delPanel de Trabajo. Por ejemplo que respuesta dar cuando el usuario presionó Enter o unbotón, etc.

CondicionesDefine que condiciones deben cumplir los datos para ser presentados en la pantalla. Sonequivalentes a las Condiciones de los Reportes y Procedimientos.

ReglasDefinen aspectos generales del Panel de Trabajo, por ejemplo orden de los datos amostrar, parámetros, etc.

AyudaTexto para la ayuda a los usuarios en el uso del Panel de Trabajo.

DocumentaciónTexto técnico para ser utilizado en la documentación del sistema.

PropiedadesPropiedades generales del Work Panel.


84

En este capítulo solo se presentarán las características y usos más salientes de los Panelesde Trabajo, pero se recomienda leer el capítulo de Paneles de Trabajo en el Manual deUsuario GENEXUS, para una visión más profunda.

Ejemplo

Para ilustrar más fácilmente el uso de Paneles de Trabajo, vamos a realizar una serie deconsultas encadenadas.Estas consultas comienzan con un Panel de Trabajo de proveedores, donde el usuarioselecciona para luego realizar alguna acción, en este caso para cada proveedorseleccionado se puede:

Visualizar los datos del proveedor.

Visualizar los pedidos del proveedor.

El form será:

si, por ejemplo, el usuario presiona el botón de Visualizar en el proveedor 125, se abreuna ventana donde se muestran los datos del proveedor:


85

Si se presiona el botón de pedidos se presentará la siguiente pantalla con los pedidos delproveedor:

A su vez este Panel de Trabajo podría extenderse, permitiendo seleccionar algún pedidopara visualizar qué artículos fueron pedidos y así sucesivamente.Las acciones que vimos en el primer Panel de Trabajo se aplican a una línea, pero existenotras acciones que no se aplican a ninguna línea en particular, por ejemplo Insertar un


86

nuevo proveedor. Si se elige esta acción se pasa el control a la transacción de proveedorespara definir uno nuevo.

Renovar - es una acción incluída automáticamente por GENEXUS y, si se elige, sevuelven a cargar todas las líneas. Más adelante nos detendremos en esta acción.Veamos ahora como se define el primer Panel de Trabajo del ejemplo.

Form del Work Panel

Este form se define de una manera similar a los forms de las transacciones.

Subfile


87

Cuando se define un subfile en el form se está indicando que se va a mostrar una cantidadindefinida de datos (en este caso los proveedores). Si bien sólo se pueden versimultáneamente las líneas presentes en la pantalla, GENEXUS provee todos losmecanismos para que el usuario se pueda 'mover' (llamaremos 'paginar') dentro de la lista,como por ejemplo ir a la primera página, a la siguiente, etc.El Panel de Trabajo anterior tiene un SubFile compuesto de PrvCod y PrvNom. LosSubFile pueden contener además de atributos, variables y arrays de una y dosdimensiones.

Subfile

Si seleccionamos el botón de “subfile” nos va a permitir incorporar un subfile en elform del work panel y definir el tamaño que deseamos.

Insertar el controltipo Subfile


88

Una vez pasteado el control en el form se abre automáticamente el siguiente dialogo:

Para seleccionar los atributos que van a ser incluidos en el subfile se debe presionar elboton “Add”. Con el tab “Column” vamos a poder cambiar los títulos de las columnas(por defecto se define el titulo del atributo). Los botones “MoveUp” y “Move Down”nos van a permitir cambiar el orden en que se van a desplegar los atributos. Con lostabs “Colors” y “Fonts” podemos cambiar los colores y el tipo de letra de lascolumnas. Con el tab Control Info se selecciona el tipo de control a utilizar, y dado eltipo, indicar la información necesaria para ese tipo, las opciones disponibles son: Edit,Check box, Combo y Dynamic Combo (o el default del atributo o variable de lacolumna).

Podemos también ajustar manualmente el ancho de cada columna desmarcando laopción de “Auto Resize”, si esta opción queda marcada el ancho de la columna lodetermina GENEXUS en función del largo del atributo o del titulo de la columna.El check box “Horizontal Scroll” permite que en tiempo de ejecución aparezca unabarra de scroll horzontal (además de la de scroll vertical que apareceautomáticamente)


89

Eventos

La forma tradicional de programar la interfaz entre el usuario y el computador (incluídoslos lenguajes de cuarta generación) es subordinar la pantalla al programa. Es decir, desdeel programa se hacen 'calls' a la pantalla. En Paneles de Trabajo es lo opuesto: elprograma está subordinado a la pantalla, ya que una pantalla realiza 'calls' al programapara dar respuesta a un evento.Esta forma de trabajar es conocida como EVENT DRIVEN (dirigida por eventos) y estípica de los ambientes GUI (Interfaz de Usuario Gráfica), en donde ya ha demostrado suproductividad, fundamentalmente porque se necesita programar sólo la respuesta a loseventos y no la tarea repetitiva que implica el manejo de toda la interfaz.La estructura de eventos es, de forma resumida, la siguiente:

Comienzo

Evento Start

Evento Refresh

Cargar datos en el SubFile a partir de la basede datos (para cada registro leído se generaun Evento Load)

Mostrar los datos en la pantalla

Evento Enter

Evento 'User Defined'

Evento Exit

Fin

Para programar cada uno de los eventos se utiliza el mismo lenguaje que ya vimos enReportes y Procedimientos, aunque no están permitidos ni los comandos relacionados conla impresión (Header, etc.) ni los de actualización de la base de datos (New, Delete, etc.).También existen comando específicos para Paneles de Trabajo.


90

Evento Start

Event Start

&Fecha = &TodayEndevent

En este caso, se utiliza el evento Start para mover la fecha actual a la variable &Fechaque por ejemplo se podrá mostrar en la pantalla. Esta técnica es muy útil parainicializar valores por defecto, sobre todo para aquellos que son complejos (porejemplo, &Valor = udf('PX', ...)).

Evento Enter

Este evento se dispara cuando el usuario presiona ENTER. Consideremos el siguienteejemplo: borrar un conjunto de proveedores. Entonces se define una nueva variable enel subfile, &Op, y por cada línea que se le asocie la opción 4 se llama a unprocedimiento que borra los clientes. El código asociado al evento enter en este casoes el siguiente:

Event Enter

For each line

If &op = '4'Call(PDltPrv, PrvCod)

ElseIf &op <> ' '

&msg = concat(&op, ' no es una opción valida')Msg( &msg )

EndifEndif

Endfor

Endevent

El evento Enter es un poco más extenso y vale la pena detenernos en él. En primerlugar se utiliza el comando FOR EACH LINE que realiza un FOR EACH, pero nosobre los datos de la base de datos, sino sobre el SubFile.


91

Para cada una de las líneas del SubFile, se pregunta por el valor de &op, si &op es '4'se llama al procedimiento DltPrv, y en otro caso, da un mensaje indicando que laopción no es válida. Notar que se podrían haber definido mas opciones y preguntarpor ellas en este evento.

Eventos definidos por el usuario (User Defined Events)

Este es un evento definido por el usuario, para el cual se debe definir el nombre('Insertar'). En este evento se llama a la transacción de proveedores (por más detallessobre como llamar de un Panel de Trabajo a una Transacción ver el capítulo dePaneles de Trabajo en el Manual de Referencia). Luego de llamar a la transacción, seejecuta el comando Refresh, que indica que se debe cargar nuevamente el SubFile, yaque se ha adicionado un nuevo proveedor. También se podría haber usado el comandocon el parámetro keep (Refresh Keep) que hace que una vez que el comando refreshse ejecuta el cursor queda posicionado en la misma línea del subfile que estaba antesde la ejecución.

Evento Refresh

Los datos que se presentan en pantalla son los cargados en el SubFile, que a su vezfueron cargados desde la base de datos.En un ambiente multi-usuario, los datos de una pantalla pueden haber quedadodesactualizados si desde otra terminal fueron modificados. Cuando el usuario deseaactualizar los datos, debe dar click sobre el boton Refresh (o presionar la tecla F5),cuyo efecto es cargar nuevamente el SubFile.En algunos casos, desde otro evento también se necesita cargar nuevamente elSubFile. Por ejemplo, cuando en otro evento se llama a una transacción que actualizalos datos (es el caso del Evento 'Crear Proveedor').


92

Tenemos, por lo tanto, que el SubFile se carga (es decir, se genera el evento Refresh)cuando:

• Se carga la pantalla - por lo tanto después del evento Start siempre hayun evento Refresh.

• El usuario dio click sobre el botón Refresh (o presiono la tecla F5).• Se ejecutó el comando Refresh en otro evento.

Carga de datos en el Panel de Trabajo

Como vimos en el diagrama de eventos, después del evento Refresh, se carga elSubFile con los datos obtenidos de la base de datos.Para determinar de que tablas se deben obtener los datos, GENEXUS utiliza el mismomecanismo descripto para los grupos FOR EACH en el capítulo Diseño de Reportes.Pero en este caso no hay ningún FOR EACH!.Sin embargo, se considera que cada Panel de Trabajo tiene un FOR EACH implícito,que contiene los siguientes atributos:

• Todos los atributos que se encuentran en la pantalla (incluso los que seencuentran en la parte fija de la misma).

• Todos los atributos que se encuentren en los Eventos, con la excepciónde aquellos que se encuentren dentro de un FOR EACH explícito.

• Todos los atributos mencionados en las reglas Hidden y Order

Con estos atributos GENEXUS determina cual es la tabla extendida correspondiente.Para cada uno de los registros encontrados, se genera un evento Load. Así, la relaciónentre el evento Refresh, el FOR EACH implícito y el evento Load es la siguiente:

Event Refresh ... Endevent

FOR EACH

Event Load ... Endevent

ENDFOR

Los datos que se leen en este FOR EACH implícito, se cargan en el SubFile, que es elque se presenta en pantalla. Esta carga se realiza 'bajo pedido', es decir que al


93

comienzo sólo se carga la primera página y, a medida que el usuario requiere másinformación, se van cargando las siguientes páginas. Existe una propiedad paraindicar que se quiere cargar el SubFile de una sola vez, si fuera necesario.Igual que en los Reportes y Procedimientos en el Listado de Navegación del Panel deTrabajo se indica qué tablas se están utilizando, índices, etc.Puede darse el caso que no exista el FOR EACH implícito. Esto se debe a que no hayatributos ni en la pantalla ni en los eventos ni en las reglas Hidden y Order (porque seusan sólo variables). En este caso se genera sólo UN evento Load y es en éste dondese deben cargar los datos en el SubFile (utilizando el comando Load), por ejemplo:

Event Refresh ... Endevent

Event Load ... For each ... Load Endfor

Endevent

Observar que en este caso se pierde la facilidad de carga 'bajo pedido' y por lo tantoantes de mostrar los datos se carga todo el SubFile.

Condiciones

Aquí se definen las restricciones a los datos de la misma forma que en los Reportes.Lo interesante de las condiciones en los Paneles de Trabajo, es que en las mismas sepuede utilizar variables que se encuentran en la pantalla, de tal manera que el usuario,cambiando los valores de estas variables, cambia los datos que se muestran en el SubFilesin tener que salir de la pantalla.Por ejemplo, si queremos visualizar sólo un rango de proveedores, agregamos en lapantalla las variables:


94

Y definiendo las condiciones:

se obtiene el efecto deseado.

Variables paraingresar elproveedor final yinicial.


95

Todas las consideraciones sobre optimización de condiciones vistas en el capítulo Diseñode Reportes son igualmente válidas aquí.

Reglas

En Reglas se aplican la mayor parte de las reglas de los Reportes, más algunasparticulares:

Order

Define cual es el orden de los datos del SubFile. Es equivalente a la cláusula ORDERdel FOR EACH y se aplica todo lo dicho en el capítulo Diseño de Reportes sobre eltema (incluída la creación de índices temporarios).Por ejemplo si queremos ver los proveedores por orden alfabético:

order( PrvNom );

Noaccept

A diferencia de las Transacciones, en los Paneles de Trabajo ningún atributo esaceptado (siempre se muestra su valor pero no se permite modificarlo). Para variablesse sigue el siguiente criterio:

• Todas las variables presentes en la pantalla son aceptadas, a no ser quetengan la regla NOACCEPT.

Por ejemplo, en un Panel de Trabajo que deseemos poner la fecha en el form, senecesita la regla:

noaccept( &Fecha );

Search

Cuando el SubFile es demasiado extenso, muchas veces se quiere brindar laposibilidad de que el usuario pueda 'posicionarse' en alguna línea determinada delmismo, en forma directa, sin tener que avanzar página por página. Por ejemplo si ennuestro Panel de Trabajo de proveedores queremos que exista la posibilidad de buscarun proveedor según su nombre, se debe definir la regla:

search( PrvNom >= &Nom );


96

y en la pantalla se debe agregar la variable &Nom:

De esta manera, cada vez que el usuario digite algo en &Nom, luego de dar Enter, elSubFile quedará posicionado en el primer proveedor con PrvNom mayor o igual aldigitado. En los casos de nombres es muy usual la regla:

search( PrvNom .LIKE. &Nom );

En donde el SubFile se posiciona en el primer proveedor cuyo PrvNom contenga a&Nom (en el ejemplo si en &Nom se digitó 'xx' se posicionará en 'GXxxxx Corp.').Si bien esta regla es muy útil para que el usuario avance rápidamente en un SubFile,se debe tener en cuenta que no hay ningún tipo de optimización sobre la misma. Si sequieren utilizar los criterios de optimización se deben usar las Condiciones.


97

Bitmaps

Los bitmaps son usados usualmente para mejorar la presentación de las aplicaciones. Sepueden incorporar en los forms de las transacciones, reportes y work panels. GENEXUS

provee dos métodos diferentes para agregar un Bitmap:

Fixed Bitmaps

Se puede agregar un Bitmap seleccionando el botón de Bitmap de la paleta deherramientas. De esta forma tenemos que indicar su ubicación. Agreguemos un logoen el work panel que permite visualizar los datos de un proveedor. El nuevo form severa de la siguiente forma:

En este caso siempre aparecerá el mismo Bitmap en el form.

Dynamic Bitmaps

Este método tiene como diferencia que el Bitmap lo asigno a una variable y usando lafunción Loadbitmap puedo cargar el Bitmap que yo desee. Por ejemplo se puedetener un Bitmap que despliegue la foto de cada proveedor.


98

Definición de una varible de tipo bitmap:

En el evento load hay que cargar el bitmap para el proveedor pasado por parámetro.

En el atributo PrvFoto se carga la ubicación del archivo (bmp).


99

En tiempo de ejecución se verá de la siguiente forma:

Gráficas

Grafiquemos el total pedido por Proveedor. Vamos a definir entonces una formula que mecalcule el total pedido en la transacción de proveedores:


100

Definimos entonces un nuevo atributo, “PrvTotPed” y decimos que este atributo es unaformula Sum vertical del atributo PedTot, de esta forma estamos definiendo el totalPedido de un proveedor como la suma de todos los totales de los pedidos de eseproveedor. Recordemos que el atributo PedTot había sido definido como una formula,sumando todos los importes de la línea que a su vez era también una formula.De esta forma tenemos disponible este atributo para usarlo en la definición del workpanel.


101

En este work panel definimos el botón “Graficar” el cual va a tener asociado el siguienteevento:

De esta manera cuando el usuario presiona el botón de graficar visualizara el total pedidopor los proveedores en forma gráfica. Vemos a continuación ejemplos de los tipos degráficos que podemos diseñar:


102


103

Properties

Generar como una ventana Popup

Se utiliza para indicar que el Panel de Trabajo debe cargarse como una ventana y noborrar la pantalla anterior, tiene sentido para ambientes que no tienen interfacesgráficas.En el segundo Panel de Trabajo del ejemplo se utilizó esta regla.Por mayor información sobre las propiedades de los distintos objetos sugerimosconsultar al manual de referencia.


104

Diálogos Objeto-Acción

Con el uso de Paneles de Trabajo, se tiene la oportunidad de definir para la aplicaciónuna arquitectura orientada a diálogos Objeto-Acción. Pero previo a introducir esteconcepto veamos cual era la forma tradicional.Si observamos una aplicación desarrollada por los métodos tradicionales, veremos quecuanto mayor es, más grande será el árbol de menúes que se tiene para acceder a losprogramas que efectivamente trabajan con los datos. La arquitectura de este tipo desistemas normalmente es:

Esta situación se puede apreciar claramente en los sistemas con muchas consultas. Engeneral, todas estas consultas dependen de un menú, pero no se encadena una consultacon las otras. Y al no estar encadenadas, se da la paradoja de que cuanto más consultas seimplementan en el sistema, menos son usados por el usuario, porque le resulta difícilacordarse de las diferencias entre ellas.Diremos que este tipo de aplicación tiene un diálogo Acción-Objeto, porque primero seelige la acción a realizar (por ejemplo modificar un proveedor, o listar los pedidos) yluego se elige el objeto al cual aplicar la acción (que proveedor o los pedidos de quefecha).Con Paneles de Trabajo se pueden implementar sistemas en donde el diálogo puede serObjeto-Acción, donde primero seleccionamos el objeto con el cual vamos a trabajar yluego las acciones que aplicamos al mismo. En este caso la arquitectura será:

Menúes

Trn Rpt Proc

Selección de laAcción

Aplicar laacción alobjeto


105

De esta manera el usuario, una vez que selecciona el tipo de objeto con el que va atrabajar, ya puede utilizar el Panel de Trabajo que le permite seleccionar el objeto en sí, yluego, las acciones a aplicar sobre el mismo.Esta arquitectura permite desarrollar aplicaciones complejas, pero que se mantienenfáciles de usar.

Menúes

Paneles deTrabajo

Trn Rpt Proc

Selección del objetoy la Acción

Aplicar laacción alobjeto

Selección deltipo de objeto


106

DISEÑO DE MENÚES

Este objeto permite definir los diferentes menúes de la aplicación. La definición de unmenú es muy fácil, y prácticamente lo único que se requiere es definir las opciones delmismo.

Ejemplo:

Menú Principal del Sistema de Compras

El menú anterior cuando es generado para FoxPro Windows es:


107

Es un menú de selección implícita, es decir la opción se selecciona directamente con elMouse.

El mismo menú generado para Visual Basic tiene el siguiente formato:

El mismo menú generado para el ambiente AS/400 tiene el siguiente formato:


108

En donde se utiliza la técnica de selección explícita, donde para seleccionar la opción sedebe digitar el número de la misma en el campo de selección.Los menúes generados para AS/400 siguen las especificaciones CUA 89 (Common UserAccess) de IBM.

Call Browser

Este browser despliega todos los objetos que se llaman a través de los comandos call yudp.Dado un programa podemos ver su árbol de llamadas (a que programas llama) y desdeque programas es llamado (eligiendo la opción Callees o Callers del dialogo del browser).En nuestro ejemplo vamos a ver el árbol de llamadas del menú Compras:


109

Desde este browser podemos editar cualquier objeto que aparezca en las listas.


110

ANEXO A. MODELOS DE DATOSRELACIONALES

El propósito de este Anexo es explicar una serie de conceptos sobre Bases de DatosRelacionales relevantes para el uso de GENEXUS.Un Modelo de Datos esta compuesto por:

Tablas

En una Base de Datos Relacional la única forma de almacenar información es enTablas.Una Tabla es una matriz (tiene filas y columnas) con un nombre asociado (ej.PROVEEDO). A las columnas les llamaremos Atributos, y a las filas Registros oTuplas. Por ejemplo la Tabla de Proveedores:

PROVEEDO


125 ABC Inc. Xxxxxxxxx

126 GXXXX Corp. Yyyyyyy

Una Tabla se diferencia de un archivo convencional porque debe cumplir lassiguientes reglas:

• Todos los atributos representan la misma información para cada una de las filas(o registros). Es decir en el atributo PrvNom se almacenan los nombres de losproveedores, y no puede ocurrir que para algunos proveedores en ese atributose almacene la dirección del mismo. En la práctica esta regla implica que noexisten tablas con diferentes tipos de registros.

• No existen dos registros con exactamente la misma información.• El orden de los registros no contiene información. Es decir se pueden reordenar

los registros sin perder información.


111

Clave primaria y Claves candidatas

Dado que no puede haber dos registros con la misma información, siempre se puedeencontrar en una tabla el atributo o conjunto de atributos cuyos valores no se duplican.Se llama a ese atributo o conjunto de atributos Clave Primaria de la tabla.En realidad pueden existir varios de esos conjuntos, a cada uno de ellos lo llamamosClave Candidata. Por ejemplo en la tabla PROVEEDO tanto PrvCod como PrvNomson claves candidatas, ya que no existen dos proveedores con el mismo código, perotampoco hay dos proveedores con el mismo nombre.En una Base de Datos Relacional sólo una de las claves candidatas debe ser definidacomo la Clave Primaria. También se debe respetar la siguiente regla: no deben existirdos tablas con la misma clave primaria.

Por ejemplo consideremos el siguiente diseño:

Tabla: PROVEEDO

Atributos: PrvCod* PrvNom

Tabla: PROVDIR

Atributos: PrvCod* PrvDir

Tanto la PROVEEDO como la PROVDIR tienen la misma clave primaria. Esto erarelativamente común cuando el criterio de diseño era separar las actualizaciones (porejemplo dado que PrvDir cambia mas que PrvNom, entonces es mejor definir unarchivo diferente en donde el registro que se modifica es menor, y por lo tanto demejor performance). Sin embargo en una Base de Datos Relacional el criterio dediseño es diferente (ver sección de Normalización) y es preferible una sola tabla conlos tres atributos:

Tabla: PROVEEDO

Atributos: PrvCod* PrvNom PrvDir


112

Indices

Son vías de acceso eficientes a las Tablas. Existen tres tipos de índices: Primarios,Extranjeros y del Usuario.El índice primario es el que se define para la Clave Primaria y, por lo tanto, se usa enel control de unicidad de los registros. Con GENEXUS todos los índices primarios sondefinidos automáticamente a partir de los identificadores de las transacciones.Los índices extranjeros son utilizados para hacer eficientes los controles de integridadinter-tablas. También son definidos automáticamente.Los índices del usuario se definen, fundamentalmente, para recorrer los datos pordeterminado orden de una forma eficiente. Por ejemplo en la tabla PROVEEDO sepuede definir un índice por PrvNom, que es muy útil para los listados ordenados pornombre. Los índices del usuario NO son definidos automáticamente.En una Base de Datos Relacional los índices se utilizan sólo por problemas deperformance, pero siempre es posible acceder a los datos de la tabla por cualquiera delos atributos de la misma.

Integridad Referencial

Son las reglas de consistencia entre los datos de las distintas tablas.Según vimos en el ejemplo, existe una relación entre la tabla PEDIDOS (Pedidos) y laPROVEEDO (Proveedores):


113

La relación entre estas dos tablas se determina analizando los atributos que tienen encomún, por ejemplo aquí tenemos que el atributo común es PrvCod, que es la claveprimaria de la tabla PROVEEDO (Proveedores) y se encuentra en la tabla PEDIDOS(Pedidos) y, por lo tanto, ambas tablas están relacionadas y la relación es 1-N.Con relación 1-N se indica que un Proveedor tiene varios Pedidos y que un Pedidosólo tiene un Proveedor. También es usual decir que la tabla de proveedores estasuperordinada a la de pedidos, y la de pedidos esta subordinada a la de proveedores.Esta relación implica que los datos de ambas tablas no son independientes y cada vezque se realicen modificaciones en una de las tablas, se deben tener un cuenta los datosde la otra tabla. A estos controles se les llama de integridad referencial y son:

• Cuando se elimina un registro en la tabla superordinada (PROVEEDO), nodeben existir registros correspondientes en la tabla subordinada (PEDIDOS).

• Cuando se crean registros en la tabla subordinada (PEDIDOS), debe existir elregistro correspondiente en la tabla superordinada (PROVEEDO).

Para hacer eficiente el primer control se utiliza el índice extranjero por PrvCod en latabla PEDIDOS y para el segundo el índice primario también por PrvCod en la tablaPROVEEDO.

1

N


114

El diagrama anterior se ha inspirado en los conocidos Diagramas de Bachman, y tienejustamente la virtud de explicitar la integridad referencial del modelo de datos.

Normalización

El proceso de normalización determina en que tablas debe residir cada uno de losatributos de la base de datos.El criterio que se sigue es básicamente determinar una estructura tal de la base dedatos, que la posibilidad de inconsistencia en los datos sea mínima.Por ejemplo, si tenemos que almacenar información sobre Proveedores y Pedidos, sepodría tener la siguiente estructura:

en donde vemos que ambas tablas tienen dos atributos en común (PrvCod y PrvNom).En el caso de PrvCod es necesario que se encuentre en ambas tablas dado que es elidentificador de los Proveedores, y por lo tanto debe estar en la de Pedidos paraindicar a que Proveedor corresponde el Pedido.La situación es diferente para PrvNom, ya que no es necesario que esté en la tabla dePedidos, porque si conocemos el PrvCod podemos determinar cual es su PrvNom(basta con buscar en la tabla PROVEEDO por la clave primaria). Si de cualquiermanera se almacena el PrvNom en la tabla PEDIDOS tenemos que esta estructuratiene más posibilidades de inconsistencia que si no estuviera allí. Por ejemplo si unProveedor cambia su PrvNom, el programador debe encargarse de tener un programaque lea todos los Pedidos de ese Proveedor y le ponga el nuevo PrvNom.

Tabla: PROVEEDOPrvCod*PrvNomPrvDir

Tabla: PEDIDOSPedNro*PedFchPrvCodPrvNomAnlNroPedTot


115

Entonces la estructura correcta (diremos 'normalizada') será:

El proceso de normalización (que se acaba de introducir de una manera muy informal)se basa en el concepto de Dependencia Funcional, cuya definición es:Se dice que un atributo depende funcionalmente de otro si para cada valor delsegundo sólo existe UN valor del primero.Por ejemplo PrvNom depende funcionalmente de PrvCod porque para cada valor dePrvCod sólo existe UN valor de PrvNom.En realidad la definición es algo mas amplia, ya que se define que un conjunto deatributos dependa funcionalmente de otro conjunto de atributos.

Tabla extendida

Como vimos en la sección de Normalización, el criterio de diseño de la base de datosse basa en minimizar la posibilidad de inconsistencia en los datos. Una base de datosdiseñada de esta manera tiene una serie de ventajas importantes (tal es así queactualmente la normalización de datos es un standard de diseño), pero se deben teneren cuenta también algunos inconvenientes.El inconveniente más notorio es que los datos se encuentran dispersos en muchastablas, y por lo tanto cuando se quieren hacer consultas mas o menos complejas a labase de datos se debe consultar una cantidad importante de tablas. Así, por ejemplo,para listar los Pedidos por Proveedor es necesario consultar las tablas PROVEEDO yPEDIDOS.Para simplificar esta tarea GENEXUS utiliza el concepto de Tabla Extendida, cuyadefinición es:

Dada una tabla de la base de datos, la tabla extendida de la misma son losatributos que pertenecen a la tabla y a todas las tablas que tengan unarelación N-1 (directa o indirectamente) con la primera. A la primera tablase le llama de Tabla Base y a las otras de Tablas N-1.

Tabla: PROVEEDO

PrvCod* PrvNom PrvDir

Tabla: PEDIDOS

PedNro* PedFch PrvCod AnlNro PedTot


116

Si hacemos un diagrama de Bachman del modelo de datos del ejemplo:

vemos que la tabla extendida de Pedidos comprende a todos los atributos de la tablaPedidos, más todos los atributos de Proveedores y todos los de Analistas, pero no losatributos de la Linea del pedido o de Artículos (porque si bien están relacionados, surelación no es N-1).

En el siguiente diagrama se muestra, para cada una de las tablas del modelo, cual es sutabla extendida:


117

Tabla base Tabla extendida

Proveedores Proveedores

Analistas Analistas

Pedidos Pedidos, Proveedores, Analistas

Linea_pedidos Linea_pedidos, Pedidos, Proveedores, Analistas,Artículos

Artículos Artículos

El concepto de tabla extendida es muy utilizado en GENEXUS, sobre todo en Reportes,Procedimientos y Paneles de Trabajo en donde siempre se trabaja con tablasextendidas y no con tablas físicas. Por ejemplo el comando FOR EACH determinauna tabla extendida y no una tabla física.


118

ANEXO B. FUNCIONES, REGLAS YCOMANDOS

FUNCIÓN DESCRIPCIÓNMANEJO DE FECHAS

Day Numero de día de una fechaMonth Numero de mes de una fechaYear Año de una fechaToday Fecha de hoyDow Numero del día de la semanaCdow Nombre del día de una fechaCmonth Nombre del mes de una fechaCtod Pasar de tipo carácter a tipo fechaDtoc Pasar de tipo fecha a carácterYmdtod Armar fecha a partir de año, mes y díaAddmth Sumar un mes a una fechaAddyr Sumar un año a una fechaAge Diferencia en años entre dos fechasEom Fecha fin de mes de una fecha

MANEJO DE STRINGS

Str Pasar un numérico a stringSubstr Substring de un stringConcat Concatenar dos stringsSpace Definir un strings con “n” blancosLen Largo de un stringTrim Quita los caracteres en blanco de un stringLtrim Quita los caracteres en blanco al principio de un

stringRtrim Quita los caracteres en blanco al final de un stringUpper Convierte un string a mayúsculasLower Convierte un string a minúsculas

Int Parte entera de un numéricoRound Redondear un valor numéricoVal Pasar un string a numérico

OTRAS


119

Old Valor del atributo antes de ser modificadoPrevious Valor del atributo en la última inserciónTime HoraSystime Hora del sistemaSysdate Fecha del sistemaUserid Identificación del usuarioUsercls Clase de usuarioWrkst WorkstationAsk Para pedir valores por pantallaUdf Función definida por el usuarioUdp Procedimiento definido por el usuarioNull( <Att|Var> ) Si un atributo tiene valor nulo o noNullvalue( <Att|Var> ) Devuelve el valor nulo de un atributoLoadBitmap Carga un bitmapRGB (<R>,<G>,<B>) Retorna el numero que representa al color RGB

determinado por los 3 parametrosColor(<GXColor>) Retorna el numero que representa al color pasado

como parametro

ORDEN DE DISPARO DE LAS

REGLAS EN LAS

TRANSACCIONES

After(Insert) Luego que se inserto el registroAfter(Update) Luego que se actualizo el registroAfter(Delete) Luego que se dio de baja el registroAfter(Confirm) Luego que se confirmo el nivel (todavía no se hizo

la modificación del registro)After(Trn) Luego que termina la transacciónAfter( <Att> ) Después de un atributoAfter(Level( <Att> )) Luego que finaliza determinado nivelLevel( <Att> ) Nivel de una transacciónModified() Si fue modificado algún atributo de un nivelInsert Si la transacción esta en modalidad insertUpdate Si la transacción esta en modalidad updateDelete Si la transacción esta en modalidad delete


120

REGLAS DESCRIPCIÓN T W R P

Default Dar un valor por defecto a un atributoEqual Asigna un valor en modalidad insert y

funciona como filtro en update y delete.Add Sumar un valor a un atributo teniendo en

cuenta la modalidad de la transacciónSubtract Restar un valor a un atributo teniendo en

cuenta la modalidad de la transacciónSerial Numerar serialmente atributosMsg Desplegar un mensajeError Dar un errorNoaccept No aceptar atributo o variable en la

pantallaCall Llamar a un programaSubmit Someter una llamada a un programaParm Para recibir los parámetrosNocheck No realizar el control de integridad

referencialAllownulls Permitir ingresar valores nulosRefcall Hacer un call cuando falla el control de

integridad referencialRefmsg Mensaje que se despliega cuando falla el

control de integridad referencialPrompt Asociar al prompt un objeto definido por

nosotrosNoprompt Inhibe la lista de selecciónAccept Aceptar atributo o variable en la pantallaDefault_mode Modalidad por defecto al ingresar en una

transacciónNoconfirm No pedir confirmación al final de un

determinado nivelColor Dar colores a los atributos, variables y

fondoOrder Orden de la tabla base del Work PanelSearch Condición de búsqueda sobre el subfileHidden Para incluir variables o atributos en el

subfileNoread Inhibe la lectura de atributosPrinter Para seleccionar el printer file en el


121

AS/400

T = TransaccionesW = Work PanelsR = ReportesP = Procedimientos

Las casillas que aparecen marcadas indican que la función aparece disponible para eseobjeto.


122

COMANDOS DESCRIPCIÓN T W R P

Header Comienzo del cabezalFooter Comienzo del pie de pagina

For each Para recorrer los registros de una tablaExit Permite salir de un whileDo while Repetición de una rutina mientras se cumpla

una condiciónDo Case Ejecuta algún bloque según que condición

se cumplaIf Ejecuta un bloque de comandos en caso que

la condición evalúe verdaderaCommit CommitRollback RollbackPrint if detail Imprime si existen registros en el subfile.Return Finaliza la ejecución y vuelve al programa

llamador&<a> = <Exp> Asignación de una variable

Lineno Numero de línea donde los datos seránimpresos

Prncmd Para pasar comandos especiales a laimpresora

Pl Largo de paginaMt Margen superiorCp Provoca un salto de página si quedan menos

de “n” líneas por imprimirNoskip No pasar a la siguiente línea de impresiónEject Salto de páginaCall Llamar a un programaSubmit Someter un programaMsg Desplegar un mensajeDo Llamar a una subrutinaSub - EndSub Bloque de subrutina

ATT = <Exp> Actualización de atributoNew - EndNew Insertar registroDelete Borrar un registro


123

T = Transacciones (eventos)W = Work Panels (eventos)R = ReportesP = Procedimientos

Las casillas que aparecen marcadas indican que la función aparece disponible para eseobjeto.

Curso GeneXus

Parte I

Copyright (c) ARTech – Noviembre 2000

TABLA DE CONTENIDO CAPACITACION GENEXUS ....................................................... 4 INTRODUCCION TEORICA ..................................................... 10 ............................................................................................................. METODOLOGIA TRADICIONAL .............................................. 14 METODOLOGIA GENEXUS........................................................ 19 ............................................................................................................. DISEÑO DE TRANSACCIONES................................................ 41 NOMENCLATURA GIK .............................................................. 47 TIPOS DE DATOS ....................................................................... 49 COMANDOS DE ASIGNACIÓN.................................................. 51 DOMINIOS ................................................................................... 52 TAB CONTROL ........................................................................... 55 INTEGRIDAD REFERENCIAL ................................................. 59 CONCEPTO DE TABLA EXTENDIDA .................................... 62 ATRIBUTOS FORMULAS ......................................................... 66 CARACTERISTICAS .................................................................... 67 CLASIFICACION .......................................................................... 68 FORMULAS HORIZONTALES ................................................... 69 FORMULAS VERTICALES.......................................................... 72 FORMULAS AGGREGATE / SELECT ........................................ 75 COMUNICACION ENTRE OBJETOS..................................... 98 REGLAS Y COMANDOS............................................................ 100 SUBRUTINAS ............................................................................. 107 ARBOL DE EVALUACION Y EVENTOS .............................. 110 ARBOL DE EVALUACION........................................................ 111 EVENTOS EN TRANSACCIONES ............................................ 119 REPORTES YPROCEDIMIENTOS ........................................ 131 COMANDO FOR EACH ............................................................ 134 INFERENCIA DE TABLAS ....................................................... 135 REPORT WIZARD ...................................................................... 141 DISTINTOS CASOS DE FOR EACH ........................................ 142 REPORT VIEWER ....................................................................... 150 PROCEDIMIENTOS ................................................................... 151 RESTRICCIONES ........................................................................ 155

WORK PANELS ...................................................................... 156 DIFERENTES TIPOS DE PANELES ....................................... 158 COMANDO FOR EACH LINE ................................................. 162 EVENTOS ................................................................................. 164 REGLAS MAS IMPORTANTES ............................................. 166 PROPIEDADES MAS IMPORTANTES................................... 167 SUBTIPOS ............................................................................... 170 KNOWDLEGE MANAGER .................................................. 175 BUSINESS OBJECTS ............................................................ 178 OBJECTOS PRIVADOS ....................................................... 187 EFICIENCIA Y PERFORMANCE ....................................... 191 DEFINICION DE FILTROS .................................................... 194 ORDEN DE RECORRIDA ....................................................... 196 MULTIPLES FORMS.............................................................. 208 STYLES ..................................................................................... 213

MENU BAR Y TOOL BAR ..................................................... 226

PROPIEDADES, EVENTOS Y METODOS ASOCIADOS A LOS CONTROLES ...................................... 229 OBJETOS MAIN ...................................................................... 238 DATA VIEWS ......................................................................... 244 WEB PANEL ............................................................................. 262

4

Capacitación GeneXus

CURSO GENEXUS PARTE I

Es indispensable para comenzar a desarrollar Aplicaciones GeneXus.

Objetivo : Capacitar a los usuarios para conseguir el cambio de mentalidad que GeneXus requierey dar elementos básicos para el diseño de Aplicaciones.

Alcance : Conceptos fundamentales y elementos básicos. No se abordan todos los temas, algunosde ellos son abordados en el Curso Genexus Parte II.

Orientado: A Usuarios que van a desarrollar directamente Aplicaciones usando GeneXus y líderes de Proyecto.

Etapas: Este curso consta de 3 etapas:Autoestudio , Curso Teórico/ Práctico y Taller.

Aprobación: Este curso es evaluado por los instructores de Artech . La evaluación consiste en la defensa del Taller realizado y el resultado de dicha evaluación (Aprobación /No aprobación) es comunicado a la Empresa.

Habilitado a: El alumno que aprueba dicho curso queda habilitado a desarrollar aplicaciones de pequeño y mediano porte, sin embargo es necesario el apoyo que se brinda en el WorkShop.

Duración: 76 horas distribuidas en cuatro semanas.

5

CURSO GENEXUS PARTE II

Objetivo: Alcanzar la capacitación completa para desarrollar Aplicaciones GeneXus. Pensamos que después del curso se levanta la productividad substancialmente alcanzando en poco tiempo el nivel máximo.

Alcance: Se tratan algunos temas que no se vieron en el Curso Genexus Parte I y se profundiza en temas avanzados.

Orientado a: Usuarios que van a desarrollar directamente aplicaciones usando GeneXus y líderes de Proyecto.

Duración: 16 horas distribuidas en cuatro días.

WORKSHOP

Objetivo: Apoyo inicial a la primera aplicación real que desarrolla el cliente. El Workshop cumple las siguientes funciones fundamentales: a) Realizar un análisis inicial junto al clienteque redunde en una planificación para la correcta inserción de GeneXus en la empresa b) Apoyar técnicamente el comienzo del desarrollo con la herramienta de cuyo resultadodepende en gran parte el futuro desempeño y satisfacción del cliente. c) Tener un seguimiento del Cliente en la etapa inicial para asegurarnos que obtiene la productividadesperada y corregir posibles desvíos en la etapa inicial.

Condiciones previas: Tener aprobado el Curso Genexus.

Orientado a: Usuarios que van a desarrollar directamente aplicaciones usando GeneXus y líderes de Proyecto.

Duración: 20 horas de consultoría en el Cliente.

Comienzo: Es conveniente comenzarlo apenas finalizado el Curso GeneXus . Debecomenzar antes de los 60 días de finalizado dicho curso, sino se pierde el derecho a realizarlo.

6

DESARROLLO DE APLICACIONES CLIENT/SERVER

Objetivo: Dar los elementos necesarios para poder generar aplicaciones en una arquitecturaCliente/ Servidor.

Condiciones previas: Tener aprobado el Curso GeneXus.

Alcance: ¿Porqué una Arquitectura Client/Server? , Consideraciones generales de las Arquitecturas C/S , Diseño de una aplicación Client/Server , Optimización y Performance de las aplicaciones , Multi-tier Architecture.

Orientado a: Gerentes de proyecto y técnicos de la empresa, ya que les brindará la posibilidad no solo de conocer a fondo esta Arquitectura y sus posibilidades, sino también les dará el conocimiento para desarrollar aplicaciones sobre las mismas .

Duración:24 horas distribuidas en 6 días.

CURSO JAVA

Objetivo: Dar los elementos necesarios para poder generar aplicaciones Java en una arquitectura Cliente/Servidor de 2 y múltiples capas para correr tanto en una Intranet como en Internet.

Condiciones previas: Tener aprobado los cursos GeneXus y Client/Server

Alcance: Información general sobre lenguaje Java, Información general sobre Generador Java, Software necesario, Configuración del Modelo, Distribución de aplicaciones para su puesta en producción, Ejecución en múltiples capas, Pool de conexiones, Lightweight Directory Access Protocol (LDAP)

Orientado a: Gerentes de Proyecto y Técnicos de la empresa.

Duración: 12 horas (teórico/práctico) distribuidas en 3 días.

DESARROLLO DE APLICACIONES PARA INTERNET

Objetivo: Dar los elementos necesarios para poder generar aplicaciones a ser utilizadas en Internet. Integrar las operaciones de Internet con la Base de Datos Coorporativa.

Condiciones previas: Tener aprobado el Curso GeneXus.

Duración: 24 horas distribuidas en 6 días.

7

CURSO DATA WAREHOUSING

Objetivo: Durante años hemos desarrollado sistemas operacionales y con ellos hemos resuelto muy bien las funciones operacionales de nuestras organizaciones (fábricas de datos). Como consecuencia de esto, en nuestras bases de datos hemos recopilado una gran cantidad de datos y con ellas hemos ofrecido un buen nivel de información a nivel de gestión. Sin embargo, no hemos podido usar esos datos para proveer información a los niveles más altos de nuestras organizaciones, ni hacerlo con el dinamismo necesario. Este fenómeno es conocido como 'data in jails' (los datos existen, pero están 'enjaulados'). Los niveles de dirección y estratégicos son los que actualmente se encuentran más carentes de información. Necesitamos proveer información de buena calidad, oportuna y en forma dinámica para el apoyo a la toma de decisiones.

En la última década surgen, bajo el nombre DATA WAREHOUSING, ciertas técnicas, metodologías y teconologías con el fin de resolver esta problemática.

ARTech ha y está trabajando en la investigación y desarrollo de tecnología para facilitar el desarrollo de Soluciones de Data Warehousing.Hemos acumulado conocimiento sobre este tema en base a material existente y a nuestra propia experiencia en proyectos de este tipo y formalizado el mismo; llegando a construir una metodología sencilla y desarrollando tecnología para apoyar todas las etapas de la solución.

El objetivo de este curso es : conocer la teoría de Data Warehousing, cuales son las componentes de la solución, técnicas y metodologías aplicadas, tecnología asociada a cada componente, y ver como la tecnología GeneXus nos apoya en cada etapa del proceso de construcción de la solución.

ALCANCE : Los punto principales que se tratan en el curso son los siguientes: Conocimientode los diferentes aspectos de la problemática, Esquema general de la solución Data Warehousing, Componentes de la solución, Etapas en el desarrollo de un proyecto, Estudiodetallado de las metodologías aplicadas en cada etapa y Tecnología asociada a cadacomponente. En forma paralela al curso teórico se irán estudiando casos prácticos y losparticipantes irán aplicando sobre éstos las metodologías aprendidas. Finalmente el participanterealizará el diseño y parte de la implementación de un caso práctico con la tecnología GeneXus - Data Warehousing.

ORIENTADO A: El Curso está orientado principalmente a Gerentes de Informática, Líderesde Proyectos y Desarrolladores. A los Líderes de proyectos y Desarrolladores se les pide teneraprobado el Curso GeneXus. A los Gerentes de Informática se les recomienda realizarpreviamente las dos primeras semanas del curso GeneXus.

DURACIÓN: 32 horas distribuidas en 8 días.

8

CURSO WORKFLOW

Objetivo: Uno de los problemas que se encuentra habitualmente en el desarrollo de aplicaciones para empresas, es que las tareas o procesos que se desarrollan en el entorno laboral de las mismas quedan inmersos en el código de la aplicación que resuelve la problemática de la empresa. Está claro que la gran mayoría de los usuarios no tienen conocimiento de estas tareas, las mismas están ocultas a sus ojos y se realizan automáticamente. El hecho de realizar cambios en dichas tareas o procesos resulta muy costoso, y es muy factible que dichos cambios redunden en realizar nuevamente la aplicación.Una buena solución al problema anterior es separar los procedimientos y asociarlos a los flujos de trabajo realizados dentro de la empresa. Vemos entonces, que el Workflow se relaciona con la automatización de los procedimientos donde los documentos, la información o tareas son pasadas entre los participantes del sistema de acuerdo a un conjunto de reglas previamente establecidas. El fin de lo anterior es llegar a culminar una meta común impuesta por la empresa.El Workflow nos da las facilidades para modelar los procesos de empresa, permitiéndonos de esta forma hacer un análisis y diseño mas profundo de los mismos. Vemos entonces al Workflow no solo como una tecnología que nos facilita el cambio, sino también, como una tecnología que nos da un marco de referencia para el análisis y diseño previo a la implantación de un sistema que implica la interacción de diversos procesos.ARTech ha estado trabajando en la investigación y desarrollo de tecnología de Workflow para incorporarla al desarrollo de los Sistemas de Información. Esto surgió al detectarse que en varios proyectos realizados nos enfrentábamos a problemas que se podían resolver de una forma más natural con este tipo de tecnología. Así en una primera instancia surgió una solución de Workflow específica para resolver la problemática de un proyecto y hoy en día se dispone de una solución integral para desarrollos con GeneXus que está siendo utilizada en varios proyectos. El objetivo de este curso es: conocer los conceptos más importantes de la teoría de Workflow, cuales son las componentes de la solución, tecnología asociada a cada componente, y ver como se integra esta tecnología al desarrollo de sistemas con GeneXus.

Alcance: Los puntos principales que se tratan en el curso son los siguientes: Conceptos Teóricos de Workflow, estudio de la herramienta de definición de procesos (GeneXus ProcessModeler), estudio del Workflow en ejecución (Inbox y Motor de Workflow), estudio de las Workflow APIs, y el estudio de la integración de la solución de Workflow con el desarrollo de los sistemas con GeneXus. En forma paralela al curso teórico se irá estudiando casos prácticos y los participantes irán aplicando sobre éstos las metodologías aprendidas. Finalmente el participante realizará el diseño y la implementación de un caso práctico con la tecnología GeneXus-Workflow.

Orientado a: El Curso está orientado principalmente a Gerentes de Informática, Líderes de Proyectos y Desarrolladores. A los Líderes de proyectos y Desarrolladores se les pide tener aprobado el Curso GeneXus. A los Gerentes de Informática se les recomienda realizar previamente las dos primeras semanas del curso GeneXus.

Duración: 16 horas distribuidas en 4 días.

9

RECOMENDACIÓN:A continuación detallamos una propuesta de capacitación para cada uno de los Roles que se llevan a cabo dentro del área de informática.Reconocemos que muchas veces estos roles son cumplidos por la misma persona o por varias , para lo cual deberán considerarse las funcionesmás que las personas.

•DESARROLLADOR GENEXUS: Persona directamente involucrada en el Desarrollo de Aplicaciones•GERENTE y/o LÍDER DE PROYECTO : Persona que coordina el desarrollo de un grupo de desarrolladores y eventualmente desarrolla aplicaciones.•GERENTE DE INFORMATICA: Persona encargada del sector informático de la Empresa.

DESAROLLADOR- CURSO GENEXUS - Al comienzo- WORKSHOP - Inmediatamente despúes de finalizado el Curso Genexus- CLIENT/SERVER - Después del Curso Genexus (si corresponde)- DESARROLLO DE APLICACIONES PARA INTERNET - Después del Curso Genexus (si corresponde)-WORKFLOW - Después del Curso Genexus (si corresponde)-CURSO PARA GERENTES DE PROYECTOS - Tres meses después de aprobado el Curso Genexus

GERENTE y/o LÍDER DE PROYECTO- CURSO GENEXUS - Al comienzo- CURSO PARA GERENTES DE PROYECTOS - Inmediatamente después del Curso Genexus- CLIENT/SERVER - Después del Curso Genexus (si corresponde)- DESARROLLO DE APLICACIONES PARA INTERNET - Después del Curso Genexus (si corresponde)- WORKFLOW - Después del Curso Genexus (si corresponde)

GERENTE DE INFORMÁTICA

- TEORICO DEL CURSO GENEXUS PARTE 1- Al comienzo

- CURSO PARA GERENTES DE PROYECTOS- Después del teórico del Curso Genexus Parte1

10

Introducción

Teórica

11

Nuestra tarea como profesionales de la informática es desarrollar y manteneraplicaciones para apoyar al usuario en su actividad final. Para realizar esta tarea se han instrumentado diferentes herrramientas y metodologías.

Con GeneXus se desarrollan aplicaciones aplicando una metodología que tiene un enfoque muy diferente al de las metodologías mas comunmente utilizadas.

Aprender a utilizarlo adecuadamente va más alla de conocer el lenguaje de especificación y lo más importante es el aprendizaje de una nueva metodología de desarrollo.

BASEDE

DATOSPROGRAMAS

REALIDAD

• DesarrolloyMantenimiento

Herramientas y Metodologías

?

12

BASEDE

DATOSPROGRAMAS

VISIONESDE

USUARIOS

SatisfaceMODELO DE

LA REALIDAD

Modelado de la realidad a partir de las Visiones de Usuarios

Ingenieria Inversa

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 objetivay detallada al mismo tiempo, que nos permita construir un modelo corporativo?

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, utilizarestas visiones de los objetos de su realidad como fuente de información parece muyrazonable.

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 visionespodremos obtener mediante Ingenieria 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 soportecomputacional (base de datos y programas ) para soportarlo.

13

Es bueno, para fijar ideas, comparar la metodología utilizada por GeneXus conocidacomo Metodología Incremental con las metodologías tradicionales más utilizadasactualmente.

Algunos de los ejemplos de estas metodologías son: Análisis Estructurado, Ingenieríade la Información, Análisis Escencial.

Estas metodologías son diferentes entre sí, pero en todos los casos, separan el análisisde los datos del de los procesos.

Veremos un esquema general que podría aplicarse a cualquiera de éstas metodologíasy estudiaremos sus problemas.

Comparación de

Metodologías

14

Metodología Tradicional

• .

15

REALIDADREALIDADANALISIS

DEDATOS

BASEDE

DATOS

ANALISISFUNCIONAL

PROGRAMACION

PROGRAMAS

GENERACION/INTERPRETACION

ESPECIFICACIONFUNCIONAL

La primera tarea, generalmente, es el análisis de datos.

Se pretende analizar la empresa y dar como producto un modelo de datos con lasEntidades 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 hacenque esta tarea sea extremadamente compleja.

Debido a la complejidad de la construcción de un sistema integrado,lo que se hacenormalmente es dividirlo en módulos, y cada uno solucionará los problemasoperativos 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ónredundante y como consecuencia todo intento de buscar información fuera del entornode cada aplicación resulte imposible o por lo menos peligroso.

16

En caso de que desearamos posteriormente realizar la integración de esos módulos esnecesario realizar modificaciones al modelo de datos (lo que a pesar de la complejidadpodríamos calificar como posible), pero las modificaciones que deberemos realizar en losprogramas 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 luegoaparecerán con mucha claridad los problemas de la carencia de información que permitanorientar 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 mascomplejas. Esto lleva a que el diseño de una base de datos corporativa sea una tarea muycomplicada y en la que son muchos los errores que se pueden cometer.

GeneXus apunta a la creación de sistemas corporativos, brindando herramientas y unametología que hagan posible la realización de esta tarea.

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 datosnecesaria para soportarlo, existe una transformación trivial. Por ello, para mayor claridaddel 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 tareageneralmente llamada Análisis Funcional, donde se estudia la empresa desde el punto de vista de las funciones y que tiene como resultado una Especificación Funcional.

El producto de la función anterior es la Especificación Funcional. Sería deseable queesta Especificación Funcional fuera independiente de la Especificación de Datos. Peroesto 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 lasespecificaciones funcionales.

Esta es la causa fundamental de los grandes costos de mantenimiento que deben soportarlas empresas.

17

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ónLenguajes de bajo nivel como pueden ser COBOL, RPG, C, PASCAL, ADA, FORTRAN.

Lenguajes de 4a. GeneraciónLenguajes 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 analistadebe 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 escribemucho menos (probablemente 10 veces menos) y, como consecuencia, la productividades 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 hoyestas herramientas están dotadas de primitivas que permiten complementar su código, porlo 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ónpermiten 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 puedeinterpretar la especificación funcional, (que obviamente debe ser totalmente rigurosa), y producir automáticamente los programas.

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 nicodificación procedural alguna).

Algunos ejemplos son ADELIA, AS/SET, LANSA, SYNON, TELON, etc..Existe otracategorí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.

18

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, estasherramientas están dotadas de Lenguajes de Diagramas de Acción, (en la prácticalenguajes de 4a. generación), que permiten complementar su código, por lo que suaplicabilidad 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ónBaja productividad en el desarrollo

Lenguajes de 4a. GeneraciónBuen aumento de productividad en el desarrollo sobre L3G.

GeneradoresBuen 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 suvalidez 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.

19

Los fundadores de ARTech han desarrollado una amplia actividad de consultoríainternacional en diseño de grandes bases de datos.

Cuando se comenzaron a utilizar verdaderos modelos corporativos, que normalmenteposeen cientos de tablas, les quedó claro que no debía perderse más tiempo buscandoalgo que no existe: las bases de datos estables.

Luego de importantes investigaciones, desarrollaron una teoría, organizaron unametodología e implementaron una herramienta para posibilitar el desarrolloincremental y permitir la convivencia con las bases de datos reales (inestables), a costo mínimo.

Metodología

20

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 éllas 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.

Desarrollo con

REALIDADDESCRIPCIONDE OBJETOS

21

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 datoscomo los programas de la aplicación.

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 realizarinferencias que permiten obtener más conocimiento.


BASE DE CONOCIMIENTO

BASEDE

DATOS

PROGRAMAS

Desarrollo con

22

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.


BASE DE CONOCIMIENTO

BASEDE

DATOS

PROGRAMAS

ANALISISDE

DATOS

ANALISISFUNCIONAL

PROGRAMACION

Comparación de Metodologías GENERACION/

INTERPRETACION

ESPECIFICACIONFUNCIONAL

23

La primer tarea que hay que realizar es pasar a describir los objetos de la realidad, mediante objetos Genexus.

Para ello existen 5 objetos básicos:

TRANSACCIONESLas transacciones permiten definir los objetos de la realidad. La mayor parte de lastransacciones pueden ser identificadas prestando atención a las entidades que el usuariomenciona (por ej. Clientes, Proveedores, Artículos).A partir de las transacciones Genexus infiere el diseño de la base de datos.

PROCEDIMIENTOSProcesos no interactivos de actualización de la base de datos (procesos batch).

REPORTESRecuperan información a partir de los datos almacenados y no los alteran. Los reportesson lo que conocemos habitualmente como listados.

PANELES DE TRABAJOPermite definir consultas interactivas a la base de datos. Es un objeto muy flexible quese presta para múltiples usos.

MENUESObjetos organizadores del resto.

Descripción de Objetos

Transacciones(TRNs)

Reportes(RPTs)

Procedimientos(PROCs)

Work Panels (WKPs)

Menues(MNUs)

24

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 sistematizaen 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 índicesnecesarios.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.

Sistematización del conocimiento

Base de ConocimientoBase de Conocimiento

Transacciones(TRNs)

Reportes(RPTs)


Work Panels (WKPs)

Menues(MNUs)

25

A partir del conocimiento especificado a través de las transacciones, GENEXUS diseña el modelo de datos normalizado (en 3a. forma normal).

Inferencia de la Base de Datos


Transacciones(TRNs)

Reportes(RPTs)


Work Panels (WKPs)

Menues(MNUs)

BaseBasedede

DatosDatos

26

GENEXUS genera automáticamente los programas necesarios para crear la base de datos, y la crea mediante ellos.

Creación de la Base de Datos


BaseBasedede

DatosDatos

Programas Generación

BD

Transacciones(TRNs)

Reportes(RPTs)


Work Panels (WKPs)

Menues(MNUs)

27

GENEXUS genera automáticamente, a partir de la Base de Conocimiento, losprogramas de la aplicación.

Generación de los Programas de laAplicación


Programas de Aplicacion

(TRN, RPT, PROC, WKP y MNU)

Transacciones(TRNs)

Reportes(RPTs)


Work Panels (WKPs)

Menues(MNUs)

BaseBasedede

DatosDatos

28

En este estado , la aplicación está pronta.

Resultado final en la Etapa de Desarrollo




Aplicaciones

Transacciones(TRNs)

Reportes(RPTs)


Work Panels (WKPs)

Menues(MNUs)

BaseBasedede

DatosDatos

29

Como se ha dicho, durante el ciclo de vida de la aplicación, existen muchasmodificaciones.

Ante cambios en las visiones de usuarios, GENEXUS diseña la nueva base de datos.

Las Visiones de los Usuarios Cambian




Nueva Nueva BaseBasedede

DatosDatos

NuevasTransacciones

NuevosReportes

NuevosProcedimientos

NuevosWork Panels

NuevosMenues

BaseBasedede

DatosDatos

30

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 eventualesproblemas que esa reorganización podría ocasionar.

Una vez analizado el análisis de impacto, el analista resolverá efectuarla reorganización o renunciar a ella volviendo a la situación anterior.

Análisis de Impacto Totalmente Automático




DatosDatos

NuevasTransacciones

NuevosReportes


NuevosWork Panels

NuevosMenues

Análisisde

impacto


BaseBasedede

DatosDatos

31

Si el analista ha dado el visto bueno a la reorganización, GENEXUS genera automáticamente los programas necesarios para esareorganizació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 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.

Generación de Programas de Reorganizaciónde la Base de Datos




DatosDatos

NuevasTransacciones

NuevosReportes


NuevosWork Panels

NuevosMenues

Programasde

Reorganiz.


BaseBasedede

DatosDatos

32

Análisis Automático del Impacto de loscambios sobre los Programas


DatosDatos

NuevasTransacciones

NuevosReportes


NuevosWork Panels

NuevosMenues


NuevosProgramas de Aplicacion


Análisisde

impacto

33

GENEXUS genera /regenera automáticamente los programasnecesarios.

Generación Automática de Nuevos programas


DatosDatos

NuevasTransacciones

NuevosReportes


NuevosWork Panels

NuevosMenues




Generaciónde nuevosProgramas

34

Ahora se tienen las nuevas aplicaciones. El ciclo de mantenimiento estácompleto.

Aplicaciones

Nueva Realidad , con los cambios en la Aplicación


DatosDatos

NuevasTransacciones

NuevosReportes


NuevosWork Panels

NuevosMenues




35

Múltiples Plataformas de ejecución a partir de una única especificación

ARQUITECTURAS CENTRALIZADASPlataforma Lenguaje Generado AS/400 COBOL/400, RPG/400ARQUITECTURAS FILE SERVERPlataforma Lenguaje Generado DOS Foxpro, Clipper DBFWINDOWS Foxpro for Windows DBF

Visual Basic ACCESSVisual Fox DBF

ARQUITECTURA CLIENT/SERVERCliente Database Server Plataformas (Ejs.)FOXPRO WIN, VB, VFP, JAVA ORACLE Unix, NT

MS SQL SERVER Alfa, WINDOWS NT y 95 INFORMIX Unix, NTDB2 Common Servers RS6000, OS2DB2/400 AS400

36

Metodología Incremental

Consiste en construir una aplicación mediante aproximacionessucesivas.

DEFINICION INICIAL

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 unametodología de desarrollo que podríamos llamar “Metodología Incremental”, ya que el proceso se realiza mediante aproximaciones sucesivas.

En cada momento desarrollamos la aplicación con el conocimiento quetenemos y luego cuando pasamos a tener más (o simplemente diferente) conocimiento, GENEXUS se ocupará de hacer automáticamente todas lasadaptaciones 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.

37

Ciclos Diseño-Prototipo yDiseño-Producción

Diseño Prototipo 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 durantela 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 solamentecuando el prototipo ha sido totalmente aprobado, o luego de haberinstrumentado y probado algún cambio.

38

BASEDE

DATOSPROGRAMAS

Prototipación Integral en PC

MODELO DELA REALIDAD

Construcción Automática

Usuario probando todos los detallesde la aplicación

La construcción automática del soporte computacional nos dará la granposiblidad de crear prototipos. Verdaderos prototipos ! , ya que estos tendrán un funcionamiento equivalente al del sistema en producción real, permitiendo quese 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.

39

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 de sistemas es, habitualmente,una tarea que insumebastante tiempo. Como muchos de estos problemas sólo son detectados en las pruebasfinales 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 lasespecificaciones mientras se implementa el sistema. La consecuencia de mantener lasespecificaciones, es que se acaba implementando una solución relativamenteinsatisfactoria.El impacto de estos problemas disminuiría mucho si se consiguiera probar cadaespecificació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, esla posibilidad de mostrar al usuario formatos de pantallas, informes, etc. animados pormenúes. Esto permite ayudar al usuario a tener una idea de qué sistema se le construirápero, al final, siempre se presentan sorpresas.

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

40

Ahora vamos a concentrarnos en cuál es la forma práctica utilizada porGeneXus, para la captura de la realidad de la que tanto hablamos.

Jean Dominique Warnier y Ken Orr, formularon una teoría acerca de cómopuede ser construida una aplicación de procesamiento de datos. Algunos de sus enunciados fueron los siguientes:

• Los datos y los procesos están estructurados.• Todos los procesos son subdivididos en subconjuntos partiendo del nivel másalto 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.

Analicemos por ejemplo un proceso de emisión de las Facturas de unaempresa:

Tenemos en este proceso 5 niveles, distinguiendo en cada nivel, los conjuntosrepetitivos de lo que está presente una sola vez. Vemos que la gestiónjerárquica de los datos hace aparecer relaciones entre los conjuntos definidosen 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 incluído en él.

Todo conjunto de nivel inferior se llama Conjunto de Partida y todo conjuntode nivel superior se llama Conjunto de Llegada.

En el momento de jerarquizar procesos y datos, sería muy bueno que obtuvieraeste 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 tantocomo la de los procesos.

Warnier-Orr

Emisión dela Factura

Comienzo

Emisión deuna Factura(cuerpo)

Fin

Emisión delcabezal

Proceso deemisión delíneas

Fin

Nro de FacturaNro de ClienteNombre ClienteFecha Factura

Comienzo

Emisión deuna línea

Fin

Código ProductoNombre ProductoPrecio ProductoCantidad ProductoImporte Producto

41

DISEÑO DE TRANSACCIONES

42

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 siguientenotació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 comoidentificador de cada instancia de este conjunto. Notaremos a estos atributoscon un asterisco. Este es en definitiva el concepto de clave primaria por lo queen la elección de estos atributos debemos atender a todas las reglascorrespondientes a su definición.

El conjunto de atributos entre paréntesis representa la ocurrencia de variospara cada instancia del nivel anterior. En el ejemplo, una factura tiene variosproductos.

Notación GeneXus para Transacciones

Ejemplo: Proceso de Emisión de Facturas

FacNro* Código de la facturaCliCod Código del clienteCliNom Nombre del clienteFacFch Fecha de la factura

(ProdCod* Código del productoProdNom Nombre del productoProdPre ) Precio del producto

43

Definición del diseño de Base de Datos en 3era Forma Normal para soportar las transaccciones definidas.

TRN. FACTURA TABLAS

FacNro* FacturaCliCod FacNro*CliNom CliCodFacFch CliNom

(ProdCod* FacFchProdNomProdPre Factura1FacLinCnt FacNro*FacLinImp) ProdCod*

ProdNomProdPre

FacLinCntFacLinImp

Veamos el proceso de obtención de una base de datos en 3era. forma normal a partirde las especificaciones de transacciones.

Para esto utilizaremos como ayuda las dependencias funcionales que se derivaríande la definición de la transacción.

La definición de esta primera transacción a determinado las siguientes dependenciasfuncionales.

FacNro ----> CliCodFacNro ----> CliNomFacNro ----> FacFch

Por lo que se definirá una tabla con el siguiente diseñoFacNro*CliCodCliNomFacFch

Tenemos además las siguientes dependencias funcionales determinadas por el 2do nivel de la transacción.

FacNro, ProdCod ----> ProdNomFacNro, ProdCod ----> ProdPreFacNro, ProdCod ----> FacLinCntFacNro, ProdCod ----> FacLinImp

Que definirán una tabla con el siguiente diseñoFacNro *ProdCod*ProdNomProdPreFacLinCntFacLinImp

44

Trn. Clientes

CliCod* CliNom

Trn. Productos

ProdCod*ProdNomProdPre

Clientes

CliCod* CliNom

Producto


Factura

FacNro*CliCodCliNomFacFch

Factura1

FacNro*ProdCod*ProdNomProdPreFacLinCntFacLinImp

Definición de las transacciones Clientes y Productos

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á lasmodificaciones necesarias en las ya existentes ( Factura y Factura1 ) para considerar elconjunto total de dependencias funcionales.

CliCod ----> CliNomProdCod ----> ProdNom, ProdPre

La siguiente dependencia funcional

FacNro ----> CliNom

se ha vuelto transitiva a partir de la existencia de las dep. func.

FacNro ----> CliCodCliCod ----> CliNom

Por lo que deberá modificarse la tabla Factura.

Análogamente con la tabla Factura1 y las dependencias funcionales

FacNro, ProdCod ----> ProdNom, ProdPreProdCod ----> ProdNom, ProdPre

45

GeneXus establece las relaciones por los nombres.

Todo lo que es conceptualmente lo mismo, debe tener el mismo nombre.

Transacciones: Factura ClienteFacNro* CliCod SI CliCod*CliNom CliNom.......... ...........

Factura ClienteFacNro* CliFacCod NO CliCod *

Conceptos diferentes no deben tener el mismo nombre.Ventas ComprasFctVtaNro* FctCmpNro*Fecha NO FechaCliCod PrvCod

CliNom PrvNom

46

• Facilitan la tarea de darle nombre a un atributodentro de las reglas establecidas

• Facilitan la tarea de integración de bases de conocimiento

Es conveniente usar padrones para losnombres de atributos.

47

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 utilizadopor 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.Calificador, Puede existir uno o dos calificadores.

Categoría Semántica (1 a 3)

Objeto ( 1 a 6 )

Calificador (1 a 3)

Calificador (1 a 3)

Complemento(texto libre)

Nomenclatura GIK - Nombre del Atributo

48

Ejemplo de Nomenclatura GIK

Objetos Categorias CalificadorCli

Cli

Cli

Cli

FacVta

FacCmp

Cod

Nom

Fch

Fch

Nro

Nro

Ini

Fin

49

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 sucontenido.

Long VarcharPermite almacenar una cantidad de caracteres indefinida. Se utiliza normalmentepara almacenar textos, descripciones, comentarios, etc.El largo que se le asigna es considerado el largo máximo (la implementacióndepende de la plataforma).

VarCharPermiten 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.

50

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.

DateTimePermite 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.

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.

51

Comandos de asignación

• +=

• -=

• *=

• /=

Sintaxis: <Variable_o_Atributo> <Comando> <Expresión>

Ejemplo: &I += 1 (equivalente a &I = &I + 1)

52

El objetivo de los dominios es permitir usar definiciones de atributosgené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 cliente son asociados a él. Por lo tanto, sien 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 pemiten un mayor nivel de abstracción en la definición de la aplicación.

Dominios

Cuando debemos usar dominios?

• Atributos con la misma definición• No existe relación entre ellos

Ejemplo: Dirección Char 30

Dirección del ClienteDirección del Banco

Atributos

Dominio

53

Reglas

• Se utilizan para definir el comportamiento de las transacciones.

• Algunas reglas– Default, Error, Ask, Msg, Asignación, Add, Subtract, etc.

• Default(FacFch, &today);• Error(‘No se permiten clientes sin nombre’)

if null(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 suestructura y su COMPORTAMIENTO.

En el caso de las Transacciones, el comportamiento se define mediante el uso de Reglas (Rules).

Algunas reglas:Default - 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 queremospermitir que queden ingresados clientes sin nombre:

Error(‘No se permiten clientes sin nombre’)if null(CliNom);

Cuando se cumple la condición ( null(CliNom) ) se despliega el mensaje (‘No se permiten clientessin nombre’) en pantalla y no se permite continuar hasta que el usuario ingrese un nombre sobre el campo CliNom.

Asignacion - Dentro de las reglas de la transaccion se permiten definir asignaciones a atributos, dicha asignacion implica una actualizacion en la tabla base del nivel o en alguna de las tablas quepertenecen a la tabla extendida del nivel.Una asignacion en las reglas es LOCAL (vale solo para la transaccion en la cual fue definida).

Orden de evaluaciónLa 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).

541612121212

Toolbar de ControlesPara el diseño de Pantallas • Atributo / Variable• Texto• Línea• Recuadro• Subfile• Botón • Bitmap• Tab Control• Print Block

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 bar de Controles que contiene los tipos de controles que se pueden agregar al form que se está editando.

55

Tab Control• Permite definir varios controles dentro de un Tab

Control.• Tiene una o varias páginas.

– Default: Dos páginas– Agregar o eliminar páginas:

• Botón derecho sobre el Tab Control

– Página• Título• Area útil

– Check Box de Hide Tabs ==> Para diseño de Wizards

• Sólo para los generadores visuales.

Un Tab Control tiene una o varias páginas (por defecto tiene dos). Cada páginatiene un título y un área útil, es decir donde se ponen los controles de esapágina. Sólo una de las páginas puede estar activa a la vez y es la que se puedever. 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 opcionescon botón derecho sobre el Tab Control.

Hide TabsPara mostrar sólo la página activa y no mostrar los tabs. Util para la definiciónde Wizards.

5662

• 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/Foxpro/Visual FoxPro y se requiere como mínimo la versión 3.10.505.

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.

5763

Generación de HELP Tipo Windows

• 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.

58

Al definir un modelo, es necesario ingresar cierta información. La información solicitada es la siguiente:

•Name: Nombre del modelo que se esta creando•Type: Tipo de modelo (Prototipo, Producción, Backup)•Language: Idioma (Inglés, Español, Portugues, Italiano)•Generador: Plataforma en la cual se desea que sean generados los programas (tanto los programas de creación/reorganización de la base de datos, como los programas de aplicación).•DBMS: Sistema Manejador de Base de Datos•Target Path: Directorio en el cual quedaran los programas generados (este directorio será creado bajo el directorio de la Base de Conocimiento).

El botón Preferences permite configurar ciertas propiedades para el modelo (dependiendo del generador elegido, algunas propiedades a configurar seran distintas).

El botón DBMS Options permite configurar la información requerida para el acceso a la Base de Datos (por ejemplo, Data Source, etc.).

El botón Execution permite configurar ciertas propiedades de ejecución (por ejemplo, donde se encuentra instalado el intérprete).

Pasemos a Prototipo...

59

INTEGRIDADREFERENCIAL

60

Las reglas de integridad referencial permiten asegurar la consistencia entre losdatos de las distintas tablas. El diagrama anterior se ha inspirado en losconocidos Diagramas de Bachman, y tiene la virtud de explicitar la integridadreferencial del modelo de datos.

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 determinaanalizando los atributos que tienen en común.

Por ejemplo, entre las tablas Clientes y Categorías tenemos que el atributocomún es el código de la categoría, que es la clave primaria de la tablaCategoría. Decimos que la relación entre ambas tablas es 1-N, que indica queun cliente tiene una categoría y una categoría tiene N clientes. También esusual 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 esindependiente, por lo que es neceario realizar controles para que la informaciónsea consistente.

A estos controles se les llama de Integridad Referencial y básicamente son lossiguientes:

* 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 debenexistir registros correspondientes en la tabla subordinada (Client).

Diagrama de Bachman

Catego

Client

Depart

DtoCod*DtoNom

CliCod*CliNomCatCodDtoCod

CatCod*CatNom

61

Definición de Indices Para hacer eficientes los controles de Integridad, GeneXus crea automáticamente índices, queson vías de acceso eficientes a las Tablas. Existen tres tipos de índices: Primarios, Extranjeros y del Usuario.

Indice 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 tablassubordinadas (Client), exista el registro correspondiente en la tabla superordinada (Catego). Con GeneXus todos los índices primarios son definidos automáticamente a partir de losidentificadores de las transacciones.

Indice 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 una tablasuperordinada (Catego), no deben existir registros correspondientes en la tabla subordinada(Client).

Indice del Usuario: Los índices del usuario se definen, fundamentalmente, para recorrer los datos por determinadoorden de una forma eficiente. Por ejemplo, en la tabla Client se puede definir un índice porCliNom, que es muy útil para los listados ordenados por nombre. 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.

Definición de Indices

Tabla IndiceTipo Composición

Catego PK CatCodDepart PK DtoCodClient PK CliCod

FK DtoCodFK CatCod

62

CONCEPTO DE TABLA EXTENDIDA

63

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 maneratiene 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 algunosinconvenientes.

El inconv3eniente más notorio es que los datos se encuentran dispersos en muchastablas, 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.

DefiniciónDada una tabla de la base de datos, se denominatabla 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.

Tabla Extendida

64

Tabla Base y Tabla Extendida

FACTURA CLIENTE CATEGORIA

FACTURA1 PRODUCTO

FacNro*FacFchCliCod

CliCod*CliNomCatCod

CatCod*CatDto

FacNro*ProdCod* FacLinCnt


65

Tabla Base: Tabla extendida:Categoría CategoríaCliente Cliente

CategoríaFactura Factura

ClienteCategoría

Factura1 Factura1ProductoFacturaClienteCategoría

Producto Producto

66

ATRIBUTOS FORMULAS

67

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 otrosatributos.

En cada transacción se puede definir qué atributos son fórmulas, pero esta definiciónes 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 sintáxis 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 lasreglas 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.

68

Clasificación

HorizontalesUna o varias expresiones aritméticas condicionales.

VerticalesSUM COUNT

Aggregate / SelectSelect

Max, Min, FindAggregate

Sum, Count

Fórmula HorizontalLos atributos involucrados en la misma deben pertenecer a la tablaextendida del atributo definido como fórmula.

Fórmula VerticalLos atributos involucrados deben pertenecer a la tabla directamentesubordinada del atributo definido como fórmula.Son incondicionales.

Aggregate / SelectPueden navegar sobre cualquier tabla del modelo.Son condicionales.

69

Atributo = <Expresión> if <Condición>;<Expresión> if <Condición>;

:<Expresión> Otherwise;

Fómulas Horizontales

<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ómula deja de estar almacenado en la tabla y decimos que es un atributovirtual.

<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 atributosutilizados en dicha fórmula se encuentren en ella.

70

Ejemplo:

TRANSACCION TABLACliCod* CliCod*CliNom CliNomCliTotCmp CliTotCmpCliTotPgo CliTotPgoCliSdo = CliTotCmp- CliTotPgo

Fómulas Horizontales

Un atributo puede definirse como fómula 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órmulaLa 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 objeto GeneXus ya que el atributono está almacenado en la tabla.

•ReglaLa 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.

71

Importe de la Línea de la Factura


FACTURA1 PRODUCTO

FacCod*FacFchCliCod

CliCod*CliNomCatCod

CatCod*CatDto

FacCod*ProdCod*FacLinCnt


FacLinImp = FacLinCnt * ProdPre if FacLinCnt <= 100;

(FacLinCnt * ProdPre * 0.9) if FacLinCnt >100;

En el ejemplo, definimos al importe del producto en la factura (FacLinImp) como una fórmula horizontal, por lo cual dicho atributo no está almacencadoen la tabla Factura1.

72

Sintáxis:– 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

Fórmulas VerticalesSUM - COUNT

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.

Estas fórmulas se utilizan cuando el valor de un atributo se obtiene sumando o contando filas de una tabla que está directamente subordinada (es decir, cuando las filas pertenecen a una tabla que está en una relación 1 a N).Se consideran todas las filas que pertenecen a la relación ya que no se puedenestablecer condiciones.Se resuelve mediante una navegación vertical, de ahí el nombre FórmulasVerticales

PerformanceEl hecho que la fórmula no este almacenada, puede ocasionar en algunos casos, problemas de performance debido al tiempo que puede demorar el recálculo. Esto dependerá de la cantidad de registros que se sumen / cuenten.

Para evitar este inconveniente, Genexus provee la posibilidad de definir a la fórmula vertical 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.

73

Factura

Factura1

1

N

Cálculo del subtotal de la FacturaFactura:

FacNro*FacFchCliCodFacSubTot = SUM(FacLinImp)

Factura1:FacNro*ProdCod*FacLinCntFacLinImp = FacLinCnt * ProdPre

•FacSubTot y FacLinImp no están almacenados.• Equivalencia entre SUM redundante y regla ADD

Fórmulas VerticalesSUM - COUNT

Precisamos calcular ahora el subtotal de las líneas de la factura, que hemosllamado FacSubTot. Este atributo está en el cabezal de la factura y el atributo a ser sumado está 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órmulasVerticales.

Se puede decir que un SUM redundante es equivalente a la regla ADD.

74

Fórmulas Verticales

Sólo se puede definir entre atributos de tablas “directamente”subordinadas

FACTURA CLIENTE

FACTURA1

SUM(att) No permitido

1N

1

N

FacSubTot = SUM(FacLinImp)

FacLinImp

SUM (att)Puede ser Fórmula

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óncorrespondiente.

75

Son fórmulas que permiten buscar, sumar, contaratributos que cumplan determinadas condiciones, encualquier tabla del modelo.

Aggregate– Sum – Count

Select– Max– Min – Find

Fórmulas Aggregate/Select

Fórmulas Aggregate

Sum .- Suma condicionalmente atributos de cualquier tabla del modeloCount .- Cuenta condicionalmente filas de cualquier tabla del modelo

Fórmulas Select

Find .-Buscar el valor de un atributo en determinadas condicionesMax .-Buscar el máximo valor de un atributo en determinadas condicionesMin .-Buscar el mínimo valor de un atributo en determinadas condiciones

76

Fórmulas Aggregate/Select

Sintáxis

– atrib = Sum | Count (<att>, <cond. búsq.>, <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 )

Max ( atributo a maximizar, condiciones de maximización, valor por defecto en caso de no encontrar quien cumpla con las condiciones, valor de retorno en casode encontrar)

Find (atributo a buscar, condiciones de búsqueda, valor por defecto en caso de no encontrar quien cumpla con las condiciones)

77

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 retorno 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

Para distinguirlas en los listadosVerticales - SUM y COUNT todas las letras en mayúsculasAggregate - Sum y Count sólo la primer letra con mayúscula

Los siguientes ejemplos de fórmulas Aggregate y fórmulas Select, se incluyen comodocumentación y no necesariamente se harán ejemplos en el curso, salvo que losalumnos lo pidan.

Ejemplo de Count Aggregate:

Total de productos con descuento en la factura:Factura

FacNro*FacFchCliCodFacTotArtDscto = Count(ProdCod, FacDscto > 0)

78

Factura1FacNro*ProdCod*FacLinCntFacDsctoFacLinImp

FacNro ProdCod FacDscto1 1 101 2 01 3 201 4 0

FacTotArtDscto = 2

79

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.

Sintáxis:

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 dolar del día.La tabla de cotizaciones no tiene ninguna relación con la de documentos.

Documentos CotizacionesDocNro* MonCod*DocFch MonFch*DocImp MonCotDocImpDolar = DocImp / DocCotDolarDocCotDolar = Find(MonCot, MonCod = ‘U$S’ .and. MonFch = DocFch)

80

Max

Esta función determina el máximo valor de un atributo en una tabla. Obtenido estevalor, que corresponderá a una determinada fila, la función devuelve el valor de cualquier atributo de dicha fila.

Sintáxis:

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 (Tablade llegada), es decir no puede ser un atributo fórmula o pertenecer a su tablaextendida.

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 estaralmacenado 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.

Documentos CotizacionesDocNro* MonCod*DocFch MonFch*DocImp MonCotDocImpDolarDocCotDolar

81

Atributo a maximizar … MonFch

Condición ........................ MonCod = U$S y el máximo valor de MonFchdebe ser menor o igual a la fecha de documento

Atributo a devolver ................ MonCot

Valor por defecto ..................... 0

Ejemplo de uso del Max:

DocImpDolar = DocImp / DocCotDolar

DocCotDolar = Max(MonFch, MonCod = ‘U$S’ .and. MonFch <= DocFch, , MonCot)

Fecha del Documento 15/01/94, le corresponde la cotización del día 13/01/94.

MonFch MonCot10/01/94 10011/01/94 11012/01/94 11213/01/94 11516/01/94 117

82

Min

Atributo = Min(<Atributo a Minimizar>, <Condición de minimización>, <Valor pordefecto>, <Atributo a Devolver>) IF <Condición de disparo>

Esta función determina el mínino valor de un atributo en una tabla. Obtenido este valor, que corresponderá a una determinada fila, la función devuelve el valor de cualquieratributo 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.

Documentos CotizacionesDocNro* MonCod*DocFch MonFch*DocImp MonCotDocImpDolar = DocImp / DocCotDolarDocCotDolar = 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 MonCot10/01/94 10011/01/94 11012/01/94 11213/01/94 11516/01/94 11717/01/94 118

83

Consideraciones aplicables a todas las fórmulasAggregate/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

Documentos Cotizaciones(Tabla de partida) (Tabla de llegada)

Consideraciones de performance:

Tanto las fórmulas Verticales como las fórmulas Agregate/Select, implican la realizaciónde navegaciones en la Base de Datos, por lo que es importante considerar la forma en queesto es realizado.

Las fórmulas Verticales cuentan o suman los valores que estan en "memoria“,es decir, no recorren la tabla subordinada de nuevo, en caso de insertar, actualizar o eliminar una línea.

Las fórmulas Aggregate/Select en cambio, recorren cada vez los registros para hacer el recálculo.

Las fórmulas Verticales pueden almacenarse en forma redundante y GeneXus se encargará de mantenerlas actualizadas.

84

USO DE LA FORMULA MAX( ).

Ejemplo: Buscar el precio del producto segúnla fecha de la Factura.

Transacción Productos Transacción FacturaProdCod* FacNro*ProdDsc CliCod

(ProdFch* FacTotProdPre) FacFch

(ProdCod* FacProdPre

FacLinCntFacLinImp)

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 incluirProdFch debido a que no podríamos saber que valor darle a la fecha para poderheredar directamente el ProdPre.

Definimos el atributo FacProdPre y buscaremos con una fórmula el preciocorrespondiente 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 )

85

FacProdPre = Max(ProdFch, ProdFch <= FacFch, 0, ProdPre)

Fecha de Factura: 10/10/93Precio correspondiente: 220

Código de Producto Fecha Aumento Precio Valor del Producto1021 10/08/89 200 1021 20/11/90 2101021 03/10/92 2201021 15/10/95 2301022 10/08/89 1001022 20/11/90 1101022 03/10/92 120

1022 15/10/95 180

USO DE LA FORMULA MAX( ).

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.

86

Transacción de CotizacionesMonId*CotMes*MonDsc(CotDia*

CotImp)

Transacción de AsientosAsiNro*AsiFchAsiMesAsiDia

(AsiIdLin*MonIdAsiImpMEAsiImpNSAsiTipDHCtaIdAsiFndCot)

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 anterior a la fechadel asiento.

87

A. Transacción de Cotizaciones:MonId*CotMes*MonDsc(CotDia*

CotImp)

Transacción de asientos :AsiNro*AsiFchAsiMes = Month(AsiFch) AsiDia = Day(AsiFch)

(AsiIdLin*MonIdAsiImpMEAsiImpNSAsiTipDHCtaIdAsiFndCot) = Find(CotImp, CotMes=AsiMes .and. CotDia=AsiDia)

if MonId<>’NS’;1 otherwise;

88

B. Transacción de Asientos :AsiNro*AsiFchAsiMes =Month(AsiFch) AsiDia =Day(AsiFch)

(AsiIdLin*MonIdAsiImpMEAsiImpNS = AsiImpME*AsiFndCot if AsiFndCot<>0;

AsiImpME*AsiMaxCot if AsiMaxCot<>0;1 otherwise;

AsiTipDHCtaId

AsiFndCot a=Find(CotImp, CotMes=AsiMes .and. CotDia = AsiDia)if MonId <> “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”;

89

1. Condiciones involucradas en unaFórmula Aggregate Select

Condición de BúsquedaEs la condición a la cual está sujeta la búsqueda.

Condición de DisparoEs la condición que determina si la fórmula se ejecuta.

90

2. Inferencias en el caso de unaFó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 (tablade partida) y la tabla sobre la cual se está resolviendo la fórmula (tabla de llegada).

91

En el ejemplo:Transacción de Cotizaciones:

MonId*

CotMes* Given : MonIdMonDsc(CotDia*

CotImp)

Transacción de Asientos :AsiNro*AsiFchAsiMes =Month(AsiFch) AsiDia = Day(AsiFch)

(AsiIdLin*MonIdAsiImpMEAsiImpNSAsiTipDHCtaIdAsiFndCot) =Find(CotImp, CotMes=AsiMes .and. CotDia = AsiDia)

if MonId <> “NS”;1 otherwise;

En la fórmula AsiFndCot, está implícita la condición de queAsiento1.MonId = Cotizac1.MonId

Esto se refleja en la navegación como “Given: MonId”

92

3.Cómo se determina la tabla sobre la cualefectuar 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 Retorno

De otra forma:<Atr.Fórm.> - Fórmula Inválida

Es importante aclarar que los atributos involucrados en la fórmula AggregateSelect 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 extendidade la tabla de llegada.

93

X = Find( A , B = C .and. D = 4 .and. E = F , 0 )

Atributos de la tabla extendida de X

Ejemplo de determinación de la tabla sobrela cual buscar:

94

Deben pertenecer físicamente a una misma tabla

X = Find( A , B = C .and. D = 4 .and. E = F , 0 )

Atributos de la tabla extendida de X

Ejemplo de determinación de la tabla sobrela cual buscar:

95

4. Fórmulas Aggregate Select no pueden participar en fórmulas SUM y COUNT simplesNo se permite definir una fórmula SUM que suma un atributo que esuna Aggegate/Select o depende de ella.

Ejemplo:

FacProdPre = fórmula MAXFacLinImp = FacLinCnt * FacProdPreFacSubTot = SUM (FacLinImp)

Para resolver esto, se debería almacenar el valor de FacProdPre en otroatributo, pues las Fórmulas Aggregate Select NO PUEDEN SER DEFINIDAS REDUNDANTES.

O utilizar la regla ADD en lugar del SUM vertical

96

5. Dependencia física de las fórmulasAggregate Select

Las Fórmulas Aggregate Select dependen de la inserción, actualizacióno eliminación física del o los registros que involucran.

EJEMPLO :Transacción de Asientos

AsiNro*AsiFchAsiTotDeb = Sum(RengImp, RengTipDH=“D” , 0)AsiTotHab = Sum(RengImp, RengTipDH=“H” , 0)

(RengId*MonCodRengImpNSRengImpRengTipDHCtaCod )

El COUNT vertical en caso de agregar o borrar una línea no recorretoda la tabla de nuevo, a diferencia del Count Aggregate/Select.

Las fórmulas verticales cuentan o suman los valores que estan en "memoria". Las aggregate/select no.

97

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órmulasverticales solamente sobre tablas directamente subordinadas.

2. En las fórmulas agg/sel se pueden especificar condiciones de búsqueda. En las verticalesno.

3. Las fórmulas verticales cuentan o suman los valores que estan en "memoria". Las

aggregate/select no.

4. Las fórmulas verticales cuentan o suman atributos que pueden ser fórmulas (pero estafó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 FISICAMENTE en la tabla de llegada

5. Las fórmulas agg/sel no se pueden definir como redundantes. Las verticales sí.

98

COMUNICACION ENTRE OBJETOS

99

Objetos GeneXus

TRN

RPT

MENU WKP

PROC

Comunicación entre objetos GeneXusUna de las características importantes de los objetos de GeneXus es podercomunicarse entre ellos o con otros programas externos. Un objeto GeneXuspuede llamar o ser llamado por otro objeto, intercambiando información entreellos a través de parámetros que se declaran en cada uno.

100

• CALL

• UDP (User defined Procedure)

• UDF (User defined Function)

Reglas y Comandospara implementar la comunicación

Para implementar la comunicación entre objetos GeneXus (y “no GeneXus”, esdecir programas externos) se disponen de los siguientes comandos o reglas :

CALL - Llama a un objeto o programa externo, permitiéndose pasar parámetrossi é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 retornará 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ónUDF no deben abrir ninguna tabla, mientras que los llamados por la funciónUDP sí lo pueden hacer.

Esta diferencia existe SOLAMENTE en el generador Fxp 2.6 y VFP (en losdemás generadores no existe diferencia entre los udp y udf), las UDF al regresarno reabren/reposicionan las tablas, por lo tanto no soportan que el programallamado 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.

101

Objeto Prefijo El nombre se trunca a:Transacción T 7 caracteresProcedimiento P 7 “Reportes R 7 “Work Panel W 7 “Menú M 7 “Web Panels H 7 “

Cuál es la convención usuada para el nombre de losobjetos GeneXus en las llamadas?

Los programas llamados con las reglas o comandos mencionados pueden ser cualquier objeto GeneXus (Transacciones, Procedimientos , etc.), o un programaexterno 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 truncadode 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.

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(RImpFac, FacNro) if insert .and. after(TRN);

donde ImpFac es el nombre del Report que imprime la factura recibida comoparámetro.

102

Sintáxis

En regla de Transacciones:call(nom-prog,par1,...,par2) if (condición);

En layout de los reports, program source de losprocedures, eventos de Work Panel y eventos deTransacciones:

if (condición)call(nom-prog, par1,...,par2)

endif

Call

La regla o comando Call 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 call 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.

103

La regla PARM tiene como función declarar los parámetros enel objeto llamado.

Sintáxis: 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)

Call - Regla Parm

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.

104

SintáxisEn reglas de Transacciones<Att|&var> = Udp(nom-prog,par1,...,parn) if (condición);

En Fórmulas:<Att> = Udp(nom-prog,par1,...,parn) if (condición);

En el layout de los reportes, y en los eventos de Work Panelso Transacciones:<&var> = Udp(nom-prog,par1,...,parn) En el program source de un procedimiento:if (condición)

<Att|&var> = Udp(nom-prog,par1,...,parn)endif

Udp

La Udp ejecuta el objeto o programa ‘nom-prog’ que retornará un valor queserá asignado a un atributo o a una variable dependiendo del caso.

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 eventosde transacciones o work-panels.

105

El último parámetro en la regla parm es el valor deretorno.

Ejemplo:parsal = udp(PAltaCli, par1, … , parn)

En las Rules de PAltaCli poner:parm(par1, ..., parn, parsal );

Udp - Regla Parm

Al igual que en los programas llamados con call, en los programas llamados porUDPs se deben declarar los parámetros con la regla Parm. A diferencia con loscalls, el programa llamado siempre va a tener un parámetro como mínimo (el parámetro de retorno).

Ejemplo: Tenemos un procedimiento que calcula la calificación de un funcionario

FunValCalificacion = Udp(PCalif ,FunId, FunFchIngreso );

En el procedimiento PCalif, tenemos las 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.

El último parámetro especificado en la regla parm, cuando se está invocando al objeto con UDP es de salida. El protocolo para el resto de los parámetros depende de la implementación, NO se debe esperar que sean de entrada/salida.

106

Los programas llamados se pueden considerar como funciones , ya que al ser llamados utilizando UDP van a retornar un valor. Este valor que retornan es el último parámetro en la regla parm del objeto llamado y no debe ser especifificado 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 categoria del cliente.

Nota: El valor de retorno de una UDP / UDF de Genexus, es asignado a la variable o atributo en cuestión, pero dicho atributo o variable no es pasado como parámetro de ida.

Ejemplo: &A = 1&A = UDP(PXXX)

En este ejemplo, el procedimiento XXX devuelve &A , pero no se puede asumir o esperar que reciba como parametro &A=1 , de hecho el valor de &A al ejecutarse el procedimiento tiene valor nulo.

Ejemplo:

FacImpDesc = udp(‘Pcaldto’, FacTot,FacCat)

En procedimiento PCaldto:

parm(&tot, &cat, &desc);

Parámetro de retorno

107

SUBRUTINAS

108

Comando SUBSintáxis :Sub 'RoutineName’

//cuerpo de la subrutinaEndSub

• 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 Panels, Reportes y Procedures.

109

Comando DO

Sintáxis :Do 'RoutineName'

Ejecuta la rutina ‘RoutineName’.Disponible en Transacciones, Work Panels, Reportes y Procedures.

110

ARBOL DE EVALUACION Y EVENTOS

111

Arbol de evaluación

error (‘No hay Stock’)

ArtStk

FctCnt

FctImp

FctTot

FctSubTot

FctDto

ArtPrc

CatDto

CliTotCmp

FctFleVal

FctFch

R. Add(FctTot, CliTotCmp) ;F. FctTot = FctSubTot - FctDto + FctFleValF. FctDto = FctSubTot * CatDtoF. FctFleVal = MAX( FctFleFch, FctFleFch <= FctFch, ...F. FctSubTot = SUM ( FctImp)F. FacImp = FacCnt * ArtPrcR. Subtract(FctCnt, ArtStk) ;R. Error( ‘Stock Insuficiente’) if ArtStk < 0 ;

Arbol de EvaluaciónEl 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 abajohacia 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 partirde 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 luegoel ERROR, o sea que al momento de considerar el error, ya se disparó el subtract, y se disminuyó el stock.

112

Es importante mencionar que cuando se encuentra un error se desarma el Arbolde 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 hubieraen algunos casos se dispara con el valor anterior. Ejemplo: A = 1/A, se ejecutaen realidad con el valor anterior de A.

A = 1 / Old(A)

113

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 querercambiar 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 calculamosnuevamente (FctTotCalc), y emitimos un error si no es así.

Si construimos el arbol 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 <> total ingresado) ya para la primeralí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 lineas (a la salida del nivel).

Alteraciones del orden de disparode las Reglas

PrvCod*FctNro*...FctTotIng Total ingresado

( ArtCod*FctCntFctPrcFctImp = FctPrc * FctCnt)

...FctTotCalc = SUM (FctImp) Total calculado

Error

Total Calculado

Total Ingresado

Fact Impt

Error('El total ingresado no coincide con el total calculado') if (FctTotCalc <> FctTotIng) .and. after(level(ArtCod));

114

Entonces le marco el evento de disparo After(level(ArtCod))

Error('El 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 Arbol de Evaluación, dejándose todo en el estado anterior a producirse el error. El error detienecualquier actualización a la base de datos.

Estos casos no son muy frecuentes, pero se dan y hay que conocerlos.

A continuación se describirán cada una de estas funciones que permiten resolver casoscomo este, en el que el momento que GeneXus definió para ejecutar la regla no es el deseado.

// INCORRECTO

Error('El total de la factura no coincide con el ingresado') if FctTotIng <> FctTotCalc;

// CORRECTO

Error('El total de la factura no coincide con el ingresado') if FctTotIng <> FctTotCalc

.and. after(level(ArtCod));

115

Funciones booleanas que permiten cambiar el momentode disparo de una regla

Level( Atributo) Insert

After( Atributo ) Update

After(Insert) Delete

After(Update)

After(Delete)

After(Confirm)

After(Level(Atributo))

After(Trn)

Son funciones lógicas que devuelven .T. or .F.

LevelSintáxis: Level(Atributo)Retorna 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 tomaria el nivel del parámetro.Ejemplo: Call(‘Pxxx, CliCod’) if Insert ;

AfterSintáxis: After(<Event>)Donde <Event> puede ser :<Att> | <Action> | Level(<Att>) | Trn | Confirm

After(Attribute)Ejemplo: A = B * C if After(C);Ejecuta la regla después de aceptar el valor del atributo C.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.

116

Insert, Update, DeletePara condicionar el modo de disparo

After(Confirm)Dispara la regla después de haber confirmado los datos del nivel asociado pero antes de haber realizado la actualización.

After(Insert)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 ClientesCliCod* Código de ClienteCliNom Nombre de ClienteCliSts 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(Insert) ;call('pficha', CliCod) if After(Update);call('pficha', CliCod) if After(Trn);

El cliente ya existe o ya se han grabado las modificaciones.

After(Trn)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.

117

Reglas que ocurren en el mismo evento

Son disparadas en el orden en que fueron definidas

Ejemplo

call(' ') if After(Trn);

call(' ') if After(Trn);

Ejemplo

call('pgmname', CliCod, &flag) if After(Confirm);

error(' ') if After(Confirm) .and. &flag = 'N’ ;

Para CALLs, ERRORs, y MSGs, si dos reglas ocurren en el mismo evento y no dependen entre sí, vale el orden en el cual se definieron.

Ejemplo 1Se ejecuta un Call y luego el otro

Ejemplo 2Se quiere llamar a un procedimiento que realiza determinada validación, y queretorna 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';v

Importante:En los calls los parámetros son de ida/vuelta del punto de vista del lenguaje, pero del punto de vista del especificador son sólamente de ida. Es decir, para determinar el árbol de evaluación de reglas y fórmulas, Genexus considera a los parámetros de los calls como de ida.

En el ejemplo 2, si se escribieran las reglas en orden inverso, Genexus en el árbol de evaluación de eventos, las consideraría en dicho órden (no determinaría que la regla error vaya después del call, porque los parámetros del call son considerados de ida).

118

En otras palabras, si se escribieran las reglas del ejemplo 2 en orden inverso, y la &flag resultara negativa, el error no se dispararía.

Si en lugar de utilizar CALL utilizáramos UDP (siendo &flag el campo de salida) el error se dispararía después del UDP, sea cual sea el orden de definición, ya que &flag sería claramente el output de la UDP.

119

Ejemplo de transaccion de dos niveles

Level CabFac.....................................> reglas stand-alone Trasmit Screen....................................> evaluación de reglas y fórmulas según árbolConfirm Screen....................................> reglas after(confirm) Insert/Update/Delete ....................................> reglas after(insert/update/delete)

Level LinFacTrasmit Screen..........................> evaluación de reglas y fórmulas según árbolConfirm 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 (trn)

EndLevel

120

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 esllamado 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ódigoasociado a cada evento posible, el cual se disparará sólo si el evento se produce. Porejemplo, puede haber un código asociado al evento de presionar una tecla (Porejemplo <Enter>), que se activará cuando el usuario decida presionar esa tecla.

La programación dentro del evento sigue un estilo procedural.

Eventos en las Transacciones

El código permanece ocioso hasta que ocurreun evento al cual está relacionado

Evento = Acción reconocida por un objeto y a la cual se le puede asociar un código ejecutable

121

Start: Es un evento del sistema y se da al comienzo del programa. Es normalmenteusado para asignar valores a variables.

User Defined Event: Es un evento definido por el usuario, que es activado una vezque se selecciona una opción del menú o se presiona una tecla de función/botón.

After Trn: 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.

Eventos explícitos en lasTransacciones

Evento Start

Evento ‘User-Event’

Evento After Trn

Evento Exit

122

Generalmente es utilizado para la asignación de variables y parámetros que interesaevaluar una sola vez en la ejecución del programa.

Evento Start

Sintáxis: Event StartEndEvent

Se ejecuta al principio del programa.

Ejemplo: Guardar el inicio de ejecución del programaEvent Start

&entrada=Time( )EndEvent

123

Evento StartEjemplos:

1.- Event Start&Mes1 = ‘Enero’

EndEvent

2.- En el Evento Start de la transacción de Facturas :

Event Startcall(PFindCli,&today, CliCod)

EndEvent

Parámetro de salida. Se instancia el Cliente. Se accede sólo a las Facturas de ese Cliente.

En el Evento Start no hay atributos disponibles como para ser evaluados y/o usados.

En el ejemplo 2, el parámetro CliCod es de salida, es decir vuelve cargado del procedimiento. En este caso, queda instanciado el Cliente, o sea que actúa como filtro.

En otras palabras, el comportamiento es el mismo que si se hubiera recibido en la transacción como parámetro al código de cliente en el propio atributo (CliCod). Es decir, parm(CliCod);

124

Este evento 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.

Eventos del UsuarioSintáxis:

Event ’User-event-name’ <Key>Level <att>

Endevent

EjemploEvent ‘Deuda Cliente’ 2

Level FacIdif .not. null(CliId)

call(wdeucli,CliId)endif

Endevent

125

Equivalente a la función After(trn), pero permite agrupar todas las acciones que se deseen evaluar en el after(trn) sin tener que condicionarlas por separado (rules).

Ejemplo:

Event After trnreturn

Endevent

Abandonar el programa una vez que se ejecutó un ciclo completo de la transacción.

Evento After Trn

Event After trnEndEvent

Ejemplo:Event After trn

ReturnEndEvent

126

Evento ExitEvent Exit

…………….

EndEvent

Se activa cuando el usuario abandona elprograma.

Ej: Llamar a un procedimiento que graba lahora de entrada y salida del programa paracada usuario en una tabla de control.

Event Exit&user = userid()&salida = Time()call(‘pcontrol’, &entrada, &salida, &user)

EndEvent

En el Evento Exit no hay atributos disponibles como para ser evaluados y/o usados.

127

Esta 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 eventoStart no entra en conflicto con las reglas llamadas stand-alone ya que conceptualmentesu evaluación son en diferentes momentos. Las reglas stand-alone se evalúan en el primer nivel antes del despliege de la pantalla. El evento Start se evalúa al comenzarel programa.

Rules / EventosEn caso de conflicto de evaluación entre reglasy eventos de una transacción, la regla se evalúaprimero.

Eventos: Rules:Event After trn call(tvenfac,FctCod) if after(trn);

…….return

End event

128

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:Event Start

&Orgnom = udp(PNombre, Orgcod)Endevent

2. Imprimir una factura al presionar F7 o presionar el botón correspondiente.

Event 'Imprimir Factura' 7call(RPFac, FacNro)

Endevent

3. Podemos querer retornar al programa llamador una vez que la transacción haya sidoingresada:

Event After trnReturn

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 trn&Veces = &Veces + 1

Endevent

Event Exit&Msg = 'El número de transacciones grabadas: ’ + str(&Veces)msg(&Msg)

Endevent

129

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" 4Call(wVerComp, CliCod)

Endevent

Cuando el usuario presione la tecla F4, llamaremos al work panel 'VerCompras' quemostrará las otras compras del cliente.

130

Restricciones•No se permiten comandos asociados a otros eventos existentes en los work panels (load, refresh,etc.).

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 las funciones como Insert, Update , Delete, After(Event), etc.Para condicionar el disparo de eventos a los modos de ejecución activos debemosutilizarlos en combinación con reglas.

Recomendaciones•Controlar mediante variables seteadas en las reglas que los eventos de usuario hagancalls en situaciones válidas.•Los eventos de usuario pueden evaluarse en cualquier momento, sin tener en cuentael 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.

Consideraciones

• No se permite asignar valor a los atributos.

• Start-Exit ---> Sin tabla base

• User Event-After(trn) ---> Con tabla Base

131

REPORTES Y

PROCEDIMIENTOS

132

Reportes y Procedimientos

Reportes

• Procesos no interactivos de consulta de la base de datos.

Procedimientos

• Procesos no interactivos de actualización de la base de datos.

Reportes

Definen procesos no interactivos de extracción de datos. Usualmente un reporte esun listado que se envía a la impresora, aunque también puede ser visualizado porpantalla.

Procedimientos

Definen procesos no interactivos de actualización de la base de datos y subrutinasde uso general. Podemos decir que son un superset de los reportes, ya que puedenhacer todo lo que estos hacen y además actualizar la base de datos.

133

Características

• Definición procedural

• Definición sobre la Base de Conocimiento

• Independencia de la Base de Datos

•Definición Procedural.

A diferencia de las transacciones donde las especificaciones se realizan en forma declarativay GeneXus resuelve en el momento de generar el programa la secuencia de ejecución, en losreportes las especificaciones son realizadas en forma procedural.

• Definición sobre la Base de Conocimiento.

La gran protencia del lenguaje de reportes/procedimientos es que las definiciones se hacensobre la Base de Conocimiento y no directamente sobre el modelo físico. Esto nos permiteutilizar 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 esposible porque GeneXus conoce las relaciones entre las tablas de la Base de Datos. Otroejemplo claro, es el caso de los atributos fórmulas, donde aprovecharemos que GeneXussabe 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únmomento decimos qué tablas se deben recorrer ni qué índices se deben utilizar, sino queesto es determinado por GeneXus en base a las especificaciones realizadas.De esta manera logramos una real independencia de la base de datos, ya que en cualquiercambio en las tablas será manejado automáticamente por GeneXus.

134

Comando For EachSintaxis:For Each [Order] [ Atr...Atr]

Where <Condition>...

Where <Condition>Defined by <Attribute List>

…..

Endfor

Toda la definición del acceso a la base de datos y la estructura del reporte o procedimiento, se realizansólo con este comando.

Usando el FOR EACH se define la información que se va a leer de la base de datos, pero la forma de hacerlo se basa en nombrar los atributos a utilizar y NUNCA se especifican nombres de tablas ni nombres de índices. Con este comando se define QUE atributos se necesitan y en qué ORDEN se quieren recuperar, y GeneXus se encarga de encontrar COMO hacerlo.

El acceso a la base de datos queda especificado por los atributos que son utilizados dentro de un grupo FOR EACH - ENDFOR. Para ese conjunto de atributos GeneXus buscará la tabla extendida que los contenga (el concepto de tabla extendida es muy importante en este comando y sugerimos repasar su definición).

Order: Lista de atributos que indican el orden de recorrida de la tabla base. Sólo pueden mencionarseatributos 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, se crea el índice en forma temporal.

Where: Establecen condiciones de filtro en la recorrida de la información. Se pueden mencionaratributos de la tabla base y/o de la tabla extendida.

Defined by: Al mencionar en esta cláusula algún atributo secundario de la tabla que se desea recorrer,dicho(s) atributo(s) participará(n) en la elección de la tabla base del For Each. Debe quedar claro queel/los atributos mencionados en el Defined by “participan” en la determinación de la tabla base asícomo también participan los demás atributos mencionados en todo el For Each. Los atributosmencionados en esta cláusula no tienen más peso que los otros atributos del For each. El objetivo de esta cláusula es permitir “mencionar” cierto(s) atributo(s) en el cuerpo del For each (sin actuar como filtros, ni ordenar por ellos, ni imprimirlos) sino que sólo se desea(n) referenciar en el For Each para que participe(n) en la determinación de la tabla base.

135

• Determinadas automáticamente a través de losatributos del grupo For Each (Order , where, definedby y cuerpo del For Each)

• GeneXus después de definir los atributos queparticipan determina una Tabla Base y su TablaExtendida

• A partir de esto define la navegación

Inferencia de las tablas utilizadas en el For Each

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:

En base a la definición realizada para el reporte, GeneXus determina automáticamente lo siguiente:1. Que las tablas que se deben utilizar en el reporte son Client y Depart 2. Que la tabla que debe recorrerse es Client3. Que debe accederse a la tabla Depart para complementar la información (obtener DptNom) 4. Que el orden de recorrida es CliCod y que el índice que debe usarse es el Indice IClientTodo esto en base a una especificación que sólo incluía los atributos a listar.

136

1. Cómo pudo GeneXus determinar qué tablas se utilizan en el reporte ?

Para esto se debe determinar en qué tablas están los atributos que se han mencionadodentro del comando FOR EACH. Con la base de datos en 3era Forma Normal podemos definir dos conceptos, atributosprimarios y secundarios:

Atributo Primario: Es aquel atributo que es parte de la clave primaria de alguna tabladel 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 lastablas 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 almacendosen 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 atributosecundario. 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 cualhemos respondido la interrogante planteada.

2. Cómo pudo GeneXus determinar qué tabla debe recorrer y qué otras tablasdebe acceder para complementar la información ?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 conocimiento, puedesaber cuales son las relaciones que existen entre las tablas de la base de datos. Estamosen 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 ejemplodiremos 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 puedeacceder para obtener otra información.

137

Repasemos los conceptos de tabla base y tabla extendida:

Toda tabla del modelo (tabla base), tiene información que le permite acceder a todaslas tablas del modelo con las cuales está relacionada. La Tabla Base define su TablaExtendida 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 instanciade cada tabla de la tabla extendida.

Aplicando estos conceptos al ejemplo, vemos que la tabla de Clientes está en unarelación de N para 1 con la tabla de Departamentos:

Clientes <<----------------> Departametnos

Es decir que para cada instancia de la tabla de Clientes (Tabla Base) existe solo unainstancia correspondiente en la tabla de Departamentos, por lo que dicha tablapertenece 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 lastablas, y puede entonces además saber cuales son las navegaciones válidas entre estas.

138

3. Qué orden y qué índices deben utilizarse?

El reporte saldrá ordenado por Código de Cliente ( CliCod ) utilizando el IndiceIClient.

FOR EACH Client Order : CliCodIndex : 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.

GeneXus conoce los índices de las tablas de la Base de Datos, y entonces puede elegirel índice a utilizar para satisfacer este orden.

Es posible listar en un orden diferente utilizando la cláusula Order del FOR EACH.

139

Ejemplo :Tabla Base y Tabla Extendida


FACTURA1 PRODUCTO

FacNro*FacFchCliCod

CliCod*CliNomCatCod

CatCod*CatDto

FacNro*ProdCod*FacLinCnt


140

When None

• Ejecutar determinado código, cuando en un For Each no se encuentra ningún registro.

• SintáxisFor 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 WhenNone ya que son considerados dos For Each paralelos .

141

Report Wizard

• Permite diseñar el layout de un reporte (oprocedimiento) 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.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). 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 loscabezales de los atributos para cada uno de los niveles se desplieganhorizontalmente o verticalmente.Presionando el botón de “Finish “ se graban las definiciones y se sale del diálogo del Report Wizard.

•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 posibleeditar el Wizard mediante la opción : Edit / Report/Proc. Wizard.

•El Wizard permite que los niveles tengan o no orden . El atributo que indica el ordenno tiene por qué ser el primero del nivel.

142

For Each paralelos

For Each // Facturas

EndFor

For Each // Recibos

EndFor

Navegaciones totalmente independientes.

Los For Each se pueden definir en forma paralela o anidada.

En el ejemplo hemos definido dos for eachs paralelos. El primero recorrerá todas lasfacturas y el segundo todos los recibos.

143

For Each anidados

Tres Casos:

• Tabla Base de los For Each distintas pero relacionadas por unoo 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 losatributos utilizados en el cuerpo del For Each siempre y cuando estos atributos no esten 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 Each principal. Este caso se distingue en el diagrama de navegación utilizando BREAK en lugar de For Each paratodo grupo For Each subordinado que no defina una nueva tabla base.

144

For Each anidados• Caso 1 : Tablas extendidas de los For Each

distintas pero relacionadas por uno o más atributos

For Each[CliCod] [CliNom]For Each

[FacNro] [FacTot]Endfor

Endfor Atributo relación: CliCod

• Se instancia el orden CliCod en el For Each

Cliente

Facturas

CliCod

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 tablabase), 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 : CliCodIndex : I00101 Navigation filters:

Start from: First record Loop while: Not end of table

------->> Client ( CliCod ) FOR EACH Factur

Order : CliCodIndex : I00402 Navigation filters:

Start from: CliCod = CliCod

Loop while: CliCod = CliCod

-------- >> Factur ( FacNro ) END FOR

END FOR

145

For Each anidados

Caso 2 : Cuando tenemos que la tabla base delos For eachs son distintas y no existe ningún atributo que las relacione, el resultado que obtenemos es el Producto Cartesiano de dichas tablas.

Producto Cartesiano: Para cada registro de la tabla base del primer For Each se recorretoda la tabla asociada al For Each anidado.

146

Corte de Control• Caso 3 :

Procesar información por grupos. Ej: 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 ControlLa resolución de este reporte puede hacerse accediendo únicamente a las facturas, recorriendola tabla ordenada por cliente. En este caso imprimiríamos solo aquellos clientes que tienenfacturas.

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, porejemplo imprimir el total facturado al cliente.

Lo interesante del caso dos for eachs tendrán como tabla base la tabla de facturas. Para lograresto 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), losatributos 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 quequeremos ya que en una misma tabla pueden ser varios, por ejemplo podríamos querer realizarel 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.

147

Para resumir, un corte de control queda definido de la siguiente manera:

Existen dos grupos FOR EACH anidados sobre la misma Tabla Base, losatributos de corte quedan definidos por el conjunto de atributos especificadosen el comando ORDER.

Para hacer un corte de control, necesitamos hacer una navegación de Facturas porFecha.

Cuando ejecutemos este reporte, generará un índice temporal por fecha, sobre la tablaFacturas.

La navegación de un corte de control es la siguiente:

FOR EACH FacturOrder : CliCodNavigation filters:

Start from: First record

Loop while: Not end of table

----- >> Factur ( FacNro ) --- > Client ( CliCod )

BREAK FacturOrder : CliCod, FacNroNavigation filters:

Loop while: CliCod = CliCodFacNro = FacNro

------->> Factur ( FacNro ) END BREAK

END FOR La particularidad de esto es que el segundo For each se muestra como un BREAK.

148

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 ejemplosupongamos 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 (Item 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 esglobal para todos los FOR EACH que definamos en el layout y la segunda se cumplesó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 igualglobal 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 comoparámetro.

149

Diseño de la salida

Header…...End

CP [nlinea]Lineno [nlinea]EjectNoskip

FooterMB :

End

MT

PL

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). Ej: PL 66Setea 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, pasaa 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.

150

Report Viewer

• Permite:– Imprimir– Visualizar el reporte mientras se está generando– Paginado– 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, almacenandose 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.

151

PROCEDIMIENTOS

152

Inserción de registrosEjemplo: Inserción en tabla de resumen de

ventas anuales

Tabla: CliCod*VtaAno*VtaTot

NewCliCod = &CliCodVtaAno = &AnoVtaTot = &Total

When DuplicateFor each

VtaTot = VtaTot + &TotalEndfor

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 quisieramos aplicar un tratamiento especial para estos casos, podemosusar el comando When Duplicate para decir que acción tomar cuando se detecta que el valor de la clave en un alta ya existe en la tabla correspondiente.

153

For Each

Atr = <Exp> Actualiza atributo de ..………. la tabla extendida

Endfor

La actualización se realiza en el EndFor.

Actualización

Los atributos actualizables dentro de un grupo For Each, son todos lospertenecientes a la tabla extendida.

La actualización física se realiza cuando se encuentra el EndFor del grupoFor Each correspondiente.

154

For Eachdefined By FacFch

Delete sólo Tabla BaseendFor

La ejecución real del comando se producecuando se encuentra el Delete y no cuando sellega al EndFor .

Delete

La eliminación de registros de la tabla base dentro de un grupo For Each se hace mediante el comando DELETE.

155

• No se realiza control de integridad referencial

• No Actualiza atributos definidos como redundantes

Restricciones

En los procedimientos, el control de Integridad Referencial queda a cargo del programador, 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, los atributos instanciados por el For Each y no mencionados en el New son inferidos para la inserción del registro.

156

WORK PANELS

157

Work Panels

• Definir consultas interactivas a la base de datos.

• Es muy flexible por lo que se presta paramúltiples usos.

158

Las normas Common User Acces de IBM definen diversos tipos de pantallas, estandarizando los diálogos con el usuario.

Diferentes tipos de Paneles

- Entry Panel - Display Panel - Single Choice Selection List - Multiple Choice Selection List - Action List

159

Paneles de Entrada

Son paneles de entrada/salida. A través de ellos se aceptan y se desplieganvalores. Por ejemplo, un panel de entrada puede ser una pantalla previa a unaimpresión, donde se piden los parámetros necesarios para la misma y luego se llama a un Report.

Entry Panel - Panel de Entrada

160

Display Panel - Panel de Salida

Paneles de Despliegue

En estos paneles, los datos pueden ser solamente exhibidos.

Un panel de despliegue puede ser una pantalla plana o puede mostraruna cantidad variable de datos. Esto último, consiste en mostrar variaslíneas por pantalla permitiendo que el usuario se desplace hacia arribay hacia abajo (scrolling).

161

Listas de Selección de opción única

Una lista de selección de opción única contiene un grupo de opciones de las que losusuarios pueden seleccionar solamente una. La forma de hacer la selección es teclearalgún valor en la línea a ser seleccionada. Una acción puede ser entonces ejecutadasobre el contenido de la línea seleccionada.

Listas de Selección de opción múltipleUna lista de selección de opción múltiple contiene un grupo de posibilidades de lasque los usuarios pueden seleccionar cualquier número de ellas. Una lista de este tipo permite que una acción (solamente una) sea ejecutada en variaslíneas simultaneamente.

Lista de AcciónSe pueden elegrir acciones diferentes a aplicar a cada una de las líneas.

Area Fija

Subfile

Eventos yTeclas de función

Selección Unica/Selección Múltiple/Listas de Acción

162

Comando For Each Line

Sintáxis:For Each Line

…….. Recorre todas las lineasEndFor del subfile

En caso de querer recorrer sólo las lineas del subfileque fueron seleccionadas:

For Each Selected Line………….

EndFor

•El comando For Each Line permite recorrer el Subfile (no la base de datos). Para cada una de las lineas del subfile, se ejecuta el cuerpo del For Each Line.

•El comando For Each Selected Line permite recorrer sólo las lineas que fueronseleccionadas del Subfile.

Los generadores no visuales sólo permiten selección única.En Visual FoxPro, no es posible seleccionar varias lineas en los grids a diferencia de Visual Basic (es una limitación de VFP, no del generador).

163

La forma de programar los paneles de trabajo está inspirada en la programación de los ambientes gráficos, especialmente en la llamada Programación Dirigida por Eventos (Event Driven Programming).

Por Programación Dirigida por Eventos se entiende un estilo de programación en el cual las aplicaciones contienen código quepermanece ocioso hasta que es llamado para responder eventosprovocados por el usuario o por el sistema.

Los Work-Panels se definirán entonces de una manera menosprocedural que en la programación clásica, y orientada a eventos. Los eventos son acciones que pueden suceder o no. Tendremos un código asociado a cada evento posible, el cual se disparará sólo si el evento se produce.

Programación dirigida por EventosEl código del programa permanece ocioso hasta que seinvoca su ejecución mediante acciones tomadas por eloperador del programa frente a la pantalla .

Ejemplo:

Event EnterCódigo en respuesta a pulsar la tecla Enter

EndEvent

164

Evento Start: Es un evento del sistema, ocurre cuando se comienza a ejecutar el work panel. Es usado comunmente para asignar valores a variables, generalmente para dar valores pordefecto a las variables del área fija de la pantalla.

Evento Refresh: Es un evento del sistema, ocurre inmediatamente antes de comenzar la cargadel subfile. En un ambiente multiusuario, los datos de la pantalla pueden estar desactualizadossi fueron modificados desde otra terminal. En este caso, cuando el usuario desee actualizarlos, deberá presionar el botón refresh cuyo efecto es cargar nuevamente el subfile.

Comando Refresh: En algunos casos, desde otro evento también puede ser necesario cargarnuevamente el subfile. Por ejemplo cuando en un evento se llama a una transacción queactualiza los datos (Ejemplo "Ingresar" (F6)) que se están desplegando en el subfile, lo que se hace entonces es ejecutar el comando refresh luego del call a la transacción.También se necesita hacer un refresh cuando una variable que aparece en las Conditions esmodificada por el usuario. Estas variables determinan qué datos se cargarán en el subfile, siuna condición cambia, el subfile debe ser cargado nuevamente.

Evento Load: Es un evento del sistema que ocurre cuando un subfile está siendo cargado. Para cada registro que se cargará en él, se disparará este evento.Este evento es usadogeneralmente para cargar variables en el subfile. Los valores de estas variables pueden ser calculados o leidos de la base de datos usando el comando For Each.Se puede hacer referencia a cualquier atributo que pertenezca a la tabla extendida asociada al panel de trabajo.Evento Enter: Este evento ocurre cuando el usuario presiona Enter.Evento Exit: Este evento ocurre después que el usuario presionó la tecla de salida (ESC o F12), o el comando "return" es ejecutado en cualquier evento.User Defined Event:: Se pueden definir eventos del usuario, los que pueden estar asociados a una tecla de función o a un botón. De esta manera el evento ocurre cuando el operadorpresiona la tecla de función o el botón asociado al evento.

Eventos

• Start• Refresh• Load• Enter• User-defined• Exit

165

Estructura de los eventosComienzo

Evento StartEvento RefreshEvento Load

Mostrar datos en pantalla

Evento EnterEvento 'User Defined'Evento ExitFin

166

OrderDefine cuál es el orden de los datos en el subfile. Es equivalente a la cláusula ORDER del For Each y se aplica todo lo dicho en la sección de Reportes sobre el tema (incluida la creación de índices temporales).Por ejemplo, si quisieramos ver los clientes ordenados por nombre:

Order(CliNom);NoacceptA diferencia de las Transacciones, en los paneles de trabajo ningún atributo es aceptado. En cambio las variables presentes en la pantalla son aceptadas, a no ser que tengan la reglaNOACCEPT.

SearchCuando el subfile es demasiado extenso, muchas veces se quiere brindar la posibilidad de queel usuario pueda 'posicionarse' en alguna línea determinada del mismo, en forma directa, sin tener que avanzar página por página. Por ejemplo, para buscar un cliente por su nombre se debe definir la regla:

Search(CliNom >= &Nom);

Hidden: Esta regla es usada para indicarle a GeneXus cuales atributos o variables debenincluirse en el subfile sin estar presentes en el mismo. Se usa cuando por razones de presentación, no es conveniente mostrar un atributo en el área de subfile de la pantalla, perose quiere capturar su valor cuando se haga el load de la misma.

Workfile_lines (<MaxLine>): Dado que los subfiles se cargan en archivos temporales y queno existe un límite en la cantidad de líneas a cargar en ellos en PC o LAN , puede traerproblemas si la tabla base asociada tiene muchos registros ya que el archivo temporal tendría todos los registros de la tabla base. Usando esta regla, se menciona en MaxLine la máxima cantidad de líneas que se permite cargar en el subfile. Si el límite expecificado se excede, se despliega el siguiente mensaje “ Number of lines exceeded xxxx ”.

Reglas más importantes

• Order• Noaccept• Search• Hidden• Workfile_lines

167

Propiedades más importantes

LoadingLoad RecordsLoad at StartupAutomatic RefreshRefresh Timeout (FoxPro only)

Load Records: Los posibles valores son ‘Load on request’ o ‘Load all records’.Load on request: A medida que se va paginando va cargando los registros del subfile (‘Carga a pedido’).Load all records: Carga todos los registros.

Load at Startup: Los valores posibles son ‘Yes’ o ‘No’.Yes: Inmediatamente después de ejecutar el Workpanel se carga el subfile.No: No carga el subfile del panel hasta que no se ingresen los valores de la parte fija del WorkPanel.

Automatic Refresh: Esta property es especialmente útil en el caso de un subfile con sólo variables, cuando uno desea que se haga automáticamente un refresh cada vezque uno de los valores de la parte fija son modificados. Los valores posibles son

Only when variables in condition change (default): : Tiene el comportamientode siempre.When any variable changes: Genera un refresh cada vez que cualquier variable de la parte fija del Workpanel es modificada.

Refresh Timeout: Esta property es para que se haga un refresh del subfileautomáticamente si el usuario no efectuó ninguna operación en el lapso de tiempoespecificado. No hay valores predefinidos. Debe especificarse un valor en segundos(lapso de tiempo).

168

Work -Panel con tabla base:En la navegación:For Each [ Tabla Base ]

Order: Atributos del indice por clave Primaria (si no se incluyó reglaorder)

Index: Clave primaria (si no se incluyó regla Order)

// Otros For Eachs definidos en los eventosEndfor

Work -Panel sin tabla base:No se mencionan atributos en: Panel

Reglas Hidden() y Order()Eventos

En este caso se genera sólo un Evento Load, y es en él donde se deben cargar los datos en el subfile, haciendo for each a la (s) tabla(s) deseadas cargando las variables del form.

Work-Panel con o sin Tabla Base ?

Los atributos que determinan la tabla base y suextendida son los definidos en:

• Panel • Reglas Hidden y Order• Eventos ( fuera de comandos For Each)

•Work Panel sin tabla base comando LOAD

169

Diálogo Modal/No Modal

• Property Modal dialog– En transacciones y work panels (llamados).

• Opciones:– Yes if parameters specified– Yes– No

• Sólo generadores Visuales.

•Esta propiedad permite indicar para cada objeto, si utilizar diálogo “modal” o “no modal”.

•“Diálogo modal” significa que mientras el objeto llamado no se cierre, el objeto llamador se mantiendrá inactivo.

•“Diálogo no modal” en cambio, significa que ambos objetos (llamador y llamado) pueden estar activos al mismo tiempo, es decir que se puede alternar entre uno y otro, trabajando con ambos simultáneamente.

•Los valores posibles de esta propiedad son:

Yes if parameters specified: Es la opción por defecto. Significa que si el objeto recibe parámetros, el diálogo será “modal”, mientras que si no recibe parámetros el diálogo sera “no-modal”.

Yes: Dialogo modal.

No: Dialogo no modal.

170

SUBTIPOS

171

En el ejemplo, se necesita definir el banco origen y destino en la misma transacción.

Esto no es correcto pues tengo que poner atributos con el mismo nombre en lamisma transacción.

Para estos casos GeneXus provee los Subtipos, los cuales permiten definir quedos atributos que se llaman diferente, corresponden al mismo concepto.

Ejemplo: Transferencias entre Bancos.

Atributos similares que cumplen roles diferentes.

Transacción de Bancos:BcoCod* Código de BancoBcoNom Nombre de Banco

Transacción de Transferencia : TrnNro* Número de transacciónTrnFch Fecha

‘Problema’ BcoCod Banco OrigenAtributos BcoNom Nombre del Banco Origencon el BcoCod Banco Destinomismo BcoNom Nombre del Banco Destinonombre TrnImp Importe

Subtipos

172

Hay que definir atributos con distinto nombre y que tengan una dependencia funcional.

Los atributos que se encuentran en una relación Subtipo/Supertipo siempre compartenla misma definición.

•Se realizan los controles de integridad referencial.

•La tabla extendida que se obtiene con la definición del subtipo, es la misma que seobtendría en el caso que se utilizara directamente el supertipo.

Transferencia:TrnNro*TrnFch

SubtiposBancos: TrnBcoOriCodBcoCod* TrnBcoOriNomBcoNom

TrnBcoDestCodTrnBcoDestNom

Subtipo SupertipoTrnBcoOriCod BcoCodTrnBcoOriNom BcoNom

TrnBcoDestCod BcoCodTrnBcoDestNom BcoNom

173

Todavía queda algo por determinar. Tenemos dos bancos y dos nombres pero enningún lugar indicamos el nombre a que banco corresponde.Es acá donde aparece la necesidad de definir grupos.

Decimos que el Código de Banco Origen y el Nombre pertenecen al mismo Grupo.

Almacenado TrnBcoOriCod GrupoTrnBcoOri

Inferido TrnBcoOriNom

Almacenado TrnBcoDestCod GrupoTrnBcoDest

Inferido TrnBcoDestNom

Subtipos: Grupos

174

Algunas Consideraciones

• El subtipo y supertipo serán definidos del mismo tipo, GeneXus lo determina así y cuando se quiere definir un subtipo este "hereda" la definición del supertipo.

• No incluir subtipo y supertipo en la misma transacción, nitampoco en la misma tabla extendida.

• No se pueden actualizar los subtipos inferidos (Add, Subtract).

• Los subtipos no se pueden definir redundantes

175

KNOWLEDGEMANAGER

176

Distribución

Se genera el archivo Respaldo.xpw en la raiz de la KB

177

Consolidación

Pide el path del archivo .xpw a ser consolidado

178

BUSINESS OBJECTS

179

Qué es un Business Object ?

••RepresentaciRepresentacióón de un objeto de la n de un objeto de la realidadrealidad::productoproducto, persona, , persona, facturafactura, , monedamoneda, , paispais

••Para Para susu definicidefinicióón se n se tomantoman en en cuentacuenta: : atributosatributosqueque definendefinen al objetoal objeto,, operacionesoperaciones que le sonque le sonrelevantesrelevantes, , ccóómo se mo se relacionarelaciona con con otrosotros objetosobjetos..

Un Business Object es la representación de un objeto de la realidad. Para su definición se toman en cuenta: qué atributos lo definen, qué operaciones le son relevantes y cómo se relaciona con otros objetos.

Algunos ejemplos concretos de Business Objects son: producto, persona, factura, moneda, pais.

Un Business Object es un objeto comunmente usado por distintos tipos de aplicaciones(ejemplo de BO: persona) o por aplicaciones desarrolladas para un área específica (ejemplo de BO: moneda).

Un Business Object no debe estar directamente "ligado" a ninguna aplicación en particular, de esta manera se asegura su portabilidad.

Cada Business Object es autocontenido, es decir, su definición no depende de otros objetos, sin embargo esta implementado de tal manera de que pueda interactuar con otros Business Objects.

180

Cómo representar un BusinessObject con Genexus?

CadaCada BO BO GeneXusGeneXus eses un folder un folder queque contienecontienetodostodos objetosobjetos necesariosnecesarios parapara definirdefinir el el comportamientocomportamiento y el y el usouso de de dichodicho BOBO::

TransaccionesTransacciones queque definendefinen objetoobjetoss bbáásicosicossWork Panels de Work Panels de trabajotrabajoReportesReportesProcedimientosProcedimientos queque implementenimplementen operacionesoperaciones

relevantesrelevantes

181

Business Object GeneXus

Ejemplo: Business Object Paises

Cada BO es un folder que contiene todos objetos GeneXus necesarios para definir el comportamiento y el uso de dicho BO.

182

Características de un BO

IndependienteIndependienteNo No ligadoligado a a ningunaninguna aplicaciaplicacióónnStandard y simpleStandard y simpleFFáácilmentecilmente adaptableadaptableDocumentadoDocumentadoBienBien testeadotesteado

183

Cuándo usar BO?

Al Al crearcrear nuevasnuevas aplicacionesaplicaciones

Al Al agregaragregar nuevasnuevas funcionalidadesfuncionalidades a a unaunaaplicaciaplicacióónn existenteexistente

184

Ventajas de su uso

ReusabilidadReusabilidad : : ––aumentaaumenta productividadproductividad––disminuyedisminuye esfuerzoesfuerzo de de desarrollodesarrollo

ProveerProveer solucionessoluciones rráápidamentepidamenteFacilitarFacilitar la la ampliaciampliacióónn de de laslas fufunncionalidadescionalidades de de

unauna aplicaciaplicacióónnCompartirCompartir conocimientoconocimiento

185

Algunos BO Genexus

PaisesPaisesProductosProductosPersonasPersonasMonedasMonedasTipos de IVATipos de IVANumeradoresNumeradores

Disponibles en el Disponibles en el Web SiteWeb Site de de ArtechArtech

186

Distribución de los BO

EExportaxportarr el folder el folder queque contienecontiene el BOel BO

EEnvnvííaarr exportaciexportacióón (n (xpwxpw) ) porpor mail amail a [email protected]@artech.com.uy

DDatosatos importantesimportantes queque debendeben ser ser incluidosincluidos en la en la documentacidocumentacióón n enviadaenviada::

••BBrevereve descripciondescripcion del BO (del BO (objetosobjetos queque lo lo componencomponen y y susu funcionalidadfuncionalidad) ) ••DDocumentaciocumentacióónn adicional adicional queque se se deseedesee adjuntaradjuntar. . ••AAutorutor••FFechaecha de de úúltimaltima actualizaciactualizacióónn••VVersiersióón de n de GeneXusGeneXus con con queque se implementse implementóó

ARTech ARTech pondrpondráá disponibledisponible el BOel BO eenn susu Web SiteWeb Site..

187

OBJETOS PRIVADOSOBJETOS PRIVADOS

188

Objetos Privados • Objetivo: proteger el conocimiento

Normalmente en una KB hay objetos que son el “núcleo” y que tienen realmente el conocimiento que hace a la solución y hay objetos “secundarios”, que le dan forma a esa solución.

A partir de la versión GeneXus 7.0 aparecen los “objetos privados”. El objetivo de esta nueva característica es facilitar el negocio del conocimiento, permitiendo a quien lo licencia reservarse el control exclusivo de ciertos objetos (llamados “privados”) que considere necesario.

La idea es que el propietario de una KB, al momento de exportar conocimiento (mediante el Knowledge Manager) seleccione aquellosobjetos que quiera “privatizar”, llamados objetos privados, los cuales no podrán ser modificados por el “comprador”. Aquellos objetos que no se “privaticen” seguirán siendo públicos.

Se entiendo por “objetos” todos los objetos GeneXus como ser Transacciones, Work Panel, Reportes, Procedimientos, etc., pero no Tablas, Índices, Grupos, etc.

189

Objetos Privados

• Al momento de “distribuir”, si existe algún objeto privado se ingresará:

• Copyright by: Derechos de autor del dueño del objeto.

• Buyer: Casa de software a la cual se esta licenciando.

• Purpose: Texto general.

Objetos Públicos

Un objeto podrá ser público sin restricción alguna, en cuyo caso puede seguir siendo utilizado libremente. En este caso no es necesario hacer nada con el objeto.

Objetos PrivadosEn el caso de que el propietario del objeto decida definirlo como privado, únicamente en la KB origen se podrá acceder libremente y modificarlo. Los demás usuarios (aquellos que licencien conocimiento de aquel) sólo podrán editar sus pantallas, ver el cabezal del mismo (Information) y generarlo.

Para definir un objeto como privado, se debe ir a Object/Information, en la solapa Advanced, dónde se debe marcar el check Private Object. Sólo se puede marcar un objeto como Privado en diseño. En prototipo y producción no está habilitada esa facilidad ya que se heredará en la siguiente actualización de ese modelo (impacto).

Esto sólo indica que el objeto será Privado, pero no se hará ningún proceso con él, hasta el momento de su exportación (distribución).

190

Objetos Privados • Operativa de los objetos privados: son

“generables” y algunas partes visibles y/o editables

Si al momento de exportar, se seleccionó algún objeto, se habilitará un nuevo botón, Copyrigth Notice, para ingresar la siguiente información:

Copyright by: Derechos de autor del dueño del objeto.

Buyer: Casa de software a la cual se esta licenciando.

Purpose: Texto general.

Esta información, en un XPW, es la misma para todos los objetos privados, ya que se agrupa a una “aplicación”.

Recién luego de ingresar esta información, el XPW será encriptado en su totalidad, incluso aquellos objetos públicos que también se hayan seleccionado.

Si no se indica la información de Copyright, se hará una distribución normal y el XPW no quedará encriptado. Es decir que si bien pueden haber objetos privados, para que efectivamente sean encriptados, se debe ingresar la información de Copyrigth.

191

EFICIENCIA Y PERFORMANCE DE LAS APLICACIONES

192

Optimización de Entrada-Salida:Dado que el acceso a las tablas es costoso, vamos a ver cómo minimizarlo.

Uso de Calls:Veremos cuándo debemos empezar a preocuparnos por el uso de estecomando.

Open y Close de archivos:Cuánto y cómo influyen las operaciones de apertura y cierre de archivos en el tiempo de respuesta de nuestra aplicación.

Uso de índices temporales:Evaluación del costo de creación de índices temporales vs. el costo de mantenimiento de índices permanentes.

Puntos a Considerar

• Optimización de la Entrada-Salida• Uso de Calls• Open y Close de archivos• Uso de Indices Temporales

193

Normalmente los programas procesan registros agrupando aquellos que tengan ciertascaracterísticas comunes, por ejemplo, todas las facturas de un determinado cliente, o lasventas de una clase de artículos. Estas características comunes, se establecen a través de condiciones que determinan un filtro sobre los registros. Tales condiciones se especifican en GeneXus de diversasformas; asi pueden ser por ejemplo WHEREs en un FOR EACH, condiciones en unafórmula Aggregate/Select, parametros , etc.Ejemplo: De todos los clientes, quiero imprimir los datos de aquellos cuyo código esteen un rango determinado.El tiempo necesario para realizar el proceso con los registros que cumplen lascondiciones, determina el grado de "optimización" que tiene la estrategia de accesoelegida. Decimos que una estrategia de acceso esta más "optimizada" que otra, cuandoes necesario un menor tiempo para leer todos los registros que cumplen las condicionesestablecidas. La optimización consiste en posicionarse lo mas cerca posible del primer registro del grupo que cumple las condiciones y desde alli leer secuencialmente hasta el último quelas cumpla. Lo que se establece en definitiva, es un intervalo que cubre todos losregistros que cumplen las condiciones. En este intervalo no necesariamente todos los registros cumplen la condición.En estoscasos, la mejor estrategia consiste en tener el menor intervalo tal que cubra a todos losregistros que cumplirán la condición. Igualmente las lecturas se realizarán para todoslos registros de este intervalo, pero solamente se considerarán aquellos que cumplancon las condiciones.

Optimización de Entrada-SalidaDefinición de Filtros

Peor Estrategia Estrategia Optima Begin of File Begin of File

READREAD READ < Start PointREAD READREAD READREAD READREAD READREAD < End Point

READREADREAD

End of File End of File

194

Where: La clausula "Where" permite filtrar registros en la navegación de un determinadogrupoFOR EACH.Por ejemplo: Para establecer los filtros descritos anteriormente, utilizaríamos la siguiente especificación:

FOR EACHW HERE CliCiu = 'Montevideo' .AND. CliCod >= 1 .AND. CliCod<= 100

...ENDFOR

Conditions:Las "Conditions" sirven para establecer un filtro en forma global, es decir que solamentese podrá acceder a los registros que cumplan con esta condición. Cuando se estableceuna condición sobre atributos, afecta a todos los grupos FOR EACH que contengan eseatributo. Reports, Work-panel y Procedures poseen esta posibilidad. Se prevee la implementación a nivel de Transacciones en próximas versiones.

Parámetros: Es otra forma de establecer una condición en forma global, perosolamente por igualdad. Cuando se recibe un parámetro en un atributo, obtenemos unaespecificación equivalente a una condición.Por ejemplo: un procedimiento tiene la siguiente regla: Parm(CliCod);Esta regla es equivalente a tener: parm(&Cliente);y la condición:CliCod = &Cliente;

• Cláusula Where en For Each• Conditions en Prcs, Rpts, Wkps.• Parm() en Trns, Prcs, Rpts, Wkps

Definición de Filtros

195

Definición de la estrategia de acceso con GeneXusPara definir una buena estrategia de acceso, GeneXus cuenta con una inteligenciarazonable. A contínuación se explica cómo se decide la estrategia a partir de las especificacionesrealizadas.Se determinará, estableciendo ( de acuerdo a las condiciones y el orden en que debanconsiderarse los registros), una posición inicial y una posición final en el archivo, leyendo en forma secuencial en este intervalo.

Se realizará entonces lo siguiente:1. Determinar el orden de recorrida del archivo

2. Fijar la posición de comienzo (Start). Posicionarse lo más cerca posible del primer registro que cumple las condiciones.

3. Leer secuencialmente, descartando los registros que no cumplan las condiciones, hasta alcanzar la posición de fin.

4. Fijar la posición de fin (End). Se dice de aquellas condiciones, tales que a partir del primer registro que no las cumple, no existen más registros que sí la cumplan.

Definición de la estrategia de acceso.

1ero.) Se define el orden en que se recorrerá elarchivo

2do.) Se elige el punto de comienzo (Starting point)

3ero.) Elegir la posición final ( End Point).

4to.) Leer secuencialmente los registros entre elpunto inicial y el punto final, seleccionando losregistros que cumplen las condiciones ydescartando los restantes.

196

El orden en que deban considerarse los registros, junto con las condiciones de "filtro" determinarán la mejor estrategia de acceso. El orden puede considerarse como una condición previa, para la definición de la optimización de las condiciones de filtro. Es decir, que la estrategia de acceso se define, tomando en cuenta como primera cosa el orden que se hayadefinido.

Orden de RecorridaImportancia del Orden en que se leen los

registros.Ejemplo: Condiciones de Filtro compatibles con el Orden

For each Order CliCodWhere CliCod >= &IniCod .and. CliCod <= &FinCod

....

....Endfor

Cod Nombre1 Smith

* 2 Jones <----- Starting Point Read &IniCod = 2* 3 Ball Read &FinCod = 4* 4 King <----- Ending Point Read

5 Ander

197

Ejemplo: Condiciones de Filtro no compatibles con el Orden

For each Order CliNomWhere CliCod >= &CodIni .and. CliCod <= &CodFin

. . .Endfor

Cod Nombre*3 Ander <----- Starting Point Read &CodIni = 25 Ball Read &CodFin = 4 6 Churchill Read1 King Read

*4 Smith Read*2 William <----- Ending Point Read

Orden de Recorrida

Importancia del Orden en que se leen los registros.

198

Cuando no se define un orden: Se debe tener en cuenta que el no especificar un orden, no implica que GeneXus lo elegirá de forma que optimice las condiciones definidas. Sino quese tomará el orden de la clave primaria y en base a este orden se optimizarán lascondiciones que sean posibles.Excepción: Existe un caso en el que se puede elegir un índice diferente al de la clave primaria, y es en el de anidamiento de FOR EACHs, cuando existe una relación entreatributos primarios de los mismos. En este caso el FOR EACH anidado elegirá el orden de acuerdo a las condiciones de filtro establecidas por su relación con FOR EACHsanteriores.Ejemplo: Clientes CliCod* Tipos TypCod*

CliNom TypNomTypCod

Tenemos Clientes y Tipos de clientes, y queremos listar los tipos de clientes y los clientesde cada tipo, haremos la siguiente especificación:

For each [TypCod] [TypNom]

For each [CliCod] [CliNom]

EndforEndfor

Como primera cosa, GeneXus infiere que los clientes que queremos recorrer son aquellosdel tipo (TypCod) que acabamos de considerar en el FOR EACH anterior. Es decir, quehay una condición implícita que indica que:Tipos.TypCod =Cliente.TypCod

Ejemplo: Nombre inicial : &IniNomNombre final : &FinNom

For each Where Clinom >= &IniNom .and. Clinom <= &FinNom

Endfor

Orden elegido --> CliCod

Orden de Recorrida

Si no se define un Orden se elige el de la Primary Key

199

Esto ocurre cuando se tienen FOR EACHs anidados, cuyas tablas bases tienen algunarelación; GeneXus la encuentra y determina en forma automática una condicióndefiltro. Esta relación sólo puede establecerse entre atributos primarios (aquellos queforman parte de la clave primaria de alguna tabla), ya que es el único caso en que un atributo puede estar en más de una tabla. Esta condición (Tipos.TypCod = Cliente.TypCod) establecida en el for each de clientes, sólo es optimizable si el ordenes TypCod. Pero decíamos que el no especificar ningún orden implica que el orden a tomar es el de la clave primaria (CliCod), por lo que no sería posible entonces la optimización.Pero en este caso, como única excepción, se elige el orden que permitaoptimizar la condición de filtro.

200

Posición de ComienzoConsideraciones para su definición.

Se consideran las condiciones compatibles con el orden y quesean por:

Si el orden es ascendente• Mayor (>) • Mayor o Igual ( >=)• Igual (=)

Si el orden es descendente• Menor (<)• Menor o Igual (<=)• Igual(=)

• Las condiciones deben estar relacionadas por .And.

201

Posición de Comienzo

Ejemplos:

Orden: A B CCondiciones : A>= 5 .and. C > 3 Posición de comienzo: A>=5

Orden: A B CCondiciones : A > 5 .and. B < 2 .AND. C > 3 Posición de comienzo: A > 5

202

La Posición Final

Consideraciones para su definición

• Se consideran las condiciones por:

Si el orden es ascendente• Menor (<) • Menor o Igual (<=)• Igual (=)

Si el orden es descendente• Mayor (>)• Mayor o Igual (>=)• Igual (=)

• Las condiciones deben estar relacionadas por .And.

203

Diagrama de Navegación

For each CliCodWhere CliCod >= &IniCli .AND. CliCod <= &EndCli

[ CliCod ] [CliNom ]Endfor

FOR EACH ClientesOrder : CliCodIndex : IClienteNavigation filters:

Start from:CliCod >= &IniCli

Loop WhileCliCod <= &EndCli

Constraints:CliCod >= &IniCli .AND. CliCod <= &EndCli

---->> CLIENTES ( CliCod )END FOR

204

For each CliCod[ CliCod ] [CliNom ]

Endfor

FOR EACH ClientesOrder : CliCodIndex : IClienteNavigation filters:

Start from:First record

Loop while:Not end of table

---->> CLIENTES ( CliCod )

END FOR

Diagrama de Navegación

205

- Calls : ¿En qué casos deberíamos considerar el costo de la ejecución de un Call? En la gran mayoría de los casos no es necesario que nos preocupemos por esto. Sin embargo en algún caso eliminar ¨Calls” puede significar la diferencia entre una buenay una mala performance ( ya que no tiene el mismo costo que hacerlo todo en un únicoprograma que en varios ). Generalmente, éstos comienzan a ser un problema cuando lo que se tiene no es una única llamada a otro programa sino que son varias.

En C/S, el tiempo de un call no es considerable ya que se van abriendo cursores sin preocuparse de cerrarlos hasta el final de la ejecución de la aplicación o si.no si se llegó al límite de cursores para usar, los que ya fueron usados, son marcados como borrables, a fin de cerrarlos sólo si es necesario, si se vuelven a utilizar la definición ya está, por lo que el tiempo de creación disminuye.

En File/Server, se cierran o abren los índices dependiendo de los indices utilizados. En NTX e IDX, si es necesario usar un indice que esta abierto, primero se cierra y luego se vuelve a abrir. Si es CDX, no cierra el indice sino que se reposiciona usando el mismo-. Ejemplo:Para cada cuenta, que cumpla las condiciones se llama a otro programa. Supongamos que las cuentas en las condiciones establecidas son 10.000, entonces se realizarán 10.000 "Calls", lo que seguramente tendrá una costo importante en el tiempototal del proceso.

• Calls

•Apertura y Cierre de Archivos

• Uso de Indices Temporales

También influyen en la performance:

206

For each CuentaWhere Cuenta > &cta

Call('Pvalida', ... ) Endfor

En el AS/400 las funciones resueltas con Calls en los programas generados son: Time() , Today() (se ejecuta una vez por programa) , Cdow(), Cmonth(), Userid(), Usercls(), Wrkstn()

Los calls en XBASE no tienen en sí mismos un gran costo, pero pueden generar cierres y reaperturas de tablas que sí importan. Se implementaron dos esquemas distintos de calls (entendiendo por Call : el call propiamente dicho y las UDP y UDF ), los que dependen del tipo de indice que se está utilizando.

Indices NTX/IDX/NDX - a) Cuando el Objeto llamado no utiliza ninguna tabla abierta por el objeto llamador: En este caso el objeto llamador (X) no cierra ninguna de las tablas que utilizapara realizar el llamado (call) , y el objeto llamado (Y) abre y cierra únicamente las tablas queutiliza.

b) Cuando el Objeto llamado (Obj.Y), utiliza alguna tabla abierta por el objeto llamador.

En las llamadas (calls) a otros objetos, el programa llamado cierra las tablas que necesita, quehayan sido abiertas por el programa llamador y las abre con los índices que deba utilizar. Antes de retornar, el programa llamado cierra todas las tablas que usó. El programa llamador, después de retornar del programa llamado, abre aquellas tablas que necesita y fueron cerradas por el programa llamado.

Resumiendo: El llamado siempre cierra lo que usa y el llamador se tiene que preocupar de reabrirlo que corresponda, el peor caso es cuando los dos usan las mismas tablas y el mejor es cuandousan todas distintas.

a) Pgma X Pgma Y b) Pgma X Pgm YOpen A, B, C Open D,E Open A, B, C Open D, ECall Y .... Call Y Close B y Open B

Close D, E ....Close A B C Close B, D, E

Open BClose A,B, C

207

Indices CDX: En este caso, en los objetos llamados, no se cierran las tablasque habían sido abiertas en los objetos llamadores y solamente reabren losíndices de la forma que los necesita.

Pgma X Pgma YOpen A, B, C Open D, E……. Reposiciona Indices B,CCall Y ....Restaura todo a como Close D, Eestaba antes del call...

Close A, B, C

Indices Temporales:

En Client/Server los indices temporales se construyen más rapidamente que en File/Server, ya que solo se indexarán los registros que cumplan las condiciones y no requiere un uso exclusivo de la tabla.

En File/Server, se construye el indice para la ejecución del programa y luego se borran. El tiempo de creación es considerable dependiendo del número de registros de la tabla y de la cantidad y largo de los campos.

En el AS/400 se usa la instrucción OPNQRYF para definir índices temporales. Dependiendo de todo eso es que conviene o no crearse un índice de usuario.

208

MULTIPLES FORMS

20945454241

Múltiples Forms por Objeto

• Poder tener N pantallas por objeto.

• Permitir dentro de una misma KB tener modelosen los que se genera para ambiente gráfico y otros en los que se genera para ambientecaracteres.

210

Form Classes

•Create automatically in new objects:Significa que cada vez que se crea un nuevo objeto, automáticamentese crea un form de esa clase en el mismo. Cuando se importa, se generaautomáticamente un form para cada clase que sea Autocreate.Puede haber una o más classes Autocreate.

•Create Reports and Procedures using “Form que se seleccione”:Como en reports y procedures no hay multi-form, se elige entre el Graphic y Text.

•New Class: Classes definidas por el usuario que pueden ser tanto Graphic comoText.

211

•Las Form Classes y sus propiedades son globales a la KB (File/Form Classes),pero se pueden editar desde cualquier modelo. A su vez, en cada modelo se puede definir una lista de form classes de

preferencia (File/Edit Model/Model Forms) para cada generador del modelo.

•El default de un form puede ser en base a otro form o en base al default deGenexus.

Múltiples Forms por Objeto• Form Classes

– Graphic y Text (son del sistema)– Definidas por el usuario (modo texto o gráfico)

• Cada objeto tiene forms que pertenecen a alguna de las form classes y cada Modelo tieneasociado una lista de Form Classes para cadagenerador del mismo.– Opción: File/ Edit Model/ Model Forms

212

•Apertura del objeto: para decidir cual mostrar en forma inicial.•La lista de forms del modelo se tiene en cuenta en 2 casos:

1.- Al especificar un objeto, para decidir cuál form considerarPara cada objeto, se toma la primer form class de la lista del modelo y se busca si existe en el objeto un form de esa clase. Si no existe, se busca de la form class que sigue en lalista y así hasta encontrar o que se acabe la lista. Si seacaba la lista y no se encontró, entonces de acuerdo algenerador (gráfico o de caracteres) se busca un form que sea de ese tipo, si tampoco se encuentra entonces seespecifica cualquiera y en el caso que haya que convertir, se convierte a texto. En cualquier caso, en el reporte de laespecificación aparece cuál fue la form class que se eligiópara cada objeto.

2.- Al abrir el objeto, para decidir cuál mostrar en forma inicial

¿Cuándo decide GX el form a utilizar ?

• En tiempo de Especificación

• Apertura del objeto

213

STYLES

214

Propiedades de los Styles

• Permiten la definición de standards.

• La definición es “por tipo” de objetos(transacciones, work panels, etc).

• Objeto GeneXus no tenido en cuenta al normalizar.

Los Styles son otro objeto GeneXus, su forma de definir es similar a la de losotros objetos, pero con la particularidad de que NO son tenidos en cuenta en la normalización o generación de programas.

Sólo se utilizan para definir standards, sin la necesidad de tener que diseñarForm por Form.Pueden ser modificados, y automáticamente se reactualizan los forms necesarios.

Hay Styles para transacciones, work panels, etc. , pero un style es de un solo tipo. Las excepciones a esta regla son los Styles de Work Panels que sirven también para Prompts y los Styles de Report y Procedure que pueden usarse para cualquiera de los dos.

Nota: No existen Styles de Styles

215

Definición de un Style• Object/New Object.• Ejemplo de un Style de transacción.

216

Style

Este espacio se puede usar para poner comentarios

Data Area

Style Area

Se ven en los forms unas líneas que definen diferentes áreas. Lo que está dentro del rectángulo es la denominada "Data Area" (área de datos). El resto del form es la "Style Area". A su vez, la Style Area está dividida en 8 sectores (ver figura). Cuando el desarrollador empiece a usar styles las lineas de la data areaaparecerán solas. De todas maneras también se pueden hacer aparecer con un botón de la toolbar.

•Los controles que están completamente comprendidos en un sector conservan su posición relativa a éste, cuando se mueven las líneas.•Aquellos controles que pasan desde un lado de una línea hacia el otro, conservan su posición relativa a la línea (se mueven junto con la línea).•Si un control pasa por encima de 2 líneas paralelas (o dicho de otra manera, comienza antes de la línea de borde izquierdo de la data area y termina después de la línea del borde derecho, o bien la misma situación con respecto a los bordes superior e inferior), pueden suceder dos cosas:

A). Es un control con "autoresize". En este caso, el control mantiene su posición relativa a la primera de las líneas que cruza.B). Es un control sin "autoresize". El control se agranda o se achica tanto como se separen o acerquen las líneas, manteniendo cada uno de los extremos del control su posición relativa a la línea más cercana.

217

Tres Tipos de Controles

• Controles que vienen de la default Data Area

• Los que vienen del Style

• Controles del Usuario– Los que agrega el usuario al objeto.– Los que vienen de la data area del Style.

•Los controles en la Data Area del style se pasan al objeto sólo en caso de inicialización (cuando el objeto es creado basado en el style y no en futuras reaplicaciones) y una vez en el objeto es considerado como un control de usuario dentro de éste.

218

Creación de un objeto basado en un Style

• Al momento de crear el objeto, en el Information/Style se elige el Style deseado.

• Relación entre objeto y Style:– Form y Properties: Relación dinámica– Otras partes del objeto: Relación estática

• Dinamismo con las properties– Los objetos heredan las propiedades del style asociado– El dinamismo es “por property”

Cuando se crea un objeto con un Style asociado, el objeto se inicializa con todas las partes del Style (a excepción del Information, obviamente). Excepto para el Form y las properties, la relación entre las partes del objeto y del Style es estática (si se cambia el Style no se cambia el objeto). Pero tanto para el Form como para las properties puede ser dinámica (que por ejemplo, cuando se cambie el Form del Style se cambie el form del objeto). En el caso de las properties, el dinamismo se mantiene en forma independiente para cada property.

Cuando el objeto es creado sin especificar un Style asociado, GeneXusconsidera de todas maneras para el form la asociación a un Form Style Default. Es decir que aunque el objeto no tenga Style asociado, a los efectos del form es como si estuviera asociado a un Style Default.

Cuando se crea un objeto, se tiene Syle dinámico, pero dinamismo con la default data area sólo si el objeto es un transacción. En las próximas transparencias veremos cómo es que se pierde el dinamismo.

El estado de dinamismo se puede ver por el color con el que están dibujadas las líneas. Si son rojas, está dinámico. Si no está dinámico, son azules.

219

Creación de un objeto basado en un Style

Las líneas de la data area estan en azul indicando que se perdió el dinamismocon la default data area.Las lineas de la style area estan en rojo indicando que existe dinamismo entre la style area de la transacción de clientes y la style area del style.

NOTA: Se puede perder el dinamismo con la style area del Style y seguir teniendo dinamismo con las properties del Style (siendo esto último “por property”; es decir, teniendo dinamismo con algunas properties y no con todas).

220

Cómo asociar Styles a objetos existentes

• Opciones– Object/Information/Style – Reapply Form Style

Cuando se crea un objeto nuevo con un Style asociado, el objeto es inicializado con todas las partes del Style.Cuando el objeto ya existe, y se le asocia un Style, lo único que hereda de éste es el Form y las Properties (sólo las properties que tienen en el objeto los valores por default), siendo el dinamismo de las properties “por property” (se respetan las otras partes del objeto: Event, Rules, etc.). En otras palabras, es útil asociar un Style a un objeto existente cuando se quiere utilizar sólo los Form del Style y las properties del Style en el objeto.

Para asociar un Style (o cambiar el Style asociado) a un objeto ya existente se debe editar la "Information" del mismo, seleccionando alli el Style deseado.Para aplicar el Style a cualquiera de los forms del objeto se usa el menu Edit / Reapply Form Style.

Antes de aplicar el Style, hay que tener en cuenta que aquellos controles que no provenían del Style asociado anteriormente (controles del usuario), permanecerán en el form del objeto, con lo que pueden ocurrir superposiciones.

221

Qué pasa con el dinamismo ?

• Cuando se pierde ?– Cuando se modifican

• los controles que vienen de la DDA • los controles que vienen de la “style area” del Style• el seteo de una property

• Opciones:– Edit \ Default Data Area– Edit \ Reapply Style Form

Si se modifica un control que figura en el form como resultado del cálculo de la Default Data Area (control que viene de la DDA), se pierde el dinamismo en ésta (por ej.: si en una transacción se modificó uno de los controles correspondientes a los atributos de la estructura, al agregar nuevos atributos en la misma no aparecerán automáticamente en la Data Area). Análogamente, si se modifica cualquiera de los controles que vienen de la style area del Style, se pierde el dinamismo con el Style. Si se modifica el valor de una property en el objeto, entonces se pierde el dinamismo con “esa property” del style.

No se pierde ninguno de los dinamismos al agregar nuevos controles (ya sea en la Data Area o en el Style Area) del objeto que se está diseñando. Estos controles se consideran “de usuario” .Tampoco se pierde ninguno de los dinamismos al modificar o borrarcualquiera de los controles “de usuario”.

Una vez que se pierde el dinamismo con la Data Area o con el Style, se puede recuperar utilizando las opciones de menu Edit – Default Data Area y Edit –Reapply Form Style, respectivamente.

222

Cambio en el tamañode la Data area

• Para agrandar o achicar la data area, sólo sirve mover los bordes derecho y/o inferior.

El form del Style tiene la capacidad de adaptarse al tamaño de la Data Area del objeto en el que se lo utiliza. Cuando la Data Area se agranda (ya sea debido al calculo de Default Data Area o a la accion del usuario) el mecanismo de aplicacion dinamica del Style se encarga de agrandar tambien el frame, y mover hacia la derecha y hacia abajo los controles que estan a la derecha y abajo de la Data Area respectivamente. Similar comportamiento se observa al achicar la Data Area (se achica el frame y los controles se mueven hacia la izquierda y hacia arriba).

El tamaño de la data area definido en el form del style (y por lo tanto también el tamaño del frame) se considera como tamaño mínimo de la data area del form del objeto.

223

Consideraciones parael diseño de Styles

• Los controles que queden dentro de la Data Area del Style son considerados como “Controles del usuario”.

• Definir forms para diferentes form classes si los objetos que lo usan tienen múltiples forms. (Ej.: definir un form gráfico y uno de texto en el style).

• Cuando se ponen Eventos y Rules incluir comentarios al principio sobre que cambios se deben realizar en el objeto.

Cuando se ponen Evento y Rules, incluir comentarios al principio sobre quécambios se deben realizar en el objeto. Por ejemplo, en las rules de un Style para transacciones poner:

//sustituir “clave” por el nombre del atributo clavenoaccept(clave)

224

Master Style• Objetivo: Style default

• Se define por modelo

• Por “tipo de objeto” salvo:– Prompt - Workpanel– Report – Procedure

– File/Edit Model/Master Styles

•Master StyleExiste la posibilidad de declarar, para cada tipo de objeto, cuál de los styles existentes en el modelo se desea que sea considerado como Master Style (es decir, cuál se desea utilizar en lugar del “default style”). No es que se tenga que “crear un Master Style”sino que entre aquellos que ya existen, se puede elegir uno y declararlo como Master. Esta declaración es de caracter opcional: es posible no declarar a ninguno como Master y simplemente funcionará todo como hasta ahora (utilizando el “default style”).

•En File/Edit Model/Master Styles se designa el Master Style para cada tipo de objeto. En cada caso están disponibles los styles existentes y la opción “(None)”.

Si bien al momento de crear un objeto style, se puede elegir tanto crear un Report Stylecomo un Procedure Style, el tipo del style que en definitiva se crea es siempre Procedure Style. Los Procedure Style pueden ser usados como style tanto para Reportscomo para Procedures. De la misma manera pueden ser elegidos tanto como para Master Style de Reports como para Master Style de Procedures. Por otro lado, los Work Panel Style pueden ser usados como style tanto para Work Panels como para Prompts.

225

Master Style

• Precedencia: – Style asociado– Master Style– Default

226

MENU BAR Y TOOL BAR

227

Tipo de objeto Menu Bar

• Para definición de Menu Bar y Tool Bar – Object/New Object/Menu Bar

• Add y Delete de Items– Edit/Insert y Edit/Delete respectivamente– Subitems– Personalización del item Help/About

• Sólo en generadores gráfico:– VB, VFP, JAVA

Cada objeto GeneXus que tenga Form puede tener su propio Menu Bar y Tool Bar. Para definirlos, se usa el tipo de objeto GeneXus Menu Bar.

Para agregar o borrar opciones (items) del Menu Bar, se utilizan las opcionesEdit/Insert y Edit/Delete respectivamente.La definición de la Tool Bar es exactamente igual a la del Menu Bar, sólo que en lositems de la Tool Bar se debe definir también el bitmap correspondiente.

El item Help/About llama a un work panel GX_ABOUT. GeneXus por defecto yaprovee este work panel, en caso de querer personalizarlo se debe crear un nuevo work panel con este mismo nombre con la información deseada.

228

Tipo de objeto Menu BarDefinición de Eventos

• Cada item sin subitems puede tener asociado un evento(Object/Events).

• Nombre del evento: Event Menubar.nombre del item• Son generales No se permiten atributos.• En transacciones y work panels

– Property Menubar : *Default, *None, Menu Bar existente– Pueden programarse eventos para los items de la Menu Bar.

Son particulares Se permiten atributos.

Los eventos definidos en el Menu Bar son generales, por lo cual se ejecutaránen todos los objetos que utilicen el Menu Bar. Por esta razón es que no se permite el uso de atributos en los mismos.

Luego de definido un Menu Bar, se debe indicar en que objetos se utilizará. Esto se indica con la property Windows Interface de las transacciones y work panels.En las transacciones y work panels que utilicen el Menu Bar definido, se pueden programar eventos para los items del Menu Bar . Como estos eventosson particulares de cada objeto, sí se pueden usar atributos.

Si un mismo evento se programa en el Menu Bar y en el objeto, se ejecuta el del objeto.

229

PROPIEDADES, EVENTOS Y METODOS ASOCIADOS A LOS

CONTROLES

230

•Algunos controles tienen un nombre por defecto, pero hay otros que no; porlo cual si se les quiere aplicar alguna property hay que asociarles un nombre ya que de lo contrario no aparecen en la columna “Control” al hacerInsert/Property.

•En el caso del Form el nombre del control (por defecto) es Form.Si se desea cambiar el título de un Form, la forma es:

Form.Caption=‘Datos del Cliente’ + CliNom

•En el caso de un control tipo texto, se le debe dar un nombre.

PROPIEDADES DE LOS CONTROLES

• Cada control en un Form tiene un ‘nombre’ y ‘propiedades’ asociadas.

• Insert/Property: despliega la lista de propiedades válidas para cada control.

• Según el tipo de control, las properties que tieneasociadas.

• Sólo en generadores gráficos:– VB, VFP, JAVA

231

Propiedades de los Controles

• El ‘nombre del control’ para atributos/variables es el nombre del atributo/variable.

• NOTA: Si una variable es un vector, debeindicarse un nombre a cada posición del vector para diferenciarlas.

232

Diálogo:Select Property

• Se accede a través de la opción Insert/Property cuando se editan:– Rules, Eventos, Subrutinas, etc en transacciones,

work panels y web panels

• No disponibles en reports y procedures

233

Diálogo:Select Property

•Form:Permite seleccionar para que tipo de form (Graphic, Text o de Usuario) se le asignará una propiedad a un control.

•Control:Muestra la lista de controles que hay en el form que se está diseñando yque tienen un nombre asociado.

•Property:Despliega la lista de propiedades que se pueden aplicar al controlseleccionado y en la segunda columna se despliegan los tipos de cadaproperty.

El Help trae el Help de la property seleccionada

234

EVENTOS EN CONTROLES

• Insert/Events

• Permite asociar Eventos a cada Control.– DblClick– Click– RightButton– IsValid– OnLineActivate

•DblClick: El código asociado a dicho evento se ejecuta al hacer “doble click” sobre el campo.

•Click:El código asociado a dicho evento se ejecuta al hacer “click”

sobre el campo.

•Right Button: Se dispara cuando se presiona el botón derecho del mouse.

•IsValid:Se dispara cuando se hace la validación del control.

235

Evento OnLineActivate• Evento asociado al control “subfile”• Se dispara cuando se activa una línea en el subfile:

– al clickear una línea con el mouse– moverse a través de la grilla con el teclado– cuando se hace refresh de la grilla.

• Los valores son los de la línea “nueva”• Los for each incluidos en este evento se anidan a

la tabla base del workpanel.• Disponible en transacciones y work panels.

OnLineActivateEs un evento asociado al tipo de control subfile. Los For Eachs que se incluyan en dicho evento estarán anidados a la tabla base del work panel, es decir, se comportan igual a los For Eachs del evento Enter.

236

Eventos en Controles

•Form:Permite seleccionar para que tipo de form se le asociará una evento a un control.

• Control:Muestra la lista de controles que hay en el form que se está diseñando.

•Event:Despliega la lista de eventos que se pueden aplicar al controlseleccionado.

237

METODOS• Se aplican a los controles.

• Sintáxis:Nombre del Control.Method([<Parms>])

• Según el tipo de control (edit, check box, etc) son los métodos quese pueden asociar.

• Se accede a través de la opción Insert/Methods cuando se editan:Rules, Eventos, Subrutinas en transacciones, work panels y web panels.

• Sólo en generadores gráfico:VB, VFP, JAVA – A excepción del método SetFocus que será implementado en

todos los generadores.

La forma de trabajar es similar a la de Properties y Eventos.

NOTA: Los generadores texto ignoran los métodos en tiempo deespecificación.

238

OBJETOS MAIN

239

Objetos Main

• GeneXus genera ejecutables por cada objeto Main.

Cualquier objeto se puede definir como el principal de un ejecutable. Esto, se define en el tab Options del Information del objeto que quiero definir como ejecutable.

El ejecutable contiene al objeto en sí y todos los que este llama.

240

Llamadas a objetos Main

• Cuando desde un objeto se llama a otro objeto que es Main:– GeneXus genera un call a un ejecutable (en lugar de un

call común)– Son compilables

Cuando desde un objeto se llama a un Main, GeneXus genera un call a un ejecutable.

241

¿Qué ocurre si un objeto que no es Main pasa a serlo?

• Ejemplo:– Trn A Wpanel B

Call(PImpClis) Call(PImpClis)– PImpClis no es main: GeneXus generó entonces en los programas

asociados a la Trn A y Wpanel B un call al programa PImpClis• El Proc ImpClis pasa a ser Main:

– En los programas asociados a la Trn A y Wpanel B GeneXus debería cambiar el call al programa PImpClis por un call a un ejecutable “ImpClis”, con lo que deberíamos regenerar estos objetos.

• Para evitar la regeneración de todos los objetos llamadores: GeneXus usa un concepto llamado STUBS

242

STUBS• Cuando el objeto ImpClis pasa a ser Main, GeneXus en lugar de

generar un único programa asociado al objeto, realiza lo siguiente:– Genera el programa “PimpClis” que sólo contiene el Call al Ejecutable

correspondiente– Genera otro programa que es el que contiene la lógica del objeto

ImpClis y será el principal del ejecutable.• Esto permite no tener que regenerar todos los objetos que llaman

al objeto ImpClis. • Al programa que contiene sólo el llamado al ejecutable se le

denomina STUB.

243

STUBS• Tenemos entonces 2 programas generados, asociados a un mismo objeto GX.• Para la denominación del programa STUB se siguen las convenciones de siempre

(P=Procs, W=Work Panels etc.)• Para la denominación del programa que será el principal del ejecutable (el que contiene

realmente el código) se usan las siguientes convenciones: » Transacción N» Work Panel U» Report O» Procedure A» Menu L» Web Panel H

• Siguiendo con el ejemplo, para el objeto ImpClis, GX generará 2 programas: PImpClis.xxx y AImpClis.xxx (xxx= extensión del generador corresp.) y el ejecutable se llamaráAImpClis.exe

244

DATA VIEWS

245

DataViews - Archivos Externos

Los Data Views de GeneXus permiten manejar ArchivosExternos como si fueran Archivos pertenecientes a la Basede Conocimiento.

Propiedades• Definición Global• Uniformización de la nomenclatura

246

DataViews - Archivos Externos

Para trabajar con Archivos Externos en GeneXustenemos dos posibilidades:

DATA VIEWS» Sin tabla Asociada» Con tabla Asociada

247

Los Data Views de GeneXus permiten manejar Archivos Externos como si fueran archivos pertenecientes a la Base de Conocimiento.

En el Data View se puede indicar que se manejará una transacción interna asociada, o no.

Data View con transacción interna asociadaSupongamos que desde una Base de Conocimiento se desea manejar el archivo externo clientes.dbf cuyos campos son:

- Codigo* - Nombre- Dir- Tel

1) Se debe crear una transacción de clientes definiendo los atributos que se deseen manejar de la tabla externa. Estos atributos internos deben coincidir en lo que serefiere a tipos y tamaños con los campos externos, pero los nombres pueden serredefinidos respetando la nomenclatura GIK.

Data Views

EXTERNALFILE

INTERNALTABLE

EXTERNALFILE

GENEXUSDA

TABASE

DATA VIEW DEFINITION

EXTERNAL ENVIRONMENT

SIN TABLA ASOCIADA

CON TABLA ASOCIADA

248

2) Se debe crear un Data View e indicar en él, cual es la transacción interna asociada. Asimismo se deben indicar las correspondencias entre los atributos internos y los campos externos.

También se debe ingresar en el Data View, información relacionada alArchivo Externo como ser la plataforma y ubicación (esto debe ser indicado tanto en el caso que el Data View tenga una transacción interna asociada, o no).

3) Los objetos GeneXus deben definirse haciendo referencia a los atributos internos de los clientes, sin embargo los programas son generados utilizando los campos externos en forma transparente.

Nota: Si bien se define una transacción de clientes, esta no provoca la creaciónde una tabla física por estar asociada a un DataView. Esta transacción seespecifica y genera como cualquier objeto de la Base de Conocimiento y enejecución, accede en forma interactiva a los registros de la tabla externa en forma transparente.

Data View sin transacción interna asociadaEn este caso, se debe crear un Data View, sin crear previamente una transacción interna. La forma de acceder al Archivo Externo es únicamente mediante la definición de procesos batch utilizando los External File Commands: XFOR EACH, XNEW, etc.

249

Assoc. table: En este punto se debe seleccionar la tabla interna asociada al Data View.

Composition: Aquí se deben indicar las correspondencias entre los atributos internosy los campos externos.

[Nombre Interno] [Nombre Externo][Nombre Interno] [Nombre Externo][Nombre Interno] [Nombre Externo]

Cuando no se menciona el Nombre Externo es porque coincide con elNombre Interno. En el ejemplo, el nombre y la dirección del cliente en el Archivo Externo se llaman CliNom y CliDir respectivamente.

Indices: En esta lista, se deben definir los índices internos que GeneXus usará en laaplicación.

Plataform Specific Information: Aquí se debe completar información del archivo externo (como ser la plataforma y ubicación).

Definición de un Data View

250

Composition

• Ejemplo:Dados los siguientes Archivos Externos:

CLIENTES PRODUCTO

Codigo* Codigo*CliNom ProDscCliDir ProPre

Composition CompositionCliCod 'Codigo' ProCod 'Codigo' CliNom ProDscCliDir ProPre

Se uniformiza la nomenclatura

251

Name: Nombre del índice que GeneXus usará en la aplicación.

Nota: Este es un nombre interno del índice, es decir, no tiene por qué ser el nombre del índice físico. Genexus hace un mapeo entre el nombre interno del índice y elnombre externo de acuerdo a la composición del mismo.

Unique o Duplicate: Si permite tener o no llave duplicada.

Compositions: Es la lista “ordenada” de campos que componen al indice. Losatributos mencionados acá deben ser parte de la Composition del Data View.

Indices

252

Las propiedades del Data View pueden definirse para cada plataforma o por modelo.

Esto nos brinda la posibilidad de especificar diferentes ubicaciones del mismo Data View dentro de la misma plataforma pero para diferentes modelos.

Por ejemplo, si se quiere darle diferente ubicación para el modelo de Prototipo Fox y para el modelo de Producción Fox, debe seleccionarse DBFCDX(model2) y DBFCDX(model 3) indicando la ubicación para cada uno de los modelos. En cambio, si se quiere la misma ubicación para todos los modelos Fox debe seleccionarse la plataforma DBFCDX.

Platform Specific Information / Add

253

Estas propiedades varían dependiendo de la plataforma seleccionada.

En este caso, por ejemplo, el archivo externo es un archivo de texto y por tanto las propiedades son referentes a un archivo de este tipo.

Platform Specific Information / Edit

254

Data View con Tabla Interna Asociada

Se trata al archivo externo como una tabla más del modelo. Se pueden utilizar los mismos comandos utilizados para acceder a las Tablas Internas (For Each, etc.) Se deben mencionar los atributos internos y Genexus al generar los programas, utilizarálos campos externos de forma transparente.

Associated Table

GENEXUSMODEL

INTERNALTABLE

EXTERNALFILE

DATA VIEWDEFINITION

EXTERNALENVIRONMENT

GENEXUSDEVELOPMENTENVIRONMENT

INTERNALINDEX

EXTERNALINDEX

- - - - -

- - - - -- - - - - -

- - - - -

- - - - -- - - - -- - - - -- - -

- - - -

255

Existe una relación de uno a uno entre los atributos de la Tabla Interna del Data View y los del Archivo Externo.

INTERNALTABLE

EXTERNALFILE

- - - - - - -

- - - - - - -

- - -

Associated TableTabla Interna = Tabla Externa

256

Los atributos definidos para la Tabla Interna y para el Data View coinciden, pero elArchivo Externo tiene atributos no declarados en el Data View. Estos atributos nopueden ser accedidos.

INTERNALTABLE

EXTERNALFILE

Not Accessed

- - - - -

- - -

- - -

Tabla Interna < Tabla Externa

Associated Table

257

Si la Tabla Interna tiene más atributos que el Archivo Externo no es válida laasociación.

DATA VIEWDEFINITION

EXTERNALENVIRONMENT

GENEXUSDATABASE

EXTERNAL FILE

NOT ALLOWED

- - - - -

- - - -

- - - -

Associated TableTabla Interna > Tabla Externa

INTERNALFILE

258

En el ejemplo, se pide tener también como datos del Cliente el E-Mail y la dirección.

DATA VIEWDEFINITION

EXTERNALENVIRONMENT

GENEXUSDATABASE

INTERNALTABLE B

INTERNALTABLE A EXTERNAL

FILE

Subtype

ALLOWED

- - - -

- - - -

- - -

Associated TableTabla Interna > Tabla Externa

USO DE SUBTIPOS

CliCod*CliNom

CliCodSub*CliNomCliDirCliEMail

CodigoNombre

259

En este caso coincide todo. Si ocurre esto no hay que detallar composición ni deíndices del Data View. Lo único que hay que hacer es asociar el Data View a la tabla externa (Platform Specific Information).

Tener en cuenta que el índice y archivo externo deben estar ubicados en el mismo directorio.

Asociación Dinámica

Las definiciones del Archivo Externo e índicesasociados coinciden con las definiciones de la TablaInterna y sus índices (tanto en nombres como en la composición).

260

Arbol de Definición

Definición Global

Data View

ArchivosExternos

CONTablas Asociadas

SINTablas Asociadas

AsociaciónDinámica

AsociaciónDefinida

261

REORGANIZACIONES -DATA VIEWS

1. EXISTE TABLA ASOCIADA

Si cambia la estructura de la tabla asociada, el cambio esdetectado en el Análisis de Impacto.No se generan programas de reorganización.

2. NO EXISTE TABLA ASOCIADA

No aparece en el análisis de impacto.

262

WEB PANEL

• Permite construir páginas WEB dinámicas queinteractúan con la base de datos.

• C/SQL– Con todos los DBMS, excepto AS/400

• Visual Basic – Access

• RPG/400 – AS/400

• Java

•Los web panels pueden generarse tanto con Visual Basic como con C/SQL.Por lo tanto, pueden ejecutarse en un servidor Windows NT (VB, C/SQL) o en servidores UNIX (usando C/SQL).

•En caso de generar con RPG, el servidor de Internet debe ser al AS/400

•Pueden usar todas las bases de datos soportadas.

•Restricción: Con el generador C/SQL no puede usarse el dbms AS/400.

1

GeneXus Intermedio.

Optimizando Aplicaciones.

Relator : Héctor Zavala Rubio.

TABLA DEL CONTENIDOTABLA DEL CONTENIDO

PUNTOS IMPORTANTES EN LA DEFINICION DE TRANSACCIONES…………………………...…003

USO Y RECOMENDACIONES EN EL USO DE SUBTIPOS……………………………………....….….038

FORMULAS AGGREGATE SELECT ……………………………………………….. ……………………059

PUNTOS A PROFUNDIZAR EN EL MANEJO DE WORK PANELS ..…………………………...……064

PUNTOS A PROFUNDIZAR EN REPORTES Y PROCEDIMIENTOS ………………………….……..074

IMPACTO Y REORGANIZACION DE LA BASE DE DATOS ……………………………………….…084

INTEGRIDAD TRANSACCIONAL Y CONTROL DE CONCURRENCIA ……………………………124

EFICIENCIA Y PERFORMANCE DE LAS APLICACIONES ..……………………………………….215

ARQUITECTURA DE MULTIPLES CAPAS ………………………………..…….……………..……….135

INTRODUCCION A CLIENTE SERVIDOR ……...…………………………….. ………………..…..…141

INTRODUCCION A PAGINAS WEB …...……...…...…………………………….. ………………………151

2

PUNTOS IMPORTANTES EN LA PUNTOS IMPORTANTES EN LA DEFINICIONDEFINICION

DE TRANSACCIONESDE TRANSACCIONES

Definición de Modos

Modo Inicial

• El modo inicial de un nivel de una Transacción dependede la plataforma y puede ser modificado en cada nivel usando la rule Default_Mode.

3

• Modo UPDATE por defecto• Se puede indicar el modo inicial usando la rule

DEFAULT_MODE• El modo se mantiene hasta cambiar a otro modo

Micro/LAN:

AS/400• El modo para el PRIMER NIVELPRIMER NIVEL se define con:

– DEFAULT_MODE para el nivel

– Sino existen dos casos:

» CON SUBFILE: update

» SIN SUBFILE- No se acepta la Primary Key: update- La Primary Key es aceptada: insert

• Modo para niveles subordinados:– DEFAULT_MODE para el nivel– Sino hereda el modo del nivel inmediatamente superior– En otro caso define igual que para el PRIMER NIVELPRIMER NIVEL

4

Loop Once

•Ningún atributo es aceptado

•La transacción recibe la variable &Mode comoparámetro (Update o Delete)

•La Primary Key se recibe como parámetro:parm(<att1>, …, <attn>);

y

Delete Cascade

• La opción Delete en una Transacción realiza un Delete Cascade del nivel subordinado, al que se esta eliminando.

• Se eliminan sólo aquellos registros incluídos en la estructura de la Transacción que se esta ejecutando.

• Si el nivel subordinado del nivel que se esta eliminando posee un nivel subordinado, el Delete Cascade no es válido.

5

EJEMPLO: Delete Cascade

OrdenOrden de de CompraCompraOrdNro*OrdFchPrvCod PrvNom Tabla OrdenAnaNroAnaNom(PrdCod*PrdDsc OrdCntOrdPrcPrdPrc)

OrdImpTot

EntregasEntregasOrdNro* Tabla EntregasPrdCod*(EntFch* Tabla Entrega1EntImporte)

- Transacción OrdenSe desea eliminar una Orden

- Transacción OrdenSe desea eliminar una Linea de la Orden

- Transacción EntregasSe desea eliminar una Linea de la Orden

Uso de &Mode

• La modalidad de una Transacción puede instanciarse recibiendo como parámetro la variable &Mode de GeneXus.

• Valores válidos para &Mode

'INS' - Insert'UPD' - Update'DLT' - Delete

• El modo recibido en &Mode se aplica al primer nively no se puede cambiar.

• La variable &Mode no puede ser modificada en la Transacción, para poder utilizarla debe ser recibida como parámetro.

6

EJEMPLO: Transacción de pedidos

PedNro*PedFchPrvCodPrvNomPedImpTot

(PrdCod*

PrdDscPedCnt

PrdPrc)

CASO 1: El Identificador se recibe en el atributoparm(PedNro, &Mode ) ;

CASO 2: El Identificador se recibe en una variableparm(&Pednro, &Mode ) ;PedNro = &Pednro IF Update .OR. Delete ;Noaccept(PedNro) IF Update .OR. Delete ;

INVOCANDO A LA TRANSACCION DE PEDIDOS

TRABAJAR CON PEDIDOS

2 = Modificar 4 = Eliminar

Número Fecha Proveedor Total - 001 01/01/92 1 Proveedor Uno 1,000,000- 002 12/03/92 2 Proveedor Dos 234,000- 003 12/12/92 3 Proveedor Tres 500,000

F6 = Ingresar Pedidos

7

Eventos:

Event EnterFor each line

if &Op = '2' // Modificarcall(TPedido,PedNro, 'UPD')

endifif &Op = '4’ // Eliminar

call(TPedido,PedNro, ‘DLT’)endif

endforrefreshEndEvent

Event 'Ingresar Pedidos' 6call(TPedido,0,’INS’)refresh

EndEvent

PUNTOS IMPORTANTES EN LA PUNTOS IMPORTANTES EN LA DEFINICIONDEFINICION


Definición de Prompts y Refcalls

8

PROMPTS• Prompt

– La facilidad de prompt despliega todos los valores posibles que pueden ser asignados a foreign keys, permitiendo al usuario seleccionar el valor deseado.

• Autoprompt

– Existe una autoprompt para cada nivel de una transacción que permite visualizar y elegir un registro de la tabla base del nivel de una Transacción.

• Activación según la plataforma:

– Prompt : PC > F4AS/400 > F4

– Autoprompt : PC > Botón de SELECT AS/400 > F16 (Ver)

Refcall('Pgm_Nombre', <Par1>,....<ParN>);

•Esta rule se utiliza para llamar un programa cuando falla el control de integridad referencial para la foreign key indicada.

•Los parámetros <Par1> .. <ParN> pueden ser tanto atributos comovariables.

•Los atributos se deben corresponder con una foreign key .

Rule Refcall

9

Prompt('Pgm_Nombre', <Par1>,....<ParN>);

•Esta rule se utiliza para llamar un programa que permita al usuario seleccionar valores posibles de una lista.

•Los parámetros <Par1> .. <ParN> pueden ser tanto atributos como variables. Si son atributos no tienen porqué formar una FK.

Foreign KeySustituye al Prompt que genera GeneXus por defecto.

Atributos SecundariosSi es uno solo, habilita el F4 sobre el mismo.Si son más de uno, habilita el F4 sobre el primero en la estructura de la transacción.

VariablesSi es una sola, habilita el F4 sobre la misma.Sin son más de una, habilita el F4 sobre la primera en ser aceptada (en lasrules).

Rule Prompt

Reglas para el prompt por defecto

• Los parámetros no instanciados se utilizan como condiciones de búsqueda con >=, con un máximode 8.

• Los parámetros instanciados aparecen como condiciones de búsqueda pero no modificable.

• Los atributos del subfile aparecen de acuerdo al orden en que están en la tabla, si uno excede el tamaño de la pantalla se intenta con el siguiente. El ancho del atributo en la pantalla es el mayor entre el ancho del atributo y su descripción .

10

TRANSACCIONES:

CategoríaCategoría SubCategoríaSubCategoría MovimientosMovimientosCatCod* CatCod* MovNro*CatNom SubCatCod* CatCod

SubCatNom SubCatCod SubCatNomCatNom

TABLAS:

Table Name Attributes Categori *CatCod

CatNom

SubCateg*CatCod *SubCatCod SubCatNom

Movimien *MovNro CatCod SubCatCod

Ejemplo

Table Program Parameters (*) Atributo InstanciadoMovimien WGx0030 MovNroCategori WGx0010 CatCodSubcateg WGx0021 CatCod*, SubCatCod

– WGX0030 es el Autoprompt para la tabla Movimien – WGx0010 es el Prompt para la tabla Categori– WGx0021 es el Prompt para la tabla Subcateg

Prompts generados al especificarla Trn de Movimientos

11

EJEMPLO: Se elimina la Transacción Categoría

Tablas:SubCateg *CatCod

*SubCatCod SubCatNom

Movimien*MovNro CatCod CatNomSubCatCod

Prompts para la Trn de Movimientos:

Table Program ParametersMovimien WGx0030 MovNroSubCateg WGx0020 CatCod, SubCatCod

Se genera un único prompt para la tabla SubCateg.

PUNTOS IMPORTANTES EN LA PUNTOS IMPORTANTES EN LA DEFINICION DEFINICION


Disparo de Rules

12

EJEMPLO: Transacción FacturaTransacción Factura

FacId*FacFchCliCodCliNomCliSdoCliDir(PrdCod*PrdDscFacLinCntFacLinPrcPrdPrcPrdStkPrdStkMinFacLinImp)

FacSubTotFacIvaFacTotCal

Reglas:default(FacFch ,today() ) ;error('No hay Stock suficiente') IF PrdStk< 0;subtract(FacLinCnt,PrdStk);

Fórmulas:FacLinImp=FacLinCnt*FacLinPrcFacSubTot = SUM (FacLinImp)FacIva = FacSubTot * 0.22FacTotCal = FacSubTot + FacIva

DISPARO DE RULES

GeneXus se encarga de determinar el orden de Disparo de las reglas según las dependencias de los atributos indicados

– ORDEN DE DECLARACION:

error('No hay Stock suficiente') IF PrdStk < 0;

subtract(FacLinCnt,PrdStk);

– ORDEN DE EVALUACION:



GeneXus se encarga de determinar el orden de Disparo de las reglas según las dependencias de los atributos indicados

– ORDEN DE DECLARACION:



– ORDEN DE EVALUACION:



13

Orden de Disparo

TOT

STOT

IVA

IMP

CANTPRECIO

STOCK

ERROR

FECHASISTEMA

FECHA

0.22

SUM

subtract

.

Cambio en el Orden de Disparo de Rules

•En la mayoría de los casos el orden de disparo de las rules inferido por GeneXus es el deseado. En algunos casos, este orden se puede querer modificar.

•Existen una serie de funciones booleanas llamadas'Transaction Event Functions' que permiten realizar estos cambios.

14

Level(Atributo)

EJEMPLO: No permitir modificar líneas de una Factura

Transacción FacturaTransacción FacturaFacId*CliCod...

( PrdCod*FacLinCntPrdPrcFacLinImp)

...FacTotCal

Regla:Error('No puede modificar la linea') IF Modified() .and. Level(PrdCod);

After(Insert | Update| Delete)

EJEMPLO: Trn ClientesTrn Clientes

CliCod*CliNomCliSdoCliDirCliSts

Llama a un procedimiento que realiza la impresión de los datos del clientey setea el atributo Status.

LLAMADAS INCORRECTAScall('pficha', CliCod) if Insert .and. After(Confirm);call('pficha', CliCod) if Update .and. After(Confirm);

LLAMADAS CORRECTASSi cada uno constituye una UTL:call('pficha', CliCod) if After(Trn) .and. (Insert .or. Update) ;Si ambos programas se consideran una única UTL:call( 'pficha', CliCod) if After(Insert) .or. After(Update);

15

After(Level(Atributo))EJEMPLO:

FacturaFactura__ProveedorProveedor

PrvCod*FacId*...FacTotIng

( PrdCod*FacLinCntPrdPrcFacLinImp)

...FacTotCal=SUM(FacLinImp)

– Rule:Error('El total ingresado no coincide con el total

calculado') IF FacTotIng<> FacTotCal;

TOT CALC

STOT

IVA

IMP

CANTPRECIO

0.22

SUM

After(Level(Atributo))Según el árbol de evaluación cada vez que el importe cambie,cambiará el total calculado.

16

After(Level(Atributo))

Entonces se debe indicar el evento de disparo:

Error('El total ingresado no coincide con el total calculado') if (FacTotCalc <> FacTotIngresado) .and. after(level(PrdCod));

After(Confirm)

EJEMPLO: Numeración Automática

Caso1FacNro = udp(’PNumera’, ‘FAC’) IF insert ;

Caso2FacNro = udp(’PNumera’, ‘FAC’) IF after(insert );

Lo correcto es :FacNro = udp(’PNumera’, ‘FAC’) IF insert .and.

after(Confirm);

17

After(Trn)EJEMPLO 1:

Queremos llamar a Líneas de Factura después de ingresar el Cabezal de la Factura.

CabezalFacturaCabezalFactura LineasFacturaLineasFacturaFacId* FacId*FacDatos (PrdCod*CliCod FacLinCnt

FacLinImp)FacTot

Si se considera el cabezal como una UTL y las líneas como otra UTL.Call ('TLinfac', FacId) IF after(Trn);

Si se considera a ambas como una única UTL.Call ('TLinfac', FacId) IF After(Insert) .or. After(Update);

After(Trn)

– EJEMPLO 2:FacturaFactura ClienteClienteFacId* CliCod*FacFch CliNomCliCod CliSdoCliNom CliDirCliSdoCliDir(PrdCod*PrdDscFacLinCntFacLinPrcPrdPrcPrdStkPrdStkMinFacLinImp)

FacSubTot = SUM(FacLinImp)FacIva = FacSubTot * 0.22FacTot= FacSubTot + FacIva

18

Rules de la trn Facturas:

add(FacTotal, CliSdo);

call('pgmname', CliCod) IF After(Level(PrdCod)); INCORRECTA

call('pgmname', CliCod) IF After(trn); CORRECTA

Reglas que ocurren en el mismo evento

• EJEMPLO 1:

| call(' ') if After(Trn);| | call(' ') if After(Trn);v

• EJEMPLO 2:

| call('pgmname',&var1,&var2,&flag) if After(Confirm);| | error('xx') if After(Confirm) .and. &flag = 'N';v

–Si se invierte el orden de estas reglas, y la validación resulta negativa, el error no se dispara.

19

Eventos en una Transacción de dos niveles

FacId*FacFch ---------> AFTER (FacFch)CliCodCliNomCliSdoCliDir ------> | AFTER (CliDir)(PrdCod* | AFTER(CONFIRM).AND.LEVEL(FacId)PrdDsc | AFTER (INSERT|UPDATE|DELETE)FacLinCnt FacLinPrc PrdPrcPrdStkPrdStkMinimoFacLinImp) --> | AFTER (LEVEL(PrdCod))FacSubTotal | AFTER (TRN)FacIvaFacTotal

USO Y RECOMENDACIONES EN EL USO DE SUBTIPOS

20

USO DE SUBTIPOS

• Consideraciones generales.

– Las relaciones entre atributos GeneXus se establecen a través de los nombres de los mismos, por ello es importante asignarle igual nombre a aquellos que conceptualmente son lo mismo y diferentesa los que no lo son.

– Se dice que el atributo A es SUBTIPO del atributo B si se cumple una dependencia funcional, o sea para cada valor de A existe un solo valor de B y el valor de A es igual al valor de B.

CASOS TIPICOS DE UTILIZACION DE SUBTIPOS

21

A. Atributos conceptualmente iguales que cumplen roles diferentes.

RESERVAS CIUDADESResNro* CiuCod*CiuCod (orig) CiuNomCiuCod (dest)

RESERVAS CIUDADESResNro* CiuCod*CiuCodOri CiuNomCiuCodDes


• Con la definición de subtipos se establece la siguiente relación:

• Los atributos secundarios de Ciudades pertenecen a la tabla extendida de Reservas pero al existir doble referencia no se pueden utilizar directamente.Se utilizan mediante definición de “grupos de subtipos”.

RESERVAS CIUDADES

22

• Utilización de atributos secundarios del supertipo definiendo atributos subtipos dentro de un grupo

CiuCodOri CiuCod (Origen)CiuNomOri CiuNom (Origen)CiuCodDes CiuCod (Destino)CiuNomDes CiuNom (Destino)


Definición de Subtipos

23

B. Especialización de atributos• Se definen PrvNro y CliNro como subtipos

EMPRESAS PROVEED CLIENTESEmpNro* PrvNro* CliNro*EmpNom PrvSal CliSalEmpRucEmpTelEmpDir Proved.

Empresas Clientes

B. Especialización de atributos

CliNro subtype of EmpNro group ClienteCliNom subtype of EmpNom group Cliente

PrvNro subtype of EmpNro group ProvPrvNom subtype of EmpNom group Prov

24

C. Evitar controles de integridad referencial

Historico de Compras ProductosPrvCod* PrdCod*PrvNom PrdTxtPrdCod*PrdTxtHisCnt

Ordenes de Compra ProveedoresOrdCmpNro* PrvCod*PrvCod PrvNomPrdCod

Historico de Compras ProductosPrvCod* PrdCod*PrvNom PrdTxtPrdCod*PrdTxtHisCnt



25

PrvCod* PrvNomPrdHisCod* (Subtipo de PrdCod)PrdHisTxt (Subtipo de PrdTxt)HisCnt

OrdCmpNro* PrvCodPrdCod



Historico de Compras ProductosPrvCod* PrdCod*PrvNom PrdTxtPrdHisCod*PrdHisTxtHisCnt


26

TABLA EXTENDIDA- HERENCIA

• Subtipos Simples.Los subtipos heredan todos las propiedades del Supertipo.(ProvNro y CliNro son subtipos de EmpNro)EMPRESAS PROVEEDORES CLIENTESEmpNro* ProvNro* CliNro*EmpNom EmpNom EmpNomEmpRuc ProvSdo CliSdoEmpTelEmpDir

• En este ejemplo, EmpNom sólo va a estar almacenado en la tabla de empresas

TABLA EXTENDIDA-HERENCIA

• Subtipos múltiplesSECCIONESDptoCod* tabla DepartDptoNom(SeccCod* tabla SeccionSeccNom)

EXPEDIENTEExpNro* tabla ExpedDptoCodIni ST de DptoCodSeccCodIni ST de SeccCodDptoCodAct ST de DptoCodSeccCodAct ST de SeccCod

27


DptoCod*SeccCod*SeccNom

ExpNro*DptoCodIniSeccCodIniDptoCodActSeccCodAct


CONSIDERACIONES SI NO SE DEFINEN GRUPOS

• Cantidad innecesaria de índicesDptoCodIni SeccCodIniDptoCodAct SeccCodActDptoCodIni SeccCodActDptoCodAct SeccCodIni

• Necesidad de poner las reglas NoCheck y NoRead en los objetos GeneXus

28


DptoCodIni ST DptoCod group InicialSeccCodIni ST SeccCod group Inicial

DptoCodAct ST DptoCod group ActualSeccCodAct ST SeccCod group Actual

Se define relacion solo entre el grupo.Se definen solo los indices necesarios para definir los

grupos.


DptoCod*SeccCod*SeccNom

ExpNro*DptoCodIniSeccCodIniDptoCodActSeccCodAct

29

Consideraciones•El subtipo y supertipo serán definidos del mismo tipo, GeneXus lo determina así y cuando se quiere definir un subtipo este "hereda" la definición del supertipo.

•El supertipo debe ser identificador en alguna transacción o al menos algún atributo del grupo.

•Si al definir el grupo, uno de los atributos inferidos queda como secundario ( S ), es porque hubo un error en la definición del grupo.

•No es aconsejable incluir subtipo y supertipo en la misma transacción, ni tampoco en la misma tabla extendida.

•Los subtipos no pueden participar en la definición de Combo Box, ni Dynamic Combo Box.

Consideraciones

• No se pueden actualizar los subtipos inferidos (Add, Subtract) -

• No se pueden definir redundantes los subtipos inferidos -– Ejemplo: CiuNomOrig

• Se pueden definir subtipos de subtipos, pero no se infieren los subtipos de subtipos inferidos, sólo son válidos para los primarios.

– Ejemplo: CliNro subtype of EmpNro grupo ClienteCliNom subtype of EmpNom grupo Cliente

CliCred subtype of CliNro grupo CliCreNO SE PUEDE CliCredNom subtype of CliNom grupo CliCred

30

FORMULAS AGGREGATE SELECT

Consideraciones

• Las tablas involucradas en la fórmula son:– 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).

• No se pueden utilizar atributos de la tabla extendidade la Tabla de Llegada.

– En caso de ser necesario, la solución es definirse como redundantes (en la Tabla de Llegada) a dichos atributos.

31

Sintáxis:

ATT = FIND(<At de retorno>, <Condicion de búsqueda>, <Val.def>) if <Condición de disparo>

FUNCION FIND

FIND RECURSIVO

Se llaman finds recursivos a aquellos que para resolverse recorren la misma tabla sobre la que esta definida la fórmula.

EJEMPLO:

MovNro* MovFch BcoIdMovNroCheMovImpCheFndNroChe MovNroAux BcoIdAuxMovNroCheAuxMovFndOtroChe = Find(MovNro, BcoId= BcoIdAux .and.

MovNroChe = MovNroCheAux .and. MovNro<>MovNroAux, 0)

32

FIND RECURSIVO

Se llaman finds recursivos a aquellos que para resolverse recorren la misma tabla sobre la que esta definida la formula.

EJEMPLO:

MovNro* MovFch BcoIdMovNroCheMovImpCheFndNroChe MovNroAux = MovNroBcoIdAux = BcoIdMovNroCheAux = MovNroChe MovFndOtroChe = Find(MovNro, BcoId= BcoIdAux .and.

MovNroChe = MovNroCheAux .and. MovNro<>MovNroAux, 0)

Debido a que: al navegarla misma Tabla, sedeben cargar en otros atributos los valores delregistro de partida para poder efecturarla comparación en la búsqueda contra los valores delregistro de llegada.

PUNTOS A PRODUNDIZAR EN EL MANEJO DE WORK PANELS

33

DETERMINACION DE LA TABLA BASE DE UN WORK PANEL

• PANEL A PARTIR• EVENTOS DE LOS • REGLAS ATRIBUTOS

PANEL– TODO ATRIBUTO QUE INTERVENGA EN EL PANEL

EVENTOS– TODO ATRIBUTO QUE ESTE FUERA DE UN GRUPO FOR

EACH

REGLAS– TODO ATRIBUTO QUE ESTE EN UNA REGLA

» HIDDEN( )» ORDER( )

Trn ProductosProdId* Tabla: PRODUCTOProdDsc

Trn FacturasFacNro* Tabla: FACTURAFacFech

(FacLinNro* Tabla: FACTURA1ProdIdProdDsc FacLinCnt)

Ejemplo:

34

Work Panel de Selección de Productos

Rules parm(&V15 ) ;order(ProdId ) ; Event EnterConditions &V15 = ProdIdProdId >= &C15 ; ReturnProdDsc .LIKE. &C16 ; EndEvent

Work Panel de Selección de Productos

Parameters : &V15FOR EACH PRODUCTO

Order : ProdIdIndex : IPRODUCTNavigation filters:

Start from:ProdId >= &C15


Constraints:ProdDsc .LIKE. &C16

---->> PRODUCTO ( ProdId ) TABLA BASE PRODUCTOEND FOR

35

WORK PANELS SIN TABLA BASE

Ejemplo: Mostrar para cada cliente el total facturado, pero sólo de los clientes que tienen facturas.

Event Loadfor each CliIddefined by FacFch

&cli =CliNom&tot =0for each

&tot =&tot +FacTotal

endforload

endfor EndEvent

NAVEGACION WORK PANELSSIN TABLA BASEEVENT Load

FOR EACH FACTURAOrder : CliIdIndex : CLIFCHNavigation filters:



---->> FACTURA ( FacId )+-----> CLIENTES ( CliId )

BREAK FACTURAOrder : CliIdNavigation filters:

Loop while:CliId = CliId

---->> FACTURA ( FacId )END FOR

END FOREND EVENT

36

WORK PANELS SIN TABLA BASE

- Todas las navegaciones se deben hacer en forma explícita,utilizando comandos For Each dentro de los eventos.

- El EVENTO LOAD sucede una sola vez al Inicio.

- Se hace un Load All del subfile.

- El cambio de variables que esten en la parte fija del panel , asociadas a

Conditions no dispara Refresh.

•Todos los For Each que se encuentran en los eventosLOAD, ENTER y de USUARIO se anidan al for each de la tabla base.

•Los For Each que se encuentran en los eventos START, REFRESH y EXIT no se anidan al for each de la tablabase.

Corte de ControlPara determinar un corte de control en un work panel con tabla base el criterio del corte hay que establecerlocon la rule: order (att1,..,attn)

Consideraciones

37

WORK PANELS / INTEGRIDAD BASE DATOSWORK PANELS - PROCS

INSWKP PROCS UPD

DELIMPLEMENTACION MANUAL DE LOS

CONTROLES INTEGRIDAD

WORK PANELS - TRNINS

WKP TRN UPD DEL

IMPLEMENTACION AUTOMATICA DE LOS CONTROLES INTEGRIDAD (objeto-acción)

PUNTOS A PROFUNDIZAR EN REPORTES Y PROCEDIMIENTOS

38

Fórmulas en Procedimientos

• Fórmulas no redundantes– Se calculan en todos los objetos que se utilizan. En un

procedimiento, se calculan con el valor que tiene el registro el el momento de leerlo, no luego que se actualiza

• Fórmulas redundantes– No se actualizan. Hay que calcularlas y actualizarlas en forma

manual.

New en la misma tabla del For Each

• New siempre se ejecuta por la clave primaria – Por lo tanto si el new esta dentro de un For Each con la misma

tabla base del New hay que tener en cuenta el orden utilizado en el For Each.

• Tabla recorrida por dos ordenes diferentes sólo es inválido para generadores xbase .

• Inferencia: Atributos instanciados por el For Each y no instanciados especificamente en el New son inferidos para la inserción del registro.

39

New en la misma tabla de For EachTabla de Medicos Tabla de ConsultaMedCod* TurFch*MedNom TurCod*EspCod MedCod*EspDsc ConNro

Sustituira un medico por otroProgram Source for test------For Each

where MedCod = &medoridefined by ConNro

newMedCod = &medsus

endnewdelete

Endfor

New en la misma tabla de For EachFOR EACH CONSUL

Order : TurFch, TurCod , MedcodIndex : I00301Navigation filters:



Constraints: Medcod = &Medori

---->> CONSU: ( TurFch, TurCod , Medcod )¦+-----> T0001 ( Medcod )

NEW MEDICO ------- > NO ES LA TABLA DESEADAKey : Medcod

---->> +MEDICO ( Medcod )Insert into MEDICO : Medcod, MedNom

END NEWEND FOR

La Tabla Base del New se infiere sólo

por los atributos utilizados dentro

del New

40

New en la misma tabla de For Each

SOLUCION:

Program Source for test------For Each

where MedCod = &medoridefined by ConNro

&ConNro = ConNronew

MedCod = &medsusConNro = &ConNro

endnewdelete

Endfor


Una vez determinada la correcta tabla base indicamos que los atributos inferidos son:TurFch, TurCod.

ConNro y MedCod son nombrados explicitamente dentro del New.

FOR EACH CONSULOrder : TurFch, TurCod, MedcodIndex : I00301Navigation filters:



Constraints: Medcod = &Medori

---->> CONSUL ( TurFch, TurCod, Medcod )NEW CONSUL

Key : TurFch, TurCod, Medcod---->> +CONSUL ( TurFch, TurCod, Medcod )Insert into CONSUL :

TurFch, TurCod, Medcod, ConNroEND NEW

END FOR

41


• Dos ordenes distintos para la misma tablaResultado de la navegación en todos los generadores excepto en XBASE:

FOR EACH CONSULOrder : MedcodIndex : I00303Navigation filters:

Start from:Medcod = &Medori

Loop while:Medcod = &Medori

---->> CONSUL ( TurFch, TurCod , Medcod )

NEW CONSULKey : TurFch, TurCod, Medcod

---->> +CONSUL ( TurFch, TurCod, Medcod )Insert into CONSUL :

TurFch, TurCod, Medcod, ConNroEND NEW

END FOR


• Dos ordenes distintos para la misma tablaEN XBASE:Procedure Pcambia: cambia----------------------------------------------------------------

(x) The program will not be generated ***********************

Error: table CONSUL with two different ordersOutput device: NONE

FOR EACH CONSULOrder : MedcodIndex : I00303Navigation filters:

42

Restricciones en la Actualización• No se puede realizar ninguna actualización en

un For Each que recorre una tabla por índicetemporal

– En ese caso se debe construir el índice de usuario o elegir otro orden por un índice existente

• No se puede actualizar ningún atributo del índice que se esta utilizando en el For Each

• (XBase) Se pierde el puntero al actualizar atributos de un índice que se esta utilizando en el programa llamador.

For Each A B C For Each defined by C defined by Ccall(‘rprog2,A,&nuevo) B = & nuevo

Endfor Endfor

IMPACTO Y REORGANIZACION DE LA BASE DE DATOS

43

Impacto de la base de datos

• Impact Database

• Impact From

• Impact Objects

• Restore Model

Creación de la Base de datosTable FACTURA conversion procedure

----------------------------------------------------------------

FACTURA is new

Table Structure:

FacNro* N(3)

FacFch D(8)

Table FACTURA1 conversion procedure

----------------------------------------------------------------

FACTURA1 is new

Table Structure:

FacNro* N(3)

FacLinNro* N(2)

FacImpLin N(10.2)

44

Impacto de la Base de datos

Table FACTURA conversion procedure----------------------------------------------------------------

Table Structure:FacNro* FACTURA N(3)FacFch FACTURA D(8)CliCod (New) (Null) N(2)

Table CLIENTES conversion procedure----------------------------------------------------------------

CLIENTES is newTable Structure:

CliCod* N(2)CliNom C(20)

Casos particulares de reorganización

• Fórmulas que dejan de serlo.

• Sacar atributos de la llave.

• Indice contenido en otro.

Reorganizaciones en más de un paso para no perder los datos:

• Como cambiar un supertipo por un subtipo .• Agregar un atributo nuevo a la clave de una tabla.• Pasar un atributo del cabezal a las líneas.• Crear un atributo fórmula y definirlo redundante.

45

Reorganización en AS/400

• Se genera en PC y se transfiere al AS.

• Son 8 pasos con retoma

• Bloqueo de información

• Se genera SAVF• GXIMPDBR

• Data areas

Reorganización en PC/CS

• MENU y RMENU

• Setup Wizard (Exportación )

46

Recomendaciones finales

• Siempre antes de hacer una reorganización hacer un respaldo.

• GeneXus no borra las tablas con datos que deja de utilizar. Esto permite recuperar estos datos en el caso en que fuese necesario.

INTEGRIDAD TRANSACCIONAL Y

CONTROL DE CONCURRENCIA

47

Conceptos Teóricos

• Control de Concurrencia

• Tipos de Diálogo

– Conversacional

– Pseudo Conversacional

• Integridad Transaccional

• Unidad de Trabajo Lógico (UTL)

• Control de Concurrencia:– controles para evitar inconsistencias en

los datos cuando se trabaja en ambiente multiusuario

Conceptos Teóricos

48

• Diálogo Conversacional– Esquema:

1. aceptar datos

2. validar usando locks

3. pedir confirmación

4. actualizar la base de datos

5. liberar locks

Conceptos Teóricos

• Diálogo Pseudo Conversacional1. aceptar datos

2. validar

3. pedir confirmación

4. lockear los datos y validar que no hayan sido modificados

5. si los datos no cambiaron actualizar la BD y liberar los locks

6. sino informar al usuario que los datos fueron cambiados.

Conceptos Teóricos

49

• Integridad Transaccional

– Un conjunto de actualizaciones a la base de datos tiene integridad transaccional cuando en caso de una finalización anormal la base de datos permanece en estado consistente.

Conceptos Teóricos

• Unidad de Trabajo Lógica (UTL)

– Conjunto de operaciones a la base de datos que deben ejecutarse todas o ninguna de ellas.

- El DBMS mantiene la integridad transaccional y los programas indican el comienzo y fin de la UTL.

Conceptos Teóricos

50

• Control de Concurrencia– Locks

– Ambiente Client/Server

– Ambiente Centralizado

• UTL• Integridad Transaccional

Enfoque GeneXus

• ¿Cómo funcionan los locks en GeneXus?

• Solo Lectura: no lockea ni es afectado por los locks de los otros programas, salvo con los locks exclusivos.

• Lectura/Escritura: lockea y es afectado por los locks de otros programas.

Control de Concurrencia

51

• Consideraciones por DBMS en la lectura:

– AS/400, DB2/400 y SQL Server: leen la última información grabada y no commiteada

– Informix y DB2/Common Servers: los programas no ven los cambios efectuados por otros usuarios quedando lockeados hasta que se realice un commit (read committed).

– Oracle: lee los últimos datos commiteados.

Control de Concurrencia

Preferences del Modelo

–Pseudo Conversational Dialog

–Lock Mode

– Isolation Level

Concurrencia en Client/Server

52

• Pseudo Conversational Dialog

• Valores:

–Use Conversational Dialog

–Check Updated Tables only (*)

–Check all accessed tables


Co

nv

er

sa

ci

on

al

Grabar BD

Eventos AfterIns/Upd/Del

Commit

EventoAfter(confirm)

PedirConfirmación

Validardatos

ObtenerDatos

Confirma?Evento

After(TRN)

Deslockear

Lockear

Tipos de Diálogo

53

•

Pseud

o Co

nvers

acion

al

Grabar BD

Eventos AfterIns/Upd/Del

Commit

Validar cambios

EventoAfter(confirm)

PedirConfirmación

Validardatos

ObtenerDatos

Confirma?

No hubo cambios?

EventoAfter(TRN)

Deslockear

Lockear

Tipos de Diálogo

• Preference Lock Mode

• Valores:– Do not specify lock level (*)

– Use page level locking

– Use row level locking

• Válida solo para Informix


54

• Preference Isolation Level

• Valores:– Read Committed (*)

– Read Uncommited

• Válida para todos los DBMSs excepto Oracle y SQL Server


• Caso Particular: Locks en SQL Server

– SQL Server 6.5

• Lockeo a página en update

• Lockeo a registro en insert configurable

–store procedure: sp_tableoptions

– SQL Server 7.0

• Es posible lockear a registro en insert y update

• Lock Dinámico


55

• ¿Qué sucede cuando un programa que actualiza la BD encuentra un registro lockeado?


TransaccionesCuando expira el time-out despliega un mensaje indicando que el registro esta siendo usado por otro usuario. El usuario puede reintentar la operación.

En SQL Server no se despliega mensaje y queda esperando indefinidamente hasta que se libera el registro.

• ¿Qué sucede cuando un programa que actualiza la BD encuentra un registro lockeado?


Procedimientos

Se intenta indefinidamente la operación hasta que se libera el registro. No despliega mensaje.

56

– Comportamiento en cada DBMS:• Oracle e Informix: instantáneo

• SQL Server: espera indefinidamente

• DB2/Common Servers: configurable para la base de datos

• DB2/400: configurable por tabla.

- Time-outDesde GeneXus no es posible configurarlo


• Preference Pseudo Conversational Dialog

Valores:– Use Conversational Dialog

– Check Updated Tables only (*)– Check all accessed tables

• Access lockea a página siempre– 256 bytes, no configurable

Concurrencia en Access

57

• UTL en Transacciones

– Por defecto se define el alcance de la UTL como toda la transacción

• UTL en Procedimientos

– Por defecto se define el alcance de la UTL como toda el programa.

• Comandos– Commit

– Rollback

UTL en GeneXus

• Preference del Modelo– Transactional Integrity

• Properties de los objetos:– Commitment

– Commit on Exit

– Confirm Transaction

Integridad Transaccional

58

Integridad Transaccional en Client/Server

• Transactional Integrity• Yes (*)

• No

• File Views • siempre tienen IT o no depedendiendo del valor de

la preference

• Transactional Integrity = No• DB2/400 e Informix desactivan la IT

• El resto de los DBMSs entran en modo autocommit

• Base de datos centralizadas• Todas las tablas en el servidor

• El DBMS asegura la IT

• Base de datos distribuidas• Tablas locales y tablas en el servidor

• No se tiene IT en las tablas locales


59

• Base de datos Informix– ANSI

• Siempre se trabaja con IT independientemente del valor de la preference Transactional Integrity

– Buffered Logged• Se trabaja con IT dependiendo del valor de la preference

Transactional Integrity, excepto en la reorganización donde no tendrá IT

– Not Logged• No se trabaja con IT independientemente del valor de la

preference Transactional Integrity


• Properties de los objetos:

–Commitment

–Commit on Exit

–Confirm Transaction

Integridad Transaccional

60

• Commitment– Valores:

• Enabled (*)

• Disabled

• Consideraciones– Válida solo en AS/400

Integridad Transaccional Object Properties

• Ejemplo property Commitment

Commitment=Disabled

Facturas NumeradorIf insert and after(confirm) Tabla

Numeradores

TablaFacturas


61

• Commit on Exit– Valores:

• Yes (*)

• No

• Consideraciones– No es válida si tiene Commitment = Disabled


COMMIT

• Ejemplo property Commit on Exit

Facturas ClienteRefcall(Tcliente, CliCod‘INS’)

Commit on Exit = No

TablaFacturas

TablaClientes


62

• Confirm Transaction– Valores:

• Yes

• No (*)

• Consideraciones– Es válida si tiene

Commitment = Enabled y

Commit on Exit = Yes


DEFINICION Y MANTENIMIENTO DE REDUNDANCIAS

63

Definición de Redundancias

• Redundancia Referencial– Para definición de índices de usuario– Por límites en la definición de una fórmula Aggregate/Select

• Redundancia por Fórmulas – Por optimización de performance en el cálculo de fórmulas

verticales

Mantenimiento de Redundancias

• GeneXus mantiene automáticamente las redundancias definidas

- Transacciones que definen la tabla. Se llama a un programa GXUnnn

• GeneXus genera programas para reconstruir las redundancias a través de:

– La ejecución del Redundancy Load Program Utility(GXLRED)

64

Redundancy load Utility

• Se genera un programa, GXLRED (GeneXus Load Redundancy) que recalcula todas las fórmulas redundantes y las actualiza junto con las redundancias referenciales.

• El programa GXLRED llama a un programa independiente para cada tabla que recalcula todas las redundancias de la tabla.

• Estos programas se pueden llamar en forma independiente o ejecutando el GXLRED.

• En el reporte del análisis de impacto se puede vercual es el programa que calcula las redundancias para una determinada tabla

– El nombre va a ser GXRnn donde nn el número de la tabla:Table Factur load redundancy procedure--------------------------------------------------Redundant attributes: FacTotalProcedure name: GXR24

Redundancy load Utility

65

Mantenimiento a través de Transacciones

• Toda transacción que defina una tabla cuyos atributos secundarios estan definidos redundantes en otras tablas llamará a un programa para actualizar las redundancias

• Programas son creados en las reorganizaciones– GXUnnn donde nnn es el número de tabla

• Actualizan la redundancia de un registro de la tabla. Reciben como parámetro la clave de la tabla.

Consideraciones

• Las fórmulas Aggregate Select no se pueden definir como redundantes (ni ninguna fórmula que dependa de una Aggregate Select).

• Los subtipos no se pueden definir redundantes.• En general, para poder definir como redundante un

atributo que es att= Fórmula1(Fórmula2) => debe definirse primero la redundancia para Fórmula2 para recién después poder definir como redundante att.

• Para cambiar una fórmula redundante primero hay que hacer el UNDO de la redundancia.

66

EFICIENCIA Y PERFORMANCE DE LAS APLICACIONES

Tips de optimización• New con When duplicate vs. For each con New.New &Existe=‘N’

Cliente=X For each Saldo =Y Where Cliente=X

When duplicate Saldo=YFor each &Existe=‘S’

Saldo=Y EndforEndfor If &Existe=‘N’

Endnew NewCliente=XSaldo= Y

EndnewEndif

67

Tips de optimización

• Utilización del operador LIKE

En AS/400 con índice temporal es el mejor caso(OPNQRYF).

En PC no importa si existe o no el índice, siempre se usa eloperador $.

En C/S lo resuelve el DBMS sobre el índice si existe y sinolo crea.

Tips de optimización

• Las funciones no se optimizan.For each order Fechawhere Fecha=Today()

…….endfor

For each order Fechawhere Fecha=&today

…….endfor

68

ARQUITECTURA DE MULTIPLES CAPAS

Varios generadores por modelo

• Generadores del Modelo

• Generador por Objeto

• Generador C/SQL

69

Generadores del Modelo• Generador para la Reorg. (el que existía )

– Usado para creación y reorganización de la base de datos.

– File/Edit Model/Generator

• Generador por Default para los objetos– En un principio coincide con el de la Reorg.,

pudiéndose elegir otro.– File/Edit Model/Tab de “Generators”

• Generadores secundarios– File/Edit Model/Tab de “Generators”

• Se controlan combinaciones válidas

Generador por Objeto

• Definir en cada objeto Main el generador a utilizar.– Opción: Information/Tab de Options/Generator

70

Cómo decide GX el generador para cada objeto ?

• Objetos Main– Por defecto se generan con el generador Default.

– Si se quiere generar con otro generador:• Information/Tab de Options/Generator

• Objetos no Main– Se utilizan los generadores de los objetos Main que

lo llamen (directa o indirectamente).

• Object /Information/Options/Generated for

Cuando se generan Call externos? • Cuando un objeto X llama a un objeto Y, se

asume que ambos se encuentran en el mismo generador. Sin embargo, si el objeto Y es Main

se asume que se debe llamar a un programa externo.

• Dos casos:– X y Y en el mismo ambiente

se genera un llamado externo LOCAL

– X y Y en distinto ambiente

se genera el RPC (Remote Procedure Call) necesario

71

INTRODUCCION A INTRODUCCION A CLIENT/SERVERCLIENT/SERVER

Qué esQué es C/S ? C/S ?

El concepto de Client/Server se refiere a una distribución de procesos: el proceso cliente y el proceso servidor, que se conectan mediante algún método de comunicación entre procesos.

Es decir, se realiza una distribución de procesos y de datos, con el fin de optimizar el uso de los recursos de un determinado sistema.

72

TiposTipos de Client/ Serverde Client/ Server

–Client / File Server.

–Client / Database Server.

73

Client / File ServerClient / File Server

Red

FILE /SERVER

Server

Archivos

ClientesServidorde Datos

Client / Database ServerClient / Database Server

Red

Server

Data Base

Servidorde Base de Datos* Datos* Lógica

Clientes

74

Arquitectura Client / Database Server

• Disminuye fuertemente el tránsito en la red, en comparación con Client / File Server.

• Permite mantener una integridad transaccional completa.

Qué obtienen los usuarios GXde Client/Server ?

• Acceso a última tecnología sin necesidad de incurrir en altos costos de entrenamiento

• Plataformas y bases de datos:

• Uso de PC’s para bajar los requerimientos del procesador central

Oracle Múltiples plataformas (Unix,Windows, Novell, etc.).

SQL Server Windows NT y Alpha

DB2 CommonServers

Múltiples plataformas (Unix,Windows, etc.)

DB2/400 AS/400

Informix Múltiples plataformas (Unix,Windows, etc.)

75

Model Properties

• Tables in Server

• Local Tables

• Connect to Server

• Data Source Name

Consideraciones para GX C/S•Preference para que las consultas se resuelvan en el Server.

•Outer Join -> Es posible generar con Outer Join para: Oracle, DB2/400, DB2 Common Servers e Informix.

•Grupo de Preferences: “Optimization”:•Delete groups•Aggregate groups•Copy Table groupsDisponible en C/S VB, C/S Foxpro, C/SQL y Java.

•Condiciones conectadas con OR pueden ser optimizadas por el DBMS (UNION).

•Es posible ordenar por atributo de la tabla extendida.

76

INTRODUCCION A INTRODUCCION A PAGINAS WEBSPAGINAS WEBS

Web

• Páginas gráficas con hipertexto• Dos tipos fundamentales:

– Páginas estáticasHTML standard.Generación con algunas herramientas.

– Páginas dinámicasGeneXusASP···

77

Web - Páginas Estáticas • Información general• Marketing• Información similar a la que se distribuye en

folletos y documentos• Acceso rápido y cómodo a información• Direcciones de correo electrónico para

información y soporte• Mantención de alto costo• Sin valor agregado

Web - Páginas Dinámicas

• Interactivas: Comunicación de ida y vuelta

• Interactúan con la base de datos (Access, Oracle, DB2, Informix, SQL Server)

• Actualización automática en GeneXus

• Entregan información según el requerimiento

• Elementos técnicos diferenciadores

78

Páginas Dinámicas - Ejemplos

• Home Banking

• Divulgación de información (con y sin costo)

• Comunicación con proveedores

• Intranet (Información dentro de la empresa)

• Intercambio de datos y documentos

• VENTA DIRECTA

Páginas Estáticas y Dinámicas

Páginas Páginas EstáticasEstáticas

PáginasPáginasDinámicasDinámicas

Web Page EditorsWeb Page Editors GeneXusGeneXus

WWW WWW -- World Wide WebsWorld Wide Webs

79

protocol://host/path/filename[?parm1,…,[parmn]]protocol:

Especifica el protocolo de acceso. Ejemplos: file, ftp, http, telnet

host:Nombre del host al cual deseamos conectarnos.Ejemplo: www.artech.com.uy

path/filename:Ubicación y nombre del documento en el servidor

[parm1,...,[parmn]]Información opcional para consultas

URL

Protocolo HTTP

Conexión/Solicitud

Respuesta/Cierre

80

<HTML><HEAD><TITLE>Esta es mi primera página</TITLE></HEAD><BODY>Esto muestra de una forma muy <I>simple</I>,la estructura básica de un documento HTML.</BODY></HTML>

HTML

81

Respues

tade

l

Progra

maCGI

CGI

Browser WWW(cliente)

Servidor

APLICACION

Someter un form

Call C

GI

��

�FORM

Respuesta delPrograma CGI

INTERNET

Cliente : BROWSER

NetScape, MS Internet Explorer

Servidor : WEB SERVER

Microsoft Internet Information Server

Netscape Server

LinksPáginasHTML

82

Web Browser

TopologíaTopología

ServidorServidor WebWebWindows NTWindows NTUNIXUNIXAS 400AS 400

ServidorServidor de de Base de Base de DatosDatosDB2, Informix, DB2, Informix, Microsoft SQL Server, Microsoft SQL Server, Oracle, AccessOracle, Access

Intranet

Internet

Web Browser

Web Servers

• Windows NT– Microsoft Internet

Information Server

– Netscape

• UNIX– Netscape

– Oracle

• AS/400– IBM

• Windows 95– WebSite Professional

– Fnord

– Personal Web Server (FrontPage 97 y 98)

83

WEB PANELS

• Interacción con la Base de Datos

• Interfase similar a Work Panel

• Desarrollo Inmediato

• Mantención bajo el mismo esquema de una aplicación tradicional GeneXus

Web Panels VS. Work Panels• El evento ENTER es el único al que se le puede

asignar un botón y en él las variables cuyos valores ingresó el usuario son transferidas al programa

• No pueden asignarse teclas de función a eventos

• El evento Refresh y Exit no están implementados

• La ergonometría puede ser diferente

84

Web Panels VS. Work Panels

• Algunas propiedades deben setearse desde código

• Algunas propiedades de objetos no están implementadas o no funcionan

• El display final no corresponde necesariamente con el de diseño

• No se han implementado todos los controles de Windows

• El tamaño de pantalla no está limitado a una resolución en particular

Web Panels VS. Work Panels

• Siempre se hace loadAll– Se puede programar paginación a pedido

• No pueden realizarse llamadas a programas que tengan salida: De un Web Panel solamente puede llamarse a otro Web Panel o a un Procedimiento que no tenga salida.– Tener en cuenta que el programa se está

ejecutando en el servidor !

85

Web panel

Web panel con subfile

86

Son permitidos call’s a (botones y eventos):

• Otros Web Panels o a sí mismo• Procedimientos

Son permitidos link’s a (Subfiles y labels):

• Web Panels• Páginas HTML estáticas

Algunas características de losWeb panels

Código embebido:

• HtmlEj.:Event Start

&FORMATO='<Font face=Arial Size="2" Color="#000000"> <Strong>'

&codcsw=concat(&formato, codssw,'')EndEvent

Permite modificar aspecto de controles del Web panel, cuando no se pueda hacer directamente con GeneXus.

87

• JavaScript

Ej.:Event Start

&c=‘<Script lenguage=“JavaScript”> alert(“Bienvenido a nuestra página Web”)</script>’

mensaje.caption=&c

EndEvent

Permite realizar acciones sobre el browser, cuando no se pueda hacer directamente con GeneXus.

Código embebido:

Seguridad

• ¿Es segura mi aplicación en Internet?– ¿es segura la comunicación en Internet?

– ¿quién puede acceder a mi base de datos?

– ¿quién puede acceder a mi aplicación?

88

Seguridad a nivel de Web Server

• Criptografía

• Solución: servidores seguros

Seguridad a Nivel de DBMS

• Como en cualquier aplicación desarrollada con GeneXus

• Dos esquemas de validación:– Sistema operativo

– DBMS

DBMS

89

Seguridad a Nivel de Aplicación

Generación de sesión

Ingreso de usuario

Login Registro

Sesión, cliente

Operación

Sesión, cliente

Validación

Sesión, cliente

Generadores - Servidores

DBMSVB Access, Oracle, MS SQL Server, Informix, DB2 (NT, RS/6000, OS/2)C/SQL Oracle, MS SQL Server, DB2/6000RPG AS/400

Windows NT UNIX AS/400C/SQL X

VB X XRPG X X

90

Requerimientos (Visual Basic)•• Servidor Windows 95, NT 3.5 o NT 4.0Servidor Windows 95, NT 3.5 o NT 4.0

– WEB Server– Visual Basic 4.0 32 bits en adelante– Webifce.dll (sólo VB 4.0)

•• Cliente desarrollo Cliente desarrollo GeneXusGeneXus– Visual Basic 32 bits en adelante– Web Browser

•• RED TCP/IPRED TCP/IP

Requerimientos (VB C/S)

• Definir Data Source

• GXCS.INI

• Cliente de Base de datos

• .dll’s Cliente Servidor

• Controles básicos VB (OCX’s).

91

Configuración del Modelo GeneXus

MODEL –PROPERTIES–PREFERENCES–EXECUTION

Model PropertiesModel Properties

92

Model Properties:Model Properties:EXECUTEEXECUTE (VB)(VB)

Model Properties:Model Properties:PREFERENCESPREFERENCES

• GENERAL– VISUAL BASIC VERSION: 4.0 (32 BITS)

• WEB INFORMATION– PROTOCOL SPECIFICATION (sólo para

VB y C/SQL)

• CLIENT SERVER INFORMATION– Connect to Server

– Data Base Name

– Data Source Name

Getting Started with GeneXus 8.0

November, 2003

MONTEVIDEO – URUGUAY Av. 18 de Julio 1645 P.4 - (5982) 402 2082CHICAGO – USA 400 N. Michigan Ave. Suite 1600 - (312) 836 9152MEXICO CITY – MEXICO Mariano Escobedo 353 A Of. 701 - (5255) 5255 4733SAO PAULO – BRAZIL Rua Samuel Morse 120 Conj. 141 - (5511) 5502 6722

Getting Started with GeneXus

Copyright © ARTech Consultores S. R. L. 1988-2003. All rights reserved. This document may not be reproduced in any form without the express permission of ARTech Consultores S.R.L. The information contained herein is intended for personal use only. TRADEMARKS ARTech GeneXus are trademarks or registered trademarks of ARTech Consultores S.R.L. All other trademarks mentioned herein are property of their respective owners.

Page 2 of 47


Content Introduction .................................................................................................................... 4

Objectives .................................................................................................................... 4 System Requirements....................................................................................................... 4

Generator Requirements ................................................................................................ 5 Trial Version Limitations.................................................................................................... 6 Installation and Setup....................................................................................................... 7

Setup Wizard ................................................................................................................ 7 Trial Version Authorization................................................................................................. 9 Getting Started Step by Step ............................................................................................10

Step 1: Creating a Knowledge Base................................................................................10 Step 2: Creating an Object in GeneXus...........................................................................10 Step 3: Defining Attributes for the Object Transaction Invoice............................................11 Step 4: Viewing the Completed Objects Form ..................................................................12 Step 5: Defining Formulas in GeneXus............................................................................13 Step 6: Inserting a Business Rule ..................................................................................15 Step 7: Reviewing the Database after Creating the Invoice Object......................................16 Step 8: Creating a Customer Object...............................................................................18 Step 9: Viewing Table Structure Changes........................................................................19 Step 10: Prototyping your Application in Visual Basic with Microsoft Access..........................20 Step 11: Viewing the Database Creation Report ...............................................................22 Step 12: Creating the Tables with the Database Manager..................................................23 Step 13: Specifying and Generating your Code ................................................................24 Step 14: Running your Application .................................................................................26 Step 15: Adding New Objects to your Project: Item Transaction.........................................27 Step 16: Viewing Table Structure Changes......................................................................29 Step 17: Impacting the Database ..................................................................................29 Step 18: Refactoring the Data and Generating the Programs .............................................30 Step 19: Running your Application .................................................................................32 Step 20: Creating a Report & Making a Call to It ..............................................................32 Step 21: Specifying and Running your Application............................................................36 How to Move your Application to .NET and JAVA ...............................................................38 Step 1: Deploying your Application to .NET with Microsoft SQL Server.................................38 Step 2: Viewing the .NET Application Running .................................................................42 Step 3: Deploying your Application to Java with Microsoft SQL Server .................................42 Step 4: Viewing the JAVA Application Running .................................................................46

Online Resources ............................................................................................................47 GeneXus Community ....................................................................................................47 Support ......................................................................................................................47 How to Buy .................................................................................................................47

Page 3 of 47


Introduction

Objectives The objectives of this document are that you:

• Discover the power of knowledge-based development • Experience the key features of GeneXus:

o Knowledge-based design o Automatic code generation o Automatic database and code maintenance o Multi-platform deployment

System Requirements GeneXus Trial includes the following products: • Development Environment

It is an Integrated Development Environment (IDE) for designing and prototyping your applications, regardless of the production platform.

• Generators GeneXus generates native code for the leading platforms. The generators available are the following:

• .NET • Java • Visual Basic

Below is a list of the hardware and software you will need in order to run GeneXus and the applications generated by it.

Processor: 500 MHz Intel Pentium class

Memory: at least 64 MB of RAM (256 MB recommended)

Hard disk: at least 50 MB of free disk space to install the Development Environment, plus an average of 10 MB for each generator. To create GeneXus applications you will need additional space or a shared disk to create the Knowledge Bases.

Hardware Requirements

Video: 800 x 600 resolution or higher, with 256 colors

Microsoft Windows 98 or higher. If you are using Windows NT, you must install service pack 6.0 or higher

Microsoft .NET Framework 1.1 Redistributable Package 1

Software Requirements

Microsoft Internet Explorer 6.0 SP1 or higher

1 The .NET Framework 1.1 Redistributable Package can be downloaded from Microsoft’s website: http://msdn.microsoft.com/library/default.asp?url=/downloads/list/netdevframework.asp. It can also be downloaded from the Download Center at GXTechnical website: http://www.gxtechnical.com/main/hdcenter.aspx?2,5,36,1035

Page 4 of 47

http://msdn.microsoft.com/library/default.asp?url=/downloads/list/netdevframework.asp

http://www.gxtechnical.com/main/hdcenter.aspx?2,5,36,1035


Generator Requirements This section contains the requirements to generate and execute applications with the different GeneXus generators:

Generator Requirements .NET

• Microsoft .NET Framework 1.1 Redistributable Package 2 • For generating Web interface applications you will need IIS 5.0 or higher

(available on Windows 2000 or XP) • For generating Windows interface applications or printing PDF reports,

you will need Visual J# Distribution Package 1.1 3 • ODBC Driver for the DBMS used

Java • Sun and/or Microsoft JDK (we recommend having both) • For generating Web interface applications:

o Web Server o Servlet Engine o JavaServer Web Development Kit

• For generating 3-tier Windows interface applications: o HTTP: you will need a Web server and a servlet engine o CORBA: you will need Visibroker

• JDBC Driver for the DBMS used Visual Basic • Microsoft Visual Studio 6.0, with Service Pack 5 or higher

• MDAC 2.6 or higher • If you use Sheridan Data Widgets, you will need version 3.0 or higher

installed • ODBC Driver for the DBMS used (except if you are working with Microsoft

Access) In addition, to create the database and execute the generated applications, you must have some of the following DBMSs installed:

Generator DBMS .NET Java

• DB2 Universal Database • DB2 UDB for iSeries • Informix • Oracle • PostgreSQL • SQL Server

Visual Basic • Access • DB2 Universal Database • DB2 UDB for iSeries • Informix • Oracle • PostgreSQL • SQL Server

2 The .NET Framework 1.1 Redistributable Package can be downloaded from Microsoft’s website: http://msdn.microsoft.com/library/default.asp?url=/downloads/list/netdevframework.asp. It can also be downloaded from the Download Center at GXTechnical website: http://www.gxtechnical.com/main/hdcenter.aspx?2,5,36,1035 3 You can obtain Visual J# Distribution Package 1.1 from Microsoft’s website: http://msdn.microsoft.com/vjsharp/downloads/howtoget/default.aspx

Page 5 of 47

http://msdn.microsoft.com/library/default.asp?url=/downloads/list/netdevframework.asp

http://www.gxtechnical.com/main/hdcenter.aspx?2,5,36,1035

http://msdn.microsoft.com/vjsharp/downloads/howtoget/default.aspx


Trial Version Limitations Although the license is Unlimited, and all the generators installed remain authorized with a unique Site Key, some restrictions apply to the number of objects: Transactions: 30; Work Panels (included the GeneXus selection prompts): 50; Web Panels (included the GeneXus selection prompts): 50; Procedures: 20; Reports: 20. It is not possible to open a knowledge base developed with GeneXus standard version from GeneXus Trial or vice versa. GeneXus Trial installation is local and single-user (there is no network installation). It does not include the Knowledge Manager's "Distribution" options. Xpz GeneXus standard versions can be consolidated (provided they do not exceed the previously mentioned limits) but they cannot be distributed. Support for GeneXus Trial is limited. If you have any doubts or problems –about version installation and activation only–, please send an e-mail to [email protected]. For any additional information, we recommend contacting your local distributor (www.genexus.com/distributors).

Page 6 of 47

mailto:[email protected]

http://www.genexus.com/distributors


Installation and Setup This section explains how to use the Setup program to install GeneXus Trial on a computer. The Setup program includes a wizard to help you make the correct choices. To start the GeneXus Setup program: 1. Start Windows. 2. Run GeneXus Trial Setup. 3. Follow the Setup Wizard instructions to install the selected products (Development

Environment and Generators).

Setup Wizard The first screen you will come across is the setup wizard welcome screen: click Next if you wish to continue with the installation. The following screen is a License agreement that you should read carefully before continuing to the next one. After selecting the I accept the License Agreement option and clicking Next, the following dialog asks you to register your name and company name. Once you have entered that information, click Next to display the following dialog box:

Figure 1 Setup wizard for GeneXus Trial

In this dialog you select the destination folder where GeneXus will be installed (a directory called gxw80Trial is suggested). By clicking the Browse button you will be able to change the default one. Click Next to go to this dialog:

Page 7 of 47


Figure 2 Product selection dialog box

Once you have selected the destination folder, you will be asked for the products you want to install (i.e. Development Environment and the different Generators). Then, click Next to begin the installation. After all the files you need have been copied to your system, the Setup program places GeneXus icons in a GeneXus group that will be automatically incorporated to your Program Manager's window.

Page 8 of 47


Trial Version Authorization This is a detailed description of the steps to authorize GeneXus: 1. Execute GeneXus 8.0 Trial Version from the desktop shortcut for GeneXus 8.0 or from the

programs menu. 2. Copy the Site Code:

Figure 3 Registration dialog box

3. In order to activate the GeneXus Trial version, go to www.genexus.com/trial/authorize and

enter the Site Code obtained in step 2. Then, click Submit to have the activation key generated and sent to your e-mail address.

4. After receiving the activation key, proceed with the product activation. Then you will be able to

start using GeneXus Trial.

Page 9 of 47

http://www.genexus.com/trial/authorize


Getting Started Step by Step The objective of this Getting Started guide is to help you easily evaluate GeneXus and test its functionality. We have created a step-by-step process for you to create a small project that is a simplification of a company’s reality. In this example you will create an Invoicing System and have the possibility to prototype in three different platforms: Visual Basic, .NET and JAVA. Although it covers the whole cycle of a standard process, this process is a simplified version that shows you the power of GeneXus and how easy it is to create applications and migrate them to new platforms. Step 1: Creating a Knowledge Base 1. On the File menu, click New

Knowledge Base. 2. Name the Knowledge Base “Demo”

and click OK to continue.

Figure 4 New Knowledge Base creation

Step 2: Creating an Object in GeneXus 1. On the Object

menu, click New Object.

2. Select the type of

object that you want to create: Transaction.

3. Name the Object:

“Invoice”.

Figure 5 Object creation dialog box

Page 10 of 47


Step 3: Defining Attributes for the Object Transaction Invoice

1. Type the attribute characteristics (name, type and description) on the Invoice Structure tab based on the following table.

2. Use the TAB button to move between the attribute name, type and description. Use the ENTER button to add a new attribute.

ATTRIBUTE TYPE DESCRIPTION InvoiceId Numeric(3,0) Invoice InvoiceDate Date Invoice Date CustomerId Numeric(5,0) Customer CustomerNm Character(30) Customer Name Now Press CTRL + “L” ItemId Numeric(5,0) Item ItemDsc Character(15) Item Description ItemPrice Numeric(7,2) Item Price ItemQty Numeric(3,0) Item Quantity ItemLnTot Numeric(7,2) Line Total Now Press ENTER, and then CTRL + LEFT InvoiceSubTot Numeric(7,2) Invoice Sub Total InvoiceTax Numeric(5,2) Invoice Tax InvoiceTotal Numeric(7,2) Invoice Total

3. After entering the attributes, click Save . Now you have created the structure of an Invoice transaction composed by two levels; the Invoice Header where we specified all the information necessary for the Header of the Invoice, and the Invoice Detail where we specify the information that will be repeated for every invoice line. The brackets indicate that for each Invoice Header there are many Lines or Invoice Detail. Every group of attributes between brackets belongs to a transaction LEVEL. Transactions can have many levels, and these levels may be nested or parallel.

Figure 6 Invoice structure

Invoice Detail

Invoice Header

Page 11 of 47


Step 4: Viewing the Completed Objects Form Once all the attributes have been defined and saved, your object form will look as follows: 1. Select the Form tab of the transaction.

Figure 7 Transaction form tab

When defining a Transaction, a default Form is automatically created by GeneXus to specify the way the end user will access data in Windows applications. This form can be changed by the developer.

Page 12 of 47


2. Select the Web Form tab of the transaction.

Figure 8 Transaction web form tab

When defining a Transaction, a default Web Form is automatically created by GeneXus to specify the way the end user will access data in Web applications. This Web Form is based on a default Theme object, which is a new object introduced in the latest GeneXus version. The Theme object improves the development and maintenance of Web applications by separating the developer’s work from the designer’s.

Step 5: Defining Formulas in GeneXus Now let’s define some calculated fields. You do this by defining formulas. • In this example we will make the following formulas:

o ItemLnTot = ItemPrice * ItemQty o InvoiceSubTot = SUM(ItemLnTot) o InvoiceTax = InvoiceSubTot * .085 4 o InvoiceTotal = InvoiceSubTot + InvoiceTax

4 Note: Most likely you will want to read the tax % from a table, but in this example we will just hardcode the tax % for simplicity.

Page 13 of 47


1. Choose the Line Total attribute (ItemLnTot) and double-click the Formula field. 2. Write the following expression: “ItemPrice * ItemQty”.

Figure 9 Transaction formula

3. Repeat Steps 1 and 2 for the other three formulas.

Figure 10 More Transaction formulas

Page 14 of 47


Step 6: Inserting a Business Rule In this case we want to have the Invoice Date defaulted to Today’s date. 1. Select the

Rules tab.

Figure 11 Rules tab

2. On the Insert menu, click Rule. 3. Select the Default rule that assigns

a default value to an attribute or variable.

4. Write down the following:

”Default(InvoiceDate, today());” which indicates that the default value for the invoice Date will be today’s date.

5. Click Save.

Figure 12 Transaction rule

Page 15 of 47


Step 7: Reviewing the Database after Creating the Invoice Object 1. On the Tools menu, click List Database.

2. Clear the Modified check box. 3. In the Select Object dialog box, click Select All and then click OK.

Figure 13 Select Object dialog box

Page 16 of 47


Figure 14 Impact Analysis Report

You can see that GeneXus automatically normalizes the tables, and creates two tables to support the Invoice object, Header & Detail: Table Invoice and Table Invoice1 (marked in the image above), with the following structure:

<Invoice> InvoiceId InvoiceDate CustomerId CustomerNm

<Invoice1> InvoiceId ItemId ItemDsc ItemPrice ItemQty

In addition, you will see that GeneXus automatically removes from the tables those attributes that we made as formulas, and makes them global formulas so you can access them automatically anywhere. Note: From the Menu: Advanced \ Table you can change a table name, add new indexes, or define redundancies.

Page 17 of 47


Step 8: Creating a Customer Object To create the Customer Transaction follow Steps 2 and 3. The following attributes will be inserted in the Customer Transaction Structure:

ATTRIBUTE TYPE DESCRIPTION CustomerId --------- -------------------- CustomerNm --------- -------------------- CustomerAddress Character(30) Customer Address CustomerEmail Character(50) Customer Email

Note that when you press the “Save” button GeneXus will ask the attribute definition for the CustomerAddress and the CustomerEmail. That is because the CustomerName and CustomerId were defined before.

After you have added a new Customer object and inserted the attributes into the structure, the Customer object will be created and its Structure and Forms will look as follows:

Figure 15 Customer transaction structure

Page 18 of 47


Figure 16 Customer transaction Win form

Figure 17 Customer transaction Web form

Step 9: Viewing Table Structure Changes By reviewing the Database (Step 7) after the Customer Object was created you can see that GeneXus has automatically normalized the tables for you. You will see that GeneXus automatically moved the CustomerNm and CustomerAddress attributes from the Invoice table to the Customer Table.

Figure 18 Customer table structure

Page 19 of 47


Figure 19 Invoice table structure

The database structure is now the following:

<Invoice> InvoiceId InvoiceDate CustomerId

<Invoice1> InvoiceId ItemId ItemDsc ItemPrice ItemQty

<Customer> CustomerId CustomerNm CustomerAddress CustomerEmail

Step 10: Prototyping your Application in Visual Basic with Microsoft Access Note: Refer to the chapter: System Requirement / Generator Requirements / Visual Basic, to make sure that you have all the software required to execute the application. You won’t need an ODBC driver or a DBMS. 1. Select Prototype. 2. Choose Visual Basic to Prototype the two objects created

so far: Invoice and Customer.

Figure 20 Toolbar menu

Figure 21 Model creation dialog box

3. Click OK.

Page 20 of 47


4. In the GeneXus Create

Model Wizard that is displayed, type a name for the model: “Prototype Visual Basic”.

5. From the combination of

Languages, User Interfaces, and different DBMSs, select “Visual Basic” with a “Win” interface (the default one) and “Access” as DBMS. Open each drop-down menu to see the different possibilities.

6. Click Next.

Figure 22 Model creation wizard, Step 1

7. In Step 2, select “Microsoft DataGrid 6.0 (OLEDB)” in the Grid version drop down.

8. Click Next. 9. In Step 3, select the Visual

Basic 6.0 path. 10. Click Next.

Figure 23 Model creation wizard, Step 2

Page 21 of 47


11. In Step 4, Click Finish.

12. In the dialog box that is displayed, click OK.

Figure 24 Database Creation Analysis dialog box

Step 11: Viewing the Database Creation Report GeneXus displays a Database Creation Report to show you exactly what it is creating in the DB you specified in this case (Access) after viewing it. To do so, click Reorganize in the Database Creation Report dialog box. After you click this button, GeneXus will generate all the code to create the database. Then it will compile the code so that you can execute the reorganization program.

Figure 25 Database Creation Report

Page 22 of 47


Step 12: Creating the Tables with the Database Manager At this stage GeneXus launches its Database Manager, a GeneXus-generated program, to create the database, perform a data transfer (refactor the database when reorganizations are performed), rename tables, create indexes and update models. 1. In the GeneXus Database Reorganization dialog box, click Execute.

The reorganization program is generated depending on your language selection in the GeneXus Create Model Wizard (Step 10). In this case the Database Manager is running a Visual Basic program to perform the tasks. 2. Click Exit.

Figure 26 Completed Database Reorganization

Page 23 of 47


Step 13: Specifying and Generating your Code After the Database has been created, you can have GeneXus specify your objects and generate the programs in the language you selected (Visual Basic Code in this example). 1. On the Build menu, click Build All. You can also click Build All in the GeneXus toolbar.

Figure 27 GeneXus toolbar

2. Select the Type: Check

specification and Other Options: Specify & Generate.

Figure 28 Build All dialog box

GeneXus presents you with a specification report for each program it will generate.

The specification report’s objective is to show you in a high level how the program will execute, which tables it will access and which operations it will perform. In this case you are viewing the specification report of the transactions; notice that transactions are programs that will enable the user to Insert, Update, and Delete functions on the database. It also ensures that referential integrity and record locking are handled. All this without you writing one line of code!

Page 24 of 47


Figure 29 Navigation Report

You will also notice that GeneXus adds new objects, called “Selection List … ”

Figure 30 Selection list

GeneXus automatically takes charge of referential integrity. That is, transactions have the necessary knowledge to avoid data inconsistency due to updates (for example, a parent with children has been deleted, or a child without a parent has been entered). However, an integrity check alone would not be enough because a check failure and a "Client does not exist" message would not be useful for the user. It is necessary to help the user find the valid values! For this reason, GeneXus not only provides integrity controls, but also creates Prompt type objects that give the user a set of valid values to choose from. Although the Prompts are initially created by GeneXus, they can be modified by the user.

Referential Integrity: It means that when you delete a customer from the Customer Transaction, the program will check that there aren’t any invoices with that customer.

Page 25 of 47


Step 14: Running your Application After the Database has been created and all your objects have been specified and generated, you can now launch VB and run your application to test it. 1. Press F5, and click Execute

in the Execution dialog box.

Figure 31 Execution dialog box

2. In the Developer Menu

dialog box, click Transactions.

3. Next, click Customer to enter new data.

Figure 32 Developer menu options

Page 26 of 47


4. Next, enter some data into the Invoice. You will notice a couple of things here: o The date automatically defaults once you tab over it. o If you tab over CustomerId you will get a system message: “No matching Customer. BROWSE

DATA?” which was automatically created by GeneXus. If you click Yes, the corresponding prompt will appear. Also, if you press F4 on the Customer Id it will display a prompt list.

o Formulas are automatically calculated when the values are entered. Step 15: Adding New Objects to your Project: Item Transaction Adding a new object called “Item” and reorganizing the Database is simple in GeneXus. 1. Select Design in the drop-down menu of the GeneXus toolbar.

2. Create the Item Transaction by following Steps 2 to 4. The following attributes will be inserted in the Item Transaction Structure:

ATTRIBUTE TYPE DESCRIPTION ItemId --------- -------------------- ItemDsc --------- -------------------- ItemPrice --------- --------------------

Note that when you press the Save button, GeneXus won’t ask for the attribute definition of any of them.

Figure 33 Item transaction structure

Page 27 of 47


3. Now click the Form and Web Form tabs to see the transaction’s windows and Web forms,

respectively.

Figure 34 Item transaction win form

Figure 35 Item transaction web form

Page 28 of 47


Step 16: Viewing Table Structure Changes After the Item object is saved, GeneXus will reorganize the tables again. The new database structure will be:

<Invoice> InvoiceId InvoiceDate CustomerId

<Invoice1> InvoiceId ItemId ItemQty

<Customer> CustomerId CustomerNm CustomerAddress CustomerEmail

<Item> ItemId ItemDsc ItemPrice

Reviewing the Database after the Item Object has been created allows you to see that GeneXus automatically normalizes the tables for you. You will see that GeneXus has automatically moved the ItemDsc and ItemPrice attributes from the Invoice1 (Invoice Detail) table to the Item Table.


Step 17: Impacting the Database Now we will go back to Prototype as we did in Step 10, and GeneXus will perform an Impact to the application. 1. Select Prototype in the drop-down menu of the GeneXus toolbar. You will see that GeneXus automatically moves the attributes from the InvoiceHeader to the Item. 2. In the dialog box that is displayed, click OK.

Page 29 of 47


3. In the Impact Analysis Report

dialog box, click Reorganize.


Step 18: Refactoring the Data and Generating the Programs

GeneXus will automatically transfer the data that was stored in the Invoice (Item data) to the Item Table.

Figure 38 Database reorganization dialog box

Page 30 of 47


1. On the Build menu, click

Build\Specify or press SHIFT + F8 to display the Select Object dialog box. Note that only the Item object will appear (if the Edited Only checkbox is selected). Click OK.

Figure 39 Object selection dialog box

2. In the Specify Objects dialog

box, select the Check specification option and click OK.

Figure 40 Object specification dialog box

3. In the Specification Report

dialog box, click Generate to generate the program associated to the Item transaction.

Figure 41 Specification Report dialog box

Page 31 of 47


Step 19: Running your Application Now let’s run the application again, to see how GeneXus moved the data from the InvoiceDetail file to the Item file. 1. Press F5, and then click Execute.

2. Click the Item file in the Developer Menu dialog box and click the Select button to see the data you entered in the Invoice.

This means that the reorganization programs not only change the database structure, but also maintain the information stored in the database.

Figure 42 Developer Menu dialog box

Step 20: Creating a Report & Making a Call to It Now let’s go back to GeneXus and create a quick report to print an invoice. We will create a report in Prototype as no Database changes will be done; we will also call the report by adding a print button to the existing Invoice object. 1. Follow Step 2 to

create the new Report object, but this time click on Report and type Invoice in the Name field.

Figure 43 Object definition dialog box

Page 32 of 47


2. Next, click Insert

from Trn in the report wizard that appears.

Figure 44 Invoice Report Wizard, Step 1

3. Choose Invoice, and

click OK.

Figure 45 Object selection dialog box

Page 33 of 47


4. Click Finish and the

report Layout will appear.

Figure 46 Invoice Report Wizard, Step 1

The Layout tab contains the output to be printed later, and each one of them can have a set of controls such as attributes, variables, labels, etc.

Figure 47 Invoice report

Page 34 of 47


The navigation structure (which data is going to be listed, and in what order) is defined in the Source tab. To this end, a very simple procedural language is used.

Figure 48 For each command

In order to make the communication between the two objects we will make a call from the Invoice Transaction to the Invoice Report.

5. Select the Rules tab. 6. Write

“parm(InvoiceId);” 7. Click Save.

Figure 49 Invoice report rule

The FOR EACH command indicates that all the reports of a certain table will be queried, showing the information indicated in the printing block(s). The FOR EACH command is used to define the information to read in the database, but this is done by naming the corresponding attributes, and you will NEVER have to specify from which tables this data will be obtained, or with what indexes.

Page 35 of 47


8. On the Object menu,

click Open and select the Invoice Transaction.

9. Next, click the Rules Tab.

10. Type in “call(RInvoice,

InvoiceId) if after(TRN);”

Figure 50 More invoice report rules

Note: After(TRN) is a GeneXus function; to read about it press CTRL + “U”, scroll to the bottom, highlight “After(TRN)” and hit the Help button.

Step 21: Specifying and Running your Application 1. To Specify your Invoice, follow Step 13, to run your application follow Step 19. 2. Click Invoice and

enter some data, then click Confirm. After this your rule will be triggered and your report will appear; your report can either be displayed on the screen or sent to a printer.

Figure 51 Destination selection

Page 36 of 47


Figure 52 Invoice Report Viewer

CONGRATULATIONS…, you have successfully created an Invoice application in GeneXus; our next step is to show you how to move your application to another platform, .NET and/or JAVA.

Page 37 of 47


How to Move your Application to .NET and JAVA

Step 1: Deploying your Application to .NET with Microsoft SQL Server Note: Refer to the chapter: System Requirement / Generator Requirements / .NET, and make sure that you have all the software required to execute the application Next we will deploy the application to .NET with a SQL DB. 1. Select Design in the drop-down menu of the GeneXus toolbar. 2. On the File Menu, click New

Model to display the GeneXus Create Model Wizard.

3. Name the model: “Prototype

.NET”. 4. Select “.NET” with a “Web”

interface and “SQLServer” as the DBMS.

5. Click Next.

Figure 53 Create Model Wizard, Step 1

6. In Step 2, select “Driver” and “SQL Server” 7. Write the name of the Database and the Server. In the example, the Database name is

“demo” 5 and the Server name is “(local)” 8. Click Next.

5 The creation of the database is not performed by GeneXus when the creation process is carried out, so the database must be created manually before GeneXus actually creates the database tables. Please refer to your SQL Server manual for information on how to create the database.

Page 38 of 47


9. In Step 3, select “No” on

Use trusted connection. 10. Enter the user id and

password for the DBMS login. In the example the User Id is “user_name” 6

11. Select the SQL Server

version. 12. Click Next.


13. In Step 4, enter the Compiler and Virtual Directory paths and click Next.

14. In Step 5, click Finish.


6 The user needs CREATION rights to the database tables. For simplicity, we recommend assigning OWNER rights.

Page 39 of 47


15. In the dialog box that is

displayed, click OK.

Figure 56 Model creation dialog box

16. Follow Steps 11 and 12 to create the database. 17. Open the Invoice Report. Select the Properties icon.

Figure 57 Invoice report toolbar

18. Select “Only To Screen” for

the Report output property under Options.

19. Save the Report Invoice

Object with the Save button or by pressing: CTRL + S.

Figure 58 Report Properties dialog box

Page 40 of 47


20. Follow Steps 13 and 14 to specify and generate the code.

21. Before executing it, compile

the code with the Compile button.

Figure 59 Application execution dialog box

22. After compiling the

application, Execute it by clicking the Execute button.

23. Execute the Invoice

Transaction. Note that the application’s menu will look like Fig. 60.

Figure 60 Application menu

Page 41 of 47


Step 2: Viewing the .NET Application Running

Figure 61 Invoice

Step 3: Deploying your Application to Java with Microsoft SQL Server Note: Refer to the chapter: System Requirement / Software Requirements / JAVA Generator, and make sure that you have all the software required to execute the application. Next we will deploy the application to Java with a SQL DB. 1. In the GeneXus toolbar, select Design.

Page 42 of 47


2. On the File menu, click

New Model to display the GeneXus Create Model Wizard.

3. Name the model: “Prototype

JAVA” 4. Select “JAVA” with a “Web”

interface and “SQLServer” as the DBMS.

5. Click Next.


6. In Step 2, enter the Database and Server name. In the example, the Database name is “demo” 7 and the Server name is “server-name”.

7. Click Next.


7 The database is not created by GeneXus when the creation process is performed, so you must create the database manually before GeneXus actually creates the database tables. Please refer to your SQL Server manual for information on how to create the database.

Page 43 of 47


8. In Step 3, enter the user id and password for the DBMS login. In the example the User Id is

“user_name” 8 9. Select the SQL Server version. 10. Click Next.

11. Enter the Servlet directory (the Servlet directory allows to specify the directory where the servlets generated will be transferred). In the example we use Resin and the Servlet directory is: “C:\resin-2.1.7\doc\WEB-INF\classes”.

12. Enter the Static content

base URL (indicates the directory where the servlet will search for the static content -javascripts and images- used in the web objects corresponding to it).

13. Finally enter the Static

content directory seen from client, which indicates the directory to which we will transfer the javascripts -*.js files- generated.

14. Click Next.


8 The user needs CREATION rights to the database tables. For simplicity we recommend assigning OWNER rights.

Page 44 of 47


15. In Step 5, enter the

Compiler Path, the Make Path, the Interpreter Path, the Classpath and the Web Application Base URL9

16. Click Next, and then click

Finish. 17. Click OK.


18. Follow Steps 11 and 12 to create the database. 19. Follow Steps 13 and 14 to specify and generate the code. Remember that before executing you must compile the code, with the Compile button Also remember to start the Servlet Server. 20. Execute the JAVA application, and then the Invoice Transaction. More information about the JAVA Development Kits at: http://www.gxtechnical.com/main/hPSAmpInf.aspx?2,8,219,E,774,JAVA

9 In the example: • Compiler Path = C:\Program Files\Microsoft SDK for Java 4.0\bin\jvc.exe • Make Path = C:\Program Files\Microsoft SDK for Java 4.0\bin\nmake.exe • Interpreter Path = C:\WINDOWS\system32\jview.exe • Classpath = gxclassr.zip;.;C:\resin-2.1.7\lib\jsdk23.jar;C:\jdbc\sqlserver\Una2000.jar • Web Application Base URL = http://localhost:8080/servlet/

Page 45 of 47

http://www.gxtechnical.com/main/hPSAmpInf.aspx?2,8,219,E,774,JAVA


Step 4: Viewing the JAVA Application Running

Figure 66 Invoice

Page 46 of 47


Online Resources

GeneXus Community The GeneXus Community provides a variety of ways to get answers to your questions, solutions to your problems, and to share your own expertise. Find the list of community resources available to you at: www.genexus.com/community

Support ARTech offers a wide range of support services and resources: • Self-Service Online Support

These resources are available to anyone online. However, the information that you access depends on your GXTechnical Access Level.

• Interactive Support Services Interact with other members of the Community and with our Support Team.

www.genexus.com/support

How to Buy The GeneXus Technologies are sold through a network of distributors worldwide. Find a distributor near you at: www.genexus.com/distributors Otherwise, please contact [email protected]

Page 47 of 47

http://www.genexus.com/community

http://www.genexus.com/support

http://www.genexus.com/distributors

mailto:[email protected]

Documents

Manual de Genexus