GeneXus Visión General

Modificado Febrero, 2003 Copyright 1989 – 2003 ARTech, all right s 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

Ta bla de Con t e n ido

I N TROD UCCI ÓN ...................................................................................................... 3 EL PROBLEM A TEÓRI CO .......................................................................................... 4 METODOLOGÍ AS TRADI CI ONALES DE DESARROLLO Y PROBLEMAS ASOCI ADOS .................................. 4 METODOLOGÍ A I NCREMENTAL ......................................................................................... 5 UN A I M PLEM EN TACI ÓN D EL D ESARROLLO I N CREM EN TAL: GEN EXUS ..................... 6 D I SEÑO................................................................................................................... 7 PROTOTI PO ............................................................................................................. 10 I MPLEMENTACI ÓN ...................................................................................................... 11 MANTENI MI ENTO ....................................................................................................... 11 I m pact o de los cam bios sobre la base de dat os: ...................................................... 11 I m pact o de los cam bios sobre los program as: ......................................................... 12 D OCUMENTACI ÓN ...................................................................................................... 12 CONSOLI DACI ÓN DE VARI AS APLI CACI ONES Y REUTI LI ZACI ÓN DE CONOCI MI ENTO. .......................... 12 CARACTERÍ STI CAS ÚN I CAS D E GEN EXUS.............................................................. 1 3 ¿QUI ÉN ES SON LOS USUARI OS D E GEN EXUS? ...................................................... 1 3

Página 2 de 14

Introducción
GeneXus es una herram ient a int eligent e, desarrollada por ARTe ch, cuyo obj et ivo es asist ir al analist a y a los usuarios en t odo el ciclo de vida de las aplicaciones. El diseño y prot ot ipo son realizados y probados en un am bient e Windows. Cuando el prot ot ipo es t ot alm ent e aprobado por sus usuarios, la base de dat os y los program as de aplicación son generados y/ o m ant enidos en form a t ot alm ent e aut om át ica, para el am bient e de producción. La idea básica de GeneXus es aut om at izar t odo aquello que es aut om at izable: norm alización de los dat os y diseño, generación y m ant enim ient o de la base de dat os y de los program as de aplicación. De est a m anera se evit a que el analist a deba dedicarse a t areas rut inarias y t ediosas, perm it iéndole poner t oda su at ención en aquello que nunca un program a podrá hacer: e nt e nde r los pr oble m a s de l usua r io. Com o un subproduct o, GeneXus ofrece una docum ent ación rigurosa, aut osuficient e y perm anent em ent e act ualizada. Est e docum ent o t iene com o obj et ivo ilust rar al lect or sobre GeneXus y los problem as que resuelve. Cont enido de las siguient es secciones: • El problem a t eórico - en est e capít ulo se hace una descripción com parada de las m et odologías t radicionales de desarrollo de sist em as y el desarrollo increm ent al. • Una im plem ent ación del desarrollo increm ent al: GeneXus. • Caract eríst icas únicas de GeneXus. • Quienes son los usuarios de GeneXus

Página 3 de 14

El problema teórico
Metodologías tradicionales de desarrollo y problemas asociados
La form a t radicional de desarrollar aplicaciones part e de una prem isa básica: e s posible const r uir un m ode lo de da t os e st a ble de la e m pr e sa . Basándose en esa prem isa, la prim era t area que se encara es el análisis de dat os, donde se est udia la realidad en form a abst ract a y se obt iene com o product o el m odelo de dat os de la em presa. La segunda t area es diseñar la base de dat os. Es m uy sencillo diseñar la base de dat os part iendo del m odelo de dat os ya conocido. Una vez que se ha est udiado la realidad desde el punt o de vist a de los dat os, se hace lo propio desde el punt o de vist a de las funciones ( análisis funcional) . Sería deseable que el est udio de la realidad t uviera com o product o una especificación funcional que dependiera sólo de dicha realidad. Lo que se hace en las m et odologías m ás usadas, sin em bargo, es obt ener una especificación funcional que se refiere a los archivos de la base de dat os ( o bien a las ent idades del m odelo de dat os, lo que es esencialm ent e equivalent e) . Una vez que se t iene la base de dat os y la especificación funcional, se pasa a la im plem ent ación de las funciones, exist iendo t radicionalm ent e para ello varias opciones ( lenguaj es de 3ª . o 4ª generación, generadores, int erpret adores) . Sin em bargo, t odas las form as de im plem ent ación vist as t ienen un problem a com ún: part en de la enunciada prem isa: e s posible const r uir un m ode lo de da t os e st a ble de la e m pr e sa , y est a prem isa es fa lsa . Realm ent e no es posible hacer, de una form a abst ract a, un m odelo de dat os det allado de la em presa y con el suficient e nivel de det alle y obj et ividad, porque nadie la conoce com o un t odo. Por ello es necesario recurrir a m últ iples int erlocut ores, y cada uno de ellos proyect a sobre el m odelo, su propia subj et ividad. Una consecuencia de est o es que, durant e t odo el ciclo de vida de la aplicación, se producen cam bios en el m odelo. Pero aún si se considerara la sit uación ideal, donde se conocen exact am ent e las necesidades y, ent onces, es posible definir la base de dat os ó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 est o sería poco im port ant e, si la especificación funcional y la base de dat os fueran independient es. Sin em bargo, dado que la especificación funcional se refiere a la base de dat os, las inevit ables m odificaciones en ést a im plican m odificaciones ( m anuales) en aquella. La m ayor consecuencia de lo ant erior est á const it uida por los m uy alt os cost os de m ant enim ient o: en la m ayoría de las em presas que t rabaj an de una m anera convencional se adm it e que el 80% de los recursos que t eóricam ent e est án dest inados al desarrollo, realm ent e se ut ilizan para hacer m ant enim ient o de las aplicaciones ya im plem ent adas. Cuando se t rat a de aplicaciones grandes la sit uación es aún peor: est e m ant enim ient o com ienza m ucho ant es de la im plem ent ación, lo que hace que los cost os de desarrollo crezcan en form a hiperlineal con respect o al t am año del proyect o. Página 4 de 14

Dado que es m uy difícil, en est e cont ext o, det erm inar y propagar las consecuencias de cam bios de la base de dat os sobre los procesos, es habit ual que, en vez de efect uarse cam bios necesarios, se opt e por int roducir nuevos archivos redundant es, con consiguient e degradación de la calidad de los sist em as y el increm ent o de los cost os m ant enim ient o.

los los la de

Metodología incremental
Una m anera alt ernat iva de resolver el problem a pasa por la sust it ución de la prem isa básica enunciada: asum ir que no e s posible const r uir un m ode lo de da t os e st a ble de la e m pr e sa y, en cam bio, ut ilizar una filosofía increm ent al. Un esquem a increm ent al parece m uy nat ural: no se encaran grandes problem as, sino que se van resolviendo los pequeños problem as a m edida que se present an. ¿Cuál será la repercusión de est e t ipo de esquem a sobre los cost os de m ant enim ient o?. Si se ut ilizaran, con est e enfoque, las m et odologías ant eriorm ent e reseñadas, esa repercusión sería m uy grande: el m odelo de dat os se m odificaría const ant em ent e y los cost os de m ant enim ient o serían aún m ucho m ayores que los enunciados. Puede verse, sin em bargo, lo siguient e: No se conoce la base de dat os pero, cada usuario, conoce m uy bien las visiones de los dat os que él ut iliza cot idianam ent e. Esas visiones de los dat os pueden ser de varios t ipos: pant allas, list ados, et c. que com ponen el aspect o ext erior de la aplicación: Aquello que es t angible para el usuario. ¿Cóm o puede ayudar el conocim ient o de est as visiones a obt ener el m odelo de dat os? ¿Puede t ransform arse el asunt o en un problem a m at em át ico?. Si ello fuera posible, la m at em át ica podría brindar una am plia gam a de recursos para ayudar a resolverlo aut om át icam ent e y, com o consecuencia, se sim plificaría m ucho la t area del analist a. Una reflexión int eresant e es la siguient e: si se conociera la base de dat os, las visiones de los dat os que t ienen los diferent es usuarios deberían poder derivarse de ella. O, dicho de ot ra m anera, la base de dat os debe sat isfacer a t odas las visiones conocidas. Puede dem ost rarse que, dado un conj unt o de visiones de dat os de usuarios, exist e siem pre una base de dat os m ínim a que las sat isface, la cual, adem ás, es única. En est e est ado, el problem a se ha t ransform ado en un problem a m at em át ico y, ent onces es preciso resolverlo, para hallar esa base de dat os. Pe r o, ¿cóm o se im ple m e nt a e st a t e or ía ?. Se t rat a de capt urar el conocim ient o que exist e en las visiones de los usuarios, y sist em at izarlo en una base de conocim ient o. La caract eríst ica fundam ent al de est a base de conocim ient o, que la diferencia de los t radicionales diccionarios de dat os, es su capacidad de inferencia: se pret ende que, en cualquier m om ent o, se puedan obt ener de est a base de conocim ient o, t ant o elem ent os que se han colocado en ella, com o cualquier ot ro que se pueda inferir a part ir de ellos.

Página 5 de 14

Si est e obj et ivo se logra, la base de dat os y los program as de aplicación pasan a ser t ransform aciones det erm iníst icas de dicha base de conocim ient o y ello perm it e:
x x

Generarlos aut om át icam ent e. Ant e cam bios en las visiones de los usuarios: Det erm inar el im pact o de dichos cam bios sobre dat os y procesos Propagar esos cam bios generando:
⇒ los program as necesarios para convert ir los dat os; ⇒ los program as de la aplicación afect ados por los cam bios.

Una implementación del desarrollo incremental: GENEXUS
GeneXus im plem ent a est a t eoría. Cuando una aplicación se desarrolla con GeneXus la prim era et apa consist e en hacer el Diseño de la m ism a regist rando las visiones de usuarios ( a part ir de las cuales el sist em a capt ura y sist em at iza el conocim ient o) . Post eriorm ent e se pasa a la et apa de Prot ot ipación en donde GeneXus genera la base de dat os ( est ruct ura y dat os) y program as para el am bient e de prot ot ipo. Una vez generado el Prot ot ipo debe ser puest o a prueba por el analist a y los usuarios. Si durant e la prueba del Prot ot ipo se det ect an m ej oras o errores se ret orna a la fase de Diseño, se realizan las m odificaciones correspondient es y se vuelve al Prot ot ipo. Llam arem os a est e ciclo de Diseño/ Prot ot ipo. Una vez que el Prot ot ipo est á aprobado, se pasa a la et apa de I m plem ent ación, en donde GeneXus genera, t am bién aut om át icam ent e, la base de dat os y program as para el am bient e de producción. En resum en, una aplicación com ienza con un Diseño, luego se Prot ot ipa, luego se I m plem ent a y en cualquiera de los pasos ant eriores se puede regresar al Diseño para realizar m odificaciones.

Página 6 de 14

A cont inuación se det alla cada una de est as t areas:

Diseño
Est a t area es realizada conj unt am ent e por el analist a y el usuario, y consist e en ident ificar y describir las visiones de dat os de los usuarios. El t rabaj o se realiza en el am bient e del usuario. Est e esquem a perm it e t rabaj ar con un baj o nivel de abst racción, ut ilizando t érm inos y concept os que son bien conocidos por el usuario final. Una consecuencia m uy im port ant e, es que la act it ud del usuario se t ransform a en francam ent e part icipat iva. El sist em a pasa a ser una obra conj unt a y, com o el usuario sigue perm anent em ent e su evolución, su calidad es m ucho m ej or que la habit ual. De acuerdo a lo vist o, GeneXus capt ura el conocim ient o por m edio de visiones de obj et os de la realidad del usuario. Los t ipos de obj et os soport ados por GeneXus son: Tr a nsa ccione s, Re por t e s, Pr oce dim ie nt os, W or k Pa ne ls, W e b Obj e ct s, M e núe s, D a t a Vie w s, St yle s y Tr a nsa ccione s de D a t a W a r e house . La t area de diseño consist e, fundam ent alm ent e, en ident ificar y describir est os obj et os. A part ir de est as descripciones, y aut om át icam ent e, GeneXus sist em at iza el conocim ient o capt urado y va const ruyendo, en form a increm ent al, la Base de Conocim ient o. Est a Base de Conocim ient o es un reposit orio único de t oda la inform ación del diseño, a part ir de la cual GeneXus crea el m odelo de dat os físico ( t ablas, at ribut os, índices, redundancias, reglas de int egridad referencial, et c.) , y los program as de aplicación. Así, la t area fundam ent al en el análisis y diseño de la aplicación se cent ra en la descripción de los obj et os GeneXus. Veam os en det alle las clases de obj et os GeneXus m ás im port ant es:

Transacciones
Página 7 de 14

Una t ransacción es un proceso int eract ivo que perm it e a los usuarios crear, m odificar o elim inar inform ación de la base de dat os. Ej em plos: Pant alla para crear, m odificar o elim inar los Client es de la Em presa. Pant alla de fact uración: proceso que perm it e a un usuario crear fact uras e incluso im prim irlas. Una pant alla perm it e al usuario t om ar diferent es acciones com o insert ar, act ualizar, elim inar, im prim ir sin t ener que volver al m enú para hacerlo.

Reportes
Un inform e es un proceso que perm it e visualizar los dat os de la base de dat os. La salida del list ado puede ser enviada a pant alla o a la im presora ( y con ello t enem os un list ado convencional) . Con est e obj et o se pueden definir desde list ados sim ples ( por ej em plo, list ar los client es) hast a m uy sofist icados, en donde exist an varios cort es de cont rol, m últ iples lect uras a la base de dat os y param et rización. Sin em bargo un I nform e no puede act ualizar la base de dat os.

Procedimientos
Est e obj et o t iene t odas las caract eríst icas de los Report es, y adem ás perm it e act ualizar la base de dat os. Los Procedim ient os son com únm ent e usados para dos t ipos de procesos:
x x x

Procesos bat ch de act ualización. Por ej em plo: elim inar t odas las fact uras de fecha ant erior a una fecha dada y que ya fueron pagadas. Subrut inas de uso general. Por ej em plo: rut ina de m ont o escrit o en donde, dado un im port e se devuelve un lit eral con el im port e en let ras ( 1010 = > 'Mil diez') Procesos a ej ecut ar en un servidor de aplicaciones o servidor de base de dat os: procesos ( generalm ent e escrit os en C/ SQL, Java o .NET) para una Mult i Tier Archit ect ure, para ser ej ecut ados en un servidor de aplicaciones o de bases de dat os.

Work Panels
Un Work Panel es una pant alla que perm it e al usuario realizar consult as int eract ivas a la base de dat os. Cuant o m ás los usuarios ut ilizan el com put ador para su t rabaj o, se t orna m ás necesaria la ut ilización de diálogos sofist icados, que le perm it an sent arse a pensar frent e al m ism o. Los work panels perm it en diseñar est e t ipo de diálogos del usuario. Por ej em plo: Un work panel que m uest ra la list a de client es y que perm it e ( a elección del usuario) ver cuales son sus fact uras o su deuda.

Web Objects
Son sim ilares al conj unt o de Work Panels y Transacciones, pero son usados en browsers en am bient e I nt ernet / I nt ranet / Ext ranet .

Menúes
Página 8 de 14

Un m enú es una pant alla que cont iene una serie de opciones fij as que el usuario selecciona para ej ecut ar.

Data Views
Perm it en considerar correspondencias ent re t ablas de bases de dat os preexist ent es y t ablas GeneXus y t rat ar aquellos con la m ism a int eligencia com o si fueran obj et os GeneXus.

Styles
El est andarizar lo m ás posible una aplicación es un reconocido buen crit erio de diseño. En part icular, la int erfaz de usuario de una aplicación result a crít ica para const ruir sist em as am igables. Cuant o m ás est ándar sean los diálogos, m ás fácil de usar será la aplicación. Los St yles const it uyen un t ipo de obj et o GeneXus orient ado a la definición de int erfaces de usuario y est ándares de program ación. Los St yles ofrecen una serie de m ecanism os para definir form at os de pant allas, reglas del negocio y event os que serán ut ilizados luego por GeneXus en form a aut om át ica, obt eniendo sist em as de m ayor calidad y dism inuyendo sensiblem ent e los t iem pos de desarrollo.

GeneXus trabaja con el conocimiento puro
Part iendo de los obj et os descrit os, el m odelo de dat os físico es diseñado con base en la Teoría de Bases de Dat os Relacionales, y asegura una base de dat os en t ercera form a norm al ( sin redundancia) . Est a norm alización es efect uada aut om át icam ent e por GeneXus. El analist a 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) , aut om át icam ent e por GeneXus. El reposit orio de GeneXus m ant iene las especificaciones de diseño en form a abst ract a, o sea que no depende del am bient e obj et o, lo que perm it e que, a part ir del m ism o reposit orio, se puedan generar aplicaciones funcionalm ent e equivalent es, para ser ej ecut adas en diferent es plat aform as.

Múltiples Plataformas / Arquitectura de Múltiples Capas
Com o consecuencia de lo ant erior es posible, por ej em plo, que un usuario de una aplicación I BM AS/ 400 cent ralizada desarrollada 100% con GeneXus, pueda hacerla funcionar t ot al o parcialm ent e en un am bient e JAVA o .NET sin t ener que m odificar los obj et os originales. Por ot ra part e, las especificaciones funcionales son t ot alm ent e independient es de la base de dat os, por lo que se m ant ienen válidas aún luego de cam bios en ést a. Est a propiedad perm it e que GeneXus pueda m ant ener aut om át icam ent e t odos los program as que genera.

Página 9 de 14

Hoy es com ún que una m ism a aplicación debe t ener algunas part es corriendo en una plat aform a y alguna en ot ras, y que t odas se puedan com unicar correct am ent e. El desarrollo con GeneXus perm it e que una aplicación pueda ser dividida para ser ej ecut ada en diferent es plat aform as y generada, para cada una, en el lenguaj e m ás adecuado, obt eniendo así arquit ect uras de m últ iples part es ( m ult i- t ier) y que hagan un m ej or uso de los recursos disponibles.

Prototipo
En las t areas de diseño est án im plícit as las dificult ades de t oda com unicación hum ana:
x x x x

El usuario olvida ciert os det alles; El analist a no t om a not a de algunos elem ent os; El usuario se equivoca en algunas apreciaciones; El analist a int erpret a m al algunas explicaciones del usuario.

Pero, adem ás, la im plem ent ación de sist em as es, habit ualm ent e, una t area que insum e bast ant e t iem po, por lo que:
x x x

Com o m uchos de est os problem as sólo son det ect ados en las pruebas finales del sist em a, el cost o ( t iem po y dinero) de solucionarlos es m uy grande; La realidad cam bia, por ello, no es razonable pensar que se pueden congelar las especificaciones m ient ras se im plem ent a el sist em a; la consecuencia de la congelación de las especificaciones, es que se acaba im plem ent ando una solución relat ivam ent e insat isfact oria.

El im pact o de est os problem as dism inuiría m ucho si se consiguiera probar cada especificación, inm ediat am ent e, y saber cual es la repercusión de cada cam bio sobre el rest o del sist em a. Una prim era aproxim ación a est o, ofrecida por diversos sist em as, es la posibilidad de m ost rar al usuario form at os de pant allas, inform es, et c. anim ados por m enúes. Est o perm it e ayudar al usuario a t ener una idea de qué sist em a se le const ruirá pero, post eriorm ent e, siem pre se present an sorpresas. Una sit uación bast ant e diferent e sería la de poner a disposición del usuario para su ej ecución, inm ediat am ent e, una aplicación funcionalm ent e equivalent e a la deseada, hast a en los m ínim os det alles. Est o es lo que hace GeneXus: Un prot ot ipo GeneXus es una aplicación pront a, funcionalm ent e equivalent e a la aplicación de producción. La diferencia ent re prot ot ipación y producción consist e en que la prim era se hace en un am bient e de m icrocom put ador, m ient ras que la producción se realiza en el am bient e obj et o del usuario ( I BM iSeries, Client e / Servidor, JAVA, .NET) . El prot ot ipo perm it e que la aplicación sea t ot alm ent e probada ant es de pasar a producción. Durant e est as pruebas, el usuario final puede t rabaj ar con dat os reales, o sea que prueba, de una form a nat ural, no solam ent e form at os de pant allas, inform es, et c. sino t am bién fórm ulas, reglas del negocio, est ruct uras de dat os, et c. La filosofía de GeneXus es de de sa r r ollo incr e m e nt a l. Cuando se t rabaj a en un am bient e t radicional, los cam bios en el proyect o hechos durant e la im plem ent ación y, sobre t odo, aquellos que son necesarios luego de que el sist em a est á im plant ado, son m uy onerosos. GeneXus resuelve est e problem a: const ruye la aplicación con una m et odología de Página 10 de 14

aproxim aciones sucesivas que perm it e, una vez det ect ada la necesidad de cam bios, prot ot iparlos y probarlos inm ediat am ent e por part e del usuario, sin cost o adicional.

Implementación
GeneXus genera aut om át icam ent e el código necesario para:
x x

Crear y m ant ener la base de dat os; Generar y m ant ener los program as para m anej ar los obj et os descrit os por el usuario.

Los am bient es y lenguaj es act ualm ent e soport ados son: M últ iple s pla t a for m a s: ƒ Se r vidor e s con Sist e m a s Ope r a t ivos: I BM OS/ 400, UNI X, LI NUX, Windows NT/ 2000 Servers. ƒ Sist e m a s de Ge r e ncia de Ba se de D a t os: I BM DB2 UDB, I nform ix, Oracle, Microsoft SQL Server. ƒ Le ngua j e s: Java, C# , Visual Basic, C/ SQL, RPG, et cét era. ƒ I nt e r ne t : C# , JAVA, Visual Basic ( ASP) , C/ SQL, HTML. ƒ W e b Se r ve r s: Microsoft I I S, Apache, WebSphere. M últ iple s a r quit e ct ur a s: Cent ralizada ( iSeries) , Client e/ Servidor de dos o t res capas, Sist em as dist ribuidos en m últ iples capas en .NET, Mult i Servidor orient ada a I nt ernet , I nt ranet , Ext ranet , Dat a Warehouse y Workflow para t odos los servidores soport ados. N ue va s pla t a for m a s de e j e cución: JAVA, Microsoft .NET.

Mantenimiento
Est a es quizás la caract eríst ica m ás im port ant e de GeneXus, y la que lo diferencia de m anera m ás clara de sus com pet idores: el m ant enim ient o, t ant o de la base de dat os ( est ruct ura y cont enido) com o de los program as, es t ot alm ent e aut om át ico. A cont inuación se explicará el proceso de m ant enim ient o, ant e cam bios en la descripción de algún obj et o GeneXus ( visión del usuario) :

Impacto de los cambios sobre la base de datos:
Aná lisis de im pa ct o: Una vez descrit os los cam bios de las visiones de usuarios, GeneXus analiza aut om át icam ent e cual es el im pact o de los m ism os sobre la base de dat os y produce un inform e donde explica com o debe hacerse la conversión de los dat os y, si cabe, qué problem as pot enciales t iene esa conversión ( inconsist encias por viej os dat os ant e nuevas reglas, et c.) . El analist a decide si acept a el im pact o y sigue adelant e o no.

Página 11 de 14

Ge ne r a ción de pr ogr a m a s de conve r sión: Una vez que los problem as han sido solucionados o bien se ha acept ado la conversión " default " , que GeneXus realiza en form a est ándar, se generan aut om át icam ent e los program as para hacer la conversión ( est ruct ura y cont enido) de la viej a base de dat os a la nueva. Ej e cución de los pr ogr a m a s de conve r sión: A cont inuación, se pasa al am bient e de ej ecución que corresponda ( prot ot ipo, producción I nt ernet , producción Client e / Servidor, et c.) y se ej ecut an los program as de conversión.

Impacto de los cambios sobre los programas:
Aná lisis de im pa ct o: A cont inuación, GeneXus analiza el im pact o 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 t am 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 analist a. Ge ne r a ción de nue vos pr ogr a m a s: A cont inuación el sist em a genera o regenera aut om át icam ent e t odos los program as.

Documentación
Todo el conocim ient o provist o por el analist a, o inferida por GeneXus, est á disponible en un reposit orio act ivo, que const it uye una m uy com plet a docum ent ación on- line, perm anent em ent e act ualizada.

Consolidación de varias aplicaciones y reutilización de conocimiento.
Varias aplicaciones pueden ser diseñadas y prot ot ipadas sim ult áneam ent e, por diferent es equipos, ut ilizando GeneXus. Est os equipos pueden int ercam biar especificaciones de diseño ut ilizando el m ódulo KNOWLEDGE MANAGER. Est o perm it e una flexibilidad ideal: el analist a t rabaj a con ent era libert ad en un am bient e de prot ot ipo, con una pequeña base de conocim ient o y, sólo cuando su aplicación est á pront a desde el punt o de vist a del usuario, debe t om arse en cuent a la base de conocim ient o corporat iva, que generalm ent e será m uy grande. En ese m om ent o, con poderosas ayudas aut om át icas, se est ablece el im pact o que t endrá la nueva aplicación, o la m odificación de la preexist ent e, sobre el m odelo corporat ivo y, si es el caso, se hacen los cam bios para asegurar la consist encia, de una m anera m uy sim ple. Con est e esquem a es posible reut ilizar, por ej em plo, Bases de Conocim ient o licenciadas de t erceras part es ( Véase Cat álogo de Bases de Conocim ient o ht t p: / / www.genexus.com / cat alogo2001) .

Página 12 de 14

Características únicas de GENEXUS
GeneXus t iene algunas caract eríst icas únicas que lo dist inguen de sus com pet idores. Ent re ellas pueden dest acarse:
x x

I nt eract ivo: El punt o de part ida es la descripción nat ural del usuario de los obj et os. La descripción de cada obj et o es t ot alm ent e independient e 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 ent e la descripción de cualquier ot ro. Est a caract eríst ica exclusiva de GeneXus es la que perm it e un m ant enim ient o t ot alm ent e aut om át ico de las aplicaciones. La curva de aprendizaj e es cort a. Diseño, creación y m ant enim ient o de la base de dat os son t ot alm ent e aut om át icos. La aplicación ( base de dat os y program as) t iene siem pre, sean cuales sean las m odificaciones que haya sufrido, la m ej or calidad: La base de dat os 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 it uyen.

x x x

x

Lenguaj es poderosos y de m uy alt o 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 est os lenguaj es las descripciones de los procesos se hacen sin referirse a los archivos involucrados, los que son inferidos aut om át icam ent e en t iem po de generación. Est a caract eríst ica perm it e una t ot al independencia ent re los dat os y dichas especificaciones. Com o consecuencia, las especificaciones de alt o nivel de GeneXus no necesit an m odificaciones de la base de dat os. Ut ilización los archivos o bases de dat os preexist ent es com o propios de GeneXus. Mant enim ient o 100% aut om át ico: El conj unt o de est os elem ent os perm it e a GeneXus generar y m ant ener aut om át icam ent e el 100% de los program as en aplicaciones norm ales de t ipo com ercial, adm inist rat ivo, financiero o indust rial. GeneXus funciona en PC’s, dej ando el com put ador de producción t ot alm ent e libre para el procesam ient o de las aplicaciones. Fácil dist ribución del conocim ient o corporat ivo para facilit ar el desarrollo de nuevas aplicaciones. Sim ple y poderosa solución para Dat a Warehousing. Verificación aut om át ica de consist encia, y consolidación, ent re aplicaciones desarrolladas separadam ent e. I ndependencia de plat aform a y arquit ect ura. Sim plicidad: GeneXus ut iliza los recursos m ás avanzados de la int eligencia art ificial para que el analist a y los usuarios, puedan usarlo de una form a m uy sim ple.

x x

x x x x x x

¿Quiénes son los usuarios de GENEXUS?
GeneXus es dist ribuido en t oda Am érica, España, I t alia, Sudáfrica, China y Taiwan y t iene en la act ualidad, m ás de 4000 client es que han cont rat ado unas 25000 licencias. Página 13 de 14

Ent re los client es exist en em presas de t odo t ipo y área de act ividad. Los client es generalm ent e desarrollan con GeneXus grandes aplicaciones corporat ivas de m isión crít ica. Generalm ent e desarrollan con GeneXus el 100% de las m ism as. Exist en m ás de 1.000 casas de soft ware, en t odo el m undo, que desarrollan sus aplicaciones 100% con GeneXus, lo que represent a algunos m iles de client es indirect os 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

Página 14 de 14

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. ......................... 3 DEFINIR EL OBJETIVO ...................................................................................................... 3 DEFINIR EL EQUIPO DE TRABAJO ...................................................................................... 4 OBTENER UNA IMAGEN GLOBAL ...................................................................................... 4 DEFINIR EL ALCANCE DE LA APLICACIÓN ......................................................................... 5 MANTENER EL DISEÑO SIMPLE......................................................................................... 5 ORIENTARSE A LOS DATOS .............................................................................................. 5 DISEÑO DE TRANSACCIONES................................................................................... 7 ESTRUCTURA DE UNA TRANSACCIÓN............................................................................... 9 Atributos ................................................................................................................... 10 Dominios .................................................................................................................. 11 Atributos Clave......................................................................................................... 11 Relación entre la estructura y el modelo de datos ................................................... 12 Tipos de controles .................................................................................................... 14 Definición de la transacción de pedidos .................................................................. 16 Niveles de una transacción....................................................................................... 18 Tipos de relación entre los objetos........................................................................... 22 FORM DE UNA TRANSACCIÓN ........................................................................................ 23 Diálogo full-screen................................................................................................... 24 Diálogo campo a campo .......................................................................................... 25 Barra o Botones de Menú......................................................................................... 25 Atributos de entrada y atributos de salida ............................................................... 26 Facilidad de Prompt................................................................................................. 26 Diálogo para transacciones con varios niveles ....................................................... 27 FORM EDITOR ............................................................................................................... 29 Form Edition Controls ............................................................................................. 29 Paleta de herramientas ............................................................................................ 30 Uso de las Herramientas .......................................................................................... 31 Toolbar..................................................................................................................... 31 Propiedades de los controles ................................................................................... 32 Editor de Propiedades, Métodos y Eventos.............................................................. 35 FÓRMULAS .................................................................................................................... 36 Fórmulas Horizontales............................................................................................. 37 Fórmulas Verticales ................................................................................................. 38 Fórmulas y Redundancia ......................................................................................... 39

Fórmulas de Fórmulas ............................................................................................. 40 REGLAS ......................................................................................................................... 41 Default...................................................................................................................... 41 Error......................................................................................................................... 41 Asignación................................................................................................................ 41 Add y Subtract .......................................................................................................... 42 Serial ........................................................................................................................ 43 Orden de evaluación ................................................................................................ 44 Call y función After .................................................................................................. 45 PROPIEDADES ................................................................................................................ 46 DISEÑO DE REPORTES.............................................................................................. 48 LAYOUT ........................................................................................................................ 48 Comando FOR EACH .............................................................................................. 51 Reportes con varios FOR EACH.............................................................................. 60 Otros comandos........................................................................................................ 67 CONDICIONES ................................................................................................................ 73 REGLAS ......................................................................................................................... 74 Default...................................................................................................................... 74 Parm......................................................................................................................... 75 REPORT WIZARD ........................................................................................................... 76 PROPERTIES................................................................................................................... 78 DISEÑO DE PROCEDIMIENTOS .............................................................................. 80 Modificación de datos .............................................................................................. 80 Eliminación de datos................................................................................................ 81 Creación de datos..................................................................................................... 81 CONTROLES DE INTEGRIDAD Y REDUNDANCIA............................................................... 82 DISEÑO DE PANELES DE TRABAJO ...................................................................... 83 EJEMPLO ....................................................................................................................... 84 FORM DEL WORK PANEL ............................................................................................... 86 Subfile....................................................................................................................... 87 EVENTOS ....................................................................................................................... 89 Evento Start .............................................................................................................. 90 Evento Enter............................................................................................................. 90 Eventos definidos por el usuario (User Defined Events).......................................... 91 Evento Refresh.......................................................................................................... 91 Carga de datos en el Panel de Trabajo.................................................................... 92 CONDICIONES ................................................................................................................ 93 REGLAS ......................................................................................................................... 95 Order ........................................................................................................................ 95

Noaccept................................................................................................................... 95 Search....................................................................................................................... 95 BITMAPS........................................................................................................................ 97 Fixed Bitmaps........................................................................................................... 97 Dynamic Bitmaps ..................................................................................................... 97 GRÁFICAS...................................................................................................................... 99 PROPERTIES................................................................................................................. 103 Generar como una ventana Popup......................................................................... 103 DIÁLOGOS OBJETO-ACCIÓN ........................................................................................ 104 DISEÑO DE MENÚES ................................................................................................ 106 CALL BROWSER .......................................................................................................... 108 ANEXO A. MODELOS DE DATOS RELACIONALES.......................................... 110 Tablas..................................................................................................................... 110 Clave primaria y Claves candidatas ...................................................................... 111 Indices .................................................................................................................... 112 Integridad Referencial............................................................................................ 112 Normalización ........................................................................................................ 114 Tabla extendida ...................................................................................................... 115 ANEXO B. FUNCIONES, REGLAS Y COMANDOS.............................................. 118

Todos los nombre de productos mencionados en este documento son marcas de sus respectivos 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 sistemas recuperables, 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 o sin finalidad de lucro, sin autorización expresa de ARTech.

GENEXUS- DISEÑO DE APLICACIONES

INTRODUCCIÓN
El presente documento es una introducción al desarrollo de aplicaciones utilizando GENEXUS. Está dirigido a profesionales de informática que se inician en el uso de GENEXUS. GENEXUS es una herramienta para el desarrollo de aplicaciones. Su objetivo es ayudar a los analistas de sistemas a implementar aplicaciones en el menor tiempo y con la mejor calidad posible. A grandes rasgos, el desarrollo de una aplicación implica tareas de análisis, diseño e implementación. La vía de GENEXUS para alcanzar el objetivo anterior es liberar a las personas de las tareas automatizables (por ejemplo, la implementación), permitiendoles así 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 de aplicaciones que una herramienta de software. Como metodología, tiene algunos puntos de contacto con las metodologías tradicionales, pero también aporta enfoques bastante diferentes en otros. En común con las metodologías tradicionales, se mantiene la importancia del análisis y diseño de la aplicación sobre la implementación. Quizás con GENEXUS este enfoque se resalta más aún, ya que el usuario de GENEXUS estará la mayor parte del tiempo realizando 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 los habituales, como, por ejemplo, el comenzar el análisis de la aplicación por la interfase del mismo 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ón demasiado abstracta del tema, se ha elegido una aplicación que se irá desarrollando a través de los distintos capítulos. El primer capítulo presenta la aplicación y los aspectos iniciales de un desarrollo con GENEXUS. El segundo capítulo trata el diseño de Transacciones, el tercero de Reportes, el cuarto de Procedimientos, el quinto de Paneles de Trabajo y por último se trata el diseño de Menúes. Debido a que en todos los capítulos se asume cierto conocimiento sobre Bases de Datos Relacionales, se ha incluido un anexo sobre el tema que describe los conceptos necesarios para 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, que comienza cuando se planifica la misma y termina cuando la aplicación sale de producción. GENEXUS acompaña todo este ciclo. Este tema es tratado en el documento Visión General, que recomendamos leer previamente.

1

GENEXUS DISEÑO DE APLICACIONES • 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.

2

GENEXUS- DISEÑO DE APLICACIONES

DESARROLLO DE UNA APLICACIÓN
La mejor forma de aprender a utilizar GENEXUS es realizando aplicaciones con él. La aplicació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 a los analistas de compras realizar dicha tarea con la mayor cantidad de información posible. La función de un analista de compras es decidir los pedidos que se deben efectuar 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 los distintos proveedores. Una vez que el pedido este hecho y aprobado, se quiere que el computador emita las ordenes de compra. En el momento de hacer un pedido es necesario hacer varias consultas, por ejemplo cuanto hay en stock, cual fue el precio de la última compra, 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 los sistemas tienen objetivos específicos. Ellos esperan que la aplicación los ayude a alcanzarlos mas rápido, mas fácil, o a un menor costo. Es parte del trabajo de análisis, el conocer esos propósitos y saber por medio de que actividades los usuarios quieren alcanzarlos. Este objetivo debe poder ser expresado en pocas palabras (uno o dos párrafos) y ser conocido 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 la formulación de un pedido." • "El sistema de compras debe asistir a usuarios no entrenados en la formulación de 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 las farmacias." De todos los objetivos posibles se debe elegir uno como el objetivo principal o prioritario. Esto es muy importante para el futuro diseño de la aplicación. Basta con observar como los distintos objetivos anteriores conducen a diseños diferentes.

3

GENEXUS DISEÑO DE APLICACIONES

Para nuestro ejemplo elegiremos el primer objetivo, dado que en la situación real el analista de compras no tenia toda la información que necesitaba. Por lo tanto, debía consultar una serie de planillas manuales y llamar por teléfono a los empleados del deposito para que realizaran un conteo manual del stock. No se debe confundir el objetivo de la aplicación (el QUE) con la funcionabilidad de la misma (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 la implementació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 dos condiciones: • 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 el comienzo 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 la participación de los usuarios en todas las etapas del desarrollo. Se recomienda tener un usuario principal disponible para la prueba de los prototipos y tener acceso a los demás usuarios de una manera fluida. Dado que con GENEXUS los miembros del equipo estarán la mayor parte del tiempo trabajando en tareas de diseño y no de codificación, se debe tomar como criterio general el 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 de obtener información sobre la posición relativa (e importancia) de la aplicación dentro de toda la organización.

4

GENEXUS- DISEÑO DE APLICACIONES

Definir el alcance de la aplicación
Luego de un estudio primario se debe decidir cuál será el alcance de la aplicación para poder cumplir con el objetivo. Para ello se recomienda seguir el Principio de Esencialidad: "Solo lo imprescindible, pero todo lo imprescindible" En el ejemplo, una vez que una orden de compra es enviada a un proveedor, se debe controlar como y cuando se fueron entregando efectivamente los productos. Sin embargo vemos que esto no es imprescindible para cumplir el objetivo de la aplicación y por lo tanto 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 frecuentemente con el usuario.

Orientarse a los datos
En esencia, una aplicación es un conjunto de mecanismos para realizar ciertos procesos sobre ciertos datos. Por lo tanto, en el análisis de la aplicación, se puede poner mayor énfasis en los procesos o en los datos. En las metodologías tradicionales -como el Análisis Estructurado- el análisis se basa en los procesos. En general, este análisis es Top-Down; se comienza con la definición más abstracta de la función del sistema, y luego se va descomponiendo esta en funciones cada vez más simples, hasta llegar a un nivel de abstracción suficiente como para poder implementarlas 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ño basado 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 controvertida en 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 siguientes ventajas:

5

GENEXUS DISEÑO DE APLICACIONES

Más estabilidad. Los datos tienden a ser más estables que los procesos y en consecuencia la aplicación será más fácil de mantener. Facilidad de integración con otras aplicaciones. Difícilmente una aplicación es totalmente independiente de las otras dentro de una organización. La mejor forma de integrarlas es tener en cuenta los datos que comparten. Incluso es posible que en un futuro el propio concepto de aplicación evolucione hacia el concepto de objeto, en donde los usuarios 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 como analizar los datos?. La respuesta de GENEXUS es analizar directamente los datos que el usuario 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- estudiando cuales son los objetos que el usuario manipula. Para cada uno de estos objetos se define cual 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 hechos objetivos, y este puede ser evaluado directamente por los usuarios, utilizando la facilidad de prototipación de GENEXUS.

6

GENEXUS- DISEÑO DE APLICACIONES

DISEÑO DE TRANSACCIONES
El análisis mismo de la aplicación comienza con la definición de las transacciones. De cualquier manera es importante tener en cuenta que todo el proceso de desarrollo es incremental y por lo tanto no es necesario definir en esta etapa todas las transacciones y cada una de ellas en su mayor detalle. Por el contrario lo importante aquí es reconocer las mas 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 los objetos (reales o imaginarios) que el usuario manipula. Afortunadamente es posible encontrar la mayor parte de las transacciones a partir de: La descripción del sistema. Cuando un usuario describe un sistema se pueden determinar muchas transacciones si se presta atención a los sustantivos que utiliza. En el ejemplo: Analistas de compras Pedidos Proveedores Artículos Ordenes de Compra

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

Para cada transacción se puede definir: Estructura De que atributos (campos en la metodología tradicional) esta compuesta y que relación tienen entre si. Pantalla o Form Cual es el form que tiene. Esto se realiza con un editor especializado. Fórmulas Que atributos se calculan a partir de otros atributos. Por ejemplo: Valor = Cantidad * Precio.

Reglas

7

GENEXUS DISEÑO DE APLICACIONES

Conjunto de reglas que debe cumplir la transacción. Por ejemplo cuales son los valores por defecto de los atributos, cuales son los controles en los datos que hay que realizar, etc. Eventos Las transacciones soportan la programación dirigida por eventos. Este tipo de programación permite el almacenamiento de código ocioso el cual es activado luego de ciertos eventos - provocados por el usuario o por el sistema. Propiedades Reglas que definen el comportamiento general de la transacción. Form Classes Cada objeto puede tener asociado mas de un form que pertenece a una determinada Form Class. Existen dos Form Classes predefinidas: Graphic y Text. Tipicamente la Form Class Graphic se usa para los ambientes graficos (por ejemplo: Windows) y la form 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 un form (de determinada Form Class) de los que se hayan asociado al objeto. Style Asociado Styles son básicamente objetos GENEXUS (su forma de definición es similar a los otros objetos), pero no son tenidos en cuenta en la normalización o generación de programas; 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 de los usuales de texto. Cuando se crea una transaccion se puede asociar un style en el cual se basara la transaccion. Ayuda Texto para la ayuda a los usuarios en el uso de la transacción. Documentación Texto técnico que se incluye para ser utilizado en la documentación del sistema.

8

GENEXUS- DISEÑO DE APLICACIONES

Forms

Estructura Form Fast Access Toolbar Cuando se bare un objeto esta toolbar se habilita con las siguientes opciones: Reglas Propiedades

Variables Eventos Help

Estructura de una transacción
La estructura define que atributos (campos) integran la transacción y como están relacionados. En el ejemplo, la transacción de Proveedores posee los siguientes atributos: PrvCod PrvNom PrvDir Código de proveedor Nombre del proveedor Dirección del proveedor

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

9

GENEXUS DISEÑO DE APLICACIONES

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 que tenemos disponibles y permite tener una descripción ampliada para éste. También se utiliza 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 o DateTime).

10

GENEXUS- DISEÑO DE APLICACIONES

El tipo de dato Long Varchar (por Variable Character) permite almacenar una cantidad de caracteres indefinida. Se utiliza normalmente para almacenar textos, por ejemplo 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, por ejemplo: en campos caracter @! significa que todos los caracteres se aceptan y despliegan 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 30 1 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 comparten definiciones similares, y que no se puede establecer ninguna relación directa entre ellos. Por ejemplo, es común almacenar todos los nombres en atributos de tipo caracter y largo 25. El uso de dominios permite usar definiciones de atributos genéricos. Por ejemplo en la transacción de proveedores tenemos el nombre (PrvNom) y mas adelante vamos a definir el nombre del analista, entonces podemos definir 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án propagados 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 identifican a 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* PrvNom PrvDir así se indica que no existen dos proveedores con el mismo Código de Proveedor.

11

GENEXUS DISEÑO DE APLICACIONES

Es importante notar que el concepto de identificador se refiere a la unicidad (si puede haber o no dos proveedores con el mismo número) y no a como se debe acceder al archivo 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 por crear un atributo artificial (no existente en la realidad) y cuyo valor es asignado automá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 datos que 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 la transacció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 luego pueden ser modificados por el analista). Diremos que la transacción de Proveedores tiene asociada la tabla PROVEEDO en el entendido que cuando se ingresen (o modifiquen, etc.) datos en la transacción estos serán almacenados en la tabla PROVEEDO. Otras transacciones simples de nuestro ejemplo son:

12

GENEXUS- DISEÑO DE APLICACIONES

Analista de compra: AnlNro* AnlNom Numero de analista Nombre del analista

Artículos: ArtCod* Código de articulo ArtDsc Descripción del articulo ArtCnt Cantidad en Stock ArtFchUltCmp Fecha ultima compra ArtPrcUltCmp Precio ultima compra ArtUnidad Unidad del articulo ArtSize Tamaño ArtDisponible 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:

13

GENEXUS DISEÑO DE APLICACIONES

Los atributos ArtUnidad, ArtDisponible y ArtSize no aparecen en el form como los atributos 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: un nombre, un precio, etc). En estos casos se le permite al usuario entrar el valor del atributo 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 que pueden ser desplegados de antemano para que el usuario seleccione uno. De esta forma controlamos que ingresen solo valores válidos. Estos tipos de controles son los que 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

14

GENEXUS- DISEÑO DE APLICACIONES

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

Radio Buttom
Los ‘Radio Buttom’, en cambio, pueden tener mas de dos valores. Todos los valores se despliegan en el form (en realidad se despliegan sus descripciones, el valor que se almacena es manejado internamente) y solo se puede seleccionar uno. En el ejemplo el 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 campo de tipo Edit y presionando un botón que se encuentra a la derecha del campo se despliega una lista con todos los valores validos. No es recomendable usar este campo como listas de selección de atributos que tienen valores que no pueden ser determinados a priori, (que son leídos de una tabla). Para estos casos se usan los Dynamic Combobox.

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

List Box
Este tipo de control tiene asociada una colección de ítems. Cada ítem tiene asociado un par <valor,descripción>. Existe la posibilidad de cargar la colección de ítems tanto en diseño como en runtime. El control da la posibilidad de seleccionar un solo ítem a la 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 del teclado.

Dynamic List Box
Este tipo de control tene asociada una colección de ítems. Cada ítem tiene asociado un par <valor,descripción>.

15

GENEXUS DISEÑO DE APLICACIONES

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 que tendrá el ítem y el otro a la descripción que éste tomará. Ambos atributos deben pertenecer a la misma tabla. En tiempo de especificación se determina la tabla desde la cual se traerán los valores y las descripciones.

Definición de la transacción de pedidos
Consideremos ahora la transacción de Pedidos. El formulario preexistente de pedidos es:
Pedido : 1456 Fecha: 02/01/92 Analista : 21 Pedro Gomez Proveedor : 125 ABC Inc. Código Descripción Cantidad Precio 321 567 Aspirinas Flogene 100 120 120 50 Total Valor 12000 6000 18000

Los atributos que integran la transacción son (dejando momentáneamente de lado la información de los Artículos del pedido): PedNro* PedFch PrvCod PrvNom AnlNro AnlNom PedTot Numero del pedido Fecha del pedido

Total del pedido

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

16

GENEXUS- DISEÑO DE APLICACIONES

Proveedores y los Pedidos y también entre los Analistas y los Pedidos, en particular aquí 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 distintas transacciones 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 que se encuentre, a no ser que ello no sea posible (es el caso de Subtipos que se detallara mas adelante). Por ejemplo al nombre del proveedor se le llama PrvNom tanto en la transacción de Proveedores como en la de Pedidos. Se debe poner nombres distintos a atributos conceptualmente distintos, aunque tengan dominios iguales. Por ejemplo el nombre del proveedor y el nombre del analista tienen el mismo dominio (son del tipo Character de largo 30), pero se refieren a datos diferentes, 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ón NO se esta describiendo la estructura de una tabla y SI los datos que se necesitan en la pantalla o en las reglas. Por ejemplo, que en la estructura anterior figure el PrvNom no quiere decir que este se encuentre en la tabla de Pedidos, simplemente indica que se necesita tener el PrvNom en la pantalla de Pedidos. La tabla asociada a el cabezal del Pedido será: Tabla: PEDIDOS PedNro* PedFch PrvCod AnlNro PedTot Índices: IPEDIDOS (PedNro) IPEDIDO1 (PrvCod) IPEDIDO2 (AnlNro) Clave Primaria Clave Extranjera 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,

17

GENEXUS DISEÑO DE APLICACIONES

que tiene a PrvCod como clave primaria, y la PEDIDOS que lo tiene como clave extranjera. La relación, que llamaremos de integridad referencial, es: • Para insertar un registro en la tabla PEDIDOS debe existir el PrvCod correspondiente en la tabla PROVEEDO. • Cuando se elimina un registro de la tabla PROVEEDO no debe haber registros con el PrvCod a eliminar en la tabla PEDIDOS. Estos controles de integridad son generados automáticamente por GENEXUS y, por ejemplo, en la transacción de Pedidos cuando se digita el PrvCod se valida que este exista en la tabla PROVEEDO e incluso se genera una subrutina que permite visualizar 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 debe definir la información sobre los Artículos del pedido. Sin embargo no es posible definir la estructura de la siguiente manera: PedNro* PedFch PrvCod PrvNom AnlNro AnlNom ArtCod ArtDsc PedCnt PedPre PedImp PedTot

Cantidad pedida Precio pedido Valor del articulo

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

18

GENEXUS- DISEÑO DE APLICACIONES

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

Nivel del cabezal Nivel de las líneas

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 de atributos que se encuentra encerrado por paréntesis diremos que pertenece a un NIVEL 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 ser paralelos entre si. Por ejemplo si el Pedido tiene varias fechas de entrega: PedNro* PedFch PrvCod PrvNom AnlNro AnlNom ( ArtCod* ArtDsc PedCnt PedPre PedImp ) ( PedFchEnt* PedImpPag ) PedTot

Fecha de entrega Importe a pagar

19

GENEXUS DISEÑO DE APLICACIONES

Con esta estructura se define que un Pedido tiene muchos Artículos y muchas Entregas, pero no hay relación directa entre ambas (a no ser el hecho de pertenecer al mismo Pedido). Si por el contrario las fechas de entrega son por articulo (cada articulo 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 debe tener uno. Por ejemplo en el Pedido tenemos que el identificador del segundo nivel es ArtCod. Con esto se indica que dentro de cada Pedido no existen dos líneas del Pedido con el mismo ArtCod, y por lo tanto el siguiente Pedido no es valido:

Pedido : 1456 Fecha: 02/01/92 Analista : 21 Pedro Gomez Proveedor : 125 ABC Inc. Código Descripción Cantidad Precio 321 321 Aspirinas Aspirinas 100 120 120 50 Total Valor 12000 6000 18000

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

20

GENEXUS- DISEÑO DE APLICACIONES

Aquí también se deben tener en cuenta los criterios sobre identificadores que se mencionaron previamente. En particular, es común definir atributos artificiales cuando no hay identificadores naturales, por ejemplo, para el caso en que si puede haber varias 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 para que 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 la concatenación de los identificadores de los niveles superiores (PedNro) mas los identificadores del nivel (PedLinNro).

21

GENEXUS DISEÑO DE APLICACIONES

La elección de los identificadores es una tarea importante y que puede simplificar o complicar la implementación de un sistema. Supongamos por ejemplo, que en el Pedido no se admite que haya dos líneas con el mismo ArtCod. La forma natural de implementar esto es definiendo a ArtCod como identificador del segundo nivel. Ahora bien, si por alguna razón se definió a PedLinNro como el identificador, ya no tendremos 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í en simplicidad y flexibilidad.

Tipos de relación entre los objetos
Muchas veces cuando los usuarios están describiendo la aplicación, es común preguntarles que tipo de relación existe entre los distintos objetos. Por ejemplo cual es la 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. En estos 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 los Artículos: Un pedido tiene muchos Artículos.

22

GENEXUS- DISEÑO DE APLICACIONES

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 que pedidos tiene.

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

23

GENEXUS DISEÑO DE APLICACIONES

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 del combo box que aparece en la toolbar. También se puede asociar un style y aplicarlo. El style se asocia en cada objeto en las propiedades del mismo. Para los Proveedores la pantalla por defecto (en este caso en modo gráfico) es:

Atributos que serán aceptados o desplegados en la pantalla

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

Diálogo full-screen
Este tipo de diálogo se genera para las plataformas donde se utilizan terminales no programables, 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 pantalla 2- Se realizan todas las validaciones 3- 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.

24

GENEXUS- DISEÑO DE APLICACIONES

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 que si se encuentra en modo Insertar se aceptan los identificadores, pero si se esta en modo Modificar no, etc. El pasaje de un modo a otro se realiza presionando teclas de función. Por ejemplo con F6 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 su validez. También trabaja con modos, pero con la diferencia que el modo es inferido automáticamente por el sistema. Por ejemplo cuando el usuario digita el PrvCod, si este existe se pasa automáticamente a modo Modificar y si no existe se pasa a modo Insertar.

Barra o Botones de Menú
En ambos tipos de diálogo se encuentra disponible una Barra de Menú que tiene las opciones para poder visualizar los distintos datos. Por ejemplo, se puede elegir ver (para luego modificar) el primer proveedor siguiente particular , el

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

25

GENEXUS DISEÑO DE APLICACIONES

Atributos de entrada y atributos de salida
Consideremos nuevamente la transacción de Pedidos pero sin sus Artículos. La pantalla 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 de salida). GENEXUS automáticamente determina que atributos son aceptados y de cuales solo se muestra su valor, siguiendo las reglas: • Solo pueden ser aceptados los atributos que se encuentran en la tabla asociada 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 base del nivel se genera la facilidad de Prompt que permite visualizar cual es el conjunto de valores validos para esos atributos. Por ejemplo, en la transacción de Pedidos presionando una tecla especial se puede visualizar cuales son todos los proveedores, con la siguiente pantalla:

26

GENEXUS- DISEÑO DE APLICACIONES

en donde se puede seleccionar el proveedor. Observar que en la primera parte de la pantalla se permite digitar el PrvCod ,el PrvNom, o el PrvDir para poder posicionarse en la lista de proveedores. Esta lista es un work panel de GeneXus que puede ser modificado 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 por nivel. Es decir se realiza la validación y la confirmación de los datos para cada uno de los niveles. Por ejemplo para la transacción de Pedidos (considerando ahora los Artículos del mismo) la pantalla por defecto es:

27

GENEXUS DISEÑO DE APLICACIONES

En ésta se aceptan primero los datos de entrada del primer nivel (los del cabezal del pedido: Numero, Fecha, Proveedor y Analista), posteriormente se validan y se pide confirmación y luego se realiza el mismo proceso para cada una de las líneas del pedido. Cuando se genera el form por defecto se diseña un subfile para el último nivel de la transacción, en el ejemplo las líneas del pedido. Trabajando con el form editor se puede transformar esta pantalla en la siguiente, que simula mejor el formulario de pedidos:

28

GENEXUS- DISEÑO DE APLICACIONES

Form Editor
Los objetos como las Transacciones o los Work Panels, tienen uno o varios Formularios asociados. A los efectos de permitir modificar los Formularios que GENEXUS automáticamente crea por defecto, se provee un Form Editor. Este Form Editor es igual para todos los objetos que tienen Formularios. El Formulario está formado por un marco de ventana (frame) cuyo título es la descripción de la transacción. Dentro de ella figurarán los distintos tipos de controles de edición del Formulario.

Form Edition Controls
En un Formulario se definen ‘controles’. Un control es una área del Formulario que tiene una forma y un comportamiento determinado. Existen los siguientes tipos de controles:

29

GENEXUS DISEÑO DE APLICACIONES

Atributo. Se utiliza para representar atributos o variables. Texto. Todo fragmento de texto fijo en la pantalla debe colocarse utilizando uno o má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 adelante en 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 o varias Paginas y cada Pagina tiene un Title y un area util donde se ponen los controles de esa pagina. Solo una de las paginas puede estar activa a la vez y es la que se puede ver, del resto solo se vera su titulo. Esto es util para cuando se quiere dividir los datos ingresados en la transaccion en distintos grupos de modo que las pantallas queden 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, en la forma de una ventana adicional, con los botones que representan los tipos de controles disponibles.

30

GENEXUS- DISEÑO DE APLICACIONES

Uso de las Herramientas
Sobre los objetos seleccionados con el puntero vamos a poder realizar varias operaciones: • 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 un control. Cada control se encuentra en una capa distinta del Formulario, por lo que algunos están "más arriba" que otros. Cuando dos objetos se superpongan, el de más arriba será visible totalmente, mientras que el otro 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 el tamaño de otros controles ya definidos: Toolbar

Alinear a la izquierda. Alinear a la derecha. Alinear al borde superior. Alinear al borde inferior. Centrar verticalmente. Centrar horizontalmente.

Separar horizontalmente. Separar verticalmente. Igualar ancho. Igualar altura. Igualar tamaño. Mostrar Grid

31

GENEXUS DISEÑO DE APLICACIONES

Propiedades de los controles
Vamos a ver las principales propiedades de cada unos de los controles que podemos insertar 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 estas opciones, donde se pueden indicar expresiones que definan la fila y la columna.

32

GENEXUS- DISEÑO DE APLICACIONES

Frame. Se puede indicar que el atributo esté rodeado por un marco. Es posible indicar el tipo: None, Single o 3D; el ancho de la/s línea/s (Width), si se pinta dentro de él o no (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 distintos tipos 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 valor del 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 área asignada al atributo en la pantalla. Sólo tiene efecto si está presente la propiedad Fill.

33

GENEXUS DISEÑO DE APLICACIONES

Texto

Text. Indica el texto que se quiere insertar en la pantalla. Puede consistir de una o más líneas. Alignment. El texto puede estar justificado a la izquierda (Left), derecha (Right) o centrado (Center). Resto de las propiedades. Ver control de Atributo.

34

GENEXUS- DISEÑO DE APLICACIONES

Recuadro

Del combo box se selecciona el tipo del borde del recuadro: single, none (sin borde) o 3D. 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ón Fill aparece deshabilitada.

Editor de Propiedades, Métodos y Eventos
A los controles (que tienen nombre asociado) que usamos en los forms se le pueden asociar 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 de propiedades/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 la opció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:

35

GENEXUS DISEÑO DE APLICACIONES

Fórmulas
Se dice que un atributo es una fórmula si su valor se puede calcular a partir del valor de otros atributos. En el ejemplo el atributo PedImp de la transacción de Pedidos se puede calcular a partir de la PedCnt y el PedPre: PedImp = PedCnt * PedPre En cada transacción se puede definir que atributos son fórmulas, pero esta definición es global, es decir toda vez que se necesite el atributo se calcula la fórmula, tanto en transacciones como en los otros objetos GENEXUS (reportes, Paneles de Trabajo, etc.). Existen distintos tipos de fórmulas: • Horizontales • Verticales • De agregación/selección

36

GENEXUS- DISEÑO DE APLICACIONES

Fórmulas Horizontales
Una fórmula horizontal se define como una o varias expresiones aritméticas condicionales. 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 del 20% si es mayor y en cualquier otro caso no hay descuento (en las fórmulas con condiciones es saludable definir siempre el OTHERWISE). La expresión puede utilizar los operadores aritméticos (+. -, *, /, ^) y funciones (por ejemplo 'today()' que devuelve la fecha del día), y para los casos en donde el calculo es muy complicado se puede llamar a una rutina que lo realice en vez de usar formulas: Descuento = udf('Pdesc', PedTot); En donde 'udf' viene de User Defined Function. 'Pdesc' es el nombre de la rutina llamada, que recibe como parámetro a PedTot y devuelve Descuento. Esta rutina puede ser una rutina externa a GENEXUS o escrita con GENEXUS utilizando el objeto Procedure. El importe del pedido también es una fórmula horizontal: PedImp = PedCnt * PedPre Vemos que la forma de definirla involucra a dos atributos (PedCnt y PedPre), pero no se indica en que tablas de encuentran. GENEXUS se encarga de buscar la manera de relacionar PedCnt y PedPre para poder calcular la fórmula (en este caso es muy fácil porque PedCnt y PedPre se encuentran en la misma tabla). En los casos en que no es posible 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 deben estar en la misma tabla extendida que la fórmula (ver el concepto de tabla extendida en el anexo sobre Bases de Datos Relacionales).

37

GENEXUS DISEÑO DE APLICACIONES

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

Fórmulas Verticales
Consideremos ahora el Total del pedido (PedTot), este se debe calcular sumando los Importes (PedImp) de cada una de las líneas del Pedido. Esta fórmula se expresa como: PedTot = SUM( PedImp ) Y es un caso de fórmula vertical, que se define como el tipo de fórmula en que los atributos involucrados no se encuentran dentro de la misma tabla extendida que la fórmula. En el caso de PedTot, si observamos el modelo de datos (usando el diagrama de tablas de GENEXUS ):

Tabla: PEDIDOS PedNro* PedFch PrvCod AnlNro PedTot 1 N Tabla: PEDIDOS1 PedNro* PedLinNro* ArtCod PedCnt PedPre PedImp

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

38

GENEXUS- DISEÑO DE APLICACIONES

Tablas superordinadas a Pedidos

Además de ver que tablas tiene subordinadas y superordinadas, podemos consultar la estructura 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 y COUNT 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órmula siempre puede ser calculada, no es necesario que la misma este almacenada y basta con recalcularla cada vez que sea necesario. Sin embargo el hecho que la fórmula no este almacenada puede ocasionar problemas de performance, debido al tiempo que pueda demorar el recálculo. Para evitar este inconveniente se puede definir la fórmula como REDUNDANTE. En este caso la fórmula se almacena en la Base de Datos y no es necesario recalcularla

39

GENEXUS DISEÑO DE APLICACIONES

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 todas las transacciones que utilicen esa fórmula. Tenemos entonces que la definición de fórmulas redundantes implica un balance de performance por un lado y almacenamiento y complejidad de los programas generados en otro, que el analista debe decidir. Si bien en teoría esta decisión puede ser bastante difícil de tomar, en la practica vemos que la mayor parte de las fórmulas que se definen redundantes son las verticales (mas adelante veremos que hay una forma 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 un número indeterminado de lecturas. Por ejemplo para calcular el PedTot se deben leer todas 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 pueden estar almacenados o ser otras fórmulas. Por ejemplo si en la transacción de Proveedores definimos: PrvTotPed = SUM( PedTot ) Total pedido del proveedor

tenemos que para calcularlo se necesita: PedTot = SUM( PedImp ) que a su vez necesita: PedImp = PedCnt * PedPre

Para fórmulas de fórmulas GENEXUS determina cual es el orden de evaluación correspondiente: PedImp PedTot PrvTotPed = PedCnt * PedPre = SUM( PedImp ) = SUM( PedTot )

40

GENEXUS- DISEÑO DE APLICACIONES

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

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 a campo). En el diálogo full-screen se asigna el valor por defecto si el usuario no digito nada en el campo. En el diálogo campo a campo primero se asigna el valor por defecto y luego se permite modificarlo.

Error
Es la regla para definir los controles que deben cumplir los datos, por ejemplo si queremos 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 precio debe ser mayor que 100' ) en pantalla y no se permite continuar hasta que el usuario ingrese un valor correcto o abandone la transacción. Una utilización relativamente común es incluir una regla de error() para prohibir alguna 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 prohibe la 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

41

GENEXUS DISEÑO DE APLICACIONES

las tablas que pertenecen a la tabla extendida del nivel. Veamos un ejemplo, en la transacción de Artículos: Artículos: ArtCod* ArtDsc ArtCnt ArtFchUltCmp ArtPrcUltCmp En el atributo ArtPrcUltCmp se desea almacenar cual fue el precio del último pedido realizado para ese articulo, y en que fecha fue realizado en ArtFchUltCmp. Esto se realiza 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 con la fecha y el precio correspondiente. Existe una similitud entre fórmulas y asignaciones, incluso la sintaxis de definición es similar. La diferencia entre ambas es que una fórmula es GLOBAL, es decir vale para todos 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 defina como 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, pero existen casos mas sofisticados. Por ejemplo en la misma transacción de Artículos tenemos el atributo ArtCnt en donde se quiere mantener cual es el stock que tenemos de cada articulo. Sin duda la transacción de Pedidos debe modificar ese valor, porque cada pedido nuevo aumenta el stock. También existirá alguna otra transacción que hace disminuir el stock, que podría ser por ejemplo una transacción de Facturación que se realiza cuando se vende el articulo. Como esta transacción esta fuera del alcance del proyecto solo estudiaremos la actualización del stock relacionada con la transacción de Pedidos. En dicha transacción se debe actualizar ArtCnt, esto se podría hacer con la Asignación:

42

GENEXUS- DISEÑO DE APLICACIONES

ArtCnt = ArtCnt + PedCnt; Pero no debemos olvidar que en la misma transacción se permite crear, modificar o eliminar un pedido, y la asignación anterior solo es correcta si se esta creando uno nuevo, 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 los casos de modificación y eliminación, pero para evitar todo esto GENEXUS posee la regla 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 de PedCnt (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, mas concretamente 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 redundante o add( PedImp, PedTot ); Dado que es común que las fórmulas verticales tengan que estar redundantes para tener 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 decir cuando 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ún identificador de la transacción. Por ejemplo en la transacción de Pedidos tenemos el PedLinNro y si queremos que este número sea asignado automáticamente por el sistema se puede usar la regla: serial(PedLinNro, PedUltLin, 1); En donde el primer parámetro define cual es el atributo que se esta numerando, el segundo 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 se incrementa de a uno). El atributo PedUltLin (Ultima línea asignada) debe ser incluido

43

GENEXUS DISEÑO DE APLICACIONES

en la estructura de la transacción en el nivel de PedNro (un pedido solo tiene UNA Ultima línea asignada): PedNro* .... PedUltLin ( PedLinNro* .... ) PedTot De esta manera para cada nueva línea del pedido el programa asigna automáticamente su número. En el diálogo campo a campo (donde la modalidad era inferida automáticamente), se debe digitar un valor inexistente en PedLinNro (usualmente 0) y el programa asigna el valor correspondiente. En el diálogo full-screen el valor se asigna cuando el usuario presiona Enter en modo Insertar.

Orden de evaluación
La definición de reglas es una forma DECLARATIVA de definir el comportamiento de la transacción. El orden en el cual fueron definidas no necesariamente indica que ese sea el orden en que se encuentran en el programa generado. GENEXUS se encarga de determinar el orden correcto según las dependencias de atributos existentes. 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 que se desea tener de ese artículo. Cuando se ingresa un pedido debemos emitir un mensaje si se sobrepasa el stock máximo de un artículo. Para ello definimos las siguientes reglas en la transacción de pedidos: msg( 'Se sobrepasa el stock máximo del artículo' ) if ArtCnt > ArtCntMax; add(PedCnt, ArtCnt); El orden de evaluación será:

44

GENEXUS- DISEÑO DE APLICACIONES

add(PedCnt, ArtCnt); 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 que ArtCntMax y no por ArtCnt + PedCnt mayor que ArtCntMax. Cada vez que se especifica una transacción se puede pedir la opción -"Detailed Navigation"- que lista cual es el orden de evaluación. En este listado se explícita en que orden se generarán (usualmente decimos 'se disparan'), no solo las reglas, sino tambié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. Este puede ser cualquier otro objeto GENEXUS, por ejemplo, de una transacción se puede llamar 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 disparar el Call. Por ejemplo, si en la transacción de Pedidos se quiere llamar a un reporte que imprime 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 le pasa. 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 de haber realizado la actualización. Se usa para algunos casos de numeración automática cuando no se quiere utilizar la regla serial para evitar problemas de control de concurrencia.

45

GENEXUS DISEÑO DE APLICACIONES

Insert | Update | Delete
Se dispara después de haber insertado, actualizado o eliminado el registro de la tabla base del nivel. Se usa fundamentalmente para llamar a procesos que realizan actualizaciones.

Level
Se dispara después de haber entrado todos los datos de un nivel. Se usa muchas veces para controles de totales, por ejemplo, si cuando se entra el cabezal del Pedido se digita un total (llamémosle PedTotDig) y se quiere verificar que este sea igual que el total 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íneas del pedido.

Trn
Se dispara después de haber entrado todos los datos de una transacción. Se usa fundamentalmente para llamar a programas que imprimen los datos o a otras transacciones. En ambientes con integridad transaccional esta regla se dispara luego que se realiza el commit de la transacción.

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

46

GENEXUS- DISEÑO DE APLICACIONES

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

47

GENEXUS DISEÑO DE APLICACIONES

DISEÑO DE REPORTES
Con Reportes se definen los procesos no interactivos de extracción de datos. Usualmente un Reporte es un listado que se envía a la impresora, aunque también puede ser visualizado en pantalla. Es un proceso no interactivo, porque primero se extraen los datos y luego se muestran, no habiendo interacción con el usuario durante el proceso de extracción, y es solo de extracción ya que no se pueden actualizar los datos leídos. Para consultas interactivas se utilizan los Paneles de Trabajo y para los procesos de actualización los Procedimientos. Para cada Reporte se debe definir: Información Datos generales del Reporte, por ejemplo nombre, descripción, etc. Layout Así como las Transacciones tienen una pantalla los Reportes tienen un layout de la salida. Condiciones Qué condiciones deben cumplir los datos para ser impresos. Reglas - Propiedades Definen aspectos generales del Reporte. Ayuda Texto para la ayuda a los usuarios en el uso del Reporte. Documentación Texto 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 se quieren listar y en que orden) y el formato de la salida. Para ello se utiliza un lenguaje procedural muy simple que describiremos brevemente a continuación. Comencemos por un Reporte para listar todos los proveedores:

48

GENEXUS- DISEÑO DE APLICACIONES

Literales

Bloque de impresion

Bloque de código

Atributos

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

49

GENEXUS DISEÑO DE APLICACIONES

La definición de reportes se divide en uno o varios bloques. Estos bloques pueden ser de código o de impresión . En los bloques de impresión se diseña la salida que posteriormente será impresa. Cada bloque de impresión puede tener un conjunto de controles (atributos, variables, textos, etc.). Podemos ver un bloque de impresión como un pedazo de papel. Los bloques de impresión (o Print Blocks) tienen asociadas ciertas propiedades, que pueden seteadas desde un dialogo que se abre al hacer doble-click sobre el 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 herramientas similar a las transacciones.

50

GENEXUS- DISEÑO DE APLICACIONES

La cual permite insertar atributos, textos, líneas, recuadros, bitmaps y nuevos bloques de impresión. Los controles son definidos de la misma forma en que se hace en el editor del form de las Transacciones (tipo de letra, color, tamaño, etc.). Todos los bloques de impresión que se encuentren entre los comandos HEADER y END son las líneas que se imprimen en el cabezal de la pagina. También existe el comando FOOTER 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 se encuentren entre el FOR EACH y el ENDFOR para cada uno de los datos que se encuentren en la base de datos. En este caso: PrvCod PrvNom PrvDir

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ón del acceso a la base de datos y la estructura del reporte se realizan solo 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 especifica de que tablas se deben obtener, ni que índices se deben utilizar. Por lo tanto, con este comando se define QUE atributos se necesitan y en qué ORDEN se van a recuperar, y GENEXUS se encarga de encontrar COMO hacerlo. Obviamente esto no siempre es posible, y en estos casos GENEXUS da una serie de mensajes de error 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 la especificación del Reporte sea del mas alto nivel posible, de tal manera que ante cambios en la base de datos la especificación del mismo se mantenga valida la mayor parte de las veces. 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 en el Anexo sobre Modelos de Datos Relacionales). Por ejemplo, en el Reporte anterior dentro del FOR EACH - ENDFOR se utilizan los atributos PrvCod, PrvNom y PrvDir, GENEXUS 'sabe' que estos atributos se encuentran en la tabla PROVEEDO y por lo tanto el comando:

51

GENEXUS DISEÑO DE APLICACIONES

For each PrvCod Endfor es interpretado por GENEXUS como: For each record in table PROVEEDO PrvCod Endfor Para clarificar el concepto hagamos un Reporte que involucre datos de varias tablas. Por ejemplo, listar el cabezal de todos los pedidos: PrvNom PrvDir PrvNom PrvDir

Fecha: 09/08/92 Listado de Pedidos Número 321 654 987 Fecha 02/02/92 03/03/92 03/03/92 Nombre Proveedor ABC Inc. GXXXX Corp. ABC Inc. Nombre Analista Juan Gomez Juan Gomez Pedro Perez

52

GENEXUS- DISEÑO DE APLICACIONES

El layout para este listado es:

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

53

GENEXUS DISEÑO DE APLICACIONES

En el listado anterior se requieren datos de las tablas PROVEEDO (PrvNom), ANALISTA (AnlNom) y PEDIDOS (PedNro y PedFch). La tabla extendida de PEDIDOS contiene a todos estos atributos y por lo tanto el comando FOR EACH se interpretará como: For each record in table PEDIDOS Find the corresponding PrvNom in table PROVEEDO Find the corresponding AnlNom in table ANALISTA PedNro Endfor PedFch PrvNom AnlNom

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

54

GENEXUS- DISEÑO DE APLICACIONES

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 )

Tablas a las cuales accede.

END FOR Donde la flecha doble ( --->> ) indica cual es la tabla base de la tabla extendida y la flecha simple ( ----> ) las tablas N-1 de la misma. Una interpretación muy práctica de este diagrama es: para la tabla de la flecha doble se leen muchos registros y para cada tabla con flecha simple se lee un solo registro por cada registro leído en la tabla con flecha 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 performance del Reporte. Para los casos en donde se quiere definir el orden de los datos de forma explícita se utiliza la cláusula ORDER en el comando FOR EACH, por ejemplo, para listar los pedidos ordenados por PrvCod: For each ORDER PrvCod PedNro 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 es la siguiente: PedFch PrvNom AnlNom

55

GENEXUS DISEÑO DE APLICACIONES

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

indice seleccionado

Si al listado anterior lo queremos ordenar por PedFch: For each ORDER PedFch PedNro Endfor PedFch PrvNom AnlNom

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 el mismo 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 en donde había un índice definido. Dada esta situación el analista debe tomar una decisión: Crear un índice del usuario. En este caso el Reporte será bastante más eficiente, pero se debe mantener un índice más (lo que implica mayor almacenamiento y mayor procesamiento en las transacciones para mantener actualizado el índice). Dejar el Reporte con el índice temporario.

56

GENEXUS- DISEÑO DE APLICACIONES

No es posible recomendar, a priori, cual de las dos soluciones es la mejor, por lo tanto se debe estudiar caso por caso la solución particular, siendo fundamental la frecuencia con 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 el Reporte (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 de atributos pertenecientes a la tabla base del grupo, pero no se puede ordenar por atributos que NO se encuentren en la misma. Por ejemplo el listado anterior no se puede ordenar por PrvNom porque la tabla base del grupo es la PEDIDOS que no tiene PrvNom. Si no existe un índice para el orden pedido se crea un índice temporario que se eliminará al finalizar el Reporte. Observar que este proceso es análogo a realizar un SORT 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. Por ejemplo, para listar sólo los pedidos de hoy: For each WHERE PedFch = Today() PedNro Endfor Se puede definir varios WHERE dentro del FOR EACH: For each WHERE PedFch = Today() WHERE PedNro > 100 PedNro Endfor Que significa que se deben cumplir AMBAS condiciones, o sea que se interpreta como 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 un solo WHERE: For each PedFch PrvNom AnlNom PedFch PrvNom AnlNom

57

GENEXUS DISEÑO DE APLICACIONES

WHERE PedFch = Today() OR PedNro > 100 PedNro Endfor GENEXUS posee una serie de mecanismos para optimizar el Reporte en función del orden del FOR EACH y de las condiciones del mismo, pero estas se aplican sólo a las condiciones que tienen la siguiente forma: WHERE <atributo> <operador> <valor> <código1> WHEN NONE <código2> Donde: <atributo> <operador> <valor> <código2> debe estar almacenado en la tabla base. debe ser = o >=. puede ser una constante o una variable. se ejecuta solo cuando no se entra en el For Each PedFch PrvNom AnlNom

En muchos casos es necesario ejecutar determinado código cuando en un For Each no se encuentra ningún registro. Para esto se usa el comando WHEN NONE. Es importante aclarar que si se incluyen For Eachs dentro del When None no se infieren Joins ni filtros de ningún tipo con respecto al For each que contiene el When None. 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 de optimización, pero no quiere decir que otras formas no sean válidas, al contrario, en el WHERE se pueden definir condiciones para atributos que son fórmulas, que no se encuentran 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 debe utilizar. 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:

58

GENEXUS- DISEÑO DE APLICACIONES

For each PedNro Endfor Según ya vimos todos estos atributos se encuentran dentro de la tabla extendida de PEDIDOS, sin embargo, también se encuentran dentro de la tabla extendida de PEDIDOS1 (Línea del pedido), pero la tabla extendida de PEDIDOS está contenida en la de PEDIDOS1 (porque justamente la de PEDIDOS1 contiene a la de PEDIDOS ademá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 EACH debe haber por lo menos un atributo que pertenezca a la tabla base. Por ejemplo, en el Reporte que estamos realizando hay dos atributos pertenecientes a la tabla base PEDIDOS (PedNro y PedFch), si ellos no estuvieran y el listado fuera: For each PrvNom Endfor se podría argumentar que la tabla extendida de PEDIDOS continúa siendo válida, sin embargo por razones de simplicidad GENEXUS en este caso indicará que no hay relación entre estos dos atributos y será necesario que se utilice algún atributo de la tabla PEDIDOS para poder generar el Reporte. También puede darse el caso que exista más de una tabla extendida mínima que contenga a los atributos del grupo FOR EACH - ENDFOR. Ante esta ambigüedad GENEXUS escoge la PRIMERA tabla extendida que cumpla con las condiciones anteriores. Para resolver estos dos problemas (no hay ningún atributo de la tabla base y hay más de una tabla extendida mínima posible), se utiliza la cláusula DEFINED BY dentro del comando FOR EACH, por ejemplo: For each Defined by PedFch PedNro Endfor PedFch PrvNom AnlNom AnlNom PedFch PrvNom AnlNom

59

GENEXUS DISEÑO DE APLICACIONES

En el DEFINED BY se debe hacer referencia a por lo menos un atributo de la tabla base que se quiere. Aún en los casos que no se dan ninguno de los problemas anteriores se recomienda el uso del DEFINED BY para Reportes más o menos complejos porque mejora bastante el 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 es posible utilizar mas de un FOR EACH para realizar Reportes más sofisticados. Supongamos que queremos listar para cada proveedor cuales son sus pedidos, por ejemplo:

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

60

GENEXUS- DISEÑO DE APLICACIONES

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

61

GENEXUS DISEÑO DE APLICACIONES

En este Reporte tenemos dos FOR EACH anidados. Si analizamos el primer FOR EACH vemos que utiliza sólo los atributos PrvCod y PrvNom y por lo tanto su tabla extendida será la de la tabla PROVEEDO, el segundo FOR EACH utiliza los atributos PedNro y PedFch y su tabla extendida será la de PEDIDOS. Pero el segundo FOR EACH se encuentra anidado respecto al primero y a su vez la tabla PEDIDOS esta subordinada a PROVEEDO (por PrvCod) por lo tanto GENEXUS interpretara el Reporte 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 pedidos en la tabla de pedidos. Más formalmente, cuando hay dos FOR EACH anidados, GENEXUS busca cual es la relación de subordinación existente entre la tabla base del segundo FOR EACH y la tabla extendida del primer FOR EACH (en el caso anterior la relación era que la tabla PEDIDOS estaba subordinada a la tabla PROVEEDO por PrvCod) y establece de esta manera la condición que deben cumplir los registros del segundo FOR EACH (en el

62

GENEXUS- DISEÑO DE APLICACIONES

ejemplo: todos los registros de la tabla PEDIDOS con el mismo PrvCod leído en el primer 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 son PrvCod y PrvNom) y la del segundo FOR EACH es la ANALISTA (porque los atributos 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 producto cartesiano entre los dos FOR EACH, es decir, para cada registro de la tabla PROVEEDO (proveedores) se imprimirán todos los registros de la tabla ANALISTA (analistas).

63

GENEXUS DISEÑO DE APLICACIONES

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:

64

GENEXUS- DISEÑO DE APLICACIONES

El layout es:

La tabla base del primer FOR EACH es la PEDIDOS (por usar PedFch) y la del segundo FOR EACH también (por usar PedNro y PrvNom). Este es un caso de corte de control sobre la tabla PEDIDOS y GENEXUS lo indica en el Listado de Navegación con la palabra BREAK en vez de FOR EACH. Los cortes de control pueden ser de varios niveles, por ejemplo, si quisiéramos listar los pedidos por fecha y dentro de cada 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 en los FOR EACH ya que es la forma de indicarle a GENEXUS por qué atributos se está realizando el corte de control

65

GENEXUS DISEÑO DE APLICACIONES

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

Los listados con FOR EACH paralelos son muy prácticos cuando se quiere hacer listados del tipo 'Listar toda la Información que se tenga sobre un Proveedor', en donde 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

66

GENEXUS- DISEÑO DE APLICACIONES

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

Definición de Variables
Antes de describir los comandos en si es bueno detenernos en el concepto de Variable. Ya vimos que los datos se almacenan en la base de datos en atributos, pero muchas veces se necesita utilizar Variables, que se diferencian de los atributos por ser locales al Reporte y no estar almacenadas en la base de datos. Una Variable es reconocida 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 que indica cual es la página que se está imprimiendo, etc. Se deben definir las características (tipo, largo, decimales, etc.) de las variables que se estén utilizando en el Reporte, con excepción de las predefinidas.

67

GENEXUS DISEÑO DE APLICACIONES

Las variables se pueden definir también en función de otros atributos, usando la opció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 mostrar totales en un listado:

68

GENEXUS- DISEÑO DE APLICACIONES

69

GENEXUS DISEÑO DE APLICACIONES

El layout es:

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

70

GENEXUS- DISEÑO DE APLICACIONES

En el ejemplo anterior:

El comando DO WHILE-ENDDO es muy usado para imprimir varias vías, por ejemplo si se quiere imprimir dos vías del Pedido. FOR EACH order PedNro &I = 0 DO WHILE &I < 2 &I = &I + 1 // Imprimir pedido .... ENDDO ENDFOR

Llamadas a otros Programas y a Subrutinas
Con el comando CALL se puede llamar a otro programa, éste puede ser otro programa GENEXUS 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 a ParameterN 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 programa llamado. Cuando desde un Reporte se llama a otro Reporte, que también imprime, es importante pasarle como parámetro la variable predefinida &Line (que contiene el número de línea que se está imprimiendo) para que el Reporte llamado no comience en una página nueva.

71

GENEXUS DISEÑO DE APLICACIONES

Con el comando DO se llama a una subrutina que se encuentra dentro del mismo Layout. En este caso no son necesarios los parámetros porque están disponibles para la subrutina los mismos datos (variables) que están disponibles en el lugar donde se hace 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 el segundo la PEDIDOS.

72

GENEXUS- DISEÑO DE APLICACIONES

Ahora bien, el primer FOR EACH es independiente del segundo y por lo tanto se imprimirán los datos del primer FOR EACH ANTES de determinar si hay datos en el segundo 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 debe usar el comando Print if detail:

Este comando define que el FOR EACH en donde se encuentre debe usar como tabla base la misma tabla base del siguiente FOR EACH. En el ejemplo el primer FOR EACH pasará a estar basado en la tabla PEDIDOS y no en la PROVEEDO y por lo tanto 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 misma tabla base, se está definiendo implícitamente un corte de control. Por lo tanto se DEBE definir explícitamente el ORDEN en el primer FOR EACH. Existen otros comandos como ser EJECT (salta de hoja), NOSKIP, etc. que se detallan en el Reference Manual.

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

73

GENEXUS DISEÑO DE APLICACIONES

Es equivalente a la cláusula WHERE del comando FOR EACH (incluso tienen la misma sintaxis), con la diferencia que el WHERE se aplica a un solo FOR EACH y las condiciones definidas aquí se aplicarán a TODOS los FOR EACH que correspondan. En el 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 el usuario elija los valores cuando se ejecuta el Reporte. Por ejemplo, si en el Reporte que lista 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 se almacena en las variables &ask1, &ask2, etc. según el orden de aparición de los ask() en las 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 Reportes son:

Default
Define el valor por defecto de los ask(). En el ejemplo anterior: default(&ask1, 1); default(&ask2, 9999);

74

GENEXUS- DISEÑO DE APLICACIONES

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

Parm
Es una lista de atributos o variables que recibe el Reporte como parámetros. Por ejemplo, si hacemos un Reporte para imprimir un pedido inmediatamente después de haberlo 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 una condición sobre los datos. En el ejemplo, al recibir como parámetro PedNro el primer FOR EACH (que esta basado en la tabla PEDIDOS que contiene PedNro) tiene como condición que PedNro sea igual al parámetro y no es necesario poner un WHERE. Si se hubiera recibido el parámetro como una variable, entonces sí es necesario definir el WHERE. Layout FOR EACH WHERE PedNro = &Pedido .... ENDFOR Reglas Parm(&Pedido);

75

GENEXUS DISEÑO DE APLICACIONES

Report Wizard
El Report Wizard permite realizar el diseño del layout de los Reportes y Procedimientos de 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 de datos 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, los paréntesis se usan para indicar niveles de FOR EACH (en vez de niveles de una transacción) y el asterisco (‘*’) se usa para indicar el orden deseado (y no para indicar la unicidad como en las transacciones). Las reglas que son usadas para definir la estructura de una transacción también se aplican al definir la estructura del layout.

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

76

GENEXUS- DISEÑO DE APLICACIONES

Paso 2: Permite definir otras características del layout. Se permite elegir los fonts para representar los atributos o textos, también se permite definir si los cabezales de los atributos para cada uno de los niveles se despliegan horizontalmente o verticalmente. El dialogo del paso 2 para la estructura de datos usada en el paso 1 se ve de la siguiente manera:

Como se puede ver, el nivel para el cual estamos definiendo el tipo del layout se presenta en un color diferente. Para este nivel, seleccionaremos el tipo vertical de layout y para el segundo nivel nos aseguraremos que el check box correspondiente al tipo de layout 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 los atributos dejamos el default. Presionando el botón de “Finish” se graban las definiciones para el paso actual y se sale del dialogo del Report Wizard.

77

GENEXUS DISEÑO DE APLICACIONES

El reporte generado es el siguiente:

Una vez que todas las opciones del Wizard fueron aceptadas, se genera el layout del reporte, el cual puede ser modificado como cualquier otro reporte. Vemos que el diseño del 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 al usuario en tiempo de ejecución. Prompt for Confirmation: Si deseamos que se pida confirmación al usuario.

78

GENEXUS- DISEÑO DE APLICACIONES

Allow User to Cancel Processing. Footer on Last Page: Imprimir el footer en la última pantalla.

79

GENEXUS DISEÑO DE APLICACIONES

DISEÑO DE PROCEDIMIENTOS
Los Procedimientos son el objeto GENEXUS con el que se definen todos los procesos no interactivos 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 puede realizar como un Procedimiento) más algunas características particulares para la actualización de la base de datos. Por esta razón se recomienda haber leído previamente el capítulo Diseño de Reportes. Vamos a ver entonces los comandos disponibles en los procedimientos para la actualizació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 no hay un comando específico de modificación (como podría ser REWRITE), sino que basta con asignar un valor a un atributo dentro de un For Each para que automáticamente se realice la modificación. Por ejemplo supongamos que queremos tener un proceso batch que actualiza el atributo ArtPrcUltCmp para adecuarlo según la inflación para todos los Artículos almacenados: 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, si también queremos modificar el atributo ArtFchUltCmp, poniéndole la fecha de hoy: For each ArtPrcUltCmp = ArtPrcUltCmp * (1 + &Inf) ArtFchUltCmp = Today( ) Endfor

80

GENEXUS- DISEÑO DE APLICACIONES

La modificación en sí se realiza en el ENDFOR y no cuando se realiza la asignación del atributo. En estos dos ejemplos se modificaron atributos de la tabla base del FOR EACH, pero también es posible actualizar atributos de las tablas N-1 (tabla extendida) con el mismo mecanismo de asignación de atributos. No todos los atributos pueden ser modificados. Por ejemplo, no se pueden modificar los pertenecientes a la clave primaria de la tabla base del FOR EACH (en este caso ArtCod). Tampoco se pueden modificar los atributos que pertenecen al índice (el orden) 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án actualizando marcando con un + estas tablas. Por ejemplo: ------>> + ARTICULO

Eliminación de datos
Para eliminar datos se utiliza el comando DELETE dentro del grupo FOR EACHENDFOR. Por ejemplo, si queremos eliminar todos los pedidos con fecha anterior a una fecha dada: For each where 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 DELETE Endfor

Creación de datos
Para crear nuevos registros en la base de datos se usan los comandos NEWENDNEW. Tomemos por ejemplo un Procedimiento que recibe como parámetros AnlNro y AnlNom e inserta estos datos en la tabla de analistas:

81

GENEXUS DISEÑO DE APLICACIONES

Programa: New AnlNro = &Nro AnlNom = &Nom Endnew Reglas: Parm( &Nro, &Nom );

Con este procedimiento se pueden crear registros en la tabla de analistas utilizando una subrutina. El comando NEW realiza el control de duplicados, y solo creará el registro si ya no se encuentra en la tabla. Con la cláusula WHEN DUPLICATE se programa la acción a realizar en caso de duplicados. Por ejemplo, en el caso anterior si se quiere que si el analista ya estaba registrado se actualice el AnlNom: New AnlNro = &Nro AnlNom = &Nom When Duplicate For each AnlNom = &Nom Endfor Endnew Observar que para realizar la modificación de atributos las asignaciones se deben encontrar 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 el de control de duplicados en el comando NEW. Pero NO se controla automáticamente la integridad referencial, por ejemplo, si hacemos un Procedimiento que crea automáticamente Pedidos, no se controlará que el PrvCod que se 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 mantenidas explícitamente con los comandos de asignación/update.

82

GENEXUS- DISEÑO DE APLICACIONES

DISEÑO DE PANELES DE TRABAJO
Con Paneles de Trabajo (o Work Panels) se definen las consultas interactivas a la base de datos. Si bien éste es un objeto muy flexible que se presta para múltiples usos, es especialmente útil para aquellos usuarios que utilizan el computador para pensar o para tomar decisiones. La forma de programar los Paneles de Trabajo esta inspirada en la programación de los ambientes gráficos, especialmente la programación dirigida por eventos. Para cada Panel de Trabajo se debe definir: Información Datos generales del Panel de Trabajo, por ejemplo nombre, descripción, etc. Form Al igual que las transacciones, se debe definir el form con el que interactuará el usuario. Eventos Aquí se define la respuesta a los eventos que pueden ocurrir durante la ejecución del Panel de Trabajo. Por ejemplo que respuesta dar cuando el usuario presionó Enter o un botón, etc. Condiciones Define que condiciones deben cumplir los datos para ser presentados en la pantalla. Son equivalentes a las Condiciones de los Reportes y Procedimientos. Reglas Definen aspectos generales del Panel de Trabajo, por ejemplo orden de los datos a mostrar, parámetros, etc. Ayuda Texto para la ayuda a los usuarios en el uso del Panel de Trabajo. Documentación Texto técnico para ser utilizado en la documentación del sistema. Propiedades Propiedades generales del Work Panel.

83

GENEXUS DISEÑO DE APLICACIONES

En este capítulo solo se presentarán las características y usos más salientes de los Paneles de Trabajo, pero se recomienda leer el capítulo de Paneles de Trabajo en el Manual de Usuario 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 de consultas encadenadas. Estas consultas comienzan con un Panel de Trabajo de proveedores, donde el usuario selecciona para luego realizar alguna acción, en este caso para cada proveedor seleccionado 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 abre una ventana donde se muestran los datos del proveedor:

84

GENEXUS- DISEÑO DE APLICACIONES

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

A su vez este Panel de Trabajo podría extenderse, permitiendo seleccionar algún pedido para 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 existen otras acciones que no se aplican a ninguna línea en particular, por ejemplo Insertar un

85

GENEXUS DISEÑO DE APLICACIONES

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

Renovar - es una acción incluída automáticamente por GENEXUS y, si se elige, se vuelven 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

Subfile

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

86

GENEXUS- DISEÑO DE APLICACIONES

Cuando se define un subfile en el form se está indicando que se va a mostrar una cantidad indefinida de datos (en este caso los proveedores). Si bien sólo se pueden ver simultáneamente las líneas presentes en la pantalla, GENEXUS provee todos los mecanismos 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. Los SubFile pueden contener además de atributos, variables y arrays de una y dos dimensiones.

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

Insertar el control tipo Subfile

87

GENEXUS DISEÑO DE APLICACIONES

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 el boton “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 los tabs “Colors” y “Fonts” podemos cambiar los colores y el tipo de letra de las columnas. Con el tab Control Info se selecciona el tipo de control a utilizar, y dado el tipo, 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 la columna). Podemos también ajustar manualmente el ancho de cada columna desmarcando la opción de “Auto Resize”, si esta opción queda marcada el ancho de la columna lo determina 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 una barra de scroll horzontal (además de la de scroll vertical que aparece automáticamente)

88

GENEXUS- DISEÑO DE APLICACIONES

Eventos
La forma tradicional de programar la interfaz entre el usuario y el computador (incluídos los lenguajes de cuarta generación) es subordinar la pantalla al programa. Es decir, desde el programa se hacen 'calls' a la pantalla. En Paneles de Trabajo es lo opuesto: el programa está subordinado a la pantalla, ya que una pantalla realiza 'calls' al programa para dar respuesta a un evento. Esta forma de trabajar es conocida como EVENT DRIVEN (dirigida por eventos) y es típica de los ambientes GUI (Interfaz de Usuario Gráfica), en donde ya ha demostrado su productividad, fundamentalmente porque se necesita programar sólo la respuesta a los eventos 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 base de datos (para cada registro leído se genera un 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 en Reportes y Procedimientos, aunque no están permitidos ni los comandos relacionados con la 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.

89

GENEXUS DISEÑO DE APLICACIONES

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

Evento Enter
Este evento se dispara cuando el usuario presiona ENTER. Consideremos el siguiente ejemplo: borrar un conjunto de proveedores. Entonces se define una nueva variable en el subfile, &Op, y por cada línea que se le asocie la opción 4 se llama a un procedimiento que borra los clientes. El código asociado al evento enter en este caso es el siguiente: Event Enter For each line If &op = '4' Call(PDltPrv, PrvCod) Else If &op <> ' ' &msg = concat(&op, ' no es una opción valida') Msg( &msg ) Endif Endif Endfor Endevent El evento Enter es un poco más extenso y vale la pena detenernos en él. En primer lugar se utiliza el comando FOR EACH LINE que realiza un FOR EACH, pero no sobre los datos de la base de datos, sino sobre el SubFile.

90

GENEXUS- DISEÑO DE APLICACIONES

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 la opción no es válida. Notar que se podrían haber definido mas opciones y preguntar por 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 detalles sobre como llamar de un Panel de Trabajo a una Transacción ver el capítulo de Paneles de Trabajo en el Manual de Referencia). Luego de llamar a la transacción, se ejecuta el comando Refresh, que indica que se debe cargar nuevamente el SubFile, ya que se ha adicionado un nuevo proveedor. También se podría haber usado el comando con el parámetro keep (Refresh Keep) que hace que una vez que el comando refresh se ejecuta el cursor queda posicionado en la misma línea del subfile que estaba antes de la ejecución.

Evento Refresh
Los datos que se presentan en pantalla son los cargados en el SubFile, que a su vez fueron cargados desde la base de datos. En un ambiente multi-usuario, los datos de una pantalla pueden haber quedado desactualizados si desde otra terminal fueron modificados. Cuando el usuario desea actualizar 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 el SubFile. Por ejemplo, cuando en otro evento se llama a una transacción que actualiza los datos (es el caso del Evento 'Crear Proveedor').

91

GENEXUS DISEÑO DE APLICACIONES

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 hay un 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 el SubFile con los datos obtenidos de la base de datos. Para determinar de que tablas se deben obtener los datos, GENEXUS utiliza el mismo mecanismo 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 se encuentran en la parte fija de la misma). • Todos los atributos que se encuentren en los Eventos, con la excepción de 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ón entre 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 el que se presenta en pantalla. Esta carga se realiza 'bajo pedido', es decir que al

92

GENEXUS- DISEÑO DE APLICACIONES

comienzo sólo se carga la primera página y, a medida que el usuario requiere más información, se van cargando las siguientes páginas. Existe una propiedad para indicar 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 de Trabajo 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 hay atributos ni en la pantalla ni en los eventos ni en las reglas Hidden y Order (porque se usan sólo variables). En este caso se genera sólo UN evento Load y es en éste donde se 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 tanto antes 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 se puede 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 SubFile sin tener que salir de la pantalla. Por ejemplo, si queremos visualizar sólo un rango de proveedores, agregamos en la pantalla las variables:

93

GENEXUS DISEÑO DE APLICACIONES

Variables para ingresar el proveedor final y inicial.

Y definiendo las condiciones:

se obtiene el efecto deseado.

94

GENEXUS- DISEÑO DE APLICACIONES

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

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

Order
Define cual es el orden de los datos del SubFile. Es equivalente a la cláusula ORDER del FOR EACH y se aplica todo lo dicho en el capítulo Diseño de Reportes sobre el tema (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 es aceptado (siempre se muestra su valor pero no se permite modificarlo). Para variables se sigue el siguiente criterio: • Todas las variables presentes en la pantalla son aceptadas, a no ser que tengan la regla NOACCEPT. Por ejemplo, en un Panel de Trabajo que deseemos poner la fecha en el form, se necesita la regla: noaccept( &Fecha );

Search
Cuando el SubFile es demasiado extenso, muchas veces se quiere brindar la posibilidad de que el usuario pueda 'posicionarse' en alguna línea determinada del mismo, en forma directa, sin tener que avanzar página por página. Por ejemplo si en nuestro Panel de Trabajo de proveedores queremos que exista la posibilidad de buscar un proveedor según su nombre, se debe definir la regla: search( PrvNom >= &Nom );

95

GENEXUS DISEÑO DE APLICACIONES

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, el SubFile quedará posicionado en el primer proveedor con PrvNom mayor o igual al digitado. 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 se quieren utilizar los criterios de optimización se deben usar las Condiciones.

96

GENEXUS- DISEÑO DE APLICACIONES

Bitmaps
Los bitmaps son usados usualmente para mejorar la presentación de las aplicaciones. Se pueden 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 de herramientas. De esta forma tenemos que indicar su ubicación. Agreguemos un logo en el work panel que permite visualizar los datos de un proveedor. El nuevo form se vera 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 la función Loadbitmap puedo cargar el Bitmap que yo desee. Por ejemplo se puede tener un Bitmap que despliegue la foto de cada proveedor.

97

GENEXUS DISEÑO DE APLICACIONES

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

98

GENEXUS- DISEÑO DE APLICACIONES

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 me calcule el total pedido en la transacción de proveedores:

99

GENEXUS DISEÑO DE APLICACIONES

Definimos entonces un nuevo atributo, “PrvTotPed” y decimos que este atributo es una formula Sum vertical del atributo PedTot, de esta forma estamos definiendo el total Pedido de un proveedor como la suma de todos los totales de los pedidos de ese proveedor. 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 work panel.

100

GENEXUS- DISEÑO DE APLICACIONES

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

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

101

GENEXUS DISEÑO DE APLICACIONES

102

GENEXUS- DISEÑO DE APLICACIONES

Properties

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

103

GENEXUS DISEÑO DE APLICACIONES

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

Menúes Trn Rpt Proc

Selección de la Acción

Aplicar la acción al objeto

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

104

GENEXUS- DISEÑO DE APLICACIONES

Menúes Paneles de Trabajo Trn Rpt Proc

Selección del tipo de objeto

Selección del objeto y la Acción Aplicar la acción al objeto

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

105

GENEXUS DISEÑO DE APLICACIONES

DISEÑO DE MENÚES
Este objeto permite definir los diferentes menúes de la aplicación. La definición de un menú es muy fácil, y prácticamente lo único que se requiere es definir las opciones del mismo. Ejemplo: Menú Principal del Sistema de Compras

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

106

GENEXUS- DISEÑO DE APLICACIONES

Es un menú de selección implícita, es decir la opción se selecciona directamente con el Mouse. El mismo menú generado para Visual Basic tiene el siguiente formato:

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

107

GENEXUS DISEÑO DE APLICACIONES

En donde se utiliza la técnica de selección explícita, donde para seleccionar la opción se debe 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 User Access) de IBM.

Call Browser
Este browser despliega todos los objetos que se llaman a través de los comandos call y udp. Dado un programa podemos ver su árbol de llamadas (a que programas llama) y desde que 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:

108

GENEXUS- DISEÑO DE APLICACIONES

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

109

GENEXUS DISEÑO DE APLICACIONES

ANEXO A. MODELOS DE DATOS RELACIONALES
El propósito de este Anexo es explicar una serie de conceptos sobre Bases de Datos Relacionales 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 en Tablas. 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 o Tuplas. Por ejemplo la Tabla de Proveedores:

PROVEEDO PrvCod 125 126 PrvNom ABC Inc. GXXXX Corp. PrvDir Xxxxxxxxx Yyyyyyy

Una Tabla se diferencia de un archivo convencional porque debe cumplir las siguientes 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 los proveedores, y no puede ocurrir que para algunos proveedores en ese atributo se almacene la dirección del mismo. En la práctica esta regla implica que no existen 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.

110

GENEXUS- DISEÑO DE APLICACIONES

Clave primaria y Claves candidatas
Dado que no puede haber dos registros con la misma información, siempre se puede encontrar 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 llamamos Clave Candidata. Por ejemplo en la tabla PROVEEDO tanto PrvCod como PrvNom son claves candidatas, ya que no existen dos proveedores con el mismo código, pero tampoco hay dos proveedores con el mismo nombre. En una Base de Datos Relacional sólo una de las claves candidatas debe ser definida como la Clave Primaria. También se debe respetar la siguiente regla: no deben existir dos 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 era relativamente común cuando el criterio de diseño era separar las actualizaciones (por ejemplo dado que PrvDir cambia mas que PrvNom, entonces es mejor definir un archivo diferente en donde el registro que se modifica es menor, y por lo tanto de mejor performance). Sin embargo en una Base de Datos Relacional el criterio de diseño es diferente (ver sección de Normalización) y es preferible una sola tabla con los tres atributos: Tabla: PROVEEDO Atributos: PrvCod* PrvNom PrvDir

111

GENEXUS DISEÑO DE APLICACIONES

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 en el control de unicidad de los registros. Con GENEXUS todos los índices primarios son definidos automáticamente a partir de los identificadores de las transacciones. Los índices extranjeros son utilizados para hacer eficientes los controles de integridad inter-tablas. También son definidos automáticamente. Los índices del usuario se definen, fundamentalmente, para recorrer los datos por determinado orden de una forma eficiente. Por ejemplo en la tabla PROVEEDO se puede definir un índice por PrvNom, que es muy útil para los listados ordenados por nombre. Los índices del usuario NO son definidos automáticamente. 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.

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 la PROVEEDO (Proveedores):

112

GENEXUS- DISEÑO DE APLICACIONES

N 1

La relación entre estas dos tablas se determina analizando los atributos que tienen en común, por ejemplo aquí tenemos que el atributo común es PrvCod, que es la clave primaria 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 Pedido sólo tiene un Proveedor. También es usual decir que la tabla de proveedores esta superordinada 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 vez que se realicen modificaciones en una de las tablas, se deben tener un cuenta los datos de la otra tabla. A estos controles se les llama de integridad referencial y son: • Cuando se elimina un registro en la tabla superordinada (PROVEEDO), no deben existir registros correspondientes en la tabla subordinada (PEDIDOS). • Cuando se crean registros en la tabla subordinada (PEDIDOS), debe existir el registro correspondiente en la tabla superordinada (PROVEEDO). Para hacer eficiente el primer control se utiliza el índice extranjero por PrvCod en la tabla PEDIDOS y para el segundo el índice primario también por PrvCod en la tabla PROVEEDO.

113

GENEXUS DISEÑO DE APLICACIONES

El diagrama anterior se ha inspirado en los conocidos Diagramas de Bachman, y tiene justamente 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 los atributos de la base de datos. El criterio que se sigue es básicamente determinar una estructura tal de la base de datos, que la posibilidad de inconsistencia en los datos sea mínima. Por ejemplo, si tenemos que almacenar información sobre Proveedores y Pedidos, se podría tener la siguiente estructura: Tabla: PROVEEDO PrvCod* PrvNom PrvDir Tabla: PEDIDOS PedNro* PedFch PrvCod PrvNom AnlNro PedTot

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 el identificador de los Proveedores, y por lo tanto debe estar en la de Pedidos para indicar a que Proveedor corresponde el Pedido. La situación es diferente para PrvNom, ya que no es necesario que esté en la tabla de Pedidos, porque si conocemos el PrvCod podemos determinar cual es su PrvNom (basta con buscar en la tabla PROVEEDO por la clave primaria). Si de cualquier manera se almacena el PrvNom en la tabla PEDIDOS tenemos que esta estructura tiene más posibilidades de inconsistencia que si no estuviera allí. Por ejemplo si un Proveedor cambia su PrvNom, el programador debe encargarse de tener un programa que lea todos los Pedidos de ese Proveedor y le ponga el nuevo PrvNom.

114

GENEXUS- DISEÑO DE APLICACIONES

Entonces la estructura correcta (diremos 'normalizada') será: Tabla: PROVEEDO PrvCod* PrvNom PrvDir Tabla: PEDIDOS PedNro* PedFch PrvCod AnlNro PedTot

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 del segundo sólo existe UN valor del primero. Por ejemplo PrvNom depende funcionalmente de PrvCod porque para cada valor de PrvCod sólo existe UN valor de PrvNom. En realidad la definición es algo mas amplia, ya que se define que un conjunto de atributos 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 datos se basa en minimizar la posibilidad de inconsistencia en los datos. Una base de datos diseñada de esta manera tiene una serie de ventajas importantes (tal es así que actualmente la normalización de datos es un standard de diseño), pero se deben tener en cuenta también algunos inconvenientes. El inconveniente más notorio es que los datos se encuentran dispersos en muchas tablas, y por lo tanto cuando se quieren hacer consultas mas o menos complejas a la base 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 y PEDIDOS. Para simplificar esta tarea GENEXUS utiliza el concepto de Tabla Extendida, cuya definición es:

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

115

GENEXUS DISEÑO DE APLICACIONES

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 tabla Pedidos, más todos los atributos de Proveedores y todos los de Analistas, pero no los atributos de la Linea del pedido o de Artículos (porque si bien están relacionados, su relación no es N-1). En el siguiente diagrama se muestra, para cada una de las tablas del modelo, cual es su tabla extendida:

116

GENEXUS- DISEÑO DE APLICACIONES

Tabla base Proveedores Analistas Pedidos Linea_pedidos

Tabla extendida Proveedores Analistas Pedidos, Proveedores, Analistas 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 tablas extendidas y no con tablas físicas. Por ejemplo el comando FOR EACH determina una tabla extendida y no una tabla física.

117

GENEXUS DISEÑO DE APLICACIONES

ANEXO B. FUNCIONES, REGLAS Y COMANDOS
FUNCIÓN MANEJO DE FECHAS Day Month Year Today Dow Cdow Cmonth Ctod Dtoc Ymdtod Addmth Addyr Age Eom MANEJO DE STRINGS Str Substr Concat Space Len Trim Ltrim Rtrim Upper Lower Int Round Val OTRAS DESCRIPCIÓN Numero de día de una fecha Numero de mes de una fecha Año de una fecha Fecha de hoy Numero del día de la semana Nombre del día de una fecha Nombre del mes de una fecha Pasar de tipo carácter a tipo fecha Pasar de tipo fecha a carácter Armar fecha a partir de año, mes y día Sumar un mes a una fecha Sumar un año a una fecha Diferencia en años entre dos fechas Fecha fin de mes de una fecha

Pasar un numérico a string Substring de un string Concatenar dos strings Definir un strings con “n” blancos Largo de un string Quita los caracteres en blanco de un string Quita los caracteres en blanco al principio de un string Quita los caracteres en blanco al final de un string Convierte un string a mayúsculas Convierte un string a minúsculas Parte entera de un numérico Redondear un valor numérico Pasar un string a numérico

118

GENEXUS- DISEÑO DE APLICACIONES

Old Previous Time Systime Sysdate Userid Usercls Wrkst Ask Udf Udp Null( <Att|Var> ) Nullvalue( <Att|Var> ) LoadBitmap RGB (<R>,<G>,<B>) Color(<GXColor>)

Valor del atributo antes de ser modificado Valor del atributo en la última inserción Hora Hora del sistema Fecha del sistema Identificación del usuario Clase de usuario Workstation Para pedir valores por pantalla Función definida por el usuario Procedimiento definido por el usuario Si un atributo tiene valor nulo o no Devuelve el valor nulo de un atributo Carga un bitmap Retorna el numero que representa al color RGB determinado por los 3 parametros Retorna el numero que representa al color pasado como parametro

ORDEN DE DISPARO DE LAS
REGLAS EN LAS TRANSACCIONES

After(Insert) After(Update) After(Delete) After(Confirm) After(Trn) After( <Att> ) After(Level( <Att> )) Level( <Att> ) Modified() Insert Update Delete

Luego que se inserto el registro Luego que se actualizo el registro Luego que se dio de baja el registro Luego que se confirmo el nivel (todavía no se hizo la modificación del registro) Luego que termina la transacción Después de un atributo Luego que finaliza determinado nivel Nivel de una transacción Si fue modificado algún atributo de un nivel Si la transacción esta en modalidad insert Si la transacción esta en modalidad update Si la transacción esta en modalidad delete

119

GENEXUS DISEÑO DE APLICACIONES

REGLAS Default Equal Add Subtract Serial Msg Error Noaccept Call Submit Parm Nocheck Allownulls Refcall Refmsg Prompt Noprompt Accept Default_mode Noconfirm Color Order Search Hidden Noread Printer

DESCRIPCIÓN Dar un valor por defecto a un atributo Asigna un valor en modalidad insert y funciona como filtro en update y delete. Sumar un valor a un atributo teniendo en cuenta la modalidad de la transacción Restar un valor a un atributo teniendo en cuenta la modalidad de la transacción Numerar serialmente atributos Desplegar un mensaje Dar un error No aceptar atributo o variable en la pantalla Llamar a un programa Someter una llamada a un programa Para recibir los parámetros No realizar el control de integridad referencial Permitir ingresar valores nulos Hacer un call cuando falla el control de integridad referencial Mensaje que se despliega cuando falla el control de integridad referencial Asociar al prompt un objeto definido por nosotros Inhibe la lista de selección Aceptar atributo o variable en la pantalla Modalidad por defecto al ingresar en una transacción No pedir confirmación al final de un determinado nivel Dar colores a los atributos, variables y fondo Orden de la tabla base del Work Panel Condición de búsqueda sobre el subfile Para incluir variables o atributos en el subfile Inhibe la lectura de atributos Para seleccionar el printer file en el

T

W R

P

120

GENEXUS- DISEÑO DE APLICACIONES

AS/400

T = Transacciones W = Work Panels R = Reportes P = Procedimientos Las casillas que aparecen marcadas indican que la función aparece disponible para ese objeto.

121

GENEXUS DISEÑO DE APLICACIONES

COMANDOS Header Footer For each Exit Do while Do Case If Commit Rollback Print if detail Return &<a> = <Exp> Lineno Prncmd Pl Mt Cp Noskip Eject Call Submit Msg Do Sub - EndSub ATT = <Exp> New - EndNew Delete

DESCRIPCIÓN Comienzo del cabezal Comienzo del pie de pagina Para recorrer los registros de una tabla Permite salir de un while Repetición de una rutina mientras se cumpla una condición Ejecuta algún bloque según que condición se cumpla Ejecuta un bloque de comandos en caso que la condición evalúe verdadera Commit Rollback Imprime si existen registros en el subfile. Finaliza la ejecución y vuelve al programa llamador Asignación de una variable Numero de línea donde los datos serán impresos Para pasar comandos especiales a la impresora Largo de pagina Margen superior Provoca un salto de página si quedan menos de “n” líneas por imprimir No pasar a la siguiente línea de impresión Salto de página Llamar a un programa Someter un programa Desplegar un mensaje Llamar a una subrutina Bloque de subrutina Actualización de atributo Insertar registro Borrar un registro

T W R P

122

GENEXUS- DISEÑO DE APLICACIONES

T = Transacciones (eventos) W = Work Panels (eventos) R = Reportes P = Procedimientos Las casillas que aparecen marcadas indican que la función aparece disponible para ese objeto.

123

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

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 requiere y dar elementos básicos para el diseño de Aplicaciones. Alcance : Conceptos fundamentales y elementos básicos. No se abordan todos los temas, algunos de 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.

4

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 cliente que 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 resultado depende 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 productividad esperada 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 . Debe comenzar antes de los 60 días de finalizado dicho curso, sino se pierde el derecho a realizarlo.

5

DESARROLLO DE APLICACIONES CLIENT/SERVER
Objetivo: Dar los elementos necesarios para poder generar aplicaciones en una arquitectura Cliente/ 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.

6

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: Conocimiento de 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, Estudio detallado de las metodologías aplicadas en cada etapa y Tecnología asociada a cada componente. En forma paralela al curso teórico se irán estudiando casos prácticos y los participantes irán aplicando sobre éstos las metodologías aprendidas. Finalmente el participante realizará 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í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: 32 horas distribuidas en 8 días.

7

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 Process Modeler), 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.

8

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 funciones má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

9

Introducción Teórica

10

REALIDAD

Herramientas y Metodologías

?
BASE DE DATOS PROGRAMAS • Desarrollo y Mantenimiento

Nuestra tarea como profesionales de la informática es desarrollar y mantener aplicaciones para apoyar al usuario en su actividad final. Para realizar esta tarea se han instrumentado diferentes 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.

11

Modelado de la realidad a partir de las Visiones de Usuarios

Satisface
MODELO DE LA REALIDAD

Ingenieria Inversa

BASE DE DATOS

PROGRAMAS

VISIONES DE USUARIOS

El primer problema al que nos enfrentamos en el desarrollo de aplicaciones es la obtención del conocimiento de la realidad. Cómo obtener el conocimiento de la realidad en una forma lo suficientemente objetiva y detallada al mismo tiempo, que nos permita construir un modelo corporativo? Todos compartirán la afirmación de que cada usuario conoce muy bien los objetos con los que trabaja cotidianamente, conoce claramente la información que se maneja en ellos, que reglas deben seguirse y que cálculos deben realizarse. Por lo tanto, utilizar estas visiones de los objetos de su realidad como fuente de información parece muy razonable. Se ha demostrado con mucha rigurosidad que es posible obtener un modelo de datos a partir de la síntesis de visiones, por lo que nuestro problema se ha reducido a un problema matemático ya que si conseguimos describir adecuadamente estas visiones podremos obtener mediante 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 soporte computacional (base de datos y programas ) para soportarlo.

12

Comparación de Metodologías

Es bueno, para fijar ideas, comparar la metodología utilizada por GeneXus conocida como Metodología Incremental con las metodologías tradicionales más utilizadas actualmente. Algunos de los ejemplos de estas metodologías son: Análisis Estructurado, Ingeniería de la Información, Análisis Escencial. Estas metodologías son diferentes entre sí, pero en todos los casos, separan el análisis de los datos del de los procesos. Veremos un esquema general que podría aplicarse a cualquiera de éstas metodologías y estudiaremos sus problemas.

13

Metodología Tradicional

•.

14

REALIDAD
ANALISIS DE DATOS

BASE DE DATOS

ANALISIS FUNCIONAL

GENERACION/ INTERPRETACION ESPECIFICACION FUNCIONAL PROGRAMACION

PROGRAMAS

La primera tarea, generalmente, es el análisis de datos. Se pretende analizar la empresa y dar como producto un modelo de datos con las Entidades y Relaciones encontradas (Modelo ER). Aquí se analiza la empresa desde el punto de vista de los objetos que existen en ella y sus relaciones. Construir un sistema integrado, que requiere un modelo de datos Corporativo de la empresa no es una tarea simple debido a que el número de objetos y relaciones hacen que esta tarea sea extremadamente compleja. Debido a la complejidad de la construcción de un sistema integrado,lo que se hace normalmente es dividirlo en módulos, y cada uno solucionará los problemas operativos de un área en particular de la empresa. Simplificaremos notablemente la tarea de modelado ya que lo que precisamos normalmente son 10 o a lo sumo 20 archivos para cada modelo. Los módulos operan sin una real integración, lo que hace que exista información redundante y como consecuencia todo intento de buscar información fuera del entorno de cada aplicación resulte imposible o por lo menos peligroso.

15

En caso de que desearamos posteriormente realizar la integración de esos módulos es necesario realizar modificaciones al modelo de datos (lo que a pesar de la complejidad podríamos calificar como posible), pero las modificaciones que deberemos realizar en los programas tienen un costo tan grande que hacen inviable la realización de la integración. La empresa tendrá de esta forma resueltos sus problemas operativos, pero luego aparecerán con mucha claridad los problemas de la carencia de información que permitan orientar la gestión y la toma de decisiones de alto nivel, ya que la información que se necesita es en general de naturaleza corporativa. En la medida que nos orientamos cada vez más a las bases de datos corporativas, la cantidad de objetos que integran la base de datos y sus relaciones se hacen mas complejas. Esto lleva a que el diseño de una base de datos corporativa sea una tarea muy complicada y en la que son muchos los errores que se pueden cometer. GeneXus apunta a la creación de sistemas corporativos, brindando herramientas y una metologí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 datos necesaria para soportarlo, existe una transformación trivial. Por ello, para mayor claridad del dibujo, eliminaremos la etapa intermedia y colocaremos directamente la base de datos. Pero el modelo de datos no es suficiente para desarrollar los programas de aplicación, porque describe los datos, pero no los comportamientos. Se recurre a una tarea generalmente llamada Análisis Funcional, donde se estudia la empresa desde el punto de vista de las 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 que esta Especificación Funcional fuera independiente de la Especificación de Datos. Pero esto no es lo común en las metodologías estudiadas. Las especificaciones producidas son “file dependents“ y, en consecuencia, modificaciones en el diseño de la base de datos, implican la necesidad de revisar las especificaciones funcionales. Esta es la causa fundamental de los grandes costos de mantenimiento que deben soportar las empresas.

16

Entre las alternativas más usadas se destacan la programación en lenguajes de 3a. generación, y en lenguajes de 4a. generación. Lenguajes de 3a. Generación Lenguajes de bajo nivel como pueden ser COBOL, RPG, C, PASCAL, ADA, FORTRAN. Lenguajes de 4a. Generación Lenguajes de programación de alto nivel como pueden ser CA IDEAL, INFORMIX 4GL, NATURAL 2, PROGRESS, etc.. Desde un punto de vista conceptual, ambos casos son idénticos. En ambos el analista debe estudiar el problema, transformarlo en un algoritmo y codificar dicho algoritmo en el lenguaje de programación. Sin embargo, existe una fuerte diferencia: en los lenguajes de 4a. generación se escribe mucho menos (probablemente 10 veces menos) y, como consecuencia, la productividad es mucho mayor y el número de errores cometidos es mucho menor. Podría argumentarse en contrario, que se pierde flexibilidad con estas herramientas, lo que es cierto en términos teóricos, pero es irrelevante en términos prácticos, dado que hoy estas herramientas están dotadas de primitivas que permiten complementar su código, por lo que su aplicabilidad ha crecido mucho. El problema visto, de que las descripciones de los procesos dependen de la base de datos, afecta a ambos por igual. Como consecuencia, los lenguajes de 4a. generación permiten aumentos de productividad muy grandes sobre los de 3a., en la tarea de desarrollo, pero ayudan bastante poco en la de mantenimiento. Otra alternativa es la utilización de un “generador” que es una herramienta que puede interpretar la especificación funcional, (que obviamente debe ser totalmente rigurosa), y producir automáticamente los programas. Aquí existe una diferencia conceptual muy grande con el caso anterior. En este caso el analista describe el problema de una forma declarativa (no existe algoritmo ni codificación procedural alguna). Algunos ejemplos son ADELIA, AS/SET, LANSA, SYNON, TELON, etc..Existe otra categoría de herramientas conceptualmente idéntica: la de aquellas que, simplemente, interpretan la especificación, como por ejemplo: MAGIC y SAPIENS. La programación en ambos casos es totalmente automática, por lo que el aumento de productividad sobre las herramientas de 3a. generación es muy grande.

17

Podría argumentarse en contrario, como a menudo se ha hecho con las herramientas de 4a. generación, que se pierde flexibilidad con estas herramientas, lo que es cierto en términos teóricos, pero es irrelevante en términos prácticos, dado que, hoy, estas herramientas están dotadas de Lenguajes de Diagramas de Acción, (en la práctica lenguajes de 4a. generación), que permiten complementar su código, por lo que su aplicabilidad ha crecido mucho. El problema visto, de que las descripciones de los procesos dependen de la base de datos, afecta también a las aplicaciones generadas mediante estas herramientas. Como consecuencia, los Generadores y los Interpretadores (como los lenguajes de 4a. generación) ayudan bastante poco en la tarea de mantenimiento. Resumiendo aquí las tres opciones vistas: Lenguajes de 3a. Generación Baja productividad en el desarrollo Lenguajes de 4a. Generación Buen aumento de productividad en el desarrollo sobre L3G. Generadores Buen aumento de productividad en el desarrollo sobre L3G y L4G. Desde el punto de vista del mantenimiento, ninguna de las herramientas ayuda mucho dado que, en todas ellas, se utilizan descripciones de procesos que pueden perder su validez cuando existen modificaciones de archivos y que, por ello, deben ser revisadas y mantenidas manualmente. Existe, sin embargo, un postulado cuyo cumplimiento evitaría este problema: PUEDE OBTENERSE UNA BASE DE DATOS ESTABLE. Lamentablemente, este postulado es falso, y sobran los contraejemplos que lo demuestran.

18

Metodología

Los fundadores de ARTech han desarrollado una amplia actividad de consultoría internacional en diseño de grandes bases de datos. Cuando se comenzaron a utilizar verdaderos modelos corporativos, que normalmente poseen cientos de tablas, les quedó claro que no debía perderse más tiempo buscando algo que no existe: las bases de datos estables. Luego de importantes investigaciones, desarrollaron una teoría, organizaron una metodología e implementaron una herramienta para posibilitar el desarrollo incremental y permitir la convivencia con las bases de datos reales (inestables), a costo mínimo.

19

REALIDAD
DESCRIPCION DE OBJETOS

Desarrollo con

Utilizando GENEXUS, la tarea básica del analista es la descripción de la realidad. Sólo el hombre podría desarrollar esta tarea, ya que sólo él puede entender el problema del usuario. Desde luego que esto modifica la actividad del analista e, incluso, su perfil óptimo, ya que lo transforma en un “Business Analyst”. Ahora trabaja en alto nivel, discutiendo problemas con el usuario y probando con él las especificaciones a nivel de prototipo, en vez de desarrollar su actividad a través de tareas de bajo nivel como son: diseñar archivos, normalizar, diseñar programas, programar, buscar y eliminar los errores de los programas.

20

REALIDAD
DESCRIPCION DE OBJETOS

BASE DE DATOS

BASE DE CONOCIMIENTO

Desarrollo con
PROGRAMAS

Al crear un nuevo sistema o proyecto Genexus, se crea una nueva Base de Conocimiento. Una vez creada la nueva Base de Conocimiento, el siguiente paso es empezar a describir los objetos de la realidad mediante objetos Genexus. A partir de los objetos definidos en la Base de Conocimiento, GENEXUS genera automáticamente tanto los programas de creación / reorganización de la base de datos como los programas de la aplicación. El término Base de Conocimiento hace referencia a la capacidad de reutilizar en forma automática el conocimiento almacenado y sobre todo a la capacidad de realizar inferencias que permiten obtener más conocimiento.

21

REALIDAD
ANALISIS DE DATOS DESCRIPCION DE OBJETOS

BASE DE DATOS

BASE DE CONOCIMIENTO

ANALISIS FUNCIONAL

Comparación de Metodologías
ESPECIFICACION FUNCIONAL

GENERACION/ INTERPRETACION

PROGRAMAS PROGRAMACION

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.

22

Descripción de Objetos

Transacciones (TRNs)

Reportes (RPTs)

Procedimientos (PROCs)

Work Panels (WKPs)

Menues (MNUs)

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:
TRANSACCIONES Las transacciones permiten definir los objetos de la realidad. La mayor parte de las transacciones pueden ser identificadas prestando atención a las entidades que el usuario menciona (por ej. Clientes, Proveedores, Artículos). A partir de las transacciones Genexus infiere el diseño de la base de datos. PROCEDIMIENTOS Procesos no interactivos de actualización de la base de datos (procesos batch). REPORTES Recuperan información a partir de los datos almacenados y no los alteran. Los reportes son lo que conocemos habitualmente como listados. PANELES DE TRABAJO Permite definir consultas interactivas a la base de datos. Es un objeto muy flexible que se presta para múltiples usos. MENUES Objetos organizadores del resto.

23

Sistematización del conocimiento

Transacciones (TRNs)

Reportes (RPTs)

Procedimientos (PROCs)

Work Panels (WKPs)

Menues (MNUs)

Base de Conocimiento Base de Conocimiento

Veamos ahora con más detalle el proceso de desarrollo de una aplicación con GeneXus. GeneXus captura el conocimiento que reside en los objetos descritos y lo sistematiza en una base de conocimiento. GENEXUS funciona basado en su capacidad de inferencia. Así infiere, por ejemplo: En el modelo de datos: las tablas, las restricciones de integridad y los índices necesarios. Los programas de creación y/o de reorganización de la base de datos. Los programas de la aplicación. Los análisis de impacto de los cambios.

24

Inferencia de la Base de Datos
Transacciones (TRNs) Reportes (RPTs) Procedimientos (PROCs) Work Panels (WKPs) Menues (MNUs)

Base de Conocimiento Base de Conocimiento

Base de Datos

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

25

Creación de la Base de Datos
Transacciones (TRNs) Reportes (RPTs) Procedimientos (PROCs) Work Panels (WKPs) Menues (MNUs)

Base de Conocimiento Base de Conocimiento

Base de Datos

Programas Generación BD

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

26

Generación de los Programas de la Aplicación
Transacciones (TRNs) Reportes (RPTs) Procedimientos (PROCs) Work Panels (WKPs) Menues (MNUs)

Base de Conocimiento Base de Conocimiento

Base de Datos

Programas de Aplicacion (TRN, RPT, PROC, WKP y MNU)

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

27

Resultado final en la Etapa de Desarrollo
Transacciones (TRNs) Reportes (RPTs) Procedimientos (PROCs) Work Panels (WKPs) Menues (MNUs)

Base de Conocimiento Base de Conocimiento

Base de Datos

Programas de Aplicacion (TRN, RPT, PROC, WKP y MNU)

Aplicaciones

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

28

Las Visiones de los Usuarios Cambian
Nuevas Transacciones Nuevos Reportes Nuevos Procedimientos Nuevos Work Panels Nuevos Menues

Base de Conocimiento Base de Conocimiento

Base de Datos

Nueva Base de Datos

Programas de Aplicacion (TRN, RPT, PROC, WKP y MNU)

Como se ha dicho, durante el ciclo de vida de la aplicación, existen muchas modificaciones. Ante cambios en las visiones de usuarios, GENEXUS diseña la nueva base de datos.

29

Análisis de Impacto Totalmente Automático
Nuevas Transacciones Nuevos Reportes Nuevos Procedimientos Nuevos Work Panels Nuevos Menues

Análisis de impacto

Base de Conocimiento Base de Conocimiento

Base de Datos

Nueva Base de Datos

Programas de Aplicacion (TRN, RPT, PROC, WKP y MNU)

Algunas veces, la nueva base de datos coincide con la anterior, en cuyo caso, todos los programas existentes seguirán siendo válidos. Otras veces, existen cambios en la base de datos. El análisis de impacto de los cambios nos informa si debe reorganizarse la base de datos, cómo debe ser hecha esa reorganización y, los eventuales problemas que esa reorganización podría ocasionar. Una vez analizado el análisis de impacto, el analista resolverá efectuar la reorganización o renunciar a ella volviendo a la situación anterior.

30

Generación de Programas de Reorganización de la Base de Datos
Nuevas Transacciones Nuevos Reportes Nuevos Procedimientos Nuevos Work Panels Nuevos Menues

Programas de Reorganiz.

Base de Conocimiento Base de Conocimiento

Base de Datos

Nueva Base de Datos

Programas de Aplicacion (TRN, RPT, PROC, WKP y MNU)

Si el analista ha dado el visto bueno a la reorganización, GENEXUS genera automáticamente los programas necesarios para esa reorganización. GENEXUS, considerando la base de conocimientos nueva y la vieja, estudia el impacto de los cambios sobre los programas actuales y produce un informe sobre el tema. La reorganización 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.

31

Análisis Automático del Impacto de los cambios sobre los Programas
Nuevas Transacciones Nuevos Reportes Nuevos Procedimientos Nuevos Work Panels Nuevos Menues

Base de Conocimiento Base de Conocimiento

Análisis de impacto

Nueva Base de Datos

Nuevos Programas de Aplicacion (TRN, RPT, PROC, WKP y MNU)

32

Generación Automática de Nuevos programas
Nuevas Transacciones Nuevos Reportes Nuevos Procedimientos Nuevos Work Panels Nuevos Menues

Base de Conocimiento Base de Conocimiento

Generación de nuevos Programas

Nueva Base de Datos

Nuevos Programas de Aplicacion (TRN, RPT, PROC, WKP y MNU)

GENEXUS genera /regenera automáticamente los programas necesarios.

33

Nueva Realidad , con los cambios en la Aplicación
Nuevas Transacciones Nuevos Reportes Nuevos Procedimientos Nuevos Work Panels Nuevos Menues

Base de Conocimiento Base de Conocimiento

Nueva Base de Datos

Nuevos Programas de Aplicacion (TRN, RPT, PROC, WKP y MNU)

Aplicaciones

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

34

Múltiples Plataformas de ejecución a partir de una única especificación
ARQUITECTURAS CENTRALIZADAS
Plataforma AS/400 Plataforma DOS WINDOWS Lenguaje Generado COBOL/400, RPG/400 Lenguaje Generado Foxpro, Clipper Foxpro for Windows Visual Basic Visual Fox

ARQUITECTURAS FILE SERVER
DBF DBF ACCESS DBF

ARQUITECTURA CLIENT/SERVER
Cliente Database Server Plataformas (Ejs.) FOXPRO WIN, VB, VFP, JAVA ORACLE Unix, NT MS SQL SERVER Alfa, WINDOWS NT y 95 INFORMIX Unix, NT DB2 Common Servers RS6000, OS2 DB2/400 AS400

35

Metodología Incremental
Consiste en construir una aplicación mediante aproximaciones sucesivas.

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 una metodologí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 que tenemos y luego cuando pasamos a tener más (o simplemente diferente) conocimiento, GENEXUS se ocupará de hacer automáticamente todas las adaptaciones en la base de datos y programas. El incrementar una aplicación implica cambios en la base de datos y programas. Los cambios en la base de datos pueden tener un costo aceptable, pero el alto costo de las adaptaciones de los programas harían inviable la aplicación de este método si no fueran resueltos automáticamente.

36

Ciclos Diseño-Prototipo y Diseñ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 durante la fase de diseño, construyendo y probando sucesivos prototipos del modelo. Ciclo de Producción: Por el contrario, pasará menos frecuentemente al bucle de DiseñoProducción, ya que la generación del sistema se realiza solamente cuando el prototipo ha sido totalmente aprobado, o luego de haber instrumentado y probado algún cambio.

37

Prototipación Integral en PC
MODELO DE LA REALIDAD

Construcción Automática
Usuario probando todos los detalles de la aplicación

BASE DE DATOS

PROGRAMAS

La construcción automática del soporte computacional nos dará la gran posiblidad de crear prototipos. Verdaderos prototipos ! , ya que estos tendrán un funcionamiento equivalente al del sistema en producción real, permitiendo que se pruebe hasta el último detalle de la aplicación. Los resultados que todos quieren ver, están en forma de programas ejecutando, lo que no es posible sin la utilización de prototipos.

38

Ventajas de la Prototipación
• Permite ver resultados en forma temprana • Permite el seguimiento de los requerimientos del usuario • Detección de errores en forma temprana • Logra el compromiso de los usuarios con el desarrollo • Sistemas de mejor calidad

Toda comunicación es suceptible de errores: •El usuario olvida ciertos detalles. •El analista no toma nota de algunos elementos. •El usuario se equivoca en algunas apreciaciones. •El analista interpreta mal algunas explicaciones del usuario. Pero, además, la implementación de sistemas es, habitualmente,una tarea que insume bastante tiempo. Como muchos de estos problemas sólo son detectados en las pruebas finales del sistema, el costo (tiempo y dinero) de solucionarlos es muy grande y la realidad cambia, por lo que no es razonable pensar que se pueden mantener las especificaciones mientras se implementa el sistema. La consecuencia de mantener las especificaciones, es que se acaba implementando una solución relativamente insatisfactoria. El impacto de estos problemas disminuiría mucho si se consiguiera probar cada especificación, inmediatamente, y saber cual es la repercusión de cada cambio sobre el resto del sistema.Una primera aproximación a esto, ofrecida por diversos sistemas, es la posibilidad de mostrar al usuario formatos de pantallas, informes, etc. animados por menúes. Esto permite ayudar al usuario a tener una idea de qué sistema se le construirá pero, al final, siempre se presentan sorpresas.

39

Warnier-Orr
Comienzo Nro de Factura Nro de Cliente Nombre Cliente Fecha Factura

Emisión del cabezal

Emisión de la Factura

Emisión de una Factura (cuerpo) Proceso de emisión de líneas

Comienzo

Emisión de una línea

Código Producto Nombre Producto Precio Producto Cantidad Producto Importe Producto

Fin

Fin

Fin

Ahora vamos a concentrarnos en cuál es la forma práctica utilizada por GeneXus, para la captura de la realidad de la que tanto hablamos. Jean Dominique Warnier y Ken Orr, formularon una teoría acerca de cómo puede ser construida una aplicación de procesamiento de datos. Algunos de sus enunciados fueron los siguientes: • Los datos y los procesos están estructurados. • Todos los procesos son subdivididos en subconjuntos partiendo del nivel más alto y empleando reglas de subdivisión adecuadas (de manera jerárquica). • Todo Proceso tiene un Comienzo, un Cuerpo, y un Final. Esta regla se aplica a la organización de datos y resultados. Analicemos por ejemplo un proceso de emisión de las Facturas de una empresa: Tenemos en este proceso 5 niveles, distinguiendo en cada nivel, los conjuntos repetitivos de lo que está presente una sola vez. Vemos que la gestión jerárquica de los datos hace aparecer relaciones entre los conjuntos definidos en los distintos niveles. Existe entonces una ley de correspondencia: Un elemento de un conjunto de un nivel inferior, se corresponde con uno del nivel superior, si esta incluído en él. Todo conjunto de nivel inferior se llama Conjunto de Partida y todo conjunto de nivel superior se llama Conjunto de Llegada. En el momento de jerarquizar procesos y datos, sería muy bueno que obtuviera este tipo de relaciones. El no observar esta ley es fuente de confusión, eliminando la claridad y la simplicidad de la organización de los datos tanto como la de los procesos.

40

DISEÑO DE TRANSACCIONES

41

Notación GeneXus para Transacciones
Ejemplo: Proceso de Emisión de Facturas FacNro* CliCod CliNom FacFch (ProdCod* ProdNom ProdPre ) Código de la factura Código del cliente Nombre del cliente Fecha de la factura Código del producto Nombre del producto Precio del producto

El siguiente paso es encontrar una forma de notación adecuada para GeneXus. Por ejemplo, una transacción de emisión de Facturas tendrá la siguiente notación. Cada nivel definirá un conjunto de atributos que deben operar en conjunto. Se ingresarán , eliminarán o modificarán conjuntamente en la base de datos. Precisamos entonces encontrar un conjunto de atributos que actúe como identificador de cada instancia de este conjunto. Notaremos a estos atributos con un asterisco. Este es en definitiva el concepto de clave primaria por lo que en la elección de estos atributos debemos atender a todas las reglas correspondientes a su definición. El conjunto de atributos entre paréntesis representa la ocurrencia de varios para cada instancia del nivel anterior. En el ejemplo, una factura tiene varios productos.

42

Definición del diseño de Base de Datos en 3era Forma Normal para soportar las transaccciones definidas.
TRN. FACTURA FacNro* CliCod CliNom FacFch (ProdCod* ProdNom ProdPre FacLinCnt FacLinImp) TABLAS Factura FacNro* CliCod CliNom FacFch Factura1 FacNro* ProdCod* ProdNom ProdPre FacLinCnt FacLinImp

Veamos el proceso de obtención de una base de datos en 3era. forma normal a partir de las especificaciones de transacciones. Para esto utilizaremos como ayuda las dependencias funcionales que se derivarían de la definición de la transacción. La definición de esta primera transacción a determinado las siguientes dependencias funcionales. FacNro ----> CliCod FacNro ----> CliNom FacNro ----> FacFch Por lo que se definirá una tabla con el siguiente diseño FacNro* CliCod CliNom FacFch Tenemos además las siguientes dependencias funcionales determinadas por el 2do nivel de la transacción. FacNro, ProdCod ----> ProdNom FacNro, ProdCod ----> ProdPre FacNro, ProdCod ----> FacLinCnt FacNro, ProdCod ----> FacLinImp Que definirán una tabla con el siguiente diseño FacNro * ProdCod* ProdNom ProdPre FacLinCnt FacLinImp

43

Definición de las transacciones Clientes y Productos Clientes CliCod* CliNom Trn. Clientes CliCod* CliNom Trn. Productos ProdCod* ProdNom ProdPre Producto ProdCod* ProdNom ProdPre Factura FacNro* CliCod CliNom FacFch Factura1 FacNro* ProdCod* ProdNom ProdPre FacLinCnt FacLinImp

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

44

GeneXus establece las relaciones por los nombres.
Todo lo que es conceptualmente lo mismo, debe tener el mismo nombre.
Transacciones: Factura FacNro* CliCod CliNom .......... Factura FacNro* CliFacCod SI Cliente CliCod* CliNom ........... Cliente NO CliCod *

Conceptos diferentes no deben tener el mismo nombre.
Ventas FctVtaNro* Fecha CliCod CliNom NO Compras FctCmpNro* Fecha PrvCod PrvNom

45

Es conveniente usar padrones para los nombres de atributos.
• Facilitan la tarea de darle nombre a un atributo dentro de las reglas establecidas • Facilitan la tarea de integración de bases de conocimiento

46

Nomenclatura GIK - Nombre del Atributo

Complemento
(texto libre)

Calificador (1 a 3) Calificador (1 a 3) Categoría Semántica (1 a 3) Objeto ( 1 a 6 )

ARTech ha definido un Standard para la nomenclatura de atributos, el GIK (GeneXus Incremental Knowledge Base). Puede gustarnos más o menos que otros. Lo importante es que es el utilizado por la comunidad de usuarios GeneXus. Esto viabiliza reutilización de conocimiento entre ellos. Nombre de atributo> Objeto + Categoría + Calificador Objeto, Es el nombre de la transacción a la que pertenece el atributo. Categoría, Es la categoría semántica del atributo. Calificador, Puede existir uno o dos calificadores.

47

Ejemplo de Nomenclatura GIK
Objetos
Cli Cli Cli Cli FacVta FacCmp

Categorias
Cod Nom Fch Fch Nro Nro

Calificador

Ini Fin

48

Tipos de Datos
• Numeric, Character, Date • Long Varchar • VarChar
– Equivalente al Character, salvo en la forma en que se almacena en la BD.

• DateTime
– Los valores de M y N no afectan la forma de almacenar el tipo de datos, sino la forma de aceptar o mostrar su contenido.

Long Varchar Permite almacenar una cantidad de caracteres indefinida. Se utiliza normalmente para almacenar textos, descripciones, comentarios, etc. El largo que se le asigna es considerado el largo máximo (la implementación depende de la plataforma). VarChar Permiten almacenar texto de largo variable. Su función, en contraposición al character, es la de optimizar el almacenamiento en la base de datos. Definición: Varchar(M, N) M es el largo máximo posible que dependerá del DBMS. Si el largo asignado al atributo es mayor que el soportado por el DBMS se utilizará el máximo soportado. N es el largo promedio. Se utiliza para optimizar los accesos a disco en algunos DBMSs . La idea es que si el valor de un atributo varchar es menor o igual que N, se almacenan N caracteres (rellenados con blancos) en el registro del archivo y se utiliza un único acceso a disco para leerlo o grabarlo.

49

En caso que el valor del atributo varchar sea mayor que N, se almacenan los primeros N en el registro del archivo y el resto en un área de overflow para lo cual es necesario un acceso adicional tanto para lectura como para escritura. Se le pueden aplicar todas las funciones y operadores existentes para el tipo de datos character. El tipo de datos Varchar es equivalente al tipo Character en todos los sentidos salvo en la forma en que se almacena en la base de datos. Para los DBMS que no soportan este tipo de dato se crean como Character. DateTime Permite almacenar una combinación de fecha y hora (hasta el segundo). DateTime(M, N) M = Largo de la fecha. Valores posibles: 0, 8 y 10. N = Largo de la hora. Valores posibles: 2, 5 y 8. 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.

50

Comandos de asignación
• += • -= • *= • /= Sintaxis: <Variable_o_Atributo> <Comando> <Expresión> Ejemplo: &I += 1 (equivalente a &I = &I + 1)

51

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 Cliente Dirección del Banco Dominio

Atributos

El objetivo de los dominios es permitir usar definiciones de atributos genéricos y luego poder asociar un atributo con su correspondiente dominio. En el ejemplo, el dominio Dirección es definido como Char de 30. Los atributos dirección del banco y del cliente son asociados a él. Por lo tanto, si en el futuro se cambia la definición de este dominio, los cambios van a ser automáticamente propagados a todos los atributos que pertenezcan a éste. De esta forma los dominios pemiten un mayor nivel de abstracción en la definición de la aplicación.

52

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 su estructura 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 queremos permitir 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 clientes sin 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 que pertenecen 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ón La definición de reglas es una forma DECLARATIVA de definir el comportamiento de la transacción. El orden en el cual fueron definidas no necesariamente indica que ese sea el orden en que se encuentran en el programa generado. GeneXus se encarga de determinar el orden correcto según las dependencias de atributos existentes (en este tema entraremos en detalle mas adelante).

53

Toolbar de Controles
Para 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.

54 12 16

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ágina tiene un título y un área útil, es decir donde se ponen los controles de esa página. Sólo una de las páginas puede estar activa a la vez y es la que se puede ver. Del resto sólo se verá su título. Las opciones Edit/Add Tab Page y Edit/Remove Tab Page son para agregar y eliminar páginas respectivamente. Puede accederse también a estas opciones con botón derecho sobre el Tab Control. Hide Tabs Para mostrar sólo la página activa y no mostrar los tabs. Util para la definición de Wizards.

55

Generación de HELP Tipo Windows
• Es necesario generar y compilar el Help.
– Opción: Build/Generate Help – El compilador viene con el Visual Basic/Foxpro/Visual FoxPro

• Disponible solamente en los generadores windows.

• Esto es para los generadores Windows. •Se genera un .HLP compatible con el Help de Windows. •El compilador de Help como se mencionó más arriba viene con el Visual Basic/Foxpro/Visual FoxPro y se requiere como mínimo la versión 3.10.505.

56 62

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.

57 63

Pasemos a Prototipo...

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). 58

INTEGRIDAD REFERENCIAL

59

Diagrama de Bachman
Catego
CatCod* CatNom

Depart
DtoCod* DtoNom

Client
CliCod* CliNom CatCod DtoCod

Las reglas de integridad referencial permiten asegurar la consistencia entre los datos de las distintas tablas. El diagrama anterior se ha inspirado en los conocidos Diagramas de Bachman, y tiene la virtud de explicitar la integridad referencial del modelo de datos. En el ejemplo, existe una relación entre la tabla Clientes y Departamentos y también entre Clientes y Categorías. La relación entre dos tablas se determina analizando los atributos que tienen en común. Por ejemplo, entre las tablas Clientes y Categorías tenemos que el atributo común es el código de la categoría, que es la clave primaria de la tabla Categoría. Decimos que la relación entre ambas tablas es 1-N, que indica que un cliente tiene una categoría y una categoría tiene N clientes. También es usual decir: . La tabla Categorías está Superordinada a la tabla de Clientes . La tabla de Clientes está Subordinada a la tabla de Categorías Esta relación implica que la información contenida en ambas tablas no es independiente, por lo que es neceario realizar controles para que la información sea consistente. A estos controles se les llama de Integridad Referencial y básicamente son los siguientes: * Cuando se crean registros en la tabla subordinada (Client), debe existir el registro correspondiente en la tabla superordinada (Catego). * Cuando se elimina un registro en la tabla superordinada (Catego), no deben existir registros correspondientes en la tabla subordinada (Client). 60

Definición de Indices
Tabla Tipo
Catego Depart Client PK PK PK FK FK

Indice Composición
CatCod DtoCod CliCod DtoCod CatCod

Definición de Indices Para hacer eficientes los controles de Integridad, GeneXus crea automáticamente índices, que son vías de acceso eficientes a las Tablas. Existen tres tipos de índices: Primarios, Extranjeros y del Usuario. 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 tablas subordinadas (Client), exista el registro correspondiente en la tabla superordinada (Catego). Con GeneXus todos los índices primarios son definidos automáticamente a partir de los identificadores de las transacciones. Indice Extranjero (FK): Los índices extranjeros son utilizados para hacer eficientes los controles de integridad intertablas. También son definidos automáticamente. Cuando se elimina un registro en una tabla superordinada (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 determinado orden de una forma eficiente. Por ejemplo, en la tabla Client se puede definir un índice por CliNom, que es muy útil para los listados ordenados por nombre. 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.

61

CONCEPTO DE TABLA EXTENDIDA

62

Tabla Extendida
Definición Dada una tabla de la base de datos, se denomina tabla extendida de la misma al conjunto de atributos conformado por:
– Atributos que pertenecen a la tabla. – Atributos que tengan una relación N-1 con la tabla extendida determinada hasta el momento.

Los criterios de normalización del diseño de la base de datos apuntan a minimizar la posibilidad de inconsistencia en los datos. Una base de datos diseñada de esta manera tiene una serie de ventajas importantes (tal es así que actualmente la normalización de datos es un standard de diseño) , pero se deben tener en cuenta también algunos inconvenientes. El inconv3eniente más notorio es que los datos se encuentran dispersos en muchas tablas, y por lo tanto cuando se quieren hacer consultas más o menos complejas a la base de datos se debe consultar una cantidad importante de tablas. Así, por ejemplo, para listar las facturas sería necesario consultar las tablas Cabezal y líneas de Facturas, Clientes, Categorías y Productos. Para simplificar esta tarea GeneXus utiliza el concepto de tabla extendida.

63

Tabla Base y Tabla Extendida

FACTURA
FacNro* FacFch CliCod

CLIENTE
CliCod* CliNom CatCod

CATEGORIA
CatCod* CatDto

FACTURA1
FacNro* ProdCod* FacLinCnt

PRODUCTO
ProdCod* ProdNom ProdPre

64

Tabla Base: Categoría Cliente Factura

Tabla extendida: Categoría Cliente Categoría Factura Cliente Categoría Factura1 Producto Factura Cliente Categoría Producto

Factura1

Producto

65

ATRIBUTOS FORMULAS

66

Características

• Relación entre Atributos, Constantes o Funciones • Definición Global, definidas a nivel del modelo • Atributo Virtual ( No se almacena en la tabla ) • Son calculadas siempre que se hace referencia al atributo

Un atributo es una fórmula si su valor se puede calcular a partir del valor de otros atributos. En cada transacción se puede definir qué atributos son fórmulas, pero esta definición es global (no es local a la transacción), es decir toda vez que se necesite el atributo se calcula la fórmula, tanto en transacciones como en los otros objetos GeneXus. Existe una similitud entre fórmulas y asignaciones (regla), incluso la 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 las reglas es LOCAL (vale sólo para la transacción en la cual fue definida). Cuando un atributo es fórmula, éste no está almacenado (a no ser que se lo defina como redundante) y cuando es una Asignación, por ser esta local, si esta almacenado.

67

Clasificación
Horizontales
Una o varias expresiones aritméticas condicionales.

Verticales
SUM COUNT

Aggregate / Select
Select Max, Min, Find Aggregate Sum, Count

Fórmula Horizontal Los atributos involucrados en la misma deben pertenecer a la tabla extendida del atributo definido como fórmula. Fórmula Vertical Los atributos involucrados deben pertenecer a la tabla directamente subordinada del atributo definido como fórmula. Son incondicionales. Aggregate / Select Pueden navegar sobre cualquier tabla del modelo. Son condicionales.

68

Fómulas Horizontales

Atributo = <Expresión> if <Condición>; <Expresión> if <Condición>; : <Expresión> Otherwise;

<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 atributo virtual. <Condición> es la condición de disparo de la fórmula. Cuando se define una fórmula horizontal, GeneXus sabe cual es la tabla extendida del atributo que se está definiendo como fórmula, y controla que todos los atributos utilizados en dicha fórmula se encuentren en ella.

69

Fómulas Horizontales
Ejemplo: TRANSACCION TABLA CliCod* CliCod* CliNom CliNom CliTotCmp CliTotCmp CliTotPgo CliTotPgo CliSdo = CliTotCmp- CliTotPgo

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órmula La fórmula es una definición global ya que está a nivel del modelo de datos, su valor será calculado cada vez que se utilice en cualquier objeto GeneXus ya que el atributo no está almacenado en la tabla. •Regla La regla está definida a nivel local en la transacción. Cada vez que se mencione el atributo, su valor no se calculará, sino que se tomará directamente de la tabla.

70

Importe de la Línea de la Factura
FACTURA
FacCod* FacFch CliCod

CLIENTE
CliCod* CliNom CatCod

CATEGORIA
CatCod* CatDto

FACTURA1
FacCod* ProdCod* FacLinCnt

PRODUCTO
ProdCod* ProdNom ProdPre

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á almacencado en la tabla Factura1.

71

Fórmulas Verticales SUM - COUNT
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

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 pueden establecer condiciones. Se resuelve mediante una navegación vertical, de ahí el nombre Fórmulas Verticales Performance El hecho que la fórmula no 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.

72

Fórmulas Verticales SUM - COUNT
Cálculo del subtotal de la Factura Factura: FacNro* FacFch CliCod FacSubTot = SUM(FacLinImp) Factura1: FacNro* ProdCod* FacLinCnt FacLinImp = FacLinCnt * ProdPre •FacSubTot y FacLinImp no están almacenados. • Equivalencia entre SUM redundante y regla ADD
Factura
1

N

Factura1

Precisamos calcular ahora el subtotal de las líneas de la factura, que hemos llamado FacSubTot. Este atributo está en el cabezal de la factura y el atributo a ser sumado 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órmulas Verticales. Se puede decir que un SUM redundante es equivalente a la regla ADD.

73

Fórmulas Verticales
Sólo se puede definir entre atributos de tablas “directamente” subordinadas
N 1

FACTURA FacSubTot = SUM(FacLinImp) 1

CLIENTE

N

SUM(att) No permitido

FacLinImp

FACTURA1

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ón correspondiente.

74

Fórmulas Aggregate/Select
Son fórmulas que permiten buscar, sumar, contar atributos que cumplan determinadas condiciones, en cualquier tabla del modelo.
Aggregate – Sum – Count Select – Max – Min – Find

Fórmulas Aggregate Sum .- Suma condicionalmente atributos de cualquier tabla del modelo

Count .- Cuenta condicionalmente filas de cualquier tabla del modelo

Fórmulas Select Find .-Buscar el valor de un atributo en determinadas condiciones Max .-Buscar el máximo valor de un atributo en determinadas condiciones Min .-Buscar el mínimo valor de un atributo en determinadas condiciones

75

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 caso de encontrar) Find (atributo a buscar, condiciones de búsqueda, valor por defecto en caso de no encontrar quien cumpla con las condiciones)

76

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 listados Verticales - SUM y COUNT todas las letras en mayúsculas Aggregate - Sum y Count sólo la primer letra con mayúscula Los siguientes ejemplos de fórmulas Aggregate y fórmulas Select, se incluyen como documentación y no necesariamente se harán ejemplos en el curso, salvo que los alumnos lo pidan. Ejemplo de Count Aggregate: Total de productos con descuento en la factura: Factura FacNro* FacFch CliCod FacTotArtDscto = Count(ProdCod, FacDscto > 0)

77

Factura1 FacNro* ProdCod* FacLinCnt FacDscto FacLinImp FacNro ProdCod FacDscto 1 1 1 1 1 2 3 4 10 0 20 0

FacTotArtDscto = 2

78

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 DocNro* DocFch DocImp DocImpDolar = DocImp / DocCotDolar DocCotDolar = Find(MonCot, MonCod = ‘U$S’ .and. MonFch = DocFch) Cotizaciones MonCod* MonFch* MonCot

79

Max Esta función determina el máximo valor de un atributo en una tabla. Obtenido este valor, que corresponderá a una determinada fila, la función devuelve el valor de cualquier atributo de dicha fila. 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 (Tabla de llegada), es decir no puede ser un atributo fórmula o pertenecer a su tabla extendida. Condición de búsqueda - Se pueden mencionar atributos almacenados o virtuales de la tabla base y de la tabla extendida de la tabla de partida. Se pueden mencionar atributos almacenados de la tabla en la que se realiza la búsqueda (Tabla de llegada). Atributo a devolver - Atributo a devolver para asignar al atributo fórmula, debe estar almacenado en la tabla de búsqueda. Condición de disparo - Se pueden mencionar atributos almacenados o virtuales de la tabla base y de la tabla extendida de la tabla de partida. Ejemplo de uso del Max: Obtener la última (máxima) cotización del dólar anterior a la fecha del documento. Documentos DocNro* DocFch DocImp DocImpDolar DocCotDolar 80 Cotizaciones MonCod* MonFch* MonCot

Atributo a maximizar … MonFch Condición ........................ MonCod = U$S y el máximo valor de MonFch debe ser menor o igual a la fecha de documento Atributo a devolver ................ MonCot Valor por defecto ..................... 0 Ejemplo de uso del Max: 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 10/01/94 11/01/94 12/01/94 13/01/94 16/01/94 MonCot 100 110 112 115 117

81

Min Atributo = Min(<Atributo a Minimizar>, <Condición de minimización>, <Valor por defecto>, <Atributo a Devolver>) IF <Condición de disparo> Esta función determina el 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 cualquier atributo de dicha fila. Ejemplo de uso de la función Min: Se quiere obtener la cotización del dólar para el día de la fecha y en caso de que no exista, la inmediatamente posterior. Documentos DocNro* DocFch DocImp DocCotDolar Cotizaciones MonCod* MonFch* MonCot = Min(MonFch, MonCod = ‘U$S’ .and. MonFch >= DocFch, , MonCot)

DocImpDolar = DocImp / DocCotDolar

Fecha del Documento 15/01/94, le corresponde la cotización del día 16/01/94. MonFch 10/01/94 11/01/94 12/01/94 13/01/94 16/01/94 17/01/94 MonCot 100 110 112 115 117 118

82

Consideraciones aplicables a todas las fórmulas Aggregate/Select
Atributo = Find(<Atributo a buscar>, <Condición de búsqueda>, <Valor por defecto>) IF <Condición de disparo> En la definición de la fórmula intervienen atributos de varias tablas: La tabla en la que está definido el atributo fórmula (tabla de partida). La tabla extendida de la tabla de partida. La tabla en la que se busca (tabla de llegada). IMPORTANTE: No se pueden utilizar atributos de la tabla extendida de la tabla de llegada Documentos (Tabla de partida) Cotizaciones (Tabla de llegada)

Consideraciones de performance: Tanto las fórmulas Verticales como las fórmulas Agregate/Select, implican la realización de navegaciones en la Base de Datos, por lo que es importante considerar la forma en que esto es realizado. Las fórmulas Verticales 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.

83

USO DE LA FORMULA MAX( ).
Ejemplo: Buscar el precio del producto según la fecha de la Factura.
Transacción Productos ProdCod* ProdDsc (ProdFch* ProdPre) Transacción Factura FacNro* CliCod FacTot FacFch (ProdCod* FacProdPre FacLinCnt FacLinImp)

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 3/10/92 Incluiremos en las líneas de la factura el atributo ProdCod. No podemos incluir ProdFch debido a que no podríamos saber que valor darle a la fecha para poder heredar directamente el ProdPre. Definimos el atributo FacProdPre y buscaremos con una fórmula el precio correspondiente de acuerdo a la fecha de factura. Buscaremos el precio de fecha máxima anterior a la fecha de factura. La fórmula quedaría: FacProdPre = Max (ProdFch, ProdFch <= FacFch, 0, ProdPre ) 84 correspondiente al

USO DE LA FORMULA MAX( ).
FacProdPre = Max(ProdFch, ProdFch <= FacFch, 0, ProdPre)

Fecha de Factura: 10/10/93 Precio correspondiente: 220 Código de Producto 1021 1021 1021 1021 1022 1022 1022 1022 Fecha Aumento Precio 10/08/89 20/11/90 03/10/92 15/10/95 10/08/89 20/11/90 03/10/92 15/10/95 Valor del Producto 200 210 220 230 100 110 120 180

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.

85

Ejemplo
Transacción de Cotizaciones MonId* CotMes* MonDsc (CotDia* CotImp) Transacción de Asientos AsiNro* AsiFch AsiMes AsiDia (AsiIdLin* MonId AsiImpME AsiImpNS AsiTipDH CtaId AsiFndCot)

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 fecha del asiento.

86

A.

Transacción de Cotizaciones: MonId* CotMes* MonDsc (CotDia* CotImp) Transacción de asientos : AsiNro* AsiFch AsiMes = Month(AsiFch) AsiDia = Day(AsiFch) (AsiIdLin* MonId AsiImpME AsiImpNS AsiTipDH CtaId AsiFndCot) = Find(CotImp, CotMes=AsiMes .and. CotDia=AsiDia) if MonId<>’NS’; 1 otherwise;

87

B.

Transacción de Asientos : AsiNro* AsiFch AsiMes =Month(AsiFch) AsiDia =Day(AsiFch) (AsiIdLin* MonId AsiImpME AsiImpNS = AsiImpME*AsiFndCot if AsiFndCot<>0; AsiImpME*AsiMaxCot if AsiMaxCot<>0; 1 otherwise; AsiTipDH CtaId 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”;

88

1. Condiciones involucradas en una
Fórmula Aggregate Select
Condición de Búsqueda Es la condición a la cual está sujeta la búsqueda. Condición de Disparo Es la condición que determina si la fórmula se ejecuta.

89

2. Inferencias en el caso de una
Fórmula Aggregate Select
La condición de búsqueda queda determinada por: – La condición explicitada como segundo parámetro. – Atributos que quedan instanciados por el ambiente en el que se dispara la Fórmula :
Intersección de la tabla extendida del atributo definido como fórmula (tabla de partida) y la tabla sobre la cual se está resolviendo la fórmula (tabla de llegada).

90

En el ejemplo:
Transacción de Cotizaciones: MonId* CotMes* MonDsc (CotDia* CotImp) Transacción de Asientos : AsiNro* AsiFch AsiMes =Month(AsiFch) AsiDia = Day(AsiFch) (AsiIdLin* MonId AsiImpME AsiImpNS AsiTipDH CtaId AsiFndCot) =Find(CotImp, CotMes=AsiMes .and. CotDia = AsiDia) if MonId <> “NS”; 1 otherwise;

Given : MonId

En la fórmula AsiFndCot, está implícita la condición de que Asiento1.MonId = Cotizac1.MonId Esto se refleja en la navegación como “Given: MonId”

91

3.Cómo se determina la tabla sobre la cual efectuar la búsqueda (tabla de llegada)
• Atributo de Búsqueda • Atributos que están en la condición y que no pertenecen a la tabla extendida del Atributo Fórmula • Atributo de Retorno De otra forma: <Atr.Fórm.> - Fórmula Inválida

Es importante aclarar que los atributos involucrados en la fórmula Aggregate Select y pertenecientes a la tabla de llegada, deben estar ALMACENADOS en la misma. Es decir, que no pueden ser fórmula ni pertenecer a la tabla extendida de la tabla de llegada.

92

Ejemplo de determinación de la tabla sobre la cual buscar:

X = Find( A , B = C .and. D = 4 .and. E = F , 0 )

Atributos de la tabla extendida de X

93

Ejemplo de determinación de la tabla sobre la cual buscar:
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

94

4. Fórmulas Aggregate Select no pueden participar en fórmulas SUM y COUNT simples
No se permite definir una fórmula SUM que suma un atributo que es una Aggegate/Select o depende de ella. Ejemplo: FacProdPre FacLinImp FacSubTot = fórmula MAX = FacLinCnt * FacProdPre = SUM (FacLinImp)

Para resolver esto, se debería almacenar el valor de FacProdPre en otro atributo, pues las Fórmulas Aggregate Select NO PUEDEN SER DEFINIDAS REDUNDANTES. O utilizar la regla ADD en lugar del SUM vertical

95

5. Dependencia física de las fórmulas Aggregate Select
Las Fórmulas Aggregate Select dependen de la inserción, actualización o eliminación física del o los registros que involucran. EJEMPLO : Transacción de Asientos AsiNro* AsiFch AsiTotDeb = Sum(RengImp, RengTipDH=“D” , 0) AsiTotHab = Sum(RengImp, RengTipDH=“H” , 0) (RengId* MonCod RengImpNS RengImp RengTipDH CtaCod )

El COUNT vertical en caso de agregar o borrar una línea no recorre toda la tabla de nuevo, a diferencia del Count Aggregate/Select. Las fórmulas verticales cuentan o suman los valores que estan en "memoria". Las aggregate/select no.

96

Diferencias entre fórmulas aggregate select y fórmulas verticales
1. Las fórmulas agg/sel actúan sobre cualquier tabla de la base de datos y las fórmulas verticales solamente sobre tablas directamente subordinadas. 2. En las fórmulas agg/sel se pueden especificar condiciones de búsqueda. En las verticales no. 3. Las fórmulas verticales cuentan o suman los valores que estan en "memoria". Las aggregate/select no. 4. Las fórmulas verticales cuentan o suman atributos que pueden ser fórmulas (pero esta fórmula no puede ser agg/sel ni involucrar en su definición una fórmula agg/sel). Los atributos mencionados en las fórmulas aggregate/select y pertenecientes a la tabla de llegada deben estar ALMACENADOS FISICAMENTE en la tabla de llegada 5. Las fórmulas agg/sel no se pueden definir como redundantes. Las verticales sí.

97

COMUNICACION ENTRE OBJETOS

98

Objetos GeneXus
TRN

RPT

PROC

MENU

WKP

Comunicación entre objetos GeneXus Una de las características importantes de los objetos de GeneXus es poder comunicarse entre ellos o con otros programas externos. Un objeto GeneXus puede llamar o ser llamado por otro objeto, intercambiando información entre ellos a través de parámetros que se declaran en cada uno.

99

Reglas y Comandos para implementar la comunicación

• CALL • UDP (User defined Procedure) • UDF (User defined Function)

Para implementar la comunicación entre objetos GeneXus (y “no GeneXus”, es decir programas externos) se disponen de los siguientes comandos o reglas : CALL - Llama a un objeto o programa externo, permitiéndose pasar parámetros si éstos son necesarios. Los parámetros especificados son de entrada/salida. UDP, UDF - Se llama a un objeto GeneXus o a un programa externo, al cual se le pasarán los parámetros necesarios y 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ón UDF no deben abrir ninguna tabla, mientras que los llamados por la función UDP sí lo pueden hacer. Esta diferencia existe SOLAMENTE en el generador Fxp 2.6 y VFP (en los demás generadores no existe diferencia entre los udp y udf), las UDF al regresar no reabren/reposicionan las tablas, por lo tanto no soportan que el programa llamado abra tablas. Por otro lado, el Call es un poco más rápido. Las UDP restauran las tablas al volver y se usan para llamar a programas que abren tablas.

100

Cuál es la convención usuada para el nombre de los objetos GeneXus en las llamadas?

Objeto Prefijo Transacción T Procedimiento P Reportes R Work Panel W Menú M Web Panels H

El nombre se trunca a: 7 caracteres 7 “ 7 “ 7 “ 7 “

7

Los programas llamados con las reglas o comandos mencionados pueden ser cualquier objeto GeneXus (Transacciones, Procedimientos , etc.), o un programa externo escrito por el usuario. El nombre de dichos objetos a utilizar en la llamada (call , udp) se forma por un prefijo (identificando el tipo de objeto) seguido por el nombre del objeto truncado de acuerdo a la tabla de más arriba. En caso de que el objeto llamado sea un programa externo, debe mencionarse el nombre del programa entre comillas; en caso de ser un objeto GeneXus va sin comillas. 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 como parámetro.

101

Call
Sintáxis En regla de Transacciones: call(nom-prog,par1,...,par2) if (condición); En layout de los reports, program source de los procedures, eventos de Work Panel y eventos de Transacciones: if (condición) call(nom-prog, par1,...,par2) endif

La regla o comando 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 workpanels) se va a ejecutar proceduralmente en el lugar donde fue escrito.

102

Call - Regla Parm
La regla PARM tiene como función declarar los parámetros en el 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)

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.

103

Udp
Sintáxis En 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 Panels o 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

La Udp ejecuta el objeto o programa ‘nom-prog’ que retornará un valor que será 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 eventos de transacciones o work-panels.

104

Udp - Regla Parm
El último parámetro en la regla parm es el valor de retorno. Ejemplo: parsal = udp(PAltaCli, par1, … , parn) En las Rules de PAltaCli poner: parm(par1, ..., parn, parsal );

Al igual que en los programas llamados con call, en los programas llamados por UDPs se deben declarar los parámetros con la regla Parm. A diferencia con los calls, el programa llamado siempre va a tener un parámetro como mínimo (el parámetro de 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.

105

Ejemplo:

FacImpDesc = udp(‘Pcaldto’, FacTot,FacCat)
En procedimiento PCaldto: parm(&tot, &cat, &desc);
Parámetro de retorno

Los programas llamados se pueden considerar como funciones , ya que al ser llamados utilizando UDP van a 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.

106

SUBRUTINAS

107

Comando SUB
Sintáxis : Sub 'RoutineName’ //cuerpo de la subrutina EndSub
• No se permite el pasaje de parámetros. • Todas las variables del programa fuente pueden ser usadas en la rutina 'RoutineName' , es decir que son globales. • Disponible en Transacciones, Work Panels, Reportes y Procedures.

108

Comando DO
Sintáxis : Do 'RoutineName' Ejecuta la rutina ‘RoutineName’. Disponible en Transacciones, Work Panels, Reportes y Procedures.

109

ARBOL DE EVALUACION Y EVENTOS

110

R. F. F. F. F.

Add(FctTot, CliTotCmp) ; FctTot = FctSubTot - FctDto + FctFleVal FctDto = FctSubTot * CatDto FctFleVal = MAX( FctFleFch, FctFleFch <= FctFch, ... FctSubTot = SUM ( FctImp)

Arbol de evaluación
CliTotCmp FctTot

F. FacImp = FacCnt * ArtPrc

R. Subtract(FctCnt, ArtStk) ; R. Error( ‘Stock Insuficiente’) if ArtStk < 0 ;

FctDto error (‘No hay Stock’) FctSubTot FctImp ArtPrc CatDto

FctFleVal

ArtStk FctCnt

FctFch

Arbol de Evaluación El conjunto de reglas y fórmulas han sido definidas sin especificar su secuencia de ejecución; pero en el momento de generar el programa GeneXus deberá determinar esta secuencia. GeneXus determina las dependencias existentes entre estas reglas y fórmulas, construyéndose lógicamente un árbol de dependencia que determinará la secuencia de evaluación. Podemos imaginar que el árbol se ejecuta de abajo hacia arriba, cada vez que cambia algún valor de un atributo, se ejecuta todo lo que depende de este atributo. Por ejemplo, si cambió la Cantidad se redispara el Importe de la línea, y a partir de esto el Sub-Total, y el Descuento y el Total y la actualización del Total de compras del cliente. También vinculado con la cantidad está el Stock, y se disparará también el Subtract correspondiente. El árbol muestra claramente que debe especificarse: error(‘No hay Stock Suficiente’) if ArtStk < 0 ; No es correcto definir: error('No hay Stock suficiente') if FctCnt > ArtStk; Esto no es correcto, pues decíamos que primero se dispara el SUBTRACT y luego el ERROR, o sea que al momento de considerar el error, ya se disparó el subtract, y se disminuyó el stock. 111

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 detiene cualquier actualización a la base de datos. El árbol es en realidad una red pero donde no pueden haber ciclos, si los hubiera en algunos casos se dispara con el valor anterior. Ejemplo: A = 1/A, se ejecuta en realidad con el valor anterior de A. A = 1 / Old(A)

112

Alteraciones del orden de disparo de las Reglas
Error

PrvCod* FctNro* Total Calculado ... FctTotIng Total ingresado ( ArtCod* Fact Impt FctCnt FctPrc FctImp = FctPrc * FctCnt) ... FctTotCalc = SUM (FctImp) Total calculado Error('El total ingresado no coincide con el total calculado') if (FctTotCalc <> FctTotIng) .and. after(level(ArtCod));

Total Ingresado

En la mayoría de los casos el orden de ejecución de las reglas definido por GeneXus a partir de nuestras especificaciones es el deseado. Pero en algunos casos puedo querer cambiar el momento de disparo de una Rule. Por ejemplo: En las facturas que recibimos de nuestro proveedor queremos controlar que el total que viene impreso en la factura (FctTotIng) sea correcto, por lo que lo calculamos nuevamente (FctTotCalc), y emitimos un error si no es así. Si construimos el 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 primera línea ingresada en la factura y se va a disparar el error en ese momento.y no podré seguir adelante. En este caso la inferencia del árbol de evaluación no me sirve, lo que quiero en realidad es que se me dispare el error cuando termine de ingresar las lineas (a la salida del nivel).

113

Entonces le marco el evento de disparo After(level(ArtCod)) Error('El total ingresado no coincide con el total calculado') if FctTotIng) .and. after(level(ArtCod)); (FctTotCalc <>

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 detiene cualquier 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 casos como 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 FctTotCalc;
// CORRECTO

FctTotIng <>

Error('El total de la factura no coincide con el ingresado') if FctTotIng <> FctTotCalc .and. after(level(ArtCod));

114

Funciones booleanas que permiten cambiar el momento de disparo de una regla
Level( Atributo) After( Atributo ) After(Insert) After(Update) After(Delete) After(Confirm) After(Level(Atributo)) After(Trn) Insert Update Delete

Son funciones lógicas que devuelven .T. or .F. Level Sintá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 ; After Sintá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.

115

Insert, Update, Delete Para 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 Clientes CliCod* Código de Cliente CliNom Nombre de Cliente CliSts 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. 116

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 1 Se ejecuta un Call y luego el otro Ejemplo 2 Se quiere llamar a un procedimiento que realiza determinada validación, y que retorna en la variable &flag, el resultado (S o N). En caso de que el resultado sea negativo se quiere mostrar un mensaje de error. | call(pgmname, CliCod, &flag) if After(Confirm); | | error(' ') if After(Confirm) .and. &flag = 'N'; 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). 117

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.

118

Ejemplo de transaccion de dos niveles
Level CabFac .....................................> reglas stand-alone Trasmit Screen ....................................> evaluación de reglas y fórmulas según árbol Confirm Screen ....................................> reglas after(confirm)
Insert/Update/Delete

....................................> reglas after(insert/update/delete) Level LinFac Trasmit Screen ..........................> evaluación de reglas y fórmulas según árbol Confirm Screen ..........................> after(confirm) .and. level(<att de 2do. nivel>) ....................................> 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
Insert/Update/Delete

119

Eventos en las Transacciones
El código permanece ocioso hasta que ocurre un evento al cual está relacionado Evento = Acción reconocida por un objeto y a la cual se le puede asociar un código ejecutable

Programación Dirigida por Eventos En las transacciones se permite la Programación Dirigida por Eventos, que es un estilo de programación en el que existe código que permanece ocioso, hasta que es llamado para responder a eventos, provocados en nuestro caso por el usuario, o por el sistema. Los eventos son acciones que pueden suceder o no. Nosotros tendremos un código asociado a cada evento posible, el cual se disparará sólo si el evento se produce. Por ejemplo, puede haber un código asociado al evento de presionar una tecla (Por ejemplo <Enter>), que se activará cuando el usuario decida presionar esa tecla. La programación dentro del evento sigue un estilo procedural.

120

Eventos explícitos en las Transacciones
Evento Start Evento ‘User-Event’ Evento After Trn Evento Exit

Start: Es un evento del sistema y se da al comienzo del programa. Es normalmente usado para asignar valores a variables. User Defined Event: Es un evento definido por el usuario, que es activado una vez que se selecciona una opción del menú o se presiona una tecla de función/botón. After 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.

121

Evento Start
Sintáxis: Event Start EndEvent

Se ejecuta al principio del programa.

Ejemplo: Guardar el inicio de ejecución del programa Event Start &entrada=Time( ) EndEvent

Generalmente es utilizado para la asignación de variables y parámetros que interesa evaluar una sola vez en la ejecución del programa.

122

Evento Start
Ejemplos: 1.Event Start &Mes1 = ‘Enero’ EndEvent

2.-

En el Evento Start de la transacción de Facturas : Event Start call(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);

123

Eventos del Usuario
Sintáxis: Event ’User-event-name’ <Key> Level <att> Endevent

Ejemplo Event ‘Deuda Cliente’ 2 Level FacId if .not. null(CliId) call(wdeucli,CliId) endif Endevent

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.

124

Evento After Trn
Event After trn EndEvent
Ejemplo: Event After trn Return EndEvent

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 trn return Endevent Abandonar el programa una vez que se ejecutó un ciclo completo de la transacción.

125

Evento Exit
Event Exit
…………….

EndEvent
Se activa cuando el usuario abandona el programa. Ej: Llamar a un procedimiento que graba la hora de entrada y salida del programa para cada usuario en una tabla de control.

Event Exit &user = userid() &salida = Time() call(‘pcontrol’, &entrada, &salida, &user) EndEvent En el Evento Exit no hay atributos disponibles como para ser evaluados y/o usados.

126

Rules / Eventos
En caso de conflicto de evaluación entre reglas y eventos de una transacción, la regla se evalúa primero.
Eventos: Event After trn ……. return End event Rules: call(tvenfac,FctCod) if after(trn);

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 evento Start no entra en conflicto con las reglas llamadas stand-alone ya que conceptualmente su evaluación son en diferentes momentos. Las reglas stand-alone se evalúan en el primer nivel antes del despliege de la pantalla. El evento Start se evalúa al comenzar el programa.

127

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' 7 call(RPFac, FacNro) Endevent 3. Podemos querer retornar al programa llamador una vez que la transacción haya sido ingresada: Event After trn Return 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

128

5. Por ejemplo, supongamos que en la transacción de facturas queremos dar la opción de visualizar otras compras del cliente. Definimos entonces un evento del usuario: Event "Ver otras compras" 4 Call(wVerComp, CliCod) Endevent Cuando el usuario presione la tecla F4, llamaremos al work panel 'VerCompras' que mostrará las otras compras del cliente.

129

Consideraciones
• No se permite asignar valor a los atributos. • Start-Exit ---> Sin tabla base • User Event-After(trn) ---> Con tabla Base

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 debemos utilizarlos en combinación con reglas. Recomendaciones •Controlar mediante variables seteadas en las reglas que los eventos de usuario hagan calls en situaciones válidas. •Los eventos de usuario pueden evaluarse en cualquier momento, sin tener en cuenta el modo en que está la transacción. •Los atributos pasados como parámetros en los calls que se ejecutan en los eventos, son de entrada/salida, por lo tanto pueden cambiar su valor instanciándose con el valor devuelto por el programa llamado.

130

REPORTES Y PROCEDIMIENTOS

131

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 es un listado que se envía a la impresora, aunque también puede ser visualizado por pantalla. Procedimientos Definen procesos no interactivos de actualización de la base de datos y subrutinas de uso general. Podemos decir que son un superset de los reportes, ya que pueden hacer todo lo que estos hacen y además actualizar la base de datos.

132

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 declarativa y GeneXus resuelve en el momento de generar el programa la secuencia de ejecución, en los reportes las especificaciones son realizadas en forma procedural. • Definición sobre la Base de Conocimiento. La gran protencia del lenguaje de reportes/procedimientos es que las definiciones se hacen sobre la Base de Conocimiento y no directamente sobre el modelo físico. Esto nos permite utilizar automáticamente todo el conocimiento ya incorporado o generado por GeneXus a partir de las especificaciones realizadas. Por ejemplo el concepto de tabla extendida, que es posible porque GeneXus conoce las relaciones entre las tablas de la Base de Datos. Otro ejemplo claro, es el caso de los atributos fórmulas, donde aprovecharemos que GeneXus sabe como calcular el valor para este atributo. •Independencia de la Base de Datos, definición a nivel de atributos. La definición de Reportes y Procedimientos se hace a nivel de atributos, en ningún momento decimos qué tablas se deben recorrer ni qué índices se deben utilizar, sino que esto es determinado por GeneXus en base a las especificaciones realizadas. De esta manera logramos una real independencia de la base de datos, ya que en cualquier cambio en las tablas será manejado automáticamente por GeneXus.

133

Comando For Each
Sintaxis:
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 realizan só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 mencionarse atributos almacenados en la tabla base. El Order es opcional, en caso de no especificarse se asume el orden de la clave primaria de la tabla base (si es que el for each no está anidado a otro for each). Elección del índice: GeneXus elige automáticamente el índice a utilizar para satisfacer el orden, en caso de que no exista, se crea el índice en forma temporal. Where: Establecen condiciones de filtro en la recorrida de la información. Se pueden mencionar atributos de la tabla base y/o de la tabla extendida. 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 que el/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 atributos mencionados 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.

134

Inferencia de las tablas utilizadas en el For Each
• Determinadas automáticamente a través de los atributos del grupo For Each (Order , where, defined by y cuerpo del For Each) • GeneXus después de definir los atributos que participan determina una Tabla Base y su Tabla Extendida • A partir de esto define la navegación

GeneXus infiere la tabla base del for each, por los atributos mencionados en el order, where, defined by y en el cuerpo del for each. Tomemos como ejemplo un reporte con la siguiente definición:

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 Client 3. 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 IClient Todo esto en base a una especificación que sólo incluía los atributos a listar.

135

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 mencionado dentro del comando FOR EACH. Con la base de datos en 3era Forma Normal podemos definir dos conceptos, atributos primarios y secundarios: Atributo Primario: Es aquel atributo que es parte de la clave primaria de alguna tabla del modelo. El atributo puede pertenecer a varias tablas, como un atributo común o como parte de la clave. Por ejemplo DptCod que es un atributo primario, está en las tablas de Client y Depart. Atributo Secundario: Es aquel atributo que no es parte de la clave primaria de ninguna tabla del modelo. El atributo puede pertenecer solamente a una tabla del modelo. Por ejemplo los atributos secundarios CliNom, CliDir solo están almacendos en la tabla Client y DeptoNom solo está almacenado en la tabla Depart. Por esta razón, se puede determinar en que tabla está un atributo si es un atributo secundario. Dado que en el FOR EACH hemos mencionado atributos secundarios de dos tablas Client y Depart, éstas son las que deben usarse en el reporte, con lo cual hemos respondido la interrogante planteada. 2. Cómo pudo GeneXus determinar qué tabla debe recorrer y qué otras tablas debe acceder para complementar la información ? 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, puede saber cuales son las relaciones que existen entre las tablas de la base de datos. Estamos en definitiva utilizando nuevamente los conceptos de tabla base y tabla extendida. El comando FOR EACH define una tabla base y una tabla extendida; en el ejemplo diremos que la tabla de Client es la Tabla Base del FOR EACH y Depart pertenece a la Tabla Extendida de dicha tabla base. La tabla base es en definitiva la que se recorre y la tabla extendida a la que se puede acceder para obtener otra información. 136

Repasemos los conceptos de tabla base y tabla extendida: Toda tabla del modelo (tabla base), tiene información que le permite acceder a todas las tablas del modelo con las cuales está relacionada. La Tabla Base define su Tabla Extendida con todas las tablas que estén en una relación de cardinalidad N para 1 con dicha tabla. Es decir que para cada instancia de la tabla base existe una única instancia de cada tabla de la tabla extendida. Aplicando estos conceptos al ejemplo, vemos que la tabla de Clientes está en una relación de N para 1 con la tabla de Departamentos: Clientes <<----------------> Departametnos Es decir que para cada instancia de la tabla de Clientes (Tabla Base) existe solo una instancia correspondiente en la tabla de Departamentos, por lo que dicha tabla pertenece a su extendida. Por el contrario, si consideramos como tabla base a la de Departamentos, para cada instancia de esta tabla existen posiblemente varios Clientes (N) asociados. Entonces la tabla de Clientes no pertenece a la extendida de Departamentos. Es claro entonces que si mencionamos atributos de la tabla de Clientes y de la tabla de Departamentos y tomando en cuenta la relación existente entre estas, (N para 1), la tabla elegida como tabla base será Clientes. GeneXus puede determinar esto automáticamente porque conoce la relación entre las tablas, y puede entonces además saber cuales son las navegaciones válidas entre estas.

137

3. Qué orden y qué índices deben utilizarse? El reporte saldrá ordenado por Código de Cliente ( CliCod ) utilizando el Indice IClient. FOR EACH Client Order : CliCod Index : 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 elegir el índice a utilizar para satisfacer este orden. Es posible listar en un orden diferente utilizando la cláusula Order del FOR EACH.

138

Ejemplo :Tabla Base y Tabla Extendida
FACTURA
FacNro* FacFch CliCod

CLIENTE
CliCod* CliNom CatCod

CATEGORIA
CatCod* CatDto

FACTURA1
FacNro* ProdCod* FacLinCnt

PRODUCTO
ProdCod* ProdNom ProdPre

139

When None
• Ejecutar determinado código, cuando en un For Each no se encuentra ningún registro. • Sintáxis
For each //clientes Where (condiciones de filtro) (proceso el cliente) When none Msg(“ningún cliente cumple condiciones”) Endfor

El Msg se ejecuta sólo cuando no se entra en el For Each. También se aplica a For Each [Selected] Line, XFor Each y XFor First, los cuales veremos más adelante. Importante: Si se incluyen For Eachs dentro del When None no se infieren Joins ni filtros de ningún tipo con respecto al For each que contiene el When None ya que son considerados dos For Each paralelos .

140

Report Wizard
• Permite diseñar el layout de un reporte (o procedimiento) de una forma mucho más fácil. • Se define a partir de una estructura de datos muy similar a las transacciones.

•El diseño del layout consiste en dos pasos: 1.- Requiere de una estructura de datos en la cual hay que incluir atributos. 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 los cabezales de los atributos para cada uno de los niveles se despliegan horizontalmente o verticalmente. Presionando el botón de “Finish “ se graban las definiciones 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 posible editar 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 orden no tiene por qué ser el primero del nivel.

141

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 las facturas y el segundo todos los recibos.

142

For Each anidados
Tres Casos:
• Tabla Base de los For Each distintas pero relacionadas por uno o varios atributos • Tabla Base de los For Each distintas y no existe ningún atributo relación entre las tablas extendidas de los For Each • Tabla Base de los For Each es la misma: Corte de Control

La tabla base queda determinada estudiando los atributos utilizados en el cuerpo del For Each en el caso de los For Each principales (no anidados). Para el caso de los For Each subordinados la tabla base queda establecida por los atributos utilizados en el cuerpo del For Each siempre y cuando estos atributos no 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 para todo grupo For Each subordinado que no defina una nueva tabla base.

143

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
Cliente

CliCod

Facturas

• Se instancia el orden CliCod en el For Each
Cuando se definen For Each anidados GeneXus intentará establecer que atributos en común tienen ambas tablas extendidas (dándole prioridad a los atributos de la tabla base), y definirá que estos atributos actuarán como condiciones de filtro en la recorrida de la tabla anidada. En este ejemplo, la tabla base del primer for each es la de clientes, y la del segundo, la de facturas. Ambas tablas están relacionadas por el atributo CliCod.
FOR EACH Client Order : CliCod Index : I00101 Navigation filters: Start from: First record Loop while: Not end of table ------->> Client ( CliCod ) FOR EACH Factur Order : CliCod Index : I00402 Navigation filters: Start from: CliCod = CliCod Loop while: CliCod = CliCod -------- >> Factur ( FacNro ) END FOR END FOR

144

For Each anidados

Caso 2 : Cuando tenemos que la tabla base de los For eachs son distintas y no existe ningún atributo que las relacione, el resultado que obtenemos es el Producto Cartesiano de dichas tablas.

Producto Cartesiano: Para cada registro de la tabla base del primer For Each se recorre toda la tabla asociada al For Each anidado.

145

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 orden - determina (tabla Factura) For Each corte de control (tabla Factura) EndFor EndFor -> Defined by, Print if detail

Corte de Control
La resolución de este reporte puede hacerse accediendo únicamente a las facturas, recorriendo la tabla ordenada por cliente. En este caso imprimiríamos solo aquellos clientes que tienen facturas. De todas maneras es necesario utilizar dos for eachs, ya que se necesita una instancia de corte, es decir un momento en el que se cambia de cliente y se puede operar en consecuencia, por ejemplo imprimir el total facturado al cliente. Lo interesante del caso dos for eachs tendrán como tabla base la tabla de facturas. Para lograr esto se puede utilizar la cláusula DEFINED BY del For each o el comando PRINT IF DETAIL. En el ejemplo podríamos mencionar un atributo de la tabla de facturas en el Defined by , con lo que estaríamos diciendole explícitamente a GeneXus que utilizara esta tabla. Si utilizamos Print if detail debemos definirlo en el primer For Each. Se debe definir además en el orden de recorrida del primer for each (cláusula ORDER), los atributos por los que se quiere realizar el corte (en el ejemplo CLICOD). Este es un requerimiento debido a que GeneXus no podría saber cual es el criterio de agrupación que queremos ya que en una misma tabla pueden ser varios, por ejemplo podríamos querer realizar el corte de control por Fecha de factura, totalizando el total facturado cada dìa. Debido a esto es que la definición de la cláusula Order es necesaria.

146

Para resumir, un corte de control queda definido de la siguiente manera: Existen dos grupos FOR EACH anidados sobre la misma Tabla Base, los atributos de corte quedan definidos por el conjunto de atributos especificados en el comando ORDER. Para hacer un corte de control, necesitamos hacer una navegación de Facturas por Fecha. Cuando ejecutemos este reporte, generará un índice temporal por fecha, sobre la tabla Facturas. La navegación de un corte de control es la siguiente: FOR EACH Factur Order : CliCod Navigation filters: Start from: First record Loop while: Not end of table ----- >> Factur ( FacNro ) --- > Client ( CliCod ) BREAK Factur Order : CliCod, FacNro Navigation filters: Loop while: CliCod = CliCod FacNro = FacNro ------->> Factur ( FacNro ) END BREAK END FOR La particularidad de esto es que el segundo For each se muestra como un BREAK. 147

Filtros en la navegación
• Where • Condition • Parm(Atr ... Atr) - Atributos recibidos como parámetros

Como filtrar la información a recuperar de la base de datos. Muchas veces es necesario filtrar la información a incluir en el reporte, por ejemplo supongamos que el reporte deberá listar sólo aquellos clientes cuyo código esté comprendido en un rango determinado. Para resolver esto, tenemos dos opciones: * El uso de condiciones (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 es global para todos los FOR EACH que definamos en el layout y la segunda se cumple sólo para el FOR EACH donde fue definida. La performance es la misma en ambos casos. Debemos escoger una de las dos opciones. La regla PARM() La utilización de atributos en la regla PARM() determina una condición por igual global para todo el reporte o procedimiento. Ejemplo: PARM(CliCod) .
For Each [ CliCod] [CliNom] Endfor

El reporte sólo podrá acceder al cliente cuyo código sea igual al recibido como parámetro. 148

Diseño de la salida
MT

Header …... End
PL

CP [nlinea] Lineno [nlinea] Eject Noskip Footer MB : End

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 66 Setea el largo de página a 66 líneas, aunque sólo 60 líneas serán impresas en el form, con un margen inferior de 6 líneas. CP [nlínea] : Si queda en la página actual un número de líneas mayor o igual al número especificado, continúa imprimiendo en la misma página. De lo contrario, pasa a imprimir en la próxima página (fuerza a un salto de página). Lineno [nlínea] : Define el número de línea donde va a ser impresa la siguiente línea. Si el número de línea actual es mayor al número especificado, entonces, la línea será impresa en la próxima página. Eject : Fuerza a un salto de página. Noskip : Tiene que estar inmediatamente después de un printblock. Si el comando se encuentra entre dos líneas, este comando las imprimirá en la misma línea. 149

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.

150

PROCEDIMIENTOS

151

Inserción de registros
Ejemplo: Inserción en tabla de resumen de ventas anuales
Tabla: CliCod* VtaAno* VtaTot

New CliCod = &CliCod VtaAno = &Ano VtaTot = &Total When Duplicate For each VtaTot = VtaTot + &Total Endfor EndNew

New: Permite dar altas en una tabla de la base de datos. Siempre se ejecuta por clave primaria Cuando hacemos una inserción en una tabla, GeneXus controla que no hayan claves duplicadas. Si quisieramos aplicar un tratamiento especial para estos casos, podemos usar 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.

152

Actualización
For Each Atr = <Exp> ..………. Endfor Actualiza atributo de la tabla extendida

La actualización se realiza en el EndFor.

Los atributos actualizables dentro de un grupo For Each, son todos los pertenecientes a la tabla extendida. La actualización física se realiza cuando se encuentra el EndFor del grupo For Each correspondiente.

153

Delete
For Each defined By FacFch Delete endFor sólo Tabla Base

La ejecución real del comando se produce cuando se encuentra el Delete y no cuando se llega al EndFor .

La eliminación de registros de la tabla base dentro de un grupo For Each se hace mediante el comando DELETE.

154

Restricciones
• No se realiza control de integridad referencial • No Actualiza atributos definidos como redundantes

En los procedimientos, el control de Integridad Referencial queda a cargo del 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.

155

WORK PANELS

156

Work Panels
• Definir consultas interactivas a la base de datos. • Es muy flexible por lo que se presta para múltiples usos.

157

Diferentes tipos de Paneles
Entry Panel Display Panel Single Choice Selection List Multiple Choice Selection List Action List

Las normas Common User Acces de IBM definen diversos tipos de pantallas, estandarizando los diálogos con el usuario.

158

Entry Panel - Panel de Entrada

Paneles de Entrada Son paneles de entrada/salida. A través de ellos se aceptan y se despliegan valores. Por ejemplo, un panel de entrada puede ser una pantalla previa a una impresión, donde se piden los parámetros necesarios para la misma y luego se llama a un Report.

159

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 mostrar una cantidad variable de datos. Esto último, consiste en mostrar varias líneas por pantalla permitiendo que el usuario se desplace hacia arriba y hacia abajo (scrolling).

160

Selección Unica/Selección Múltiple/Listas de Acción

Area Fija

Subfile

Teclas de

Eventos y función

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 los usuarios pueden seleccionar solamente una. La forma de hacer la selección es teclear algún valor en la línea a ser seleccionada. Una acción puede ser entonces ejecutada sobre el contenido de la línea seleccionada. Listas de Selección de opción múltiple Una lista de selección de opción múltiple contiene un grupo de posibilidades de las que los usuarios pueden seleccionar cualquier número de ellas. Una lista de este tipo permite que una acción (solamente una) sea ejecutada en varias líneas simultaneamente. Lista de Acción Se pueden elegrir acciones diferentes a aplicar a cada una de las líneas.

161

Comando For Each Line
Sintáxis: For Each Line …….. EndFor

Recorre todas las lineas del subfile

En caso de querer recorrer sólo las lineas del subfile que 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 fueron seleccionadas 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).

162

Programación dirigida por Eventos
El código del programa permanece ocioso hasta que se invoca su ejecución mediante acciones tomadas por el operador del programa frente a la pantalla .
Ejemplo: Event Enter Código en respuesta a pulsar la tecla Enter EndEvent

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 que permanece ocioso hasta que es llamado para responder eventos provocados por el usuario o por el sistema. Los Work-Panels se definirán entonces de una manera menos procedural 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.

163

Eventos
• • • • • • Start Refresh Load Enter User-defined Exit

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 por defecto a las variables del área fija de la pantalla. Evento Refresh: Es un evento del sistema, ocurre inmediatamente antes de comenzar la carga del subfile. En un ambiente multiusuario, los datos de la pantalla pueden estar desactualizados si 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 cargar nuevamente el subfile. Por ejemplo cuando en un evento se llama a una transacción que actualiza 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 es modificada por el usuario. Estas variables determinan qué datos se cargarán en el subfile, si una 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 usado generalmente 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 operador presiona la tecla de función o el botón asociado al evento.

164

Estructura de los eventos
Comienzo Evento Start Evento Refresh Evento Load Mostrar datos en pantalla Evento Enter Evento 'User Defined' Evento Exit

Fin

165

Reglas más importantes
• • • • • Order Noaccept Search Hidden Workfile_lines

Order Define 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); Noaccept A 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 regla NOACCEPT. Search Cuando el subfile es demasiado extenso, muchas veces se quiere brindar la posibilidad de que el 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 deben incluirse 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, pero se 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 que no existe un límite en la cantidad de líneas a cargar en ellos en PC o LAN , puede traer problemas 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 ”.

166

Propiedades más importantes
Loading Load Records Load at Startup Automatic Refresh Refresh 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 vez que uno de los valores de la parte fija son modificados. Los valores posibles son Only when variables in condition change (default): : Tiene el comportamiento de 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 subfile automáticamente si el usuario no efectuó ninguna operación en el lapso de tiempo especificado. No hay valores predefinidos. Debe especificarse un valor en segundos (lapso de tiempo).

167

Work-Panel con o sin Tabla Base ?
Los atributos que determinan la tabla base y su extendida son los definidos en: • Panel • Reglas Hidden y Order • Eventos ( fuera de comandos For Each)

•Work Panel sin tabla base

comando LOAD

Work -Panel con tabla base: En la navegación: For Each [ Tabla Base ] Order: Atributos del indice por clave Primaria (si no se incluyó regla order) Index: Clave primaria (si no se incluyó regla Order) // Otros For Eachs definidos en los eventos Endfor 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.

168

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.

169

SUBTIPOS

170

Subtipos
Ejemplo: Transferencias entre Bancos. Atributos similares que cumplen roles diferentes. Transacción de Bancos: BcoCod* BcoNom Transacción de Transferencia : TrnNro* TrnFch ‘Problema’ BcoCod Atributos BcoNom con el BcoCod mismo BcoNom nombre TrnImp

Código de Banco Nombre de Banco

Número de transacción Fecha Banco Origen Nombre del Banco Origen Banco Destino Nombre del Banco Destino Importe

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 la misma transacción. Para estos casos GeneXus provee los Subtipos, los cuales permiten definir que dos atributos que se llaman diferente, corresponden al mismo concepto.

171

Transferencia: TrnNro* TrnFch

Subtipos
Bancos: BcoCod* BcoNom TrnBcoOriCod TrnBcoOriNom TrnBcoDestCod TrnBcoDestNom

Subtipo TrnBcoOriCod TrnBcoOriNom TrnBcoDestCod TrnBcoDestNom

Supertipo BcoCod BcoNom BcoCod BcoNom

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 comparten la 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 se obtendría en el caso que se utilizara directamente el supertipo.

172

Subtipos: Grupos

Almacenado Inferido

TrnBcoOriCod TrnBcoOriNom

Grupo TrnBcoOri

Almacenado TrnBcoDestCod Inferido TrnBcoDestNom

Grupo TrnBcoDest

Todavía queda algo por determinar. Tenemos dos bancos y dos nombres pero en ningú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.

173

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, ni tampoco en la misma tabla extendida. • No se pueden actualizar los subtipos inferidos (Add, Subtract). • Los subtipos no se pueden definir redundantes

174

KNOWLEDGE MANAGER

175

Distribución

Se genera el archivo Respaldo.xpw en la raiz de la KB

176

Consolidación

Pide el path del archivo .xpw a ser consolidado

177

BUSINESS OBJECTS

178

Qué es un Business Object ?
•Representación de un objeto de la realidad: producto, persona, factura, moneda, pais •Para su definición se toman en cuenta: atributos que definen al objeto, operaciones que le son relevantes, cómo se relaciona con otros objetos.

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.

179

Cómo representar un Business Object con Genexus?
Cada BO GeneXus es un folder que contiene todos objetos necesarios para definir el comportamiento y el uso de dicho BO:
Transacciones que definen objetos básicos Work Panels de trabajo Reportes Procedimientos que implementen operaciones relevantes

180

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.

181

Características de un BO
Independiente No ligado a ninguna aplicación Standard y simple Fácilmente adaptable Documentado Bien testeado

182

Cuándo usar BO?
Al crear nuevas aplicaciones Al agregar nuevas funcionalidades a una aplicación existente

183

Ventajas de su uso
Reusabilidad :
–aumenta productividad –disminuye esfuerzo de desarrollo

Proveer soluciones rápidamente Facilitar la ampliación de las funcionalidades de una aplicación Compartir conocimiento

184

Algunos BO Genexus
Paises Productos Personas Monedas Tipos de IVA Numeradores
Disponibles en el Web Site de Artech

185

Distribución de los BO
Exportar el folder que contiene el BO Envíar exportación (xpw) por mail a webmaster@artech.com.uy Datos importantes que deben ser incluidos en la documentación enviada:
Breve descripcion del BO (objetos que lo componen y su funcionalidad) (objetos funcionalidad) •Documentación adicional que se desee adjuntar. ocumentació adjuntar. •Autor •Fecha de última actualización actualizació •Versión de GeneXus con que se implementó ersió implementó

ARTech pondrá disponible el BO en su Web Site.

186

OBJETOS PRIVADOS

187

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 aquellos objetos 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.

188

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 Privados En 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).

189

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.

190

EFICIENCIA Y PERFORMANCE DE LAS APLICACIONES

191

Puntos a Considerar
• • • • Optimización de la Entrada-Salida Uso de Calls Open y Close de archivos Uso de Indices Temporales

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 este comando. 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.

192

Optimización de Entrada-Salida Definición de Filtros Peor Estrategia
Begin of File READ READ READ READ READ READ READ READ READ READ READ End of File End of File

Estrategia Optima
Begin of File

< Start Point
READ READ READ READ

< End Point

Normalmente los programas procesan registros agrupando aquellos que tengan ciertas características comunes, por ejemplo, todas las facturas de un determinado cliente, o las ventas 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 diversas formas; asi pueden ser por ejemplo WHEREs en un FOR EACH, condiciones en una fórmula Aggregate/Select, parametros , etc. Ejemplo: De todos los clientes, quiero imprimir los datos de aquellos cuyo código este en un rango determinado. El tiempo necesario para realizar el proceso con los registros que cumplen las condiciones, determina el grado de "optimización" que tiene la estrategia de acceso elegida. Decimos que una estrategia de acceso esta más "optimizada" que otra, cuando es necesario un menor tiempo para leer todos los registros que cumplen las condiciones establecidas. 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 que las cumpla. Lo que se establece en definitiva, es un intervalo que cubre todos los registros que cumplen las condiciones. En este intervalo no necesariamente todos los registros cumplen la condición.En estos casos, la mejor estrategia consiste en tener el menor intervalo tal que cubra a todos los registros que cumplirán la condición. Igualmente las lecturas se realizarán para todos los registros de este intervalo, pero solamente se considerarán aquellos que cumplan con las condiciones.

193

Definición de Filtros

• Cláusula Where en For Each
• Conditions en Prcs, Rpts, Wkps. • Parm() en Trns, Prcs, Rpts, Wkps

Where: La clausula "Where" permite filtrar registros en la navegación de un determinado grupo FOR EACH. Por ejemplo: Para establecer los filtros descritos anteriormente, utilizaríamos la siguiente especificación: FOR EACH W HERE CliCiu = 'Montevideo' .AND. CliCod >= 1 .AND. CliCod<= 100 ... ENDFOR Conditions: Las "Conditions" sirven para establecer un filtro en forma global, es decir que solamente se podrá acceder a los registros que cumplan con esta condición. Cuando se establece una condición sobre atributos, afecta a todos los grupos FOR EACH que contengan ese atributo. 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, pero solamente por igualdad. Cuando se recibe un parámetro en un atributo, obtenemos una especificació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; 194

Definición de la estrategia de acceso.
1ero.) Se define el orden en que se recorrerá el archivo 2do.) Se elige el punto de comienzo (Starting point) 3ero.) Elegir la posición final ( End Point). 4to.) Leer secuencialmente los registros entre el punto inicial y el punto final, seleccionando los registros que cumplen las condiciones y descartando los restantes.

Definición de la estrategia de acceso con GeneXus Para definir una buena estrategia de acceso, GeneXus cuenta con una inteligencia razonable. A contínuación se explica cómo se decide la estrategia a partir de las especificaciones realizadas. Se determinará, estableciendo ( de acuerdo a las condiciones y el orden en que deban considerarse 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.

195

Orden de Recorrida
Importancia del Orden en que se leen los registros.
Ejemplo: Condiciones de Filtro compatibles con el Orden For each Order CliCod Where CliCod >= &IniCod .and. CliCod <= &FinCod .... .... Endfor Cod 1 *2 *3 *4 5 Nombre Smith Jones <----- Starting Point Read Ball Read King <----- Ending Point Read Ander

&IniCod = 2 &FinCod = 4

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 haya definido.

196

Orden de Recorrida
Importancia del Orden en que se leen los registros.
Ejemplo: Condiciones de Filtro no compatibles con el Orden For each Order CliNom Where CliCod >= &CodIni .and. CliCod <= &CodFin ... Endfor Cod Nombre *3 Ander <----- Starting Point 5 Ball 6 Churchill 1 King *4 Smith *2 William <----- Ending Point

Read Read Read Read Read Read

&CodIni = 2 &CodFin = 4

197

Orden de Recorrida
Si no se define un Orden se elige el de la Primary Key
Ejemplo: Nombre inicial : &IniNom Nombre final : &FinNom

For each Where Clinom >= &IniNom .and. Clinom <= &FinNom Endfor Orden elegido --> CliCod

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 que se tomará el orden de la clave primaria y en base a este orden se optimizarán las condiciones 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 entre atributos 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 EACHs anteriores. Ejemplo: Clientes CliCod* Tipos TypCod* CliNom TypNom TypCod Tenemos Clientes y Tipos de clientes, y queremos listar los tipos de clientes y los clientes de cada tipo, haremos la siguiente especificación: For each [TypCod] [TypNom] For each [CliCod] [CliNom] Endfor Endfor Como primera cosa, GeneXus infiere que los clientes que queremos recorrer son aquellos del tipo (TypCod) que acabamos de considerar en el FOR EACH anterior. Es decir, que hay una condición implícita que indica que:Tipos.TypCod =Cliente.TypCod

198

Esto ocurre cuando se tienen FOR EACHs anidados, cuyas tablas bases tienen alguna relación; GeneXus la encuentra y determina en forma automática una condiciónde filtro. Esta relación sólo puede establecerse entre atributos primarios (aquellos que forman 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 orden es 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 permita optimizar la condición de filtro.

199

Posición de Comienzo
Consideraciones para su definición.
Se consideran las condiciones compatibles con el orden y que sean 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.

200

Posición de Comienzo
Ejemplos:
Orden: A B C Condiciones : A>= 5 .and. C > 3 Posición de comienzo: A>=5 Orden: A B C Condiciones : A > 5 .and. B < 2 .AND. C > 3 Posición de comienzo: A > 5

201

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.

202

Diagrama de Navegación
For each CliCod Where CliCod >= &IniCli .AND. CliCod <= &EndCli [ CliCod ] [CliNom ] Endfor FOR EACH Clientes Order : CliCod Index : ICliente Navigation filters: Start from: CliCod >= &IniCli Loop While CliCod <= &EndCli Constraints: CliCod >= &IniCli .AND. CliCod <= &EndCli ---->> CLIENTES ( CliCod ) END FOR

203

Diagrama de Navegación
For each CliCod [ CliCod ] Endfor [CliNom ]

FOR EACH Clientes Order : CliCod Index : ICliente Navigation filters: Start from: First record Loop while: Not end of table ---->> CLIENTES ( CliCod ) END FOR

204

También influyen en la performance:

• Calls •Apertura y Cierre de Archivos • Uso de Indices Temporales

- 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 buena y una mala performance ( ya que no tiene el mismo costo que hacerlo todo en un único programa 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 tiempo total del proceso.

205

For each Cuenta Where 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 utiliza para realizar el llamado (call) , y el objeto llamado (Y) abre y cierra únicamente las tablas que utiliza. 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, que hayan 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 reabrir lo que corresponda, el peor caso es cuando los dos usan las mismas tablas y el mejor es cuando usan todas distintas. a) Pgma X Open A, B, C Call Y Close A B C Open B Close A,B, C Pgma Y Open D,E .... Close D, E b) Pgma X Open A, B, C Call Y Pgm Y Open D, E Close B y Open B .... Close B, D, E

206

Indices CDX: En este caso, en los objetos llamados, no se cierran las tablas que habían sido abiertas en los objetos llamadores y solamente reabren los índices de la forma que los necesita. Pgma X Open A, B, C ……. Call Y Restaura todo a como estaba antes del call ... Close A, B, C Pgma Y Open D, E Reposiciona Indices B,C .... Close D, E

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.

207

MULTIPLES FORMS

208

Múltiples Forms por Objeto
• Poder tener N pantallas por objeto. • Permitir dentro de una misma KB tener modelos en los que se genera para ambiente gráfico y otros en los que se genera para ambiente caracteres.

209 45 41 42

Form Classes

•Create automatically in new objects: Significa que cada vez que se crea un nuevo objeto, automáticamente se crea un form de esa clase en el mismo. Cuando se importa, se genera automá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 como Text.

210

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 tiene asociado una lista de Form Classes para cada generador del mismo.
– Opción: File/ Edit Model/ Model Forms

•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 de Genexus.

211

¿Cuándo decide GX el form a utilizar ?
• En tiempo de Especificación • Apertura del objeto

•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 considerar Para 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 la lista y así hasta encontrar o que se acabe la lista. Si se acaba la lista y no se encontró, entonces de acuerdo al generador (gráfico o de caracteres) se busca un form que sea de ese tipo, si tampoco se encuentra entonces se especifica cualquiera y en el caso que haya que convertir, se convierte a texto. En cualquier caso, en el reporte de la especificació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

212

STYLES

213

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 los otros 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ñar Form 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

214

Definición de un Style
• Object/New Object. • Ejemplo de un Style de transacción.

215

Style
Style Area

Data Area

Este espacio se puede usar para poner comentarios

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 area aparecerá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.

216

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.

217

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, GeneXus considera 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.

218

Creación de un objeto basado en un Style

Las líneas de la data area estan en azul indicando que se perdió el dinamismo con 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).

219

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.

220

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 borrar cualquiera 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.

221

Cambio en el tamaño de 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.

222

Consideraciones para el 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 clave noaccept(clave)

223

Master Style
• Objetivo: Style default • Se define por modelo • Por “tipo de objeto” salvo:
– Prompt - Workpanel – Report – Procedure – File/Edit Model/Master Styles

•Master Style Existe 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 Style como 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 Reports como 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.

224

Master Style
• Precedencia:
– Style asociado – Master Style – Default

225

MENU BAR Y TOOL BAR

226

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 opciones Edit/Insert y Edit/Delete respectivamente. La definición de la Tool Bar es exactamente igual a la del Menu Bar, sólo que en los items 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 ya provee este work panel, en caso de querer personalizarlo se debe crear un nuevo work panel con este mismo nombre con la información deseada.

227

Tipo de objeto Menu Bar
Definició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án en 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 eventos son 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.

228

PROPIEDADES, EVENTOS Y METODOS ASOCIADOS A LOS CONTROLES

229

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 tiene asociadas. • Sólo en generadores gráficos:
– VB, VFP, JAVA

•Algunos controles tienen un nombre por defecto, pero hay otros que no; por lo 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 hacer Insert/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.

230

Propiedades de los Controles
• El ‘nombre del control’ para atributos/variables es el nombre del atributo/variable. • NOTA: Si una variable es un vector, debe indicarse un nombre a cada posición del vector para diferenciarlas.

231

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

232

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 y que tienen un nombre asociado. •Property: Despliega la lista de propiedades que se pueden aplicar al control seleccionado y en la segunda columna se despliegan los tipos de cada property. El Help trae el Help de la property seleccionada

233

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.

234

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.

OnLineActivate Es 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.

235

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 control seleccionado.

236

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 que se 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 de especificación.

237

OBJETOS MAIN

238

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.

239

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.

240

¿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

241

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.

242

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

243

DATA VIEWS

244

DataViews - Archivos Externos
Los Data Views de GeneXus permiten manejar Archivos Externos como si fueran Archivos pertenecientes a la Base de Conocimiento. Propiedades • Definición Global • Uniformización de la nomenclatura

245

DataViews - Archivos Externos
Para trabajar con Archivos Externos en GeneXus tenemos dos posibilidades: DATA VIEWS » Sin tabla Asociada » Con tabla Asociada

246

Data Views
GENEXUS DA TABASE DATA VIEW DEFINITION EXTERNAL ENVIRONMENT

EXTERNAL FILE

SIN TABLA ASOCIADA

INTERNAL TABLE

EXTERNAL FILE

CON TABLA ASOCIADA

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 asociada Supongamos 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 se refiere a tipos y tamaños con los campos externos, pero los nombres pueden ser redefinidos respetando la nomenclatura GIK.

247

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 al Archivo 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ón de una tabla física por estar asociada a un DataView. Esta transacción se especifica y genera como cualquier objeto de la Base de Conocimiento y en ejecución, accede en forma interactiva a los registros de la tabla externa en forma transparente.

Data View sin transacción interna asociada En 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.

248

Definición de un Data View

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 internos y los campos externos. [Nombre Interno] [Nombre Interno] [Nombre Interno] [Nombre Externo] [Nombre Externo] [Nombre Externo]

Cuando no se menciona el Nombre Externo es porque coincide con el Nombre 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 la aplicación. Plataform Specific Information: Aquí se debe completar información del archivo externo (como ser la plataforma y ubicación).

249

Composition
• Ejemplo:
Dados los siguientes Archivos Externos:
CLIENTES Codigo* CliNom CliDir Composition CliCod 'Codigo' CliNom CliDir PRODUCTO Codigo* ProDsc ProPre Composition ProCod 'Codigo' ProDsc ProPre

Se uniformiza la nomenclatura

250

Indices

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 el nombre 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. Los atributos mencionados acá deben ser parte de la Composition del Data View.

251

Platform Specific Information / Add

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.

252

Platform Specific Information / Edit

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.

253

Associated Table
GENEXUS DEVELOPMENT ENVIRONMENT
GENEXUS MODEL DATA VIEW DEFINITION EXTERNAL ENVIRONMENT

----INTERNAL TABLE

----------------------

EXTERNAL FILE

INTERNAL INDEX

----------

EXTERNAL INDEX

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.

254

Associated Table
Tabla Interna = Tabla Externa

------INTERNAL TABLE

---------

EXTERNAL FILE

Existe una relación de uno a uno entre los atributos de la Tabla Interna del Data View y los del Archivo Externo.

255

Associated Table
Tabla Interna < Tabla Externa

Not Accessed

--INTERNAL TABLE

-------

EXTERNAL FILE

Los atributos definidos para la Tabla Interna y para el Data View coinciden, pero el Archivo Externo tiene atributos no declarados en el Data View. Estos atributos no pueden ser accedidos.

256

Associated Table
Tabla Interna > Tabla Externa

GENEXUS DATABASE

DATA VIEW DEFINITION

EXTERNAL ENVIRONMENT

---INTERNAL FILE NOT ALLOWED

--------

EXTERNAL FILE

Si la Tabla Interna tiene más atributos que el Archivo Externo no es válida la asociación.

257

Associated Table
Tabla Interna > Tabla Externa
USO DE SUBTIPOS

GENEXUS DATABASE
CliCod* CliNom

DATA VIEW DEFINITION

EXTERNAL ENVIRONMENT

---ALLOWED

Codigo Nombre

INTERNAL TABLE A

------

EXTERNAL FILE

Subtype CliCodSub* CliNom CliDir CliEMail INTERNAL TABLE B

En el ejemplo, se pide tener también como datos del Cliente el E-Mail y la dirección.

258

Asociación Dinámica

Las definiciones del Archivo Externo e índices asociados coinciden con las definiciones de la Tabla Interna y sus índices (tanto en nombres como en la composición).

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.

259

Arbol de Definición
Archivos Externos Data View Definición Global

CON Tablas Asociadas

SIN Tablas Asociadas

Asociación Dinámica

Asociación Definida

260

REORGANIZACIONES DATA VIEWS
1. EXISTE TABLA ASOCIADA Si cambia la estructura de la tabla asociada, el cambio es detectado 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.

261

WEB PANEL
• Permite construir páginas WEB dinámicas que interactú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.

262

GeneXus Intermedio.
Optimizando Aplicaciones. Relator : Héctor Zavala Rubio.

TABLA 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

1

PUNTOS IMPORTANTES EN LA DEFINICION DE TRANSACCIONES
Definición de Modos

Modo Inicial
• El modo inicial de un nivel de una Transacción depende de la plataforma y puede ser modificado en cada nivel usando la rule Default_Mode.

2

Micro/LAN:
• Modo UPDATE por defecto • Se puede indicar el modo inicial usando la rule DEFAULT_MODE • El modo se mantiene hasta cambiar a otro modo

AS/400
• El modo para el PRIMER 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 NIVEL

3

Loop Once
•La transacción recibe la variable &Mode como parámetro (Update o Delete)
y

•La Primary Key se recibe como parámetro: parm(<att1>, …, <attn>); •Ningún atributo es aceptado

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.

4

EJEMPLO: Delete Cascade
Orden de Compra OrdNro* OrdFch PrvCod PrvNom AnaNro AnaNom (PrdCod* PrdDsc OrdCnt OrdPrc PrdPrc) OrdImpTot Entregas OrdNro* PrdCod* (EntFch* EntImporte) - Transacción Orden
Se desea eliminar una Orden

Tabla Orden

Tabla Entregas Tabla Entrega1

- Transacción Orden
Se desea eliminar una Linea de la Orden

- Transacción Entregas
Se 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' 'UPD' 'DLT' Insert Update Delete

• El modo recibido en &Mode se aplica al primer nivel y no se puede cambiar. • La variable &Mode no puede ser modificada en la Transacción, para poder utilizarla debe ser recibida como parámetro.

5

EJEMPLO: Transacción de pedidos
PedNro* PedFch PrvCod PrvNom PedImpTot (PrdCod* PrdDsc PedCnt PrdPrc)

CASO 1: El Identificador se recibe en el atributo parm(PedNro, &Mode ) ; CASO 2: El Identificador se recibe en una variable parm(&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 Total 1,000,000 234,000 500,000

Número Fecha Proveedor - 001 01/01/92 1 Proveedor Uno - 002 - 003 12/03/92 2 Proveedor Dos 12/12/92 3 Proveedor Tres

F6 = Ingresar Pedidos

6

Eventos:
Event Enter For each line if &Op = '2' // Modificar call(TPedido,PedNro, 'UPD') endif if &Op = '4’ // Eliminar call(TPedido,PedNro, ‘DLT’) endif endfor refresh EndEvent Event 'Ingresar Pedidos' 6 call(TPedido,0,’INS’) refresh EndEvent

PUNTOS IMPORTANTES EN LA DEFINICION DE TRANSACCIONES
Definición de Prompts y Refcalls

7

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 > F4 AS/400 > F4

– Autoprompt : PC > Botón de SELECT AS/400 > F16 (Ver)

Rule Refcall
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 como variables. •Los atributos se deben corresponder con una foreign key .

8

Rule Prompt
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 Key Sustituye al Prompt que genera GeneXus por defecto. Atributos Secundarios Si 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. Variables Si 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 las rules).

Reglas para el prompt por defecto
• Los parámetros no instanciados se utilizan como condiciones de búsqueda con >=, con un máximo de 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 .

9

Ejemplo
TRANSACCIONES:
Categoría CatCod* CatNom SubCategoría CatCod* SubCatCod* SubCatNom Movimientos MovNro* CatCod SubCatCod SubCatNom CatNom

TABLAS:
Table Name Categori SubCateg Attributes *CatCod CatNom *CatCod *SubCatCod SubCatNom *MovNro CatCod SubCatCod

Movimien

Prompts generados al especificar la Trn de Movimientos
Table Program Parameters Instanciado Movimien WGx0030 MovNro Categori WGx0010 CatCod Subcateg WGx0021 CatCod*, SubCatCod (*) Atributo

– – –

WGX0030 es el Autoprompt para la tabla Movimien WGx0010 es el Prompt para la tabla Categori WGx0021 es el Prompt para la tabla Subcateg

10

EJEMPLO: Se elimina la Transacción Categoría Tablas: SubCateg Movimien

*CatCod *SubCatCod SubCatNom *MovNro CatCod CatNom SubCatCod

Prompts para la Trn de Movimientos: Table Program Parameters Movimien WGx0030 MovNro SubCateg WGx0020 CatCod, SubCatCod Se genera un único prompt para la tabla SubCateg.

PUNTOS IMPORTANTES EN LA DEFINICION DE TRANSACCIONES
Disparo de Rules

11

EJEMPLO: Transacción Factura
FacId* FacFch CliCod CliNom CliSdo CliDir (PrdCod* PrdDsc FacLinCnt FacLinPrc PrdPrc PrdStk PrdStkMin FacLinImp) FacSubTot FacIva FacTotCal

Reglas:

default(FacFch ,today() ) ; error('No hay Stock suficiente') IF PrdStk< 0; subtract(FacLinCnt,PrdStk);

Fórmulas:

FacLinImp=FacLinCnt*FacLinPrc FacSubTot = SUM (FacLinImp) FacIva = FacSubTot * 0.22 FacTotCal = FacSubTot + FacIva

DISPARO DE RULES
GeneXus se encarga de determinar el orden de Disparo de las reglas según las GeneXus se encarga de determinar el orden de Disparo de las reglas según las dependencias de los atributos indicados dependencias de los atributos indicados

–– ORDEN DE DECLARACION: ORDEN DE DECLARACION: error('No hay Stock suficiente') IF PrdStk < 0; error('No hay Stock suficiente') IF PrdStk < 0; subtract(FacLinCnt,PrdStk); subtract(FacLinCnt,PrdStk); –– ORDEN DE EVALUACION: ORDEN DE EVALUACION: subtract(FacLinCnt,PrdStk); subtract(FacLinCnt,PrdStk); error('No hay Stock suficiente') IF PrdStk < 0; error('No hay Stock suficiente') IF PrdStk < 0;

12

Orden de Disparo
TOT FECHA

IVA 0.22 . STOT
SUM

FECHA SISTEMA ERROR

STOCK

IMP
subtract

PRECIO

CANT

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.

13

Level(Atributo)
EJEMPLO: No permitir modificar líneas de una Factura Transacción Factura FacId* CliCod ... ( PrdCod* FacLinCnt PrdPrc FacLinImp) ... FacTotCal

Regla:
Error('No puede modificar la linea') IF Modified() .and. Level(PrdCod);

After(Insert | Update| Delete)
EJEMPLO: Trn Clientes CliCod* CliNom CliSdo CliDir CliSts Llama a un procedimiento que realiza la impresión de los datos del cliente y setea el atributo Status. LLAMADAS INCORRECTAS call('pficha', CliCod) if Insert .and. After(Confirm); call('pficha', CliCod) if Update .and. After(Confirm); LLAMADAS CORRECTAS Si 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);

14

After(Level(Atributo))
EJEMPLO: Factura_ Factura_Proveedor PrvCod* FacId* ... FacTotIng ( PrdCod* FacLinCnt PrdPrc FacLinImp) ... FacTotCal=SUM(FacLinImp) – Rule: Error('El total ingresado no coincide con el total calculado') IF FacTotIng<> FacTotCal;

After(Level(Atributo))
Según el árbol de evaluación cada vez que el importe cambie, cambiará el total calculado.
TOT CALC

IVA 0.22 STOT
SUM

IMP

PRECIO

CANT

15

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 Caso1 FacNro = udp(’PNumera’, ‘FAC’) IF insert ; Caso2 FacNro = udp(’PNumera’, ‘FAC’) IF after(insert ); Lo correcto es : FacNro = udp(’PNumera’, ‘FAC’) IF insert .and. after(Confirm);

16

After(Trn)
EJEMPLO 1: Queremos llamar a Líneas de Factura después de ingresar el Cabezal de la Factura.
CabezalFactura FacId* FacDatos CliCod LineasFactura FacId* (PrdCod* 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: Factura FacId* FacFch CliCod CliNom CliSdo CliDir (PrdCod* PrdDsc FacLinCnt FacLinPrc PrdPrc PrdStk PrdStkMin FacLinImp) FacSubTot = SUM(FacLinImp) FacIva = FacSubTot * 0.22 FacTot= FacSubTot + FacIva Cliente CliCod* CliNom CliSdo CliDir

17

Rules de la trn Facturas:
add(FacTotal, CliSdo); call('pgmname', CliCod) IF After(Level(PrdCod)); call('pgmname', CliCod) IF After(trn); INCORRECTA

CORRECTA

Reglas que ocurren en el mismo evento
• EJEMPLO 1: | call(' | | call(' v ') if After(Trn); ') if After(Trn);

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

18

Eventos en una Transacción de dos niveles
FacId* FacFch ---------> AFTER (FacFch) CliCod CliNom CliSdo CliDir ------> | AFTER (CliDir) (PrdCod* | AFTER(CONFIRM).AND.LEVEL(FacId) PrdDsc | AFTER (INSERT|UPDATE|DELETE) FacLinCnt FacLinPrc PrdPrc PrdStk PrdStkMinimo FacLinImp) --> | AFTER (LEVEL(PrdCod)) FacSubTotal | AFTER (TRN) FacIva FacTotal

USO Y RECOMENDACIONES EN EL USO DE SUBTIPOS

19

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 diferentes a 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

20

A. Atributos conceptualmente iguales que cumplen roles diferentes.
RESERVAS ResNro* CiuCod (orig) CiuCod (dest) RESERVAS ResNro* CiuCodOri CiuCodDes CIUDADES CiuCod* CiuNom

CIUDADES CiuCod* CiuNom

A. Atributos conceptualmente iguales que cumplen roles diferentes.
• Con la definición de subtipos se establece la siguiente relación:
RESERVAS CIUDADES

• 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”.

21

A. Atributos conceptualmente iguales que cumplen roles diferentes.
• Utilización de atributos secundarios del supertipo definiendo atributos subtipos dentro de un grupo
CiuCodOri CiuNomOri CiuCodDes CiuNomDes CiuCod CiuNom CiuCod CiuNom (Origen) (Origen) (Destino) (Destino)

Definición de Subtipos

22

B. Especialización de atributos
• Se definen PrvNro y CliNro como subtipos
EMPRESAS EmpNro* EmpNom EmpRuc EmpTel EmpDir PROVEED PrvNro* PrvSal CLIENTES CliNro* CliSal

Proved.

Empresas

Clientes

B. Especialización de atributos

CliNro CliNom PrvNro PrvNom

subtype of subtype of subtype of subtype of

EmpNro EmpNom EmpNro EmpNom

group Cliente group Cliente group Prov group Prov

23

C. Evitar controles de integridad referencial
Historico de Compras PrvCod* PrvNom PrdCod* PrdTxt HisCnt Ordenes de Compra OrdCmpNro* PrvCod PrdCod Productos PrdCod* PrdTxt

Proveedores PrvCod* PrvNom

C. Evitar controles de integridad referencial
Historico de Compras PrvCod* PrvNom PrdCod* PrdTxt HisCnt Ordenes de Compra OrdCmpNro* PrvCod PrdCod Productos PrdCod* PrdTxt

Proveedores PrvCod* PrvNom

24

C. Evitar controles de integridad referencial
PrvCod* PrvNom PrdHisCod* (Subtipo de PrdCod) PrdHisTxt (Subtipo de PrdTxt) HisCnt OrdCmpNro* PrvCod PrdCod

C. Evitar controles de integridad referencial
Historico de Compras PrvCod* PrvNom PrdHisCod* PrdHisTxt HisCnt Ordenes de Compra OrdCmpNro* PrvCod PrdCod Productos PrdCod* PrdTxt

Proveedores PrvCod* PrvNom

25

TABLA EXTENDIDA- HERENCIA
• Subtipos Simples.
Los subtipos heredan todos las propiedades del Supertipo. (ProvNro y CliNro son subtipos de EmpNro) EMPRESAS PROVEEDORES CLIENTES EmpNro* ProvNro* CliNro* EmpNom EmpNom EmpNom EmpRuc ProvSdo CliSdo EmpTel EmpDir

• En este ejemplo, EmpNom sólo va a estar almacenado en la tabla de empresas

TABLA EXTENDIDAHERENCIA
• Subtipos múltiples
SECCIONES DptoCod* DptoNom (SeccCod* SeccNom) tabla Depart tabla Seccion

EXPEDIENTE ExpNro* DptoCodIni SeccCodIni DptoCodAct SeccCodAct

tabla Exped ST de DptoCod ST de SeccCod ST de DptoCod ST de SeccCod

26

TABLA EXTENDIDAHERENCIA
DptoCod* SeccCod* SeccNom

ExpNro* DptoCodIni SeccCodIni DptoCodAct SeccCodAct

TABLA EXTENDIDA- HERENCIA
CONSIDERACIONES SI NO SE DEFINEN GRUPOS • Cantidad innecesaria de índices
DptoCodIni DptoCodAct DptoCodIni DptoCodAct SeccCodIni SeccCodAct SeccCodAct SeccCodIni

• Necesidad de poner las reglas NoCheck y NoRead en los objetos GeneXus

27

TABLA EXTENDIDA- HERENCIA
DptoCodIni SeccCodIni DptoCodAct SeccCodAct ST DptoCod ST SeccCod ST DptoCod ST SeccCod group Inicial group Inicial group Actual group Actual

Se define relacion solo entre el grupo. Se definen solo los indices necesarios para definir los grupos.

TABLA EXTENDIDAHERENCIA
DptoCod* SeccCod* SeccNom

ExpNro* DptoCodIni SeccCodIni DptoCodAct SeccCodAct

28

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 CliNom subtype of EmpNro subtype of EmpNom grupo Cliente grupo Cliente grupo CliCre grupo CliCred

NO SE PUEDE

CliCred subtype of CliNro CliCredNom subtype of CliNom

29

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 extendida de la Tabla de Llegada.
– En caso de ser necesario, la solución es definirse como redundantes (en la Tabla de Llegada) a dichos atributos.

30

FUNCION FIND
Sintáxis:
ATT = FIND(<At de retorno>, <Condicion de búsqueda>, <Val.def>) if <Condición de disparo>

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 BcoId MovNroChe MovImpChe FndNroChe MovNroAux BcoIdAux MovNroCheAux MovFndOtroChe = Find(MovNro, BcoId= BcoIdAux .and. MovNroChe = MovNroCheAux .and. MovNro<>MovNroAux, 0)

31

FIND RECURSIVO
Se llaman finds recursivos a aquellos que para resolverse recorren la misma tabla sobre la que esta definida la formula.
EJEMPLO:
Debido a que: al navegarla misma Tabla, se deben cargar en otros atributos los valores del registro de partida para poder efecturarla comparación en la búsqueda contra los valores del registro de llegada.

MovNro* MovFch BcoId MovNroChe MovImpChe FndNroChe MovNroAux = MovNro BcoIdAux = BcoId MovNroCheAux = MovNroChe MovFndOtroChe = Find(MovNro, BcoId= BcoIdAux .and. MovNroChe = MovNroCheAux .and. MovNro<>MovNroAux, 0)

PUNTOS A PRODUNDIZAR EN EL MANEJO DE WORK PANELS

32

DETERMINACION DE LA TABLA BASE DE UN WORK PANEL • PANEL • EVENTOS • REGLAS PANEL
– TODO ATRIBUTO QUE INTERVENGA EN EL PANEL

A PARTIR DE LOS ATRIBUTOS

EVENTOS
– TODO ATRIBUTO QUE ESTE FUERA DE UN GRUPO FOR EACH

REGLAS
– TODO ATRIBUTO QUE ESTE EN UNA REGLA » HIDDEN( ) » ORDER( )

Ejemplo:
Trn Productos ProdId* ProdDsc Trn Facturas FacNro* FacFech (FacLinNro* ProdId ProdDsc FacLinCnt)

Tabla: PRODUCTO

Tabla: FACTURA Tabla: FACTURA1

33

Work Panel de Selección de Productos

Rules parm(&V15 ) ; order(ProdId ) ; Conditions ProdId >= &C15 ; ProdDsc .LIKE. &C16 ;

Event Enter &V15 = ProdId Return EndEvent

Work Panel de Selección de Productos
Parameters : &V15 FOR EACH PRODUCTO Order : ProdId Index : IPRODUCT Navigation filters: Start from: ProdId >= &C15 Loop while: Not end of table Constraints: ProdDsc .LIKE. &C16 ---->> PRODUCTO ( ProdId ) END FOR TABLA BASE PRODUCTO

34

WORK PANELS SIN TABLA BASE
Ejemplo: Mostrar para cada cliente el total facturado, pero sólo de los clientes que tienen facturas.

Event Load for each CliId defined by FacFch &cli =CliNom &tot =0 for each &tot =&tot +FacTotal endfor load endfor EndEvent

EVENT Load

NAVEGACION WORK PANELS SIN TABLA BASE FOR EACH FACTURA
Order : CliId Index : CLIFCH Navigation filters: Start from: First record Loop while: Not end of table ---- >> FACTURA ( FacId ) +----- > CLIENTES ( CliId ) BREAK FACTURA Order : CliId Navigation filters: Loop while: CliId = CliId ---->> FACTURA ( FacId ) END FOR

END FOR END EVENT

35

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.

Consideraciones
•Todos los For Each que se encuentran en los eventos LOAD, 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 tabla base. Corte de Control Para determinar un corte de control en un work panel con tabla base el criterio del corte hay que establecerlo con la rule: order (att1,..,attn)

36

WORK PANELS / INTEGRIDAD BASE DATOS WORK PANELS - PROCS INS WKP PROCS UPD DEL IMPLEMENTACION MANUAL DE LOS CONTROLES INTEGRIDAD WORK PANELS - TRN INS WKP TRN UPD DEL IMPLEMENTACION AUTOMATICA DE LOS CONTROLES INTEGRIDAD (objeto-acción)

PUNTOS A PROFUNDIZAR EN REPORTES Y PROCEDIMIENTOS

37

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.

38

New en la misma tabla de For Each
Tabla de Medicos MedCod* MedNom EspCod EspDsc Sustituir a un medico por otro Program Source for test-----For Each where MedCod = &medori defined by ConNro new MedCod = &medsus endnew delete Endfor Tabla de Consulta TurFch* TurCod* MedCod* ConNro

New en la misma tabla de For Each
FOR EACH CONSUL Order : TurFch, TurCod , Medcod Index : I00301 Navigation filters: Start from: First record Loop while: Not end of table Constraints: Medcod = & Medori ---->> CONSU: ( TurFch, TurCod , Medcod ) ¦ +-----> T0001 ( Medcod )

La Tabla Base del New se infiere sólo por los atributos utilizados dentro del New

NEW MEDICO ------- > NO ES LA TABLA DESEADA Key : Medcod ---- >> +MEDICO ( Medcod ) Insert into MEDICO : Medcod, MedNom END NEW END FOR

39

New en la misma tabla de For Each
SOLUCION: Program Source for test-----For Each where MedCod = &medori defined by ConNro &ConNro = ConNro new MedCod = &medsus ConNro = &ConNro endnew delete Endfor

New en la misma tabla de For Each 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 CONSUL Order : TurFch, TurCod, Medcod Index : I00301 Navigation filters: Start from: First record Loop while: Not end of table Constraints: Medcod = &Medori ---->> CONSUL ( TurFch, TurCod, Medcod ) NEW CONSUL Key : TurFch, TurCod, Medcod ---->> +CONSUL ( TurFch, TurCod, Medcod ) Insert into CONSUL : TurFch, TurCod, Medcod , ConNro END NEW END FOR

40

New en la misma tabla de For Each
• Dos ordenes distintos para la misma tabla
Resultado de la navegación en todos los generadores excepto en XBASE: FOR EACH CONSUL Order : Medcod Index : I00303 Navigation filters: Start from: Medcod = & Medori Loop while: Medcod = & Medori ---- >> CONSUL ( TurFch, TurCod , Medcod ) NEW CONSUL Key : TurFch, TurCod, Medcod ---->> +CONSUL ( TurFch, TurCod, Medcod ) Insert into CONSUL : TurFch, TurCod, Medcod , ConNro END NEW END FOR

New en la misma tabla de For Each
• Dos ordenes distintos para la misma tabla
EN XBASE: Procedure Pcambia: cambia ---------------------------------------------------------------(x) The program will not be generated *********************** Error: table CONSUL with two different orders Output device: NONE FOR EACH CONSUL Order : Medcod Index : I00303 Navigation filters:

41

Restricciones en la Actualización
• No se puede realizar ninguna actualización en un For Each que recorre una tabla por índice temporal
– 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
defined by C call(‘rprog2,A,& nuevo)

For Each
defined by C B = & nuevo

Endfor

Endfor

IMPACTO Y REORGANIZACION DE LA BASE DE DATOS

42

Impacto de la base de datos

• Impact Database • Impact From • Impact Objects • Restore Model

Creación de la Base de datos
Table 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)

43

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 new Table 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.

44

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 )

45

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

46

Conceptos Teóricos
• Control de Concurrencia • Tipos de Diálogo – Conversacional – Pseudo Conversacional • Integridad Transaccional • Unidad de Trabajo Lógico (UTL)

Conceptos Teóricos
• Control de Concurrencia: – controles para evitar inconsistencias en los datos cuando se trabaja en ambiente multiusuario

47

Conceptos Teóricos
• 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 Conversacional 1. 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.

48

Conceptos Teóricos
• 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.

49

Enfoque GeneXus
• Control de Concurrencia
– Locks – Ambiente Client/Server – Ambiente Centralizado

• UTL • Integridad Transaccional

Control de Concurrencia
• ¿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.

50

Control de Concurrencia
• 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.

Concurrencia en Client/Server
Preferences del Modelo – Pseudo Conversational Dialog – Lock Mode – Isolation Level

51

Concurrencia en Client/Server
• Pseudo Conversational Dialog • Valores: – Use Conversational Dialog – Check Updated Tables only (*) – Check all accessed tables
Co n v e r s a c i o n a l

Tipos de Diálogo
Obtener Datos Lockear Validar datos Pedir Confirmación Confirma? Evento After(confirm) Grabar BD Eventos After Ins/Upd/Del Commit

Deslockear Evento After(TRN)

52

Tipos de Diálogo
Obtener Datos Validar datos Pedir Confirmación Confirma? Evento After(confirm) Validar cambios No hubo cambios? Grabar BD Eventos After Ins/Upd/Del Commit Evento After(TRN) Deslockear

Pseudo

Lockear

Concurrencia en Client/Server
• Preference Lock Mode • Valores:
Conversacional
– Do not specify lock level (*) – Use page level locking – Use row level locking

• Válida solo para Informix

53

Concurrencia en Client/Server
• Preference Isolation Level • Valores:
– Read Committed (*) – Read Uncommited

• Válida para todos los DBMSs excepto Oracle y SQL Server

Concurrencia en Client/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

54

Concurrencia en Client/Server
• ¿Qué sucede cuando un programa que actualiza la BD encuentra un registro lockeado? Transacciones Cuando 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.

Concurrencia en Client/Server
• ¿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.

55

Concurrencia en Client/Server
- Time-out

Desde GeneXus no es posible configurarlo – 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.

Concurrencia en Access
• 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

56

UTL en GeneXus
• 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

Integridad Transaccional
• Preference del Modelo
– Transactional Integrity

• Properties de los objetos:
– Commitment – Commit on Exit – Confirm Transaction

57

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

Integridad Transaccional en Client/Server
• 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

58

Integridad Transaccional en Client/Server
• 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

Integridad Transaccional
• Properties de los objetos:
– Commitment – Commit on Exit – Confirm Transaction

59

Integridad Transaccional Object Properties
• Commitment
– Valores:
• Enabled (*) • Disabled

• Consideraciones
– Válida solo en AS/400

Integridad Transaccional Object Properties
• Ejemplo property Commitment
Facturas
If insert and after(confirm)

Numerador

Tabla Numeradores

Commitment=Disabled Tabla Facturas

60

Integridad Transaccional Object Properties
• Commit on Exit
– Valores:
• Yes (*) • No

• Consideraciones
– No es válida si tiene Commitment = Disabled

Integridad Transaccional Object Properties
• Ejemplo property Commit on Exit
Commit on Exit = No

Facturas Refcall(Tcliente,
CliCod ‘INS’)

Cliente

Tabla Facturas

COMMIT

Tabla Clientes

61

Integridad Transaccional Object Properties
• Confirm Transaction
– Valores:
• Yes • No (*)

• Consideraciones
– Es válida si tiene
Commitment = Enabled y Commit on Exit = Yes

DEFINICION Y MANTENIMIENTO DE REDUNDANCIAS

62

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)

63

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.

Redundancy load Utility
• En el reporte del análisis de impacto se puede ver cual 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: FacTotal Procedure name: GXR24

64

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.

65

EFICIENCIA Y PERFORMANCE DE LAS APLICACIONES

Tips de optimización
• New con When duplicate vs. For each con New.
New Cliente=X Saldo =Y When duplicate For each Saldo=Y Endfor Endnew &Existe=‘N’ For each Where Cliente=X Saldo=Y &Existe=‘S’ Endfor If &Existe=‘N’ New Cliente=X Saldo= Y Endnew Endif

66

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 el operador $. En C/S lo resuelve el DBMS sobre el índice si existe y sino lo crea.

Tips de optimización
• Las funciones no se optimizan. For each order Fecha where Fecha=Today() ……. endfor

For each order Fecha where Fecha=&today ……. endfor

67

ARQUITECTURA DE MULTIPLES CAPAS

Varios generadores por modelo
• Generadores del Modelo • Generador por Objeto • Generador C/SQL

68

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

69

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

70

INTRODUCCION A CLIENT/SERVER

Qué es 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.

71

Tipos de Client/ Server

–Client / File Server. –Client / Database Server.

72

Client / File Server
Clientes
FILE / SERVER

Servidor de Datos
Archivos

Red
Server

Client / Database Server
Clientes
Data Base

Servidor de Base de Datos
* Datos * Lógica

Server

Red

73

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 GX de Client/Server ?
• Acceso a última tecnología sin necesidad de incurrir en altos costos de entrenamiento • Plataformas y bases de datos:
Oracle SQL Server DB2 Common Servers DB2/400 Informix Múltiples plataformas (Unix, Windows, Novell, etc.). Windows NT y Alpha Múltiples plataformas (Unix, Windows, etc.) AS/400 Múltiples plataformas (Unix, Windows, etc.)

• Uso de PC’s para bajar los requerimientos del procesador central

74

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 groups Disponible 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.

75

INTRODUCCION A PAGINAS WEBS

Web
• Páginas gráficas con hipertexto • Dos tipos fundamentales:
– Páginas estáticas
HTML standard. Generación con algunas herramientas.

– Páginas dinámicas
GeneXus ASP ···

76

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

77

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
WWW - World Wide Webs

Páginas Estáticas

Páginas Dinámicas

Web Page Editors

GeneXus

78

URL
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

Protocolo HTTP
Conexión/Solicitud
Respuesta/Cierre

79

HTML
<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>

80

Browser WWW (cliente)

APLICACION
m et er
I CG ll Ca

• So

un

CGI
ta

fo

rm

FORM
Respuesta del Programa CGI

l de I G s C u e ma p e s ra R rog P

ƒ

Servidor

INTERNET
Servidor : WEB SERVER Microsoft Internet Information Server Netscape Server Links Páginas HTML Cliente : BROWSER NetScape, MS Internet Explorer

81

Topología Topología
Web Browser Internet Intranet Servidor Web Windows NT UNIX AS 400

Web Browser

Servidor de Base de Datos DB2, Informix, Microsoft SQL Server, Oracle, Access

Web Servers
• Windows NT
– Microsoft Internet Information Server – Netscape

• Windows 95
– WebSite Professional – Fnord – Personal Web Server (FrontPage 97 y 98)

• UNIX
– Netscape – Oracle

• AS/400
– IBM

82

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

83

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 !

84

Web panel

Web panel con subfile

85

Algunas características de los Web panels
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

Código embebido:
• Html Ej.:
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.

86

Código embebido:
• 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.

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?

87

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

88

Seguridad a Nivel de Aplicación
Sesión, cliente

Login

Registro
Sesión, cliente

Operación

Sesión, cliente

Generación de sesión

Ingreso de usuario

Validación

Generadores - Servidores
Windows NT C/SQL VB RPG UNIX X X AS/400 X X

X

DBMS
VB Access, Oracle, MS SQL Server, Informix, DB2 (NT, RS/6000, OS/2) C/SQL Oracle, MS SQL Server, DB2/6000 RPG AS/400

89

Requerimientos (Visual Basic)
• Servidor 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 GeneXus
– Visual Basic 32 bits en adelante – Web Browser

• RED 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).

90

Configuración del Modelo GeneXus
MODEL – PROPERTIES – PREFERENCES – EXECUTION

Model Properties

91

Model Properties:

EXECUTE (VB)

Model Properties:

PREFERENCES
• GENERAL
– VISUAL BASIC VERSION: 4.0 (32 BITS)

• WEB INFORMATION
– PROTOCOL SPECIFICATION VB y C/SQL) (sólo para

• CLIENT SERVER INFORMATION
– Connect to Server – Data Base Name – Data Source Name

92

Getting Started with GeneXus 8.0
November, 2003

MONTEVIDEO – URUGUAY CHICAGO – USA MEXICO CITY – MEXICO SAO PAULO – BRAZIL

Av. 18 de Julio 1645 P.4 - (5982) 402 2082 400 N. Michigan Ave. Suite 1600 - (312) 836 9152 Mariano Escobedo 353 A Of. 701 - (5255) 5255 4733 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

Getting Started with GeneXus 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

Getting Started with GeneXus

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. Hardware Requirements 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. Video: 800 x 600 resolution or higher, with 256 colors Software Requirements 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 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

1

Page 4 of 47

Getting Started with GeneXus

Generator Requirements
This section contains the requirements to generate and execute applications with the different GeneXus generators: Generator .NET Requirements • 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 • 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 • 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)

Java

Visual Basic

In addition, to create the database and execute the generated applications, you must have some of the following DBMSs installed: Generator .NET Java DBMS • DB2 Universal Database • DB2 UDB for iSeries • Informix • Oracle • PostgreSQL • SQL Server • Access • DB2 Universal Database • DB2 UDB for iSeries • Informix • Oracle • PostgreSQL • SQL Server

Visual Basic

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

2

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

Getting Started with GeneXus

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 gxtrial@genexus.com. For any additional information, we recommend contacting your local distributor (www.genexus.com/distributors).

Page 6 of 47

Getting Started with GeneXus

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

Getting Started with GeneXus

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

Getting Started with GeneXus

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

Getting Started with GeneXus

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, Knowledge Base. click New

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

Getting Started with GeneXus

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. Invoice Header

Invoice Detail

Figure 6 Invoice structure

Page 11 of 47

Getting Started with GeneXus

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

Getting Started with GeneXus

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 o o o o example we will make the following formulas: ItemLnTot = ItemPrice * ItemQty InvoiceSubTot = SUM(ItemLnTot) InvoiceTax = InvoiceSubTot * .085 4 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

Getting Started with GeneXus 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

Getting Started with GeneXus

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

Getting Started with GeneXus

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

Getting Started with GeneXus

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

Getting Started with GeneXus

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 CustomerId CustomerNm CustomerAddress CustomerEmail TYPE ----------------Character(30) Character(50) DESCRIPTION --------------------------------------Customer Address 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

Getting Started with GeneXus

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

Getting Started with GeneXus

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: Access

Prototyping your Application in Visual Basic with Microsoft

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

3. Click OK.

Figure 21 Model creation dialog box

Page 20 of 47

Getting Started with GeneXus 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

Getting Started with GeneXus 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

Getting Started with GeneXus

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

Getting Started with GeneXus

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

Getting Started with GeneXus

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

Page 25 of 47

Getting Started with GeneXus

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

Getting Started with GeneXus 4. Next, enter some data into the Invoice. You will notice a couple of things here: o o The date automatically defaults once you tab over it. 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. Formulas are automatically calculated when the values are entered.

o

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 ItemId ItemDsc ItemPrice TYPE ------------------------DESCRIPTION ----------------------------------------------------------

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

Getting Started with GeneXus 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

Getting Started with GeneXus

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.

Figure 36 Impact Analysis Report

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

Getting Started with GeneXus

3. In the Impact Analysis Report dialog box, click Reorganize.

Figure 37 Impact Analysis Report

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

Getting Started with GeneXus

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

Getting Started with GeneXus

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

Getting Started with GeneXus 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

Getting Started with GeneXus 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

Getting Started with GeneXus 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.

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.

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

Page 35 of 47

Getting Started with GeneXus 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

Getting Started with GeneXus

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

Getting Started with GeneXus

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.

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.

5

Page 38 of 47

Getting Started with GeneXus 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 version. 12. Click Next. SQL Server

Figure 54 Create Model Wizard, Step 3

13. In Step 4, enter the Compiler and Virtual Directory paths and click Next. 14. In Step 5, click Finish.

Figure 55 Create Model Wizard, Step 4

6

The user needs CREATION rights to the database tables. For simplicity, we recommend assigning OWNER rights.

Page 39 of 47

Getting Started with GeneXus 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

Getting Started with GeneXus 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

Getting Started with GeneXus

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

Getting Started with GeneXus 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.

Figure 62 Create Model Wizard, Step 1

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.

Figure 63 Create Model Wizard, Step 2

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

Getting Started with GeneXus

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\WEBINF\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.

Figure 64 Create Model Wizard, Step 4

8

The user needs CREATION rights to the database tables. For simplicity we recommend assigning OWNER rights.

Page 44 of 47

Getting Started with GeneXus 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.

Figure 65 Create Model Wizard, Step 5

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

Getting Started with GeneXus

Step 4: Viewing the JAVA Application Running

Figure 66 Invoice

Page 46 of 47

Getting Started with GeneXus

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 sales@genexus.com

Page 47 of 47

Sign up to vote on this title
UsefulNot useful