Tuturial - Genexus (Vision General)

GeneXus Visin 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 MXICO MXICO Mariano Escobedo 353 A Of. 701 - (5255) 5255 4733 SO 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 TERI 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 SEO................................................................................................................... 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
Pgina 2 de 14
Introduccin
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 diseo 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 aplicacin 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 produccin. La idea bsica de GeneXus es aut om at izar t odo aquello que es aut om at izable: norm alizacin de los dat os y diseo, generacin y m ant enim ient o de la base de dat os y de los program as de aplicacin. De est a m anera se evit a que el analist a deba dedicarse a t areas rut inarias y t ediosas, perm it indole poner t oda su at encin 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 acin 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 erico - en est e capt ulo se hace una descripcin com parada de las m et odologas t radicionales de desarrollo de sist em as y el desarrollo increm ent al. Una im plem ent acin del desarrollo increm ent al: GeneXus. Caract erst icas nicas de GeneXus. Quienes son los usuarios de GeneXus
Pgina 3 de 14
El problema terico
Metodologas tradicionales de desarrollo y problemas asociados
La form a t radicional de desarrollar aplicaciones part e de una prem isa bsica: 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 . Basndose en esa prem isa, la prim era t area que se encara es el anlisis 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 disear la base de dat os. Es m uy sencillo disear 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 ( anlisis funcional) . Sera deseable que el est udio de la realidad t uviera com o product o una especificacin funcional que dependiera slo de dicha realidad. Lo que se hace en las m et odologas m s usadas, sin em bargo, es obt ener una especificacin 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 especificacin funcional, se pasa a la im plem ent acin de las funciones, exist iendo t radicionalm ent e para ello varias opciones ( lenguaj es de 3 . o 4 generacin, generadores, int erpret adores) . Sin em bargo, t odas las form as de im plem ent acin 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 aplicacin, se producen cam bios en el m odelo. Pero an si se considerara la sit uacin 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 paar la evolucin de la em presa Todo est o sera poco im port ant e, si la especificacin funcional y la base de dat os fueran independient es. Sin em bargo, dado que la especificacin 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 ayora 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 ericam 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 uacin es an peor: est e m ant enim ient o com ienza m ucho ant es de la im plem ent acin, lo que hace que los cost os de desarrollo crezcan en form a hiperlineal con respect o al t am ao del proyect o. Pgina 4 de 14
Dado que es m uy difcil, 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 degradacin 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
Metodologa incremental
Una m anera alt ernat iva de resolver el problem a pasa por la sust it ucin de la prem isa bsica 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 filosofa 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 pequeos problem as a m edida que se present an. Cul ser la repercusin 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 odologas ant eriorm ent e reseadas, esa repercusin sera m uy grande: el m odelo de dat os se m odificara const ant em ent e y los cost os de m ant enim ient o seran an 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 aplicacin: Aquello que es t angible para el usuario. Cm 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 podra brindar una am plia gam a de recursos para ayudar a resolverlo aut om t icam ent e y, com o consecuencia, se sim plificara m ucho la t area del analist a. Una reflexin 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 deberan 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, cm 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 erst 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.
Pgina 5 de 14
Si est e obj et ivo se logra, la base de dat os y los program as de aplicacin pasan a ser t ransform aciones det erm inst 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 aplicacin afect ados por los cam bios.
Una implementacin del desarrollo incremental: GENEXUS

GeneXus im plem ent a est a t eora. Cuando una aplicacin se desarrolla con GeneXus la prim era et apa consist e en hacer el Diseo 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 ipacin 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 Diseo, se realizan las m odificaciones correspondient es y se vuelve al Prot ot ipo. Llam arem os a est e ciclo de Diseo/ Prot ot ipo. Una vez que el Prot ot ipo est aprobado, se pasa a la et apa de I m plem ent acin, en donde GeneXus genera, t am bin aut om t icam ent e, la base de dat os y program as para el am bient e de produccin. En resum en, una aplicacin com ienza con un Diseo, luego se Prot ot ipa, luego se I m plem ent a y en cualquiera de los pasos ant eriores se puede regresar al Diseo para realizar m odificaciones.
Pgina 6 de 14
A cont inuacin se det alla cada una de est as t areas:
Diseo
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 raccin, 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 evolucin, 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 ne 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 diseo 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 acin del diseo, a part ir de la cual GeneXus crea el m odelo de dat os fsico ( t ablas, at ribut os, ndices, redundancias, reglas de int egridad referencial, et c.) , y los program as de aplicacin. As, la t area fundam ent al en el anlisis y diseo de la aplicacin se cent ra en la descripcin 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
Pgina 7 de 14
Una t ransaccin es un proceso int eract ivo que perm it e a los usuarios crear, m odificar o elim inar inform acin 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 uracin: 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 rizacin. 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 erst 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 ualizacin. 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 ilizacin de dilogos sofist icados, que le perm it an sent arse a pensar frent e al m ism o. Los work panels perm it en disear est e t ipo de dilogos 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 eleccin 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 .
Menes
Pgina 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 aplicacin es un reconocido buen crit erio de diseo. En part icular, la int erfaz de usuario de una aplicacin result a crt ica para const ruir sist em as am igables. Cuant o m s est ndar sean los dilogos, m s fcil de usar ser la aplicacin. Los St yles const it uyen un t ipo de obj et o GeneXus orient ado a la definicin de int erfaces de usuario y est ndares de program acin. 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 sern 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 fsico es diseado con base en la Teora 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 alizacin 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, segn corresponda) , aut om t icam ent e por GeneXus. El reposit orio de GeneXus m ant iene las especificaciones de diseo 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.
Mltiples Plataformas / Arquitectura de Mltiples Capas

Com o consecuencia de lo ant erior es posible, por ej em plo, que un usuario de una aplicacin 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 vlidas an 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.
Pgina 9 de 14
Hoy es com n que una m ism a aplicacin 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 aplicacin 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 diseo est n im plcit as las dificult ades de t oda com unicacin 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 acin 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 slo 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 congelacin de las especificaciones, es que se acaba im plem ent ando una solucin relat ivam ent e insat isfact oria.
El im pact o de est os problem as dism inuira m ucho si se consiguiera probar cada especificacin, inm ediat am ent e, y saber cual es la repercusin de cada cam bio sobre el rest o del sist em a. Una prim era aproxim acin 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 enes. 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 uacin bast ant e diferent e sera la de poner a disposicin del usuario para su ej ecucin, inm ediat am ent e, una aplicacin 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 aplicacin pront a, funcionalm ent e equivalent e a la aplicacin de produccin. La diferencia ent re prot ot ipacin y produccin consist e en que la prim era se hace en un am bient e de m icrocom put ador, m ient ras que la produccin 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 aplicacin sea t ot alm ent e probada ant es de pasar a produccin. 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 bin frm ulas, reglas del negocio, est ruct uras de dat os, et c. La filosofa 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 acin 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 aplicacin con una m et odologa de Pgina 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.
Implementacin
GeneXus genera aut om t icam ent e el cdigo 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 ct 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 cucin: JAVA, Microsoft .NET.
Mantenimiento
Est a es quizs la caract erst 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 inuacin se explicar el proceso de m ant enim ient o, ant e cam bios en la descripcin de algn obj et o GeneXus ( visin 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 conversin de los dat os y, si cabe, qu problem as pot enciales t iene esa conversin ( 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.
Pgina 11 de 14
Ge ne r a cin de pr ogr a m a s de conve r sin: Una vez que los problem as han sido solucionados o bien se ha acept ado la conversin " default " , que GeneXus realiza en form a est ndar, se generan aut om t icam ent e los program as para hacer la conversin ( est ruct ura y cont enido) de la viej a base de dat os a la nueva. Ej e cucin de los pr ogr a m a s de conve r sin: A cont inuacin, se pasa al am bient e de ej ecucin que corresponda ( prot ot ipo, produccin I nt ernet , produccin Client e / Servidor, et c.) y se ej ecut an los program as de conversin.
Impacto de los cambios sobre los programas:

An lisis de im pa ct o: A cont inuacin, GeneXus analiza el im pact o de los cam bios sobre los program as, y produce un diagnst ico inform ando qu program as deben generarse o re- generarse y proporcionando t am bin, para el nuevo program a, o bien el diagram a de navegacin o bien un pseudo- cdigo, a eleccin del analist a. Ge ne r a cin de nue vos pr ogr a m a s: A cont inuacin el sist em a genera o regenera aut om t icam ent e t odos los program as.
Documentacin
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 acin online, perm anent em ent e act ualizada.
Consolidacin de varias aplicaciones y reutilizacin de conocimiento.

Varias aplicaciones pueden ser diseadas 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 diseo 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 pequea base de conocim ient o y, slo cuando su aplicacin 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 aplicacin, o la m odificacin 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 ( Vase Cat logo de Bases de Conocim ient o ht t p: / / www.genexus.com / cat alogo2001) .
Pgina 12 de 14
Caractersticas nicas de GENEXUS

GeneXus t iene algunas caract erst 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 descripcin nat ural del usuario de los obj et os. La descripcin 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 descripcin de uno, ello no im plicar la necesidad de m odificar m anualm ent e la descripcin de cualquier ot ro. Est a caract erst 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. Diseo, creacin y m ant enim ient o de la base de dat os son t ot alm ent e aut om t icos. La aplicacin ( 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
Lenguaj es poderosos y de m uy alt o nivel para la definicin de PROCESOS, WORK PANELS y WEB OBJECTS, as com o una definicin 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 generacin. Est a caract erst 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 ilizacin 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 PCs, dej ando el com put ador de produccin t ot alm ent e libre para el procesam ient o de las aplicaciones. Fcil dist ribucin del conocim ient o corporat ivo para facilit ar el desarrollo de nuevas aplicaciones. Sim ple y poderosa solucin para Dat a Warehousing. Verificacin aut om t ica de consist encia, y consolidacin, 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
Quines son los usuarios de GENEXUS?

GeneXus es dist ribuido en t oda Am rica, Espaa, I t alia, Sudfrica, China y Taiwan y t iene en la act ualidad, m s de 4000 client es que han cont rat ado unas 25000 licencias. Pgina 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 isin crt 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
Pgina 14 de 14
GENEXUS
Diseo de Aplicaciones
Copyright ARTech Consultores 1988-1999. All rights reserved.
TABLA DE CONTENIDO
INTRODUCCIN............................................................................................................ 1 DESARROLLO DE UNA APLICACIN ..................................................................... 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 APLICACIN ......................................................................... 5 MANTENER EL DISEO SIMPLE......................................................................................... 5 ORIENTARSE A LOS DATOS .............................................................................................. 5 DISEO DE TRANSACCIONES................................................................................... 7 ESTRUCTURA DE UNA TRANSACCIN............................................................................... 9 Atributos ................................................................................................................... 10 Dominios .................................................................................................................. 11 Atributos Clave......................................................................................................... 11 Relacin entre la estructura y el modelo de datos ................................................... 12 Tipos de controles .................................................................................................... 14 Definicin de la transaccin de pedidos .................................................................. 16 Niveles de una transaccin....................................................................................... 18 Tipos de relacin entre los objetos........................................................................... 22 FORM DE UNA TRANSACCIN ........................................................................................ 23 Dilogo full-screen................................................................................................... 24 Dilogo campo a campo .......................................................................................... 25 Barra o Botones de Men......................................................................................... 25 Atributos de entrada y atributos de salida ............................................................... 26 Facilidad de Prompt................................................................................................. 26 Dilogo 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, Mtodos y Eventos.............................................................. 35 FRMULAS .................................................................................................................... 36 Frmulas Horizontales............................................................................................. 37 Frmulas Verticales ................................................................................................. 38 Frmulas y Redundancia ......................................................................................... 39
Frmulas de Frmulas ............................................................................................. 40 REGLAS ......................................................................................................................... 41 Default...................................................................................................................... 41 Error......................................................................................................................... 41 Asignacin................................................................................................................ 41 Add y Subtract .......................................................................................................... 42 Serial ........................................................................................................................ 43 Orden de evaluacin ................................................................................................ 44 Call y funcin After .................................................................................................. 45 PROPIEDADES ................................................................................................................ 46 DISEO 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 DISEO DE PROCEDIMIENTOS .............................................................................. 80 Modificacin de datos .............................................................................................. 80 Eliminacin de datos................................................................................................ 81 Creacin de datos..................................................................................................... 81 CONTROLES DE INTEGRIDAD Y REDUNDANCIA............................................................... 82 DISEO 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 GRFICAS...................................................................................................................... 99 PROPERTIES................................................................................................................. 103 Generar como una ventana Popup......................................................................... 103 DILOGOS OBJETO-ACCIN ........................................................................................ 104 DISEO DE MENES ................................................................................................ 106 CALL BROWSER .......................................................................................................... 108 ANEXO A. MODELOS DE DATOS RELACIONALES.......................................... 110 Tablas..................................................................................................................... 110 Clave primaria y Claves candidatas ...................................................................... 111 Indices .................................................................................................................... 112 Integridad Referencial............................................................................................ 112 Normalizacin ........................................................................................................ 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 dueos.
DISEO DE APLICACIONES CON GENEXUS

COPYRIGHT ARTech Consultores SRL. 1988 - 1999. Queda prohibida cualquier forma de reproduccin, transmisin o archivo en sistemas recuperables, sea para uso privado o pblico por medios mecnicos, electrnicos, fotocopiadoras, grabaciones o cualquier otro, total o parcial, del presente ejemplar, con o sin finalidad de lucro, sin autorizacin expresa de ARTech.
GENEXUS- DISEO DE APLICACIONES
INTRODUCCIN
El presente documento es una introduccin al desarrollo de aplicaciones utilizando GENEXUS. Est dirigido a profesionales de informtica 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 aplicacin implica tareas de anlisis, diseo e implementacin. La va de GENEXUS para alcanzar el objetivo anterior es liberar a las personas de las tareas automatizables (por ejemplo, la implementacin), permitiendoles as concentrarse en las tareas realmente difciles y no automatizables (anlisis y diseo). Desde un punto de vista terico, GENEXUS es ms una metodologa de desarrollo de aplicaciones que una herramienta de software. Como metodologa, tiene algunos puntos de contacto con las metodologas tradicionales, pero tambin aporta enfoques bastante diferentes en otros. En comn con las metodologas tradicionales, se mantiene la importancia del anlisis y diseo de la aplicacin sobre la implementacin. Quizs con GENEXUS este enfoque se resalta ms an, ya que el usuario de GENEXUS estar la mayor parte del tiempo realizando tareas de anlisis y GENEXUS, en s, tareas de implementacin (por ejemplo, normalizacin de la base de datos, generacin de programas, etc.). Por otro lado, algunos de los enfoques metodolgicos son bastante diferentes que los habituales, como, por ejemplo, el comenzar el anlisis de la aplicacin por la interfase del mismo con el usuario, la casi nula referencia a la implementacin fsica del sistema, etc. Para presentar estos nuevos conceptos, y a los efectos de no realizar una presentacin demasiado abstracta del tema, se ha elegido una aplicacin que se ir desarrollando a travs de los distintos captulos. El primer captulo presenta la aplicacin y los aspectos iniciales de un desarrollo con GENEXUS. El segundo captulo trata el diseo de Transacciones, el tercero de Reportes, el cuarto de Procedimientos, el quinto de Paneles de Trabajo y por ltimo se trata el diseo de Menes. Debido a que en todos los captulos 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 captulo. Por razones didcticas, en este documento no se tratan los siguientes temas: Ciclo de vida de una aplicacin: Una aplicacin tiene un ciclo de vida, que comienza cuando se planifica la misma y termina cuando la aplicacin sale de produccin. GENEXUS acompaa todo este ciclo. Este tema es tratado en el documento Visin General, que recomendamos leer previamente.
GENEXUS DISEO DE APLICACIONES Uso de GENEXUS : Toda la informacin respecto a la operacin de GENEXUS en s (manejo de teclas, edicin de texto, etc.) se trata en el Tutorial GENEXUS, que sugerimos repasar posteriormente.
DESARROLLO DE UNA APLICACIN

La mejor forma de aprender a utilizar GENEXUS es realizando aplicaciones con l. La aplicacin que se ha elegido es una simplificacin de una aplicacin 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 informacin posible. La funcin de un analista de compras es decidir los pedidos que se deben efectuar a los proveedores de los distintos artculos. 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 aplicacin.
Definir el objetivo
No se debe olvidar que los computadores son meras herramientas. Los usuarios de los sistemas tienen objetivos especficos. Ellos esperan que la aplicacin los ayude a alcanzarlos mas rpido, mas fcil, o a un menor costo. Es parte del trabajo de anlisis, el conocer esos propsitos y saber por medio de que actividades los usuarios quieren alcanzarlos. Este objetivo debe poder ser expresado en pocas palabras (uno o dos prrafos) y ser conocido por todas las personas involucradas con el sistema. En el ejemplo, alguno de los propsitos posibles son: "El sistema de compras debe disminuir la burocracia existente para la formulacin de un pedido." "El sistema de compras debe asistir a usuarios no entrenados en la formulacin de pedidos de tal manera que su desempeo se asemeje al de un experto." "El sistema de compras debe permitir la disminucin 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 diseo de la aplicacin. Basta con observar como los distintos objetivos anteriores conducen a diseos diferentes.
GENEXUS DISEO DE APLICACIONES
Para nuestro ejemplo elegiremos el primer objetivo, dado que en la situacin real el analista de compras no tenia toda la informacin que necesitaba. Por lo tanto, deba consultar una serie de planillas manuales y llamar por telfono a los empleados del deposito para que realizaran un conteo manual del stock. No se debe confundir el objetivo de la aplicacin (el QUE) con la funcionabilidad de la misma (COMO se alcanzar el objetivo).
Definir el equipo de trabajo

A continuacin se debe definir cul ser el equipo de personas encargado de la implementacin del sistema. Dicho equipo debe tener como mnimo dos personas: El analista de sistemas. Y un usuario. Los analistas de sistemas que trabajen en el desarrollo de la aplicacin deben cumplir dos condiciones: Haber sido entrenados en el uso de GENEXUS Tener una orientacin a las aplicaciones. Se recomienda que dichos analistas pasen algn tiempo trabajando con los usuarios en el comienzo del proyecto a los efectos de familiarizarse con los conceptos, vocabulario, problemas existentes, etc. Como la aplicacin se desarrolla de una manera incremental, es MUY IMPORTANTE la participacin 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 dems usuarios de una manera fluida. Dado que con GENEXUS los miembros del equipo estarn la mayor parte del tiempo trabajando en tareas de diseo y no de codificacin, se debe tomar como criterio general el trabajar en equipos PEQUEOS, por ejemplo, no ms de cinco personas.
Obtener una imagen global

Se debe tener entrevistas con el nivel gerencial mas alto que se pueda, de modo de obtener informacin sobre la posicin relativa (e importancia) de la aplicacin dentro de toda la organizacin.
Definir el alcance de la aplicacin

Luego de un estudio primario se debe decidir cul ser el alcance de la aplicacin 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 aplicacin y por lo tanto no ser tratado.
Mantener el diseo simple

Se debe planificar pensando en un proceso de diseo y desarrollo incremental. Comenzando por pequeos pasos y verificando la evolucin del modelo frecuentemente con el usuario.
Orientarse a los datos

En esencia, una aplicacin es un conjunto de mecanismos para realizar ciertos procesos sobre ciertos datos. Por lo tanto, en el anlisis de la aplicacin, se puede poner mayor nfasis en los procesos o en los datos. En las metodologas tradicionales -como el Anlisis Estructurado- el anlisis se basa en los procesos. En general, este anlisis es Top-Down; se comienza con la definicin ms abstracta de la funcin del sistema, y luego se va descomponiendo esta en funciones cada vez ms simples, hasta llegar a un nivel de abstraccin 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 diseo basado en las funciones ser ms difcil de mantener. La idea que una aplicacin se puede definir por una nica funcin es muy controvertida en aplicaciones medias o grandes. Frecuentemente se descuida el anlisis de las estructuras de datos. No facilita la integracin de aplicaciones. Si, por el contrario, el diseo se basa en los datos, se puede obtener las siguientes ventajas:
Ms estabilidad. Los datos tienden a ser ms estables que los procesos y en consecuencia la aplicacin ser ms fcil de mantener. Facilidad de integracin con otras aplicaciones. Difcilmente una aplicacin es totalmente independiente de las otras dentro de una organizacin. La mejor forma de integrarlas es tener en cuenta los datos que comparten. Incluso es posible que en un futuro el propio concepto de aplicacin evolucione hacia el concepto de objeto, en donde los usuarios pedirn 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 implementarn en el computador. El diseo comienza -como veremos ms en detalle en el siguiente captulo- 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 anlisis se concentra en hechos objetivos, y este puede ser evaluado directamente por los usuarios, utilizando la facilidad de prototipacin de GENEXUS.
DISEO DE TRANSACCIONES
El anlisis mismo de la aplicacin comienza con la definicin 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 descripcin del sistema. Cuando un usuario describe un sistema se pueden determinar muchas transacciones si se presta atencin a los sustantivos que utiliza. En el ejemplo: Analistas de compras Pedidos Proveedores Artculos Ordenes de Compra
Formularios existentes. Por cada formulario que se utilice en el sistema es casi seguro que existir una transaccin para la entrada de los mismos.
Para cada transaccin se puede definir: Estructura De que atributos (campos en la metodologa tradicional) esta compuesta y que relacin tienen entre si. Pantalla o Form Cual es el form que tiene. Esto se realiza con un editor especializado. Frmulas Que atributos se calculan a partir de otros atributos. Por ejemplo: Valor = Cantidad * Precio.
Reglas
Conjunto de reglas que debe cumplir la transaccin. 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 programacin dirigida por eventos. Este tipo de programacin permite el almacenamiento de cdigo 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 transaccin. 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 bsicamente objetos GENEXUS (su forma de definicin es similar a los otros objetos), pero no son tenidos en cuenta en la normalizacin o generacin de programas; slo se utilizan para definir estndares. 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 transaccin. Documentacin Texto tcnico que se incluye para ser utilizado en la documentacin del sistema.
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 transaccin

La estructura define que atributos (campos) integran la transaccin y como estn relacionados. En el ejemplo, la transaccin de Proveedores posee los siguientes atributos: PrvCod PrvNom PrvDir Cdigo de proveedor Nombre del proveedor Direccin del proveedor
que componen la informacin que se quiere tener de un proveedor.
Atributos
Para cada atributo se debe definir:
Name: Es el nombre del atributo. Se utiliza para identificar al atributo. Title: Es un string que acompaa al atributo en los listados de documentacin que tenemos disponibles y permite tener una descripcin ampliada para ste. Tambin 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 (Numrico, alfanumrico, fecha, Long Varchar, Varchar o DateTime).
10
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: Nmero de posiciones decimales. Picture - Formato del campo que permite una visualizacin en la entrada y salida, por ejemplo: en campos caracter @! significa que todos los caracteres se aceptan y despliegan en maysculas. Value Range: Rango de valores vlidos para el atributo. Por ejemplo: La siguiente definicin: 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 comn cuando estamos definiendo la base de datos, tener atributos que comparten definiciones similares, y que no se puede establecer ninguna relacin directa entre ellos. Por ejemplo, es comn almacenar todos los nombres en atributos de tipo caracter y largo 25. El uso de dominios permite usar definiciones de atributos genricos. Por ejemplo en la transaccin 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 definicin de este dominio, los cambios sern propagados automticamente a los atributos que pertenecen a l.
Atributos Clave
Tambin es necesario definir cual es el atributo o conjunto de atributos que identifican a la transaccin (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 Cdigo de Proveedor.
11
Es importante notar que el concepto de identificador se refiere a la unicidad (si puede haber o no dos proveedores con el mismo nmero) y no a como se debe acceder al archivo donde se almacenan los proveedores. Reglas para los identificadores: Toda transaccin 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 cdigo 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 automticamente por el sistema.
Relacin entre la estructura y el modelo de datos

GENEXUS utiliza la estructura de la transaccin 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 informacin va construyendo el modelo de datos. En este caso a la transaccin 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 automticamente, pero luego pueden ser modificados por el analista). Diremos que la transaccin de Proveedores tiene asociada la tabla PROVEEDO en el entendido que cuando se ingresen (o modifiquen, etc.) datos en la transaccin estos sern almacenados en la tabla PROVEEDO. Otras transacciones simples de nuestro ejemplo son:
12
Analista de compra: AnlNro* AnlNom Numero de analista Nombre del analista
Artculos: ArtCod* Cdigo de articulo ArtDsc Descripcin del articulo ArtCnt Cantidad en Stock ArtFchUltCmp Fecha ultima compra ArtPrcUltCmp Precio ultima compra ArtUnidad Unidad del articulo ArtSize Tamao ArtDisponible Disponibilidad Que tendrn asociadas las tablas ANALISTA y ARTICULO respectivamente. Tabla: ANALISTA AnlNro* AnlNom Tabla: ARTICULO ArtCod* ArtDsc ArtCnt ArtFchUltCmp ArtPrcUltCmp ArtUnidad ArtSize ArtDisponible Veamos ahora la definicin del form de artculos:
13
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 pequeo y que pueden ser desplegados de antemano para que el usuario seleccione uno. De esta forma controlamos que ingresen solo valores vlidos. Estos tipos de controles son los que veremos a continuacin.
Check Box
Es usado para aquellos atributos que tienen solo dos posibles valores True o False (como en nuestro ejemplo para sealar si existe disponibilidad del artculo). Existe
14
una nica descripcin (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 tamao 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 botn 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 seleccin de atributos que tienen valores que no pueden ser determinados a priori, (que son ledos 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 operacin es similar a la del combo box, solo que los valores desplegados son descripciones ledas de una determinada tabla.
List Box
Este tipo de control tiene asociada una coleccin de tems. Cada tem tiene asociado un par <valor,descripcin>. Existe la posibilidad de cargar la coleccin de tems tanto en diseo 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 seleccin 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 coleccin de tems. Cada tem tiene asociado un par <valor,descripcin>.
15
La coleccin de tems se carga en runtime desde una tabla de la base de datos. Tambin es posible agregar tems en forma manual en runtime. En tiempo de diseo se asocian dos atributos al Dynamic List Box, uno al valor que tendr el tem y el otro a la descripcin que ste tomar. Ambos atributos deben pertenecer a la misma tabla. En tiempo de especificacin se determina la tabla desde la cual se traern los valores y las descripciones.
Definicin de la transaccin de pedidos

Consideremos ahora la transaccin de Pedidos. El formulario preexistente de pedidos es:
Pedido : 1456 Fecha: 02/01/92 Analista : 21 Pedro Gomez Proveedor : 125 ABC Inc. Cdigo Descripcin Cantidad Precio 321 567 Aspirinas Flogene 100 120 120 50 Total Valor 12000 6000 18000
Los atributos que integran la transaccin son (dejando momentneamente de lado la informacin de los Artculos 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 transaccin tiene algunas caractersticas interesantes a destacar: tanto PrvCod y PrvNom, como AnlNro y AnlNom son atributos que estn presentes en otras transacciones. De esta manera estamos indicando que existe una relacin entre los
16
Proveedores y los Pedidos y tambin 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 relacin 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 transaccin 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 caracterstica a destacar es que, cuando se define la estructura de una transaccin 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 relacin de integridad entre la tabla PROVEEDO,
17
que tiene a PrvCod como clave primaria, y la PEDIDOS que lo tiene como clave extranjera. La relacin, 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 automticamente por GENEXUS y, por ejemplo, en la transaccin 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 transaccin

Volviendo al ejemplo, para terminar de disear la transaccin de Pedidos se debe definir la informacin sobre los Artculos 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 significara que para cada pedido existe solo UN articulo, lo que no se corresponde con el formulario. La estructura correcta es:
18
PedNro* PedFch PrvCod PrvNom AnlNro AnlNom ( ArtCod* ArtDsc PedCnt PedPre PedImp ) PedTot
Nivel del cabezal Nivel de las lneas
donde el identificador es PedNro y para cada numero de pedido existe solo una fecha, un cdigo y nombre de proveedor, un nmero y nombre del analista y un solo total, pero muchos Artculos, cantidades pedidas, precios y importes de la lnea . Los parntesis indican que para cada Pedido existen muchos Artculos. Cada grupo de atributos que se encuentra encerrado por parntesis diremos que pertenece a un NIVEL de la transaccin. Cabe notar que el primer nivel queda implcito y no necesita un juego de parntesis. As, la transaccin 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 transaccin 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
Con esta estructura se define que un Pedido tiene muchos Artculos y muchas Entregas, pero no hay relacin 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 transaccin tiene un identificador, cada nivel de la misma tambin 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 lneas 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. Cdigo Descripcin Cantidad Precio 321 321 Aspirinas Aspirinas 100 120 120 50 Total Valor 12000 6000 18000
porque existen dos lneas del Pedido con el mismo ArtCod.
20
Aqu tambin se deben tener en cuenta los criterios sobre identificadores que se mencionaron previamente. En particular, es comn 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 automticamente la transaccin. Cada nivel de la transaccin 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 concatenacin de los identificadores de los niveles superiores (PedNro) mas los identificadores del nivel (PedLinNro).
21
La eleccin de los identificadores es una tarea importante y que puede simplificar o complicar la implementacin de un sistema. Supongamos por ejemplo, que en el Pedido no se admite que haya dos lneas con el mismo ArtCod. La forma natural de implementar esto es definiendo a ArtCod como identificador del segundo nivel. Ahora bien, si por alguna razn se defini a PedLinNro como el identificador, ya no tendremos ese control automtico 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 relacin entre los objetos

Muchas veces cuando los usuarios estn describiendo la aplicacin, es comn preguntarles que tipo de relacin existe entre los distintos objetos. Por ejemplo cual es la relacin entre los proveedores y los pedidos: Un proveedor tiene muchos pedidos (relacin 1-N). Un pedido tiene un solo proveedor (relacin N-1). Como ya vimos, la relacin 1-N se puede definir con la estructura: PrvCod* PrvNom .... (PedNro* .... ) Y la relacin N-1 como: PedNro* .... PrvCod PrvNom .... Vemos que generalmente para cada relacin N-1 habr una relacin simtrica 1-N. En estos casos se debe definir la estructura N-1 y no la 1-N. Otro caso muy comn son las relaciones M-N, por ejemplo entre los pedidos y los Artculos: Un pedido tiene muchos Artculos.
22
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 Artculos y no para cada articulo que pedidos tiene.
Form de una transaccin

Cada transaccin 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
agregar o quitar forms a travs de las opciones Edit/Add New Form o Edit/Select Forms. Tambien se puede seleccionar el form con el cual se desea trabajar seleccionndolo del combo box que aparece en la toolbar. Tambin 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 grfico) es:
Atributos que sern 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 operacin 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 dilogo para las transacciones, full-screen o campo a campo.
Dilogo full-screen
Este tipo de dilogo se genera para las plataformas donde se utilizan terminales no programables, por ejemplo para el IBM AS/400. El funcionamiento bsico del dilogo 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 confirmacin, si no se confirma se vuelve a 1.
24
5- Si se confirma la operacin esta es realizada y se vuelve a 1. Este proceso tiene leves alteraciones segn 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 funcin. Por ejemplo con F6 se pasa a modo Insertar, con F11 a modo Modificar, etc.
Dilogo 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 dilogo, cada vez que un campo es digitado inmediatamente se controla su validez. Tambin trabaja con modos, pero con la diferencia que el modo es inferido automticamente por el sistema. Por ejemplo cuando el usuario digita el PrvCod, si este existe se pasa automticamente a modo Modificar y si no existe se pasa a modo Insertar.
Barra o Botones de Men

En ambos tipos de dilogo 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
Atributos de entrada y atributos de salida

Consideremos nuevamente la transaccin de Pedidos pero sin sus Artculos. 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 automticamente 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 frmulas 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 estn 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 transaccin de Pedidos presionando una tecla especial se puede visualizar cuales son todos los proveedores, con la siguiente pantalla:
26
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.
Dilogo para transacciones con varios niveles

Para el caso de transacciones con varios niveles se tiene un proceso de dilogo por nivel. Es decir se realiza la validacin y la confirmacin de los datos para cada uno de los niveles. Por ejemplo para la transaccin de Pedidos (considerando ahora los Artculos del mismo) la pantalla por defecto es:
27
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 confirmacin y luego se realiza el mismo proceso para cada una de las lneas del pedido. Cuando se genera el form por defecto se disea un subfile para el ltimo nivel de la transaccin, en el ejemplo las lneas del pedido. Trabajando con el form editor se puede transformar esta pantalla en la siguiente, que simula mejor el formulario de pedidos:
28
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 automticamente 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 ttulo es la descripcin de la transaccin. Dentro de ella figurarn los distintos tipos de controles de edicin 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
Atributo. Se utiliza para representar atributos o variables. Texto. Todo fragmento de texto fijo en la pantalla debe colocarse utilizando uno o ms controles de este tipo. Lnea. Con este control se dibujan lneas horizontales o verticales. Recuadro. Permite definir recuadros de distintos tamaos y formas. SubFile. Permite definir SubFiles. La definicin de los subfiles se vera mas adelante en el capitulo de Work Panels. Botn. Permite definir Botones (tambin llamados Command Buttons). Bitmap. Permite definir bitmaps estticos en la pantalla. Cada control tiene una serie de propiedades (ancho de lnea, 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 diseadas 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
Uso de las Herramientas

Sobre los objetos seleccionados con el puntero vamos a poder realizar varias operaciones: Cambiar el tamao y forma de un control. Edicin 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 estn "ms arriba" que otros. Cuando dos objetos se superpongan, el de ms arriba ser visible totalmente, mientras que el otro slo 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 tamao 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 tamao. Mostrar Grid
31
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 opcin 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
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 lnea/s (Width), si se pinta dentro de l o no (Fill) y si el tamao 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 botn de Setup permite definir caractersticas propias a cada tipo de control. Dentro Fore Color. Este botn es para seleccionar el color con el que se desplegar el valor del atributo y la/s lnea/s del frame, si tuviera. Back Color. Con este botn se puede seleccionar el color con el que se pinta el rea asignada al atributo en la pantalla. Slo tiene efecto si est presente la propiedad Fill.
33
Texto
Text. Indica el texto que se quiere insertar en la pantalla. Puede consistir de una o ms lneas. Alignment. El texto puede estar justificado a la izquierda (Left), derecha (Right) o centrado (Center). Resto de las propiedades. Ver control de Atributo.
34
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 explicacin en el control de Atributo.
Lnea
Utiliza el mismo dilogo de edicin de propiedades con la salvedad de que la opcin Fill aparece deshabilitada.
Editor de Propiedades, Mtodos y Eventos

A los controles (que tienen nombre asociado) que usamos en los forms se le pueden asociar propiedades, mtodos o eventos, por ejemplo: cambiarle el font a un texto, hacer un texto visible o invisible, deshabilitar un botn, 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 opcin de men Insert/Property (o Insert/Event) cuando se esta editando los eventos, rules o subrutinas de la transaccin. El dialogo que aparece es el siguiente:
35
Frmulas
Se dice que un atributo es una frmula si su valor se puede calcular a partir del valor de otros atributos. En el ejemplo el atributo PedImp de la transaccin de Pedidos se puede calcular a partir de la PedCnt y el PedPre: PedImp = PedCnt * PedPre En cada transaccin se puede definir que atributos son frmulas, pero esta definicin es global, es decir toda vez que se necesite el atributo se calcula la frmula, tanto en transacciones como en los otros objetos GENEXUS (reportes, Paneles de Trabajo, etc.). Existen distintos tipos de frmulas: Horizontales Verticales De agregacin/seleccin
36
Frmulas Horizontales
Una frmula horizontal se define como una o varias expresiones aritmticas 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 frmulas con condiciones es saludable definir siempre el OTHERWISE). La expresin puede utilizar los operadores aritmticos (+. -, *, /, ^) y funciones (por ejemplo 'today()' que devuelve la fecha del da), 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 parmetro 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 tambin es una frmula 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 frmula (en este caso es muy fcil 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 'frmula invalida'. Ahora bien, cuales son los atributos que pueden estar involucrados?. La respuesta es: en una frmula horizontal todos los atributos de los cuales depende la frmula deben estar en la misma tabla extendida que la frmula (ver el concepto de tabla extendida en el anexo sobre Bases de Datos Relacionales).
37
Cuando se define una frmula horizontal GENEXUS 'sabe' cual es la tabla extendida y controla que todos los atributos utilizados se encuentren en ella.
Frmulas Verticales
Consideremos ahora el Total del pedido (PedTot), este se debe calcular sumando los Importes (PedImp) de cada una de las lneas del Pedido. Esta frmula se expresa como: PedTot = SUM( PedImp ) Y es un caso de frmula vertical, que se define como el tipo de frmula en que los atributos involucrados no se encuentran dentro de la misma tabla extendida que la frmula. 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 tambin el Database Browser de GENEXUS para determinar que tablas estn subordinadas y superordinadas a la de pedidos (eligiendo la opcin Superordinated o Subordinated del dialogo del browser):
38
Tablas superordinadas a Pedidos
Adems de ver que tablas tiene subordinadas y superordinadas, podemos consultar la estructura de una tabla, que ndices tiene (composicin de los ndices), frmulas, etc. Existen dos operadores para frmulas verticales: SUM que suma todos los datos y COUNT que cuenta cuantos datos hay.
Frmulas y Redundancia
En base a los criterios de normalizacin y dado que por definicin una frmula 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 frmula no este almacenada puede ocasionar problemas de performance, debido al tiempo que pueda demorar el reclculo. Para evitar este inconveniente se puede definir la frmula como REDUNDANTE. En este caso la frmula se almacena en la Base de Datos y no es necesario recalcularla
39
cada vez que se use. Una vez que la frmula es definida como redundante, GENEXUS se encarga de agregar todas las subrutinas de mantenimiento de redundancia a todas las transacciones que utilicen esa frmula. Tenemos entonces que la definicin de frmulas 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 teora esta decisin puede ser bastante difcil de tomar, en la practica vemos que la mayor parte de las frmulas que se definen redundantes son las verticales (mas adelante veremos que hay una forma muy fcil de hacerlo) y pocas veces las horizontales. La razn de esto es que el calculo de las frmulas verticales pueden insumir un nmero indeterminado de lecturas. Por ejemplo para calcular el PedTot se deben leer todas las lneas del pedido, que pueden ser una cantidad bastante grande.
Frmulas de Frmulas
Una frmula se calcula a partir del valor de otros atributos. Dichos atributos pueden estar almacenados o ser otras frmulas. Por ejemplo si en la transaccin 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 frmulas de frmulas GENEXUS determina cual es el orden de evaluacin correspondiente: PedImp PedTot PrvTotPed = PedCnt * PedPre = SUM( PedImp ) = SUM( PedTot )
40
Reglas
Segn el Anlisis 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 definicin 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 segn el tipo de dilogo (full-screen o campo a campo). En el dilogo full-screen se asigna el valor por defecto si el usuario no digito nada en el campo. En el dilogo 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 condicin ( 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 transaccin. Una utilizacin relativamente comn es incluir una regla de error() para prohibir alguna de las modalidades de la transaccin: error( 'No se permite eliminar Pedidos' ) if delete; Con esta regla se prohibe que el usuario entre en el modo eliminacin y as se prohibe la eliminacin de Pedidos.
Asignacin
Dentro de las reglas de la transaccin se permiten definir asignaciones a atributos, dicha Asignacin implica una actualizacin en la tabla base del nivel o en alguna de
41
las tablas que pertenecen a la tabla extendida del nivel. Veamos un ejemplo, en la transaccin de Artculos: Artculos: 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 transaccin de Pedidos las siguientes reglas: ArtPrcUltCmp = PedPre if insert; ArtFchUltCmp = PedFch if insert; As cada vez que se ingrese una lnea del pedido se actualiza la tabla de Artculos con la fecha y el precio correspondiente. Existe una similitud entre frmulas y asignaciones, incluso la sintaxis de definicin es similar. La diferencia entre ambas es que una frmula es GLOBAL, es decir vale para todos los objetos GENEXUS que la utilicen, mientras que una Asignacin es LOCAL, vale solo para la transaccin en la cual fue definida. Cuando un atributo es frmula este no esta almacenado (a no ser que se lo defina como redundante) y cuando es una Asignacin, por ser esta local, si esta almacenado.
Add y Subtract
Las asignaciones que vimos en la seccin anterior eran relativamente fciles, pero existen casos mas sofisticados. Por ejemplo en la misma transaccin de Artculos tenemos el atributo ArtCnt en donde se quiere mantener cual es el stock que tenemos de cada articulo. Sin duda la transaccin de Pedidos debe modificar ese valor, porque cada pedido nuevo aumenta el stock. Tambin existir alguna otra transaccin que hace disminuir el stock, que podra ser por ejemplo una transaccin de Facturacin que se realiza cuando se vende el articulo. Como esta transaccin esta fuera del alcance del proyecto solo estudiaremos la actualizacin del stock relacionada con la transaccin de Pedidos. En dicha transaccin se debe actualizar ArtCnt, esto se podra hacer con la Asignacin:
42
ArtCnt = ArtCnt + PedCnt; Pero no debemos olvidar que en la misma transaccin se permite crear, modificar o eliminar un pedido, y la asignacin anterior solo es correcta si se esta creando uno nuevo, ya que si por ejemplo se est eliminando, la asignacin correcta es: ArtCnt = ArtCnt - PedCnt; Entonces, para actualizar ArtCnt correctamente se necesitara tambin considerar los casos de modificacin y eliminacin, pero para evitar todo esto GENEXUS posee la regla add() que lo hace automticamente: add(PedCnt, ArtCnt); Con esta regla si se esta insertando una lnea 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 frmula 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 comn que las frmulas verticales tengan que estar redundantes para tener buena performance se recomienda el uso de la regla ADD y no la frmula SUM. La regla SUBTRACT es equivalente pero realiza las operaciones contrarias, es decir cuando se esta insertando resta, en caso de eliminacin suma, etc.
Serial
Esta regla es til cuando se quiere asignar automticamente valores a algn identificador de la transaccin. Por ejemplo en la transaccin de Pedidos tenemos el PedLinNro y si queremos que este nmero sea asignado automticamente por el sistema se puede usar la regla: serial(PedLinNro, PedUltLin, 1); En donde el primer parmetro 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 nmero de lnea asignado) y el tercer parmetro el incremento (en este caso se incrementa de a uno). El atributo PedUltLin (Ultima lnea asignada) debe ser incluido
43
en la estructura de la transaccin en el nivel de PedNro (un pedido solo tiene UNA Ultima lnea asignada): PedNro* .... PedUltLin ( PedLinNro* .... ) PedTot De esta manera para cada nueva lnea del pedido el programa asigna automticamente su nmero. En el dilogo campo a campo (donde la modalidad era inferida automticamente), se debe digitar un valor inexistente en PedLinNro (usualmente 0) y el programa asigna el valor correspondiente. En el dilogo full-screen el valor se asigna cuando el usuario presiona Enter en modo Insertar.
Orden de evaluacin
La definicin de reglas es una forma DECLARATIVA de definir el comportamiento de la transaccin. 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 segn las dependencias de atributos existentes. Veamos un ejemplo: Supongamos que definimos en la transaccin de Artculos un nuevo atributo: ArtCntMax, del mismo tipo que ArtCnt. Este atributo indicar el stock mximo que se desea tener de ese artculo. Cuando se ingresa un pedido debemos emitir un mensaje si se sobrepasa el stock mximo de un artculo. Para ello definimos las siguientes reglas en la transaccin de pedidos: msg( 'Se sobrepasa el stock mximo del artculo' ) if ArtCnt > ArtCntMax; add(PedCnt, ArtCnt); El orden de evaluacin ser:
44
add(PedCnt, ArtCnt); msg( 'Se sobrepasa el stock mximo del artculo' ) 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 transaccin se puede pedir la opcin -"Detailed Navigation"- que lista cual es el orden de evaluacin. En este listado se explcita en que orden se generarn (usualmente decimos 'se disparan'), no solo las reglas, sino tambin las frmulas y lecturas de tablas.
Call y funcin 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 transaccin se puede llamar a un reporte o a otra transaccin, 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 transaccin 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 parmetro que se le pasa. Al tener after(trn), el Call se realizar despus 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 Asignacin. Los after() existentes son:
Confirm
La regla se dispara despus de haber confirmado los datos del nivel pero antes de haber realizado la actualizacin. Se usa para algunos casos de numeracin automtica cuando no se quiere utilizar la regla serial para evitar problemas de control de concurrencia.
45
Insert | Update | Delete

Se dispara despus 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 despus 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 (llammosle 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 recin se realizar cuando se terminaron de entrar todas las lneas del pedido.
Trn
Se dispara despus de haber entrado todos los datos de una transaccin. 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 transaccin.
Propiedades
En el editor de propiedades de las transacciones se pueden definir reglas de comportamiento general. A continuacin vemos la pantalla para la edicin de las mismas:
46
Por ejemplo vamos a setear propiedades que estn asociadas con el manejo de la integridad transaccional y con la interface. Podemos indicar si deseamos que la transaccin haga un commit al final o que no deseamos que se pidan confirmaciones cada vez que se actualiza un nivel, etc.
47
DISEO DE REPORTES
Con Reportes se definen los procesos no interactivos de extraccin de datos. Usualmente un Reporte es un listado que se enva a la impresora, aunque tambin puede ser visualizado en pantalla. Es un proceso no interactivo, porque primero se extraen los datos y luego se muestran, no habiendo interaccin con el usuario durante el proceso de extraccin, y es solo de extraccin ya que no se pueden actualizar los datos ledos. Para consultas interactivas se utilizan los Paneles de Trabajo y para los procesos de actualizacin los Procedimientos. Para cada Reporte se debe definir: Informacin Datos generales del Reporte, por ejemplo nombre, descripcin, 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. Documentacin Texto tcnico para ser utilizado en la documentacin del sistema.
Layout
En el Layout se define simultneamente la estructura de la navegacin (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 continuacin. Comencemos por un Reporte para listar todos los proveedores:
48
Literales
Bloque de impresion
Bloque de cdigo
Atributos
En donde tenemos los comandos Header, End, For each y Endfor. Para describir ms fcilmente el funcionamiento de estos comandos veamos el resultado de ejecutar el programa generado correspondiente:
49
La definicin de reportes se divide en uno o varios bloques. Estos bloques pueden ser de cdigo o de impresin . En los bloques de impresin se disea la salida que posteriormente ser impresa. Cada bloque de impresin puede tener un conjunto de controles (atributos, variables, textos, etc.). Podemos ver un bloque de impresin como un pedazo de papel. Los bloques de impresin (o Print Blocks) tienen asociadas ciertas propiedades, que pueden seteadas desde un dialogo que se abre al hacer doble-click sobre el bloque de impresin, como ser: los colores a usar, el tipo de papel, el tipo de letra, etc. El dialogo es el siguiente
Para el diseo de los bloques de impresin tenemos disponible una paleta de herramientas similar a las transacciones.
50
La cual permite insertar atributos, textos, lneas, recuadros, bitmaps y nuevos bloques de impresin. Los controles son definidos de la misma forma en que se hace en el editor del form de las Transacciones (tipo de letra, color, tamao, etc.). Todos los bloques de impresin que se encuentren entre los comandos HEADER y END son las lneas que se imprimen en el cabezal de la pagina. Tambin existe el comando FOOTER que permite imprimir un pie de pgina en cada hoja. El comando FOR EACH indica que se impriman todos los bloques de impresin 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, quizs, el comando ms importante en los Reportes ya que toda la definicin 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 informacin 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 razn por la cual no se hace referencia al modelo fsico de datos es para que la especificacin del Reporte sea del mas alto nivel posible, de tal manera que ante cambios en la base de datos la especificacin 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 definicin 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
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 Nmero 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
El layout para este listado es:
Si recordamos el modelo de datos definido en el captulo Diseo de Transacciones, el Diagrama de Bachman es:
53
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 Navegacin) donde se indica cuales son las tablas que se estn accediendo, en este caso el listado es:
54
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 interpretacin muy prctica 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 ledo 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 explcita se utiliza la clusula 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 automticamente por GENEXUS. La navegacin para este reporte es la siguiente: PedFch PrvNom AnlNom
55
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 ningn 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 Navegacin indicar que esta creando un 'ndice temporario'. Navegacin: A temporary index will be created for PedFch on table PEDIDOS Obviamente este proceso es ms lento si lo comparamos con el listado anterior en donde haba un ndice definido. Dada esta situacin el analista debe tomar una decisin: Crear un ndice del usuario. En este caso el Reporte ser bastante ms eficiente, pero se debe mantener un ndice ms (lo que implica mayor almacenamiento y mayor procesamiento en las transacciones para mantener actualizado el ndice). Dejar el Reporte con el ndice temporario.
56
No es posible recomendar, a priori, cual de las dos soluciones es la mejor, por lo tanto se debe estudiar caso por caso la solucin 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 anlogo 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 clusula WHERE. Por ejemplo, para listar slo 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 clusulas estn 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
WHERE PedFch = Today() OR PedNro > 100 PedNro Endfor GENEXUS posee una serie de mecanismos para optimizar el Reporte en funcin del orden del FOR EACH y de las condiciones del mismo, pero estas se aplican slo a las condiciones que tienen la siguiente forma: WHERE <atributo> <operador> <valor> <cdigo1> WHEN NONE <cdigo2> Donde: <atributo> <operador> <valor> <cdigo2> 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 cdigo cuando en un For Each no se encuentra ningn 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 ningn tipo con respecto al For each que contiene el When None. Cuando la condicin ha sido optimizada en el Listado de Navegacin aparece como 'Navigation Filter' y cuando no, como 'Constraint'. Tener en cuenta que cuando la condicin tiene esta forma se realizara algn tipo de optimizacin, pero no quiere decir que otras formas no sean vlidas, al contrario, en el WHERE se pueden definir condiciones para atributos que son frmulas, que no se encuentran en la tabla base, etc.
Determinacin de la tabla extendida del grupo FOR EACH

Resulta muy til saber cmo GENEXUS determina la tabla extendida que se debe utilizar. El criterio bsico 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
For each PedNro Endfor Segn ya vimos todos estos atributos se encuentran dentro de la tabla extendida de PEDIDOS, sin embargo, tambin se encuentran dentro de la tabla extendida de PEDIDOS1 (Lnea del pedido), pero la tabla extendida de PEDIDOS est contenida en la de PEDIDOS1 (porque justamente la de PEDIDOS1 contiene a la de PEDIDOS adems 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 podra argumentar que la tabla extendida de PEDIDOS contina siendo vlida, sin embargo por razones de simplicidad GENEXUS en este caso indicar que no hay relacin entre estos dos atributos y ser necesario que se utilice algn atributo de la tabla PEDIDOS para poder generar el Reporte. Tambin puede darse el caso que exista ms de una tabla extendida mnima que contenga a los atributos del grupo FOR EACH - ENDFOR. Ante esta ambigedad GENEXUS escoge la PRIMERA tabla extendida que cumpla con las condiciones anteriores. Para resolver estos dos problemas (no hay ningn atributo de la tabla base y hay ms de una tabla extendida mnima posible), se utiliza la clusula DEFINED BY dentro del comando FOR EACH, por ejemplo: For each Defined by PedFch PedNro Endfor PedFch PrvNom AnlNom AnlNom PedFch PrvNom AnlNom
59
En el DEFINED BY se debe hacer referencia a por lo menos un atributo de la tabla base que se quiere. An en los casos que no se dan ninguno de los problemas anteriores se recomienda el uso del DEFINED BY para Reportes ms o menos complejos porque mejora bastante el tiempo de especificacin del Reporte.
Reportes con varios FOR EACH

For Each anidados
Hasta ahora hemos definido reportes en donde exista un solo FOR EACH, pero es posible utilizar mas de un FOR EACH para realizar Reportes ms sofisticados. Supongamos que queremos listar para cada proveedor cuales son sus pedidos, por ejemplo:
El layout que se debe definir es (slo se muestran los grupos FOR EACH):
60
Si colapsamos todos los print blocks, queda mas claro como se definen los FOR EACH anidados.
61
En este Reporte tenemos dos FOR EACH anidados. Si analizamos el primer FOR EACH vemos que utiliza slo 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 listarn, para cada registro en la tabla de proveedores, cuales son sus pedidos en la tabla de pedidos. Ms formalmente, cuando hay dos FOR EACH anidados, GENEXUS busca cual es la relacin de subordinacin existente entre la tabla base del segundo FOR EACH y la tabla extendida del primer FOR EACH (en el caso anterior la relacin era que la tabla PEDIDOS estaba subordinada a la tabla PROVEEDO por PrvCod) y establece de esta manera la condicin que deben cumplir los registros del segundo FOR EACH (en el
62
ejemplo: todos los registros de la tabla PEDIDOS con el mismo PrvCod ledo en el primer FOR EACH). Puede darse el caso en que no exista relacin 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 relacin entre estas dos tablas extendidas. En este caso GENEXUS da el mensaje 'No existe relacin directa' y har el producto cartesiano entre los dos FOR EACH, es decir, para cada registro de la tabla PROVEEDO (proveedores) se imprimirn todos los registros de la tabla ANALISTA (analistas).
63
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
El layout es:
La tabla base del primer FOR EACH es la PEDIDOS (por usar PedFch) y la del segundo FOR EACH tambin (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 Navegacin con la palabra BREAK en vez de FOR EACH. Los cortes de control pueden ser de varios niveles, por ejemplo, si quisiramos 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
For Each paralelos

Tambin 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 prcticos cuando se quiere hacer listados del tipo 'Listar toda la Informacin que se tenga sobre un Proveedor', en donde el Layout ser del tipo: For each ... //Informacin del Proveedor For each .... // Informacin sobre Pedidos Endfor For each .... // Informacin sobre Precios Endfor .... Endfor
66
Otros comandos
En el Layout se pueden utilizar otros comandos adems de los ya vistos. Nos limitaremos aqu a ver solo los ms significativos (para un repaso exhaustivo de los mismos sugerimos ver el Reference Manual).
Definicin 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 pgina que se est imprimiendo, etc. Se deben definir las caractersticas (tipo, largo, decimales, etc.) de las variables que se estn utilizando en el Reporte, con excepcin de las predefinidas.
67
Las variables se pueden definir tambin en funcin de otros atributos, usando la opcin de Based On. Se recomienda utilizar esta opcin siempre que sea posible.
Asignacin
Este comando permite asignar valores a variables. Por ejemplo si queremos mostrar totales en un listado:
68
69
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 impresin condicional, es decir, imprimir una lnea solo cuando se cumple alguna condicin.
70
En el ejemplo anterior:
El comando DO WHILE-ENDDO es muy usado para imprimir varias vas, por ejemplo si se quiere imprimir dos vas 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 parmetros que se envan, estos parmetros pueden ser atributos, variables y constantes. Los parmetros pueden ser actualizados en el programa llamado. Cuando desde un Reporte se llama a otro Reporte, que tambin imprime, es importante pasarle como parmetro la variable predefinida &Line (que contiene el nmero de lnea que se est imprimiendo) para que el Reporte llamado no comience en una pgina nueva.
71
Con el comando DO se llama a una subrutina que se encuentra dentro del mismo Layout. En este caso no son necesarios los parmetros porque estn disponibles para la subrutina los mismos datos (variables) que estn 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 tena como tabla base la PROVEEDO y el segundo la PEDIDOS.
72
Ahora bien, el primer FOR EACH es independiente del segundo y por lo tanto se imprimirn 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 imprimirn 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 implcitamente un corte de control. Por lo tanto se DEBE definir explcitamente 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
Es equivalente a la clusula 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 aplicarn a TODOS los FOR EACH que correspondan. En el Listado de Navegacin se indica a que FOR EACH se estn 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. segn el orden de aparicin 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
Las variables &ask1 y &ask2 deben definirse y el orden (1,2,... ) es el de definicin en las condiciones.
Parm
Es una lista de atributos o variables que recibe el Reporte como parmetros. Por ejemplo, si hacemos un Reporte para imprimir un pedido inmediatamente despus de haberlo digitado, en la Transaccin 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 lneas del pedido .... ENDFOR ENDFOR Reglas Parm(PedNro); Cuando en Parm() se recibe un atributo, automticamente este se toma como una condicin sobre los datos. En el ejemplo, al recibir como parmetro PedNro el primer FOR EACH (que esta basado en la tabla PEDIDOS que contiene PedNro) tiene como condicin que PedNro sea igual al parmetro y no es necesario poner un WHERE. Si se hubiera recibido el parmetro como una variable, entonces s es necesario definir el WHERE. Layout FOR EACH WHERE PedNro = &Pedido .... ENDFOR Reglas Parm(&Pedido);
75
Report Wizard
El Report Wizard permite realizar el diseo del layout de los Reportes y Procedimientos de manera mas sencilla. Diseemos nuevamente el reporte de pedidos por proveedor. El diseo 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 sintctica similar a la usada en las transacciones, sin embargo, los parntesis se usan para indicar niveles de FOR EACH (en vez de niveles de una transaccin) 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 transaccin tambin se aplican al definir la estructura del layout.
Para disear 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 cdigo de proveedor y el interno por numero de pedido. Una vez que se ha definido correctamente la estructura, se presiona el botn de Next para pasar al siguiente paso.
76
Paso 2: Permite definir otras caractersticas del layout. Se permite elegir los fonts para representar los atributos o textos, tambin 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 ttulos, mientras que los de los atributos dejamos el default. Presionando el botn de Finish se graban las definiciones para el paso actual y se sale del dialogo del Report Wizard.
77
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 diseo del layout es idntico 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 ejecucin. Prompt for Confirmation: Si deseamos que se pida confirmacin al usuario.
78
Allow User to Cancel Processing. Footer on Last Page: Imprimir el footer en la ltima pantalla.
79
DISEO DE PROCEDIMIENTOS
Los Procedimientos son el objeto GENEXUS con el que se definen todos los procesos no interactivos de actualizacin de la base de datos y las subrutinas de uso general. Este objeto tiene todas las caractersticas de los Reportes (cualquier Reporte se puede realizar como un Procedimiento) ms algunas caractersticas particulares para la actualizacin de la base de datos. Por esta razn se recomienda haber ledo previamente el captulo Diseo de Reportes. Vamos a ver entonces los comandos disponibles en los procedimientos para la actualizacin de la base de datos
Modificacin de datos
La modificacin de datos de la base de datos se realiza de forma implcita, ya que no hay un comando especfico de modificacin (como podra ser REWRITE), sino que basta con asignar un valor a un atributo dentro de un For Each para que automticamente se realice la modificacin. Por ejemplo supongamos que queremos tener un proceso batch que actualiza el atributo ArtPrcUltCmp para adecuarlo segn la inflacin para todos los Artculos almacenados: Programa: For each ArtPrcUltCmp = ArtPrcUltCmp * (1 + &Inf) Endfor Reglas: Parm( &Inf );
Se puede modificar ms de un atributo dentro del mismo FOR EACH, por ejemplo, si tambin queremos modificar el atributo ArtFchUltCmp, ponindole la fecha de hoy: For each ArtPrcUltCmp = ArtPrcUltCmp * (1 + &Inf) ArtFchUltCmp = Today( ) Endfor
80
La modificacin en s se realiza en el ENDFOR y no cuando se realiza la asignacin del atributo. En estos dos ejemplos se modificaron atributos de la tabla base del FOR EACH, pero tambin es posible actualizar atributos de las tablas N-1 (tabla extendida) con el mismo mecanismo de asignacin 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 Navegacin se informa cuales son las tablas que se estn actualizando marcando con un + estas tablas. Por ejemplo: ------>> + ARTICULO
Eliminacin 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 // Despus de eliminar las lineas se elimina el cabezal DELETE Endfor
Creacin de datos
Para crear nuevos registros en la base de datos se usan los comandos NEWENDNEW. Tomemos por ejemplo un Procedimiento que recibe como parmetros AnlNro y AnlNom e inserta estos datos en la tabla de analistas:
81
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 clusula WHEN DUPLICATE se programa la accin 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 modificacin 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 automticamente es el de control de duplicados en el comando NEW. Pero NO se controla automticamente la integridad referencial, por ejemplo, si hacemos un Procedimiento que crea automticamente 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 lneas del mismo explcitamente. El mismo criterio se aplica para las frmulas redundantes. Estas deben ser mantenidas explcitamente con los comandos de asignacin/update.
82
DISEO 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 mltiples 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 programacin de los ambientes grficos, especialmente la programacin dirigida por eventos. Para cada Panel de Trabajo se debe definir: Informacin Datos generales del Panel de Trabajo, por ejemplo nombre, descripcin, 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 ejecucin del Panel de Trabajo. Por ejemplo que respuesta dar cuando el usuario presion Enter o un botn, 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, parmetros, etc. Ayuda Texto para la ayuda a los usuarios en el uso del Panel de Trabajo. Documentacin Texto tcnico para ser utilizado en la documentacin del sistema. Propiedades Propiedades generales del Work Panel.
83
En este captulo solo se presentarn las caractersticas y usos ms salientes de los Paneles de Trabajo, pero se recomienda leer el captulo de Paneles de Trabajo en el Manual de Usuario GENEXUS, para una visin ms profunda.
Ejemplo
Para ilustrar ms fcilmente 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 accin, 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 botn de Visualizar en el proveedor 125, se abre una ventana donde se muestran los datos del proveedor:
84
Si se presiona el botn de pedidos se presentar la siguiente pantalla con los pedidos del proveedor:
A su vez este Panel de Trabajo podra extenderse, permitiendo seleccionar algn pedido para visualizar qu artculos fueron pedidos y as sucesivamente. Las acciones que vimos en el primer Panel de Trabajo se aplican a una lnea, pero existen otras acciones que no se aplican a ninguna lnea en particular, por ejemplo Insertar un
85
nuevo proveedor. Si se elige esta accin se pasa el control a la transaccin de proveedores para definir uno nuevo.
Renovar - es una accin includa automticamente por GENEXUS y, si se elige, se vuelven a cargar todas las lneas. Ms adelante nos detendremos en esta accin. 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
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 slo se pueden ver simultneamente las lneas 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 pgina, a la siguiente, etc. El Panel de Trabajo anterior tiene un SubFile compuesto de PrvCod y PrvNom. Los SubFile pueden contener adems de atributos, variables y arrays de una y dos dimensiones.
Subfile
Si seleccionamos el botn de subfile nos va a permitir incorporar un subfile en el form del work panel y definir el tamao que deseamos.
Insertar el control tipo Subfile
87
Una vez pasteado el control en el form se abre automticamente 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 ttulos 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 informacin 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 tambin ajustar manualmente el ancho de cada columna desmarcando la opcin de Auto Resize, si esta opcin queda marcada el ancho de la columna lo determina GENEXUS en funcin del largo del atributo o del titulo de la columna. El check box Horizontal Scroll permite que en tiempo de ejecucin aparezca una barra de scroll horzontal (adems de la de scroll vertical que aparece automticamente)
88
Eventos
La forma tradicional de programar la interfaz entre el usuario y el computador (includos los lenguajes de cuarta generacin) 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 tpica de los ambientes GUI (Interfaz de Usuario Grfica), en donde ya ha demostrado su productividad, fundamentalmente porque se necesita programar slo 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 ledo 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 estn permitidos ni los comandos relacionados con la impresin (Header, etc.) ni los de actualizacin de la base de datos (New, Delete, etc.). Tambin existen comando especficos para Paneles de Trabajo.
89
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 tcnica 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 lnea que se le asocie la opcin 4 se llama a un procedimiento que borra los clientes. El cdigo 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 opcin valida') Msg( &msg ) Endif Endif Endfor Endevent El evento Enter es un poco ms 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
Para cada una de las lneas 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 opcin no es vlida. Notar que se podran 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 transaccin de proveedores (por ms detalles sobre como llamar de un Panel de Trabajo a una Transaccin ver el captulo de Paneles de Trabajo en el Manual de Referencia). Luego de llamar a la transaccin, se ejecuta el comando Refresh, que indica que se debe cargar nuevamente el SubFile, ya que se ha adicionado un nuevo proveedor. Tambin se podra haber usado el comando con el parmetro keep (Refresh Keep) que hace que una vez que el comando refresh se ejecuta el cursor queda posicionado en la misma lnea del subfile que estaba antes de la ejecucin.
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 tambin se necesita cargar nuevamente el SubFile. Por ejemplo, cuando en otro evento se llama a una transaccin que actualiza los datos (es el caso del Evento 'Crear Proveedor').
91
Tenemos, por lo tanto, que el SubFile se carga (es decir, se genera el evento Refresh) cuando: Se carga la pantalla - por lo tanto despus del evento Start siempre hay un evento Refresh. El usuario dio click sobre el botn 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, despus 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 captulo Diseo de Reportes. Pero en este caso no hay ningn FOR EACH!. Sin embargo, se considera que cada Panel de Trabajo tiene un FOR EACH implcito, 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 excepcin de aquellos que se encuentren dentro de un FOR EACH explcito. 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 relacin entre el evento Refresh, el FOR EACH implcito 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 implcito, se cargan en el SubFile, que es el que se presenta en pantalla. Esta carga se realiza 'bajo pedido', es decir que al
92
comienzo slo se carga la primera pgina y, a medida que el usuario requiere ms informacin, se van cargando las siguientes pginas. 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 Navegacin del Panel de Trabajo se indica qu tablas se estn utilizando, ndices, etc. Puede darse el caso que no exista el FOR EACH implcito. 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 slo variables). En este caso se genera slo 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 slo un rango de proveedores, agregamos en la pantalla las variables:
93
Variables para ingresar el proveedor final y inicial.
Y definiendo las condiciones:
se obtiene el efecto deseado.
94
Todas las consideraciones sobre optimizacin de condiciones vistas en el captulo Diseo de Reportes son igualmente vlidas aqu.
Reglas
En Reglas se aplican la mayor parte de las reglas de los Reportes, ms algunas particulares:
Order
Define cual es el orden de los datos del SubFile. Es equivalente a la clusula ORDER del FOR EACH y se aplica todo lo dicho en el captulo Diseo de Reportes sobre el tema (includa la creacin de ndices temporarios). Por ejemplo si queremos ver los proveedores por orden alfabtico: order( PrvNom );
Noaccept
A diferencia de las Transacciones, en los Paneles de Trabajo ningn 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 lnea determinada del mismo, en forma directa, sin tener que avanzar pgina por pgina. Por ejemplo si en nuestro Panel de Trabajo de proveedores queremos que exista la posibilidad de buscar un proveedor segn su nombre, se debe definir la regla: search( PrvNom >= &Nom );
95
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 rpidamente en un SubFile, se debe tener en cuenta que no hay ningn tipo de optimizacin sobre la misma. Si se quieren utilizar los criterios de optimizacin se deben usar las Condiciones.
96
Bitmaps
Los bitmaps son usados usualmente para mejorar la presentacin de las aplicaciones. Se pueden incorporar en los forms de las transacciones, reportes y work panels. GENEXUS provee dos mtodos diferentes para agregar un Bitmap:
Fixed Bitmaps
Se puede agregar un Bitmap seleccionando el botn de Bitmap de la paleta de herramientas. De esta forma tenemos que indicar su ubicacin. 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 mtodo tiene como diferencia que el Bitmap lo asigno a una variable y usando la funcin Loadbitmap puedo cargar el Bitmap que yo desee. Por ejemplo se puede tener un Bitmap que despliegue la foto de cada proveedor.
97
Definicin de una varible de tipo bitmap:
En el evento load hay que cargar el bitmap para el proveedor pasado por parmetro. En el atributo PrvFoto se carga la ubicacin del archivo (bmp).
98
En tiempo de ejecucin se ver de la siguiente forma:
Grficas
Grafiquemos el total pedido por Proveedor. Vamos a definir entonces una formula que me calcule el total pedido en la transaccin de proveedores:
99
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 haba sido definido como una formula, sumando todos los importes de la lnea que a su vez era tambin una formula. De esta forma tenemos disponible este atributo para usarlo en la definicin del work panel.
100
En este work panel definimos el botn Graficar el cual va a tener asociado el siguiente evento:
De esta manera cuando el usuario presiona el botn de graficar visualizara el total pedido por los proveedores en forma grfica. Vemos a continuacin ejemplos de los tipos de grficos que podemos disear:
101
102
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 grficas. En el segundo Panel de Trabajo del ejemplo se utiliz esta regla. Por mayor informacin sobre las propiedades de los distintos objetos sugerimos consultar al manual de referencia.
103
Dilogos Objeto-Accin
Con el uso de Paneles de Trabajo, se tiene la oportunidad de definir para la aplicacin una arquitectura orientada a dilogos Objeto-Accin. Pero previo a introducir este concepto veamos cual era la forma tradicional. Si observamos una aplicacin desarrollada por los mtodos tradicionales, veremos que cuanto mayor es, ms grande ser el rbol de menes que se tiene para acceder a los programas que efectivamente trabajan con los datos. La arquitectura de este tipo de sistemas normalmente es:
Menes Trn Rpt Proc
Seleccin de la Accin
Aplicar la accin al objeto
Esta situacin 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 ms consultas se implementan en el sistema, menos son usados por el usuario, porque le resulta difcil acordarse de las diferencias entre ellas. Diremos que este tipo de aplicacin tiene un dilogo Accin-Objeto, porque primero se elige la accin a realizar (por ejemplo modificar un proveedor, o listar los pedidos) y luego se elige el objeto al cual aplicar la accin (que proveedor o los pedidos de que fecha). Con Paneles de Trabajo se pueden implementar sistemas en donde el dilogo puede ser Objeto-Accin, 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
Menes Paneles de Trabajo Trn Rpt Proc
Seleccin del tipo de objeto
Seleccin del objeto y la Accin Aplicar la accin 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 fciles de usar.
105
DISEO DE MENES
Este objeto permite definir los diferentes menes de la aplicacin. La definicin de un men es muy fcil, y prcticamente 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
Es un men de seleccin implcita, es decir la opcin 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
En donde se utiliza la tcnica de seleccin explcita, donde para seleccionar la opcin se debe digitar el nmero de la misma en el campo de seleccin. Los menes 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 travs 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 opcin Callees o Callers del dialogo del browser). En nuestro ejemplo vamos a ver el rbol de llamadas del men Compras:
108
Desde este browser podemos editar cualquier objeto que aparezca en las listas.
109
ANEXO A. MODELOS DE DATOS RELACIONALES

El propsito 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 informacin 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 informacin 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 direccin del mismo. En la prctica esta regla implica que no existen tablas con diferentes tipos de registros. No existen dos registros con exactamente la misma informacin. El orden de los registros no contiene informacin. Es decir se pueden reordenar los registros sin perder informacin.
110
Clave primaria y Claves candidatas

Dado que no puede haber dos registros con la misma informacin, 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 cdigo, pero tampoco hay dos proveedores con el mismo nombre. En una Base de Datos Relacional slo una de las claves candidatas debe ser definida como la Clave Primaria. Tambin se debe respetar la siguiente regla: no deben existir dos tablas con la misma clave primaria. Por ejemplo consideremos el siguiente diseo: Tabla: PROVEEDO Atributos: PrvCod* PrvNom Tabla: PROVDIR Atributos: PrvCod* PrvDir Tanto la PROVEEDO como la PROVDIR tienen la misma clave primaria. Esto era relativamente comn cuando el criterio de diseo 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 diseo es diferente (ver seccin de Normalizacin) y es preferible una sola tabla con los tres atributos: Tabla: PROVEEDO Atributos: PrvCod* PrvNom PrvDir
111
Indices
Son vas 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 automticamente a partir de los identificadores de las transacciones. Los ndices extranjeros son utilizados para hacer eficientes los controles de integridad inter-tablas. Tambin son definidos automticamente. 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 automticamente. En una Base de Datos Relacional los ndices se utilizan slo 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. Segn vimos en el ejemplo, existe una relacin entre la tabla PEDIDOS (Pedidos) y la PROVEEDO (Proveedores):
112
N 1
La relacin entre estas dos tablas se determina analizando los atributos que tienen en comn, por ejemplo aqu tenemos que el atributo comn 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 estn relacionadas y la relacin es 1-N. Con relacin 1-N se indica que un Proveedor tiene varios Pedidos y que un Pedido slo tiene un Proveedor. Tambin 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 relacin 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 tambin por PrvCod en la tabla PROVEEDO.
113
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.
Normalizacin
El proceso de normalizacin determina en que tablas debe residir cada uno de los atributos de la base de datos. El criterio que se sigue es bsicamente determinar una estructura tal de la base de datos, que la posibilidad de inconsistencia en los datos sea mnima. Por ejemplo, si tenemos que almacenar informacin sobre Proveedores y Pedidos, se podra 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 comn (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 situacin 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 ms 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
Entonces la estructura correcta (diremos 'normalizada') ser: Tabla: PROVEEDO PrvCod* PrvNom PrvDir Tabla: PEDIDOS PedNro* PedFch PrvCod AnlNro PedTot
El proceso de normalizacin (que se acaba de introducir de una manera muy informal) se basa en el concepto de Dependencia Funcional, cuya definicin es: Se dice que un atributo depende funcionalmente de otro si para cada valor del segundo slo existe UN valor del primero. Por ejemplo PrvNom depende funcionalmente de PrvCod porque para cada valor de PrvCod slo existe UN valor de PrvNom. En realidad la definicin 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 seccin de Normalizacin, el criterio de diseo de la base de datos se basa en minimizar la posibilidad de inconsistencia en los datos. Una base de datos diseada de esta manera tiene una serie de ventajas importantes (tal es as que actualmente la normalizacin de datos es un standard de diseo), pero se deben tener en cuenta tambin algunos inconvenientes. El inconveniente ms 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 definicin 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 relacin 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
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, ms todos los atributos de Proveedores y todos los de Analistas, pero no los atributos de la Linea del pedido o de Artculos (porque si bien estn relacionados, su relacin no es N-1). En el siguiente diagrama se muestra, para cada una de las tablas del modelo, cual es su tabla extendida:
116
Tabla base Proveedores Analistas Pedidos Linea_pedidos
Tabla extendida Proveedores Analistas Pedidos, Proveedores, Analistas Linea_pedidos, Pedidos, Proveedores, Analistas, Artculos
Artculos
Artculos
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 fsicas. Por ejemplo el comando FOR EACH determina una tabla extendida y no una tabla fsica.
117
ANEXO B. FUNCIONES, REGLAS Y COMANDOS

FUNCIN 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 DESCRIPCIN Numero de da de una fecha Numero de mes de una fecha Ao de una fecha Fecha de hoy Numero del da de la semana Nombre del da de una fecha Nombre del mes de una fecha Pasar de tipo carcter a tipo fecha Pasar de tipo fecha a carcter Armar fecha a partir de ao, mes y da Sumar un mes a una fecha Sumar un ao a una fecha Diferencia en aos entre dos fechas Fecha fin de mes de una fecha
Pasar un numrico 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 maysculas Convierte un string a minsculas Parte entera de un numrico Redondear un valor numrico Pasar un string a numrico
118
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 insercin Hora Hora del sistema Fecha del sistema Identificacin del usuario Clase de usuario Workstation Para pedir valores por pantalla Funcin 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 (todava no se hizo la modificacin del registro) Luego que termina la transaccin Despus de un atributo Luego que finaliza determinado nivel Nivel de una transaccin Si fue modificado algn atributo de un nivel Si la transaccin esta en modalidad insert Si la transaccin esta en modalidad update Si la transaccin esta en modalidad delete
119
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
DESCRIPCIN 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 transaccin Restar un valor a un atributo teniendo en cuenta la modalidad de la transaccin 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 parmetros 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 seleccin Aceptar atributo o variable en la pantalla Modalidad por defecto al ingresar en una transaccin No pedir confirmacin al final de un determinado nivel Dar colores a los atributos, variables y fondo Orden de la tabla base del Work Panel Condicin de bsqueda sobre el subfile Para incluir variables o atributos en el subfile Inhibe la lectura de atributos Para seleccionar el printer file en el
W R
120
AS/400
T = Transacciones W = Work Panels R = Reportes P = Procedimientos Las casillas que aparecen marcadas indican que la funcin aparece disponible para ese objeto.
121
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
DESCRIPCIN Comienzo del cabezal Comienzo del pie de pagina Para recorrer los registros de una tabla Permite salir de un while Repeticin de una rutina mientras se cumpla una condicin Ejecuta algn bloque segn que condicin se cumpla Ejecuta un bloque de comandos en caso que la condicin evale verdadera Commit Rollback Imprime si existen registros en el subfile. Finaliza la ejecucin y vuelve al programa llamador Asignacin de una variable Numero de lnea donde los datos sern impresos Para pasar comandos especiales a la impresora Largo de pagina Margen superior Provoca un salto de pgina si quedan menos de n lneas por imprimir No pasar a la siguiente lnea de impresin Salto de pgina Llamar a un programa Someter un programa Desplegar un mensaje Llamar a una subrutina Bloque de subrutina Actualizacin de atributo Insertar registro Borrar un registro
T W R P
122
T = Transacciones (eventos) W = Work Panels (eventos) R = Reportes P = Procedimientos Las casillas que aparecen marcadas indican que la funcin 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 ............................................................................................................. DISEO DE TRANSACCIONES................................................ 41 NOMENCLATURA GIK .............................................................. 47 TIPOS DE DATOS ....................................................................... 49 COMANDOS DE ASIGNACIN .................................................. 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
Capacitacin 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 bsicos para el diseo de Aplicaciones. Alcance : Conceptos fundamentales y elementos bsicos. 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 lderes de Proyecto. Etapas: Este curso consta de 3 etapas:Autoestudio , Curso Terico/ Prctico y Taller. Aprobacin: Este curso es evaluado por los instructores de Artech . La evaluacin consiste en la defensa del Taller realizado y el resultado de dicha evaluacin (Aprobacin /No aprobacin) es comunicado a la Empresa. Habilitado a: El alumno que aprueba dicho curso queda habilitado a desarrollar aplicaciones de pequeo y mediano porte, sin embargo es necesario el apoyo que se brinda en el WorkShop. Duracin: 76 horas distribuidas en cuatro semanas.
CURSO GENEXUS PARTE II

Objetivo: Alcanzar la capacitacin completa para desarrollar Aplicaciones GeneXus. Pensamos que despus del curso se levanta la productividad substancialmente alcanzando en poco tiempo el nivel mximo. 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 lderes de Proyecto. Duracin: 16 horas distribuidas en cuatro das.
WORKSHOP
Objetivo: Apoyo inicial a la primera aplicacin real que desarrolla el cliente. El Workshop cumple las siguientes funciones fundamentales: a) Realizar un anlisis inicial junto al cliente que redunde en una planificacin para la correcta insercin de GeneXus en la empresa b) Apoyar tcnicamente el comienzo del desarrollo con la herramienta de cuyo resultado depende en gran parte el futuro desempeo y satisfaccin del cliente. c) Tener un seguimiento del Cliente en la etapa inicial para asegurarnos que obtiene la productividad esperada y corregir posibles desvos en la etapa inicial. Condiciones previas: Tener aprobado el Curso Genexus. Orientado a: Usuarios que van a desarrollar directamente aplicaciones usando GeneXus y lderes de Proyecto. Duracin: 20 horas de consultora en el Cliente. Comienzo: Es conveniente comenzarlo apenas finalizado el Curso GeneXus . Debe comenzar antes de los 60 das de finalizado dicho curso, sino se pierde el derecho a realizarlo.
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 , Diseo de una aplicacin Client/Server , Optimizacin y Performance de las aplicaciones , Multi-tier Architecture. Orientado a: Gerentes de proyecto y tcnicos de la empresa, ya que les brindar la posibilidad no solo de conocer a fondo esta Arquitectura y sus posibilidades, sino tambin les dar el conocimiento para desarrollar aplicaciones sobre las mismas . Duracin:24 horas distribuidas en 6 das.
CURSO JAVA
Objetivo: Dar los elementos necesarios para poder generar aplicaciones Java en una arquitectura Cliente/Servidor de 2 y mltiples capas para correr tanto en una Intranet como en Internet. Condiciones previas: Tener aprobado los cursos GeneXus y Client/Server Alcance: Informacin general sobre lenguaje Java, Informacin general sobre Generador Java, Software necesario, Configuracin del Modelo, Distribucin de aplicaciones para su puesta en produccin, Ejecucin en mltiples capas, Pool de conexiones, Lightweight Directory Access Protocol (LDAP) Orientado a: Gerentes de Proyecto y Tcnicos de la empresa. Duracin: 12 horas (terico/prctico) distribuidas en 3 das.
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. Duracin: 24 horas distribuidas en 6 das.
CURSO DATA WAREHOUSING

Objetivo: Durante aos hemos desarrollado sistemas operacionales y con ellos hemos resuelto muy bien las funciones operacionales de nuestras organizaciones (fbricas 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 informacin a nivel de gestin. Sin embargo, no hemos podido usar esos datos para proveer informacin a los niveles ms altos de nuestras organizaciones, ni hacerlo con el dinamismo necesario. Este fenmeno es conocido como 'data in jails' (los datos existen, pero estn 'enjaulados'). Los niveles de direccin y estratgicos son los que actualmente se encuentran ms carentes de informacin. Necesitamos proveer informacin de buena calidad, oportuna y en forma dinmica para el apoyo a la toma de decisiones. En la ltima dcada surgen, bajo el nombre DATA WAREHOUSING, ciertas tcnicas, metodologas y teconologas con el fin de resolver esta problemtica. ARTech ha y est trabajando en la investigacin y desarrollo de tecnologa 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 metodologa sencilla y desarrollando tecnologa para apoyar todas las etapas de la solucin. El objetivo de este curso es : conocer la teora de Data Warehousing, cuales son las componentes de la solucin, tcnicas y metodologas aplicadas, tecnologa asociada a cada componente, y ver como la tecnologa GeneXus nos apoya en cada etapa del proceso de construccin de la solucin. ALCANCE : Los punto principales que se tratan en el curso son los siguientes: Conocimiento de los diferentes aspectos de la problemtica, Esquema general de la solucin Data Warehousing, Componentes de la solucin, Etapas en el desarrollo de un proyecto, Estudio detallado de las metodologas aplicadas en cada etapa y Tecnologa asociada a cada componente. En forma paralela al curso terico se irn estudiando casos prcticos y los participantes irn aplicando sobre stos las metodologas aprendidas. Finalmente el participante realizar el diseo y parte de la implementacin de un caso prctico con la tecnologa GeneXus - Data Warehousing. ORIENTADO A: El Curso est orientado principalmente a Gerentes de Informtica, Lderes de Proyectos y Desarrolladores. A los Lderes de proyectos y Desarrolladores se les pide tener aprobado el Curso GeneXus. A los Gerentes de Informtica se les recomienda realizar previamente las dos primeras semanas del curso GeneXus. DURACIN: 32 horas distribuidas en 8 das.
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 cdigo de la aplicacin que resuelve la problemtica de la empresa. Est claro que la gran mayora de los usuarios no tienen conocimiento de estas tareas, las mismas estn ocultas a sus ojos y se realizan automticamente. 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 aplicacin. Una buena solucin 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 automatizacin de los procedimientos donde los documentos, la informacin 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 comn impuesta por la empresa. El Workflow nos da las facilidades para modelar los procesos de empresa, permitindonos de esta forma hacer un anlisis y diseo mas profundo de los mismos. Vemos entonces al Workflow no solo como una tecnologa que nos facilita el cambio, sino tambin, como una tecnologa que nos da un marco de referencia para el anlisis y diseo previo a la implantacin de un sistema que implica la interaccin de diversos procesos. ARTech ha estado trabajando en la investigacin y desarrollo de tecnologa de Workflow para incorporarla al desarrollo de los Sistemas de Informacin. Esto surgi al detectarse que en varios proyectos realizados nos enfrentbamos a problemas que se podan resolver de una forma ms natural con este tipo de tecnologa. As en una primera instancia surgi una solucin de Workflow especfica para resolver la problemtica de un proyecto y hoy en da se dispone de una solucin integral para desarrollos con GeneXus que est siendo utilizada en varios proyectos. El objetivo de este curso es: conocer los conceptos ms importantes de la teora de Workflow, cuales son las componentes de la solucin, tecnologa asociada a cada componente, y ver como se integra esta tecnologa al desarrollo de sistemas con GeneXus. Alcance: Los puntos principales que se tratan en el curso son los siguientes: Conceptos Tericos de Workflow, estudio de la herramienta de definicin de procesos (GeneXus Process Modeler), estudio del Workflow en ejecucin (Inbox y Motor de Workflow), estudio de las Workflow APIs, y el estudio de la integracin de la solucin de Workflow con el desarrollo de los sistemas con GeneXus. En forma paralela al curso terico se ir estudiando casos prcticos y los participantes irn aplicando sobre stos las metodologas aprendidas. Finalmente el participante realizar el diseo y la implementacin de un caso prctico con la tecnologa GeneXus-Workflow. Orientado a: El Curso est orientado principalmente a Gerentes de Informtica, Lderes de Proyectos y Desarrolladores. A los Lderes de proyectos y Desarrolladores se les pide tener aprobado el Curso GeneXus. A los Gerentes de Informtica se les recomienda realizar previamente las dos primeras semanas del curso GeneXus. Duracin: 16 horas distribuidas en 4 das.
RECOMENDACIN: A continuacin detallamos una propuesta de capacitacin para cada uno de los Roles que se llevan a cabo dentro del rea de informtica.Reconocemos que muchas veces estos roles son cumplidos por la misma persona o por varias , para lo cual debern considerarse las funciones ms que las personas. DESARROLLADOR GENEXUS: Persona directamente involucrada en el Desarrollo de Aplicaciones GERENTE y/o LDER DE PROYECTO : Persona que coordina el desarrollo de un grupo de desarrolladores y eventualmente desarrolla aplicaciones. GERENTE DE INFORMATICA: Persona encargada del sector informtico de la Empresa.
DESAROLLADOR - CURSO GENEXUS - Al comienzo - WORKSHOP - Inmediatamente despes de finalizado el Curso Genexus - CLIENT/SERVER - Despus del Curso Genexus (si corresponde) - DESARROLLO DE APLICACIONES PARA INTERNET - Despus del Curso Genexus (si corresponde) -WORKFLOW - Despus del Curso Genexus (si corresponde) -CURSO PARA GERENTES DE PROYECTOS - Tres meses despus de aprobado el Curso Genexus GERENTE y/o LDER DE PROYECTO - CURSO GENEXUS - Al comienzo - CURSO PARA GERENTES DE PROYECTOS - Inmediatamente despus del Curso Genexus - CLIENT/SERVER - Despus del Curso Genexus (si corresponde) - DESARROLLO DE APLICACIONES PARA INTERNET - Despus del Curso Genexus (si corresponde) - WORKFLOW - Despus del Curso Genexus (si corresponde) GERENTE DE INFORMTICA - TEORICO DEL CURSO GENEXUS PARTE 1- Al comienzo - CURSO PARA GERENTES DE PROYECTOS- Despus del terico del Curso Genexus Parte1
Introduccin Terica
10
REALIDAD
Herramientas y Metodologas
?
BASE DE DATOS PROGRAMAS Desarrollo y Mantenimiento
Nuestra tarea como profesionales de la informtica es desarrollar y mantener aplicaciones para apoyar al usuario en su actividad final. Para realizar esta tarea se han instrumentado diferentes herrramientas y metodologas. Con GeneXus se desarrollan aplicaciones aplicando una metodologa que tiene un enfoque muy diferente al de las metodologas mas comunmente utilizadas. Aprender a utilizarlo adecuadamente va ms alla de conocer el lenguaje de especificacin y lo ms importante es el aprendizaje de una nueva metodologa 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 obtencin del conocimiento de la realidad. Cmo 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 compartirn la afirmacin de que cada usuario conoce muy bien los objetos con los que trabaja cotidianamente, conoce claramente la informacin que se maneja en ellos, que reglas deben seguirse y que clculos deben realizarse. Por lo tanto, utilizar estas visiones de los objetos de su realidad como fuente de informacin parece muy razonable. Se ha demostrado con mucha rigurosidad que es posible obtener un modelo de datos a partir de la sntesis de visiones, por lo que nuestro problema se ha reducido a un problema matemtico ya que si conseguimos describir adecuadamente estas visiones podremos obtener mediante Ingenieria Inversa el modelo de datos. Este mtodo que se conoce como sntesis de visiones cannicas. Este es el punto de partida de la metodologa 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
Comparacin de Metodologas
Es bueno, para fijar ideas, comparar la metodologa utilizada por GeneXus conocida como Metodologa Incremental con las metodologas tradicionales ms utilizadas actualmente. Algunos de los ejemplos de estas metodologas son: Anlisis Estructurado, Ingeniera de la Informacin, Anlisis Escencial. Estas metodologas son diferentes entre s, pero en todos los casos, separan el anlisis de los datos del de los procesos. Veremos un esquema general que podra aplicarse a cualquiera de stas metodologas y estudiaremos sus problemas.
13
Metodologa Tradicional
14
REALIDAD
ANALISIS DE DATOS
BASE DE DATOS
ANALISIS FUNCIONAL
GENERACION/ INTERPRETACION ESPECIFICACION FUNCIONAL PROGRAMACION
PROGRAMAS
La primera tarea, generalmente, es el anlisis 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 nmero de objetos y relaciones hacen que esta tarea sea extremadamente compleja. Debido a la complejidad de la construccin de un sistema integrado,lo que se hace normalmente es dividirlo en mdulos, 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 mdulos operan sin una real integracin, lo que hace que exista informacin redundante y como consecuencia todo intento de buscar informacin fuera del entorno de cada aplicacin resulte imposible o por lo menos peligroso.
15
En caso de que desearamos posteriormente realizar la integracin de esos mdulos es necesario realizar modificaciones al modelo de datos (lo que a pesar de la complejidad podramos calificar como posible), pero las modificaciones que deberemos realizar en los programas tienen un costo tan grande que hacen inviable la realizacin de la integracin. La empresa tendr de esta forma resueltos sus problemas operativos, pero luego aparecern con mucha claridad los problemas de la carencia de informacin que permitan orientar la gestin y la toma de decisiones de alto nivel, ya que la informacin que se necesita es en general de naturaleza corporativa. En la medida que nos orientamos cada vez ms 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 diseo 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 creacin de sistemas corporativos, brindando herramientas y una metologa que hagan posible la realizacin de esta tarea. Continuando con el proceso de desarrollo en una metodologa tradicional, luego de obtener el modelo de datos se pasa a disear la base de datos. Podemos ver que entre un buen modelo de datos, y el diseo de la base de datos necesaria para soportarlo, existe una transformacin 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 aplicacin, porque describe los datos, pero no los comportamientos. Se recurre a una tarea generalmente llamada Anlisis Funcional, donde se estudia la empresa desde el punto de vista de las funciones y que tiene como resultado una Especificacin Funcional. El producto de la funcin anterior es la Especificacin Funcional. Sera deseable que esta Especificacin Funcional fuera independiente de la Especificacin de Datos. Pero esto no es lo comn en las metodologas estudiadas. Las especificaciones producidas son file dependents y, en consecuencia, modificaciones en el diseo 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 ms usadas se destacan la programacin en lenguajes de 3a. generacin, y en lenguajes de 4a. generacin. Lenguajes de 3a. Generacin Lenguajes de bajo nivel como pueden ser COBOL, RPG, C, PASCAL, ADA, FORTRAN. Lenguajes de 4a. Generacin Lenguajes de programacin de alto nivel como pueden ser CA IDEAL, INFORMIX 4GL, NATURAL 2, PROGRESS, etc.. Desde un punto de vista conceptual, ambos casos son idnticos. En ambos el analista debe estudiar el problema, transformarlo en un algoritmo y codificar dicho algoritmo en el lenguaje de programacin. Sin embargo, existe una fuerte diferencia: en los lenguajes de 4a. generacin se escribe mucho menos (probablemente 10 veces menos) y, como consecuencia, la productividad es mucho mayor y el nmero de errores cometidos es mucho menor. Podra argumentarse en contrario, que se pierde flexibilidad con estas herramientas, lo que es cierto en trminos tericos, pero es irrelevante en trminos prcticos, dado que hoy estas herramientas estn dotadas de primitivas que permiten complementar su cdigo, 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. generacin 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 utilizacin de un generador que es una herramienta que puede interpretar la especificacin funcional, (que obviamente debe ser totalmente rigurosa), y producir automticamente 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 codificacin procedural alguna). Algunos ejemplos son ADELIA, AS/SET, LANSA, SYNON, TELON, etc..Existe otra categora de herramientas conceptualmente idntica: la de aquellas que, simplemente, interpretan la especificacin, como por ejemplo: MAGIC y SAPIENS. La programacin en ambos casos es totalmente automtica, por lo que el aumento de productividad sobre las herramientas de 3a. generacin es muy grande.
17
Podra argumentarse en contrario, como a menudo se ha hecho con las herramientas de 4a. generacin, que se pierde flexibilidad con estas herramientas, lo que es cierto en trminos tericos, pero es irrelevante en trminos prcticos, dado que, hoy, estas herramientas estn dotadas de Lenguajes de Diagramas de Accin, (en la prctica lenguajes de 4a. generacin), que permiten complementar su cdigo, 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 tambin a las aplicaciones generadas mediante estas herramientas. Como consecuencia, los Generadores y los Interpretadores (como los lenguajes de 4a. generacin) ayudan bastante poco en la tarea de mantenimiento. Resumiendo aqu las tres opciones vistas: Lenguajes de 3a. Generacin Baja productividad en el desarrollo Lenguajes de 4a. Generacin 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 evitara este problema: PUEDE OBTENERSE UNA BASE DE DATOS ESTABLE. Lamentablemente, este postulado es falso, y sobran los contraejemplos que lo demuestran.
18
Metodologa
Los fundadores de ARTech han desarrollado una amplia actividad de consultora internacional en diseo de grandes bases de datos. Cuando se comenzaron a utilizar verdaderos modelos corporativos, que normalmente poseen cientos de tablas, les qued claro que no deba perderse ms tiempo buscando algo que no existe: las bases de datos estables. Luego de importantes investigaciones, desarrollaron una teora, organizaron una metodologa e implementaron una herramienta para posibilitar el desarrollo incremental y permitir la convivencia con las bases de datos reales (inestables), a costo mnimo.
19
REALIDAD
DESCRIPCION DE OBJETOS
Desarrollo con
Utilizando GENEXUS, la tarea bsica del analista es la descripcin de la realidad. Slo el hombre podra desarrollar esta tarea, ya que slo 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 travs de tareas de bajo nivel como son: disear archivos, normalizar, disear 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 automticamente tanto los programas de creacin / reorganizacin de la base de datos como los programas de la aplicacin. El trmino Base de Conocimiento hace referencia a la capacidad de reutilizar en forma automtica el conocimiento almacenado y sobre todo a la capacidad de realizar inferencias que permiten obtener ms conocimiento.
21
REALIDAD
ANALISIS DE DATOS DESCRIPCION DE OBJETOS
BASE DE DATOS
BASE DE CONOCIMIENTO
ANALISIS FUNCIONAL
Comparacin de Metodologas
ESPECIFICACION FUNCIONAL
GENERACION/ INTERPRETACION
PROGRAMAS PROGRAMACION
Como se ha visto, existen varios caminos para la implementacin de aplicaciones: 1. Programacin utilizando lenguaje de 3a. generacin. 2. Programacin utilizando lenguajes de 4a. generacin 3. Generacin / interpretacin automtica de la especificacin 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), slo se consigue con el desarrollo incremental.
22
Descripcin 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 bsicos:
TRANSACCIONES Las transacciones permiten definir los objetos de la realidad. La mayor parte de las transacciones pueden ser identificadas prestando atencin a las entidades que el usuario menciona (por ej. Clientes, Proveedores, Artculos). A partir de las transacciones Genexus infiere el diseo de la base de datos. PROCEDIMIENTOS Procesos no interactivos de actualizacin de la base de datos (procesos batch). REPORTES Recuperan informacin 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 mltiples usos. MENUES Objetos organizadores del resto.
23
Sistematizacin del conocimiento
Transacciones (TRNs)
Reportes (RPTs)
Procedimientos (PROCs)
Work Panels (WKPs)
Menues (MNUs)
Base de Conocimiento Base de Conocimiento
Veamos ahora con ms detalle el proceso de desarrollo de una aplicacin 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 creacin y/o de reorganizacin de la base de datos. Los programas de la aplicacin. Los anlisis 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 Datos
A partir del conocimiento especificado a travs de las transacciones, GENEXUS disea el modelo de datos normalizado (en 3a. forma normal).
25
Creacin de la Base de Datos

Base de Datos
Programas Generacin BD
GENEXUS genera automticamente los programas necesarios para crear la base de datos, y la crea mediante ellos.
26
Generacin de los Programas de la Aplicacin

Base de Datos
Programas de Aplicacion (TRN, RPT, PROC, WKP y MNU)
GENEXUS genera automticamente, a partir de la Base de Conocimiento, los programas de la aplicacin.
27
Resultado final en la Etapa de Desarrollo

Base de Datos
Aplicaciones
En este estado , la aplicacin est pronta.
28
Las Visiones de los Usuarios Cambian

Nuevas Transacciones Nuevos Reportes Nuevos Procedimientos Nuevos Work Panels Nuevos Menues
Base de Datos
Nueva Base de Datos
Como se ha dicho, durante el ciclo de vida de la aplicacin, existen muchas modificaciones. Ante cambios en las visiones de usuarios, GENEXUS disea la nueva base de datos.
29
Anlisis de Impacto Totalmente Automtico

Anlisis de impacto
Base de Datos
Nueva Base de Datos
Algunas veces, la nueva base de datos coincide con la anterior, en cuyo caso, todos los programas existentes seguirn siendo vlidos. Otras veces, existen cambios en la base de datos. El anlisis de impacto de los cambios nos informa si debe reorganizarse la base de datos, cmo debe ser hecha esa reorganizacin y, los eventuales problemas que esa reorganizacin podra ocasionar. Una vez analizado el anlisis de impacto, el analista resolver efectuar la reorganizacin o renunciar a ella volviendo a la situacin anterior.
30
Generacin de Programas de Reorganizacin de la Base de Datos

Programas de Reorganiz.
Base de Datos
Nueva Base de Datos
Si el analista ha dado el visto bueno a la reorganizacin, GENEXUS genera automticamente los programas necesarios para esa reorganizacin. 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 reorganizacin consiste entonces, en ejecutar esos programas. En realidad es de esperar que tengan muchas tablas comunes, que no se modificarn en la reorganizacin.
31
Anlisis Automtico del Impacto de los cambios sobre los Programas

Anlisis de impacto
Nueva Base de Datos
Nuevos Programas de Aplicacion (TRN, RPT, PROC, WKP y MNU)
32
Generacin Automtica de Nuevos programas

Generacin de nuevos Programas
Nueva Base de Datos
GENEXUS genera /regenera automticamente los programas necesarios.
33
Nueva Realidad , con los cambios en la Aplicacin

Nueva Base de Datos
Aplicaciones
Ahora se tienen las nuevas aplicaciones. El ciclo de mantenimiento est completo.
34
Mltiples Plataformas de ejecucin a partir de una nica especificacin

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
Metodologa Incremental
Consiste en construir una aplicacin mediante aproximaciones sucesivas.
DEFINICION INICIAL
La construccin automtica de la Base de Datos y programas a partir de una nica fuente de especificacin permitir a GENEXUS aplicar una metodologa de desarrollo que podramos llamar Metodologa Incremental, ya que el proceso se realiza mediante aproximaciones sucesivas. En cada momento desarrollamos la aplicacin con el conocimiento que tenemos y luego cuando pasamos a tener ms (o simplemente diferente) conocimiento, GENEXUS se ocupar de hacer automticamente todas las adaptaciones en la base de datos y programas. El incrementar una aplicacin 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 haran inviable la aplicacin de este mtodo si no fueran resueltos automticamente.
36
Ciclos Diseo-Prototipo y Diseo-Produccin
Diseo
Prototipo
Produccin
El trabajo consiste de dos ciclos: el Ciclo de Prototipacin y el Ciclo de Produccin.
Ciclo de Prototipacin: El diseador recorrer repetidamente el bucle Diseo-Prototipo durante la fase de diseo, construyendo y probando sucesivos prototipos del modelo. Ciclo de Produccin: Por el contrario, pasar menos frecuentemente al bucle de DiseoProduccin, ya que la generacin del sistema se realiza solamente cuando el prototipo ha sido totalmente aprobado, o luego de haber instrumentado y probado algn cambio.
37
Prototipacin Integral en PC
MODELO DE LA REALIDAD
Construccin Automtica
Usuario probando todos los detalles de la aplicacin
BASE DE DATOS
PROGRAMAS
La construccin automtica del soporte computacional nos dar la gran posiblidad de crear prototipos. Verdaderos prototipos ! , ya que estos tendrn un funcionamiento equivalente al del sistema en produccin real, permitiendo que se pruebe hasta el ltimo detalle de la aplicacin. Los resultados que todos quieren ver, estn en forma de programas ejecutando, lo que no es posible sin la utilizacin de prototipos.
38
Ventajas de la Prototipacin
Permite ver resultados en forma temprana Permite el seguimiento de los requerimientos del usuario Deteccin de errores en forma temprana Logra el compromiso de los usuarios con el desarrollo Sistemas de mejor calidad
Toda comunicacin 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, adems, la implementacin de sistemas es, habitualmente,una tarea que insume bastante tiempo. Como muchos de estos problemas slo 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 solucin relativamente insatisfactoria. El impacto de estos problemas disminuira mucho si se consiguiera probar cada especificacin, inmediatamente, y saber cual es la repercusin de cada cambio sobre el resto del sistema.Una primera aproximacin a esto, ofrecida por diversos sistemas, es la posibilidad de mostrar al usuario formatos de pantallas, informes, etc. animados por menes. 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
Emisin del cabezal
Emisin de la Factura
Emisin de una Factura (cuerpo) Proceso de emisin de lneas
Comienzo
Emisin de una lnea
Cdigo Producto Nombre Producto Precio Producto Cantidad Producto Importe Producto
Fin
Fin
Fin
Ahora vamos a concentrarnos en cul es la forma prctica utilizada por GeneXus, para la captura de la realidad de la que tanto hablamos. Jean Dominique Warnier y Ken Orr, formularon una teora acerca de cmo puede ser construida una aplicacin de procesamiento de datos. Algunos de sus enunciados fueron los siguientes: Los datos y los procesos estn estructurados. Todos los procesos son subdivididos en subconjuntos partiendo del nivel ms alto y empleando reglas de subdivisin adecuadas (de manera jerrquica). Todo Proceso tiene un Comienzo, un Cuerpo, y un Final. Esta regla se aplica a la organizacin de datos y resultados. Analicemos por ejemplo un proceso de emisin 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 gestin jerrquica 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 includo 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, sera muy bueno que obtuviera este tipo de relaciones. El no observar esta ley es fuente de confusin, eliminando la claridad y la simplicidad de la organizacin de los datos tanto como la de los procesos.
40
DISEO DE TRANSACCIONES
41
Notacin GeneXus para Transacciones

Ejemplo: Proceso de Emisin de Facturas FacNro* CliCod CliNom FacFch (ProdCod* ProdNom ProdPre ) Cdigo de la factura Cdigo del cliente Nombre del cliente Fecha de la factura Cdigo del producto Nombre del producto Precio del producto
El siguiente paso es encontrar una forma de notacin adecuada para GeneXus. Por ejemplo, una transaccin de emisin de Facturas tendr la siguiente notacin. Cada nivel definir un conjunto de atributos que deben operar en conjunto. Se ingresarn , eliminarn o modificarn conjuntamente en la base de datos. Precisamos entonces encontrar un conjunto de atributos que acte 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 eleccin de estos atributos debemos atender a todas las reglas correspondientes a su definicin. El conjunto de atributos entre parntesis representa la ocurrencia de varios para cada instancia del nivel anterior. En el ejemplo, una factura tiene varios productos.
42
Definicin del diseo 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 obtencin 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 derivaran de la definicin de la transaccin. La definicin de esta primera transaccin a determinado las siguientes dependencias funcionales. FacNro ----> CliCod FacNro ----> CliNom FacNro ----> FacFch Por lo que se definir una tabla con el siguiente diseo FacNro* CliCod CliNom FacFch Tenemos adems las siguientes dependencias funcionales determinadas por el 2do nivel de la transaccin. FacNro, ProdCod ----> ProdNom FacNro, ProdCod ----> ProdPre FacNro, ProdCod ----> FacLinCnt FacNro, ProdCod ----> FacLinImp Que definirn una tabla con el siguiente diseo FacNro * ProdCod* ProdNom ProdPre FacLinCnt FacLinImp
43
Definicin 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 definicin de dos nuevas transacciones: Clientes y Productos han determinado la aparicin de nuevas dependencias funcionales. GeneXus disear 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. Anlogamente 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 integracin de bases de conocimiento
46
Nomenclatura GIK - Nombre del Atributo
Complemento
(texto libre)
Calificador (1 a 3) Calificador (1 a 3) Categora Semntica (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 ms o menos que otros. Lo importante es que es el utilizado por la comunidad de usuarios GeneXus. Esto viabiliza reutilizacin de conocimiento entre ellos. Nombre de atributo> Objeto + Categora + Calificador Objeto, Es el nombre de la transaccin a la que pertenece el atributo. Categora, Es la categora semntica 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 mximo (la implementacin depende de la plataforma). VarChar Permiten almacenar texto de largo variable. Su funcin, en contraposicin al character, es la de optimizar el almacenamiento en la base de datos. Definicin: Varchar(M, N) M es el largo mximo posible que depender del DBMS. Si el largo asignado al atributo es mayor que el soportado por el DBMS se utilizar el mximo 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 combinacin 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 especficamente 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 mnimo soportado por el DBMS y reconocido como fecha vaca 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) sern considerados en cero.
50
Comandos de asignacin
+= -= *= /= Sintaxis: <Variable_o_Atributo> <Comando> <Expresin> Ejemplo: &I += 1 (equivalente a &I = &I + 1)
51
Dominios
Cuando debemos usar dominios? Atributos con la misma definicin No existe relacin entre ellos Ejemplo: Direccin Char 30 Direccin del Cliente Direccin del Banco Dominio
Atributos
El objetivo de los dominios es permitir usar definiciones de atributos genricos y luego poder asociar un atributo con su correspondiente dominio. En el ejemplo, el dominio Direccin es definido como Char de 30. Los atributos direccin del banco y del cliente son asociados a l. Por lo tanto, si en el futuro se cambia la definicin de este dominio, los cambios van a ser automticamente propagados a todos los atributos que pertenezcan a ste. De esta forma los dominios pemiten un mayor nivel de abstraccin en la definicin de la aplicacin.
52
Reglas
Se utilizan para definir el comportamiento de las transacciones. Algunas reglas
Default, Error, Ask, Msg, Asignacin, 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 transaccin. Programacin DECLARATIVA
Segn el Anlisis 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 condicin ( 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 evaluacin La definicin de reglas es una forma DECLARATIVA de definir el comportamiento de la transaccin. 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 segn las dependencias de atributos existentes (en este tema entraremos en detalle mas adelante).
53
Toolbar de Controles
Para el diseo de Pantallas Atributo / Variable Texto Lnea Recuadro Subfile Botn Bitmap Tab Control Print Block
Se utiliza para disear la pantalla (form) en forma grfica. Mientras se est diseando un form (de TRNs, WKPs 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 pginas.
Default: Dos pginas Agregar o eliminar pginas:
Botn derecho sobre el Tab Control
Pgina
Ttulo Area til
Check Box de Hide Tabs ==> Para diseo de Wizards
Slo para los generadores visuales.
Un Tab Control tiene una o varias pginas (por defecto tiene dos). Cada pgina tiene un ttulo y un rea til, es decir donde se ponen los controles de esa pgina. Slo una de las pginas puede estar activa a la vez y es la que se puede ver. Del resto slo se ver su ttulo. Las opciones Edit/Add Tab Page y Edit/Remove Tab Page son para agregar y eliminar pginas respectivamente. Puede accederse tambin a estas opciones con botn derecho sobre el Tab Control. Hide Tabs Para mostrar slo la pgina activa y no mostrar los tabs. Util para la definicin de Wizards.
55
Generacin de HELP Tipo Windows

Es necesario generar y compilar el Help.
Opcin: 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 ms arriba viene con el Visual Basic/Foxpro/Visual FoxPro y se requiere como mnimo la versin 3.10.505.
56 62
Generacin de HELP Tipo Windows

Botn 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 informacin. La informacin solicitada es la siguiente: Name: Nombre del modelo que se esta creando Type: Tipo de modelo (Prototipo, Produccin, Backup) Language: Idioma (Ingls, Espaol, Portugues, Italiano) Generador: Plataforma en la cual se desea que sean generados los programas (tanto los programas de creacin/reorganizacin de la base de datos, como los programas de aplicacin). 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 botn Preferences permite configurar ciertas propiedades para el modelo (dependiendo del generador elegido, algunas propiedades a configurar seran distintas). El botn DBMS Options permite configurar la informacin requerida para el acceso a la Base de Datos (por ejemplo, Data Source, etc.). El botn Execution permite configurar ciertas propiedades de ejecucin (por ejemplo, donde se encuentra instalado el intrprete). 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 relacin entre la tabla Clientes y Departamentos y tambin entre Clientes y Categoras. La relacin entre dos tablas se determina analizando los atributos que tienen en comn. Por ejemplo, entre las tablas Clientes y Categoras tenemos que el atributo comn es el cdigo de la categora, que es la clave primaria de la tabla Categora. Decimos que la relacin entre ambas tablas es 1-N, que indica que un cliente tiene una categora y una categora tiene N clientes. Tambin es usual decir: . La tabla Categoras est Superordinada a la tabla de Clientes . La tabla de Clientes est Subordinada a la tabla de Categoras Esta relacin implica que la informacin contenida en ambas tablas no es independiente, por lo que es neceario realizar controles para que la informacin sea consistente. A estos controles se les llama de Integridad Referencial y bsicamente 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
Definicin de Indices
Tabla Tipo
Catego Depart Client PK PK PK FK FK
Indice Composicin
CatCod DtoCod CliCod DtoCod CatCod
Definicin de Indices Para hacer eficientes los controles de Integridad, GeneXus crea automticamente ndices, que son vas 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 automticamente a partir de los identificadores de las transacciones. Indice Extranjero (FK): Los ndices extranjeros son utilizados para hacer eficientes los controles de integridad intertablas. Tambin son definidos automticamente. 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 automticamente ya que no se usan para los controles de integridad. En una Base de Datos Relacional los ndices se utilizan slo 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
Definicin 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 relacin N-1 con la tabla extendida determinada hasta el momento.
Los criterios de normalizacin del diseo de la base de datos apuntan a minimizar la posibilidad de inconsistencia en los datos. Una base de datos diseada de esta manera tiene una serie de ventajas importantes (tal es as que actualmente la normalizacin de datos es un standard de diseo) , pero se deben tener en cuenta tambin algunos inconvenientes. El inconv3eniente ms notorio es que los datos se encuentran dispersos en muchas tablas, y por lo tanto cuando se quieren hacer consultas ms o menos complejas a la base de datos se debe consultar una cantidad importante de tablas. As, por ejemplo, para listar las facturas sera necesario consultar las tablas Cabezal y lneas de Facturas, Clientes, Categoras 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: Categora Cliente Factura
Tabla extendida: Categora Cliente Categora Factura Cliente Categora Factura1 Producto Factura Cliente Categora Producto
Factura1
Producto
65
ATRIBUTOS FORMULAS
66
Caractersticas
Relacin entre Atributos, Constantes o Funciones Definicin 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 frmula si su valor se puede calcular a partir del valor de otros atributos. En cada transaccin se puede definir qu atributos son frmulas, pero esta definicin es global (no es local a la transaccin), es decir toda vez que se necesite el atributo se calcula la frmula, tanto en transacciones como en los otros objetos GeneXus. Existe una similitud entre frmulas y asignaciones (regla), incluso la sintxis de definicin es similar. La diferencia entre ambas es que una frmula es GLOBAL (vale para todos los objetos GeneXus que la utilicen), mientras que una asignacin en las reglas es LOCAL (vale slo para la transaccin en la cual fue definida). Cuando un atributo es frmula, ste no est almacenado (a no ser que se lo defina como redundante) y cuando es una Asignacin, por ser esta local, si esta almacenado.
67
Clasificacin
Horizontales
Una o varias expresiones aritmticas condicionales.
Verticales
SUM COUNT
Aggregate / Select
Select Max, Min, Find Aggregate Sum, Count
Frmula Horizontal Los atributos involucrados en la misma deben pertenecer a la tabla extendida del atributo definido como frmula. Frmula Vertical Los atributos involucrados deben pertenecer a la tabla directamente subordinada del atributo definido como frmula. Son incondicionales. Aggregate / Select Pueden navegar sobre cualquier tabla del modelo. Son condicionales.
68
Fmulas Horizontales
Atributo = <Expresin> if <Condicin>; <Expresin> if <Condicin>; : <Expresin> Otherwise;
<Expresin> es una expresin aritmtica que puede involucrar atributos, constantes y funciones. Los atributos que participan de la expresin deben pertenecer a la tabla base y/o a tablas que estn en una relacin N para 1 con la tabla sobre la que se define la frmula (es decir, a la tabla extendida del atributo definido como frmula). El atributo fmula deja de estar almacenado en la tabla y decimos que es un atributo virtual. <Condicin> es la condicin de disparo de la frmula. Cuando se define una frmula horizontal, GeneXus sabe cual es la tabla extendida del atributo que se est definiendo como frmula, y controla que todos los atributos utilizados en dicha frmula se encuentren en ella.
69
Fmulas Horizontales
Ejemplo: TRANSACCION TABLA CliCod* CliCod* CliNom CliNom CliTotCmp CliTotCmp CliTotPgo CliTotPgo CliSdo = CliTotCmp- CliTotPgo
Un atributo puede definirse como fmula cuando su valor se obtiene siempre de un clculo 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 Frmulas y Reglas Frmula La frmula es una definicin 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 transaccin. Cada vez que se mencione el atributo, su valor no se calcular, sino que se tomar directamente de la tabla.
70
Importe de la Lnea de la Factura

FACTURA
FacCod* FacFch CliCod
CLIENTE
CATEGORIA
CatCod* CatDto
FACTURA1
FacCod* ProdCod* FacLinCnt
PRODUCTO
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 frmula horizontal, por lo cual dicho atributo no est almacencado en la tabla Factura1.
71
Frmulas Verticales SUM - COUNT

Sintxis:
AtriFla = SUM(Att) AtriFla = COUNT(Att)
Caractersticas:
Att debe pertenecer a una tabla directamente subordinada a la tabla en la que se encuentra AtriFla. Son incondicionales. Navegacin vertical - Performance
Caractersticas de las Frmulas Verticales SUM - Suma un atributo perteneciente a una tabla directamente subordinada. COUNT - Cuenta las filas de una tabla directamente subordinada. Estas frmulas 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 relacin 1 a N). Se consideran todas las filas que pertenecen a la relacin ya que no se pueden establecer condiciones. Se resuelve mediante una navegacin vertical, de ah el nombre Frmulas Verticales Performance El hecho que la frmula no este almacenada, puede ocasionar en algunos casos, problemas de performance debido al tiempo que puede demorar el reclculo. Esto depender de la cantidad de registros que se sumen / cuenten. Para evitar este inconveniente, Genexus provee la posibilidad de definir a la frmula vertical como REDUNDANTE. En este caso la frmula se almacena en la Base de Datos y no es necesario recalcularla cada vez que se use. Profundizaremos en este tema ms adelante.
72
Frmulas Verticales SUM - COUNT

Clculo del subtotal de la Factura Factura: FacNro* FacFch CliCod FacSubTot = SUM(FacLinImp) Factura1: FacNro* ProdCod* FacLinCnt FacLinImp = FacLinCnt * ProdPre FacSubTot y FacLinImp no estn almacenados. Equivalencia entre SUM redundante y regla ADD
Factura
1
Factura1
Precisamos calcular ahora el subtotal de las lneas 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 lneas. Estas tablas estn en una relacin de 1 a N, por lo que no podemos utilizar una frmula horizontal. Precisamos una frmula que recorra todas las lneas de la factura y las sume, utilizamos para esto una frmula SUM( ) perteneciente a las llamadas Frmulas Verticales. Se puede decir que un SUM redundante es equivalente a la regla ADD.
73
Frmulas Verticales
Slo se puede definir entre atributos de tablas directamente subordinadas
N 1
FACTURA FacSubTot = SUM(FacLinImp) 1
CLIENTE
SUM(att) No permitido
FacLinImp
FACTURA1
SUM (att)
Puede ser Frmula
Slo se puede definir entre atributos de tablas directamente subordinadas. Dentro de una frmula vertical no se puede mencionar directa o indirectamente una frmula AGGREGATE/SELECT. El atributo mencionado en la frmula COUNT no puede formar parte de ninguna clave . El atributo mencionado en la frmula SUM puede ser frmula. Para frmulas de frmulas GeneXus determina cul es el orden de evaluacin correspondiente.
74
Frmulas Aggregate/Select
Son frmulas que permiten buscar, sumar, contar atributos que cumplan determinadas condiciones, en cualquier tabla del modelo.
Aggregate Sum Count Select Max Min Find
Frmulas Aggregate Sum .- Suma condicionalmente atributos de cualquier tabla del modelo
Count .- Cuenta condicionalmente filas de cualquier tabla del modelo
Frmulas Select Find .-Buscar el valor de un atributo en determinadas condiciones Max .-Buscar el mximo valor de un atributo en determinadas condiciones Min .-Buscar el mnimo valor de un atributo en determinadas condiciones
75
Frmulas Aggregate/Select
Sintxis
atrib = Sum | Count (<att>, <cond. bsq.>, <def>) atrib = Max | Min(<att>, <cond. bsq. >, <def>, <ret>) atrib = Find(<att>, <cond. bsq.>, <def>)
atrib: es el atributo que se define como frmula Sum ( atributo a ser sumado, condiciones que debe cumplir, valor por defecto ) Max ( atributo a maximizar, condiciones de maximizacin, 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 bsqueda, valor por defecto en caso de no encontrar quien cumpla con las condiciones)
76
Frmulas 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 condicin Atributo = Sum | Count (<Atributo Sumado o Contado>,<Condicin para sumar o contar> , <valor de retorno por defecto>) IF <Condicin de disparo> A diferencia de las Frmulas SUM y COUNT Verticales no es necesario que estn en una relacin de subordinacin Para distinguirlas en los listados Verticales - SUM y COUNT todas las letras en maysculas Aggregate - Sum y Count slo la primer letra con mayscula Los siguientes ejemplos de frmulas Aggregate y frmulas Select, se incluyen como documentacin y no necesariamente se harn 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. Sintxis: Atributo=Find(<Atributo a buscar>, <Condicin de bsqueda>, <Valor por defecto>) IF <Condicin de disparo) Ejemplo de uso de Find ( ): El atributo DocCotDolar obtiene la cotizacin del dolar del da. La tabla de cotizaciones no tiene ninguna relacin 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 funcin determina el mximo valor de un atributo en una tabla. Obtenido este valor, que corresponder a una determinada fila, la funcin devuelve el valor de cualquier atributo de dicha fila. Sintxis: MAX(<Atributo a Maximizar>, <Condicin de Maximizacin>, <Valor por defecto>, <Atributo a Devolver>) IF <Condicin de ejecucin> Atributo a Maximizar - Debe estar almacenado en la tabla en la que se busca (Tabla de llegada), es decir no puede ser un atributo frmula o pertenecer a su tabla extendida. Condicin de bsqueda - 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 bsqueda (Tabla de llegada). Atributo a devolver - Atributo a devolver para asignar al atributo frmula, debe estar almacenado en la tabla de bsqueda. Condicin 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 (mxima) cotizacin del dlar anterior a la fecha del documento. Documentos DocNro* DocFch DocImp DocImpDolar DocCotDolar 80 Cotizaciones MonCod* MonFch* MonCot
Atributo a maximizar MonFch Condicin ........................ MonCod = U$S y el mximo 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 cotizacin del da 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>, <Condicin de minimizacin>, <Valor por defecto>, <Atributo a Devolver>) IF <Condicin de disparo> Esta funcin determina el mnino valor de un atributo en una tabla. Obtenido este valor, que corresponder a una determinada fila, la funcin devuelve el valor de cualquier atributo de dicha fila. Ejemplo de uso de la funcin Min: Se quiere obtener la cotizacin del dlar para el da 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 cotizacin del da 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 frmulas Aggregate/Select

Atributo = Find(<Atributo a buscar>, <Condicin de bsqueda>, <Valor por defecto>) IF <Condicin de disparo> En la definicin de la frmula intervienen atributos de varias tablas: La tabla en la que est definido el atributo frmula (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 frmulas Verticales como las frmulas Agregate/Select, implican la realizacin de navegaciones en la Base de Datos, por lo que es importante considerar la forma en que esto es realizado. Las frmulas 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 lnea. Las frmulas Aggregate/Select en cambio, recorren cada vez los registros para hacer el reclculo. Las frmulas 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 segn la fecha de la Factura.
Transaccin Productos ProdCod* ProdDsc (ProdFch* ProdPre) Transaccin Factura FacNro* CliCod FacTot FacFch (ProdCod* FacProdPre FacLinCnt FacLinImp)
Atributo = MAX(Atributo a Maximizar), (Condicin de Maximizacin), (Valor por defecto), (Atributo a devolver) IF (Condicin de ejecucin)
Uso de la Frmula Max( ) para buscar el precio del producto segn la fecha de la factura Definimos la transaccin de productos de tal forma de guardar el histrico 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 lneas de la factura el atributo ProdCod. No podemos incluir ProdFch debido a que no podramos saber que valor darle a la fecha para poder heredar directamente el ProdPre. Definimos el atributo FacProdPre y buscaremos con una frmula el precio correspondiente de acuerdo a la fecha de factura. Buscaremos el precio de fecha mxima anterior a la fecha de factura. La frmula quedara: 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 Cdigo 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 Condicin....................... Factura1.ProdCod = Producto1.ProdCod (cond. implcita). El mximo valor de ProdFch <= FacFch (cond. explcita). Atributo a devolver........ ProdPre Valor por defecto.............0 , si no se encuentra ningn registro que cumpla la condicin.
85
Ejemplo
Transaccin de Cotizaciones MonId* CotMes* MonDsc (CotDia* CotImp) Transaccin de Asientos AsiNro* AsiFch AsiMes AsiDia (AsiIdLin* MonId AsiImpME AsiImpNS AsiTipDH CtaId AsiFndCot)
Hacer lo siguiente:
A. Buscar la cotizacin 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.
Transaccin de Cotizaciones: MonId* CotMes* MonDsc (CotDia* CotImp) Transaccin 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.
Transaccin 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 Cotizacin, se toma la ltima ingresada) if null (AsiFndCot) .and. MonId <> NS;
88
1. Condiciones involucradas en una

Frmula Aggregate Select
Condicin de Bsqueda Es la condicin a la cual est sujeta la bsqueda. Condicin de Disparo Es la condicin que determina si la frmula se ejecuta.
89
2. Inferencias en el caso de una

Frmula Aggregate Select
La condicin de bsqueda queda determinada por: La condicin explicitada como segundo parmetro. Atributos que quedan instanciados por el ambiente en el que se dispara la Frmula :
Interseccin de la tabla extendida del atributo definido como frmula (tabla de partida) y la tabla sobre la cual se est resolviendo la frmula (tabla de llegada).
90
En el ejemplo:
Transaccin de Cotizaciones: MonId* CotMes* MonDsc (CotDia* CotImp) Transaccin 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 frmula AsiFndCot, est implcita la condicin de que Asiento1.MonId = Cotizac1.MonId Esto se refleja en la navegacin como Given: MonId
91
3.Cmo se determina la tabla sobre la cual efectuar la bsqueda (tabla de llegada)

Atributo de Bsqueda Atributos que estn en la condicin y que no pertenecen a la tabla extendida del Atributo Frmula Atributo de Retorno De otra forma: <Atr.Frm.> - Frmula Invlida
Es importante aclarar que los atributos involucrados en la frmula Aggregate Select y pertenecientes a la tabla de llegada, deben estar ALMACENADOS en la misma. Es decir, que no pueden ser frmula ni pertenecer a la tabla extendida de la tabla de llegada.
92
Ejemplo de determinacin 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 determinacin de la tabla sobre la cual buscar:

Deben pertenecer fsicamente 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. Frmulas Aggregate Select no pueden participar en frmulas SUM y COUNT simples

No se permite definir una frmula SUM que suma un atributo que es una Aggegate/Select o depende de ella. Ejemplo: FacProdPre FacLinImp FacSubTot = frmula MAX = FacLinCnt * FacProdPre = SUM (FacLinImp)
Para resolver esto, se debera almacenar el valor de FacProdPre en otro atributo, pues las Frmulas Aggregate Select NO PUEDEN SER DEFINIDAS REDUNDANTES. O utilizar la regla ADD en lugar del SUM vertical
95
5. Dependencia fsica de las frmulas Aggregate Select

Las Frmulas Aggregate Select dependen de la insercin, actualizacin o eliminacin fsica del o los registros que involucran. EJEMPLO : Transaccin 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 lnea no recorre toda la tabla de nuevo, a diferencia del Count Aggregate/Select. Las frmulas verticales cuentan o suman los valores que estan en "memoria". Las aggregate/select no.
96
Diferencias entre frmulas aggregate select y frmulas verticales

1. Las frmulas agg/sel actan sobre cualquier tabla de la base de datos y las frmulas verticales solamente sobre tablas directamente subordinadas. 2. En las frmulas agg/sel se pueden especificar condiciones de bsqueda. En las verticales no. 3. Las frmulas verticales cuentan o suman los valores que estan en "memoria". Las aggregate/select no. 4. Las frmulas verticales cuentan o suman atributos que pueden ser frmulas (pero esta frmula no puede ser agg/sel ni involucrar en su definicin una frmula agg/sel). Los atributos mencionados en las frmulas aggregate/select y pertenecientes a la tabla de llegada deben estar ALMACENADOS FISICAMENTE en la tabla de llegada 5. Las frmulas agg/sel no se pueden definir como redundantes. Las verticales s.
97
COMUNICACION ENTRE OBJETOS
98
Objetos GeneXus
TRN
RPT
PROC
MENU
WKP
Comunicacin entre objetos GeneXus Una de las caractersticas 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 informacin entre ellos a travs de parmetros que se declaran en cada uno.
99
Reglas y Comandos para implementar la comunicacin
CALL UDP (User defined Procedure) UDF (User defined Function)
Para implementar la comunicacin 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, permitindose pasar parmetros si stos son necesarios. Los parmetros especificados son de entrada/salida. UDP, UDF - Se llama a un objeto GeneXus o a un programa externo, al cual se le pasarn los parmetros necesarios y retornar un valor, que es resultado de la ejecucin de dicho objeto o programa. La diferencia entre los UDP y UDF es que los programas llamados por la funcin UDF no deben abrir ninguna tabla, mientras que los llamados por la funcin UDP s lo pueden hacer. Esta diferencia existe SOLAMENTE en el generador Fxp 2.6 y VFP (en los dems 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 ms rpido. Las UDP restauran las tablas al volver y se usan para llamar a programas que abren tablas.
100
Cul es la convencin usuada para el nombre de los objetos GeneXus en las llamadas?
Objeto Prefijo Transaccin T Procedimiento P Reportes R Work Panel W Men M Web Panels H
El nombre se trunca a: 7 caracteres 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 ms 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 habra que poner en las Rules de la Transaccin Factura es: call(RImpFac, FacNro) if insert .and. after(TRN); donde ImpFac es el nombre del Report que imprime la factura recibida como parmetro.
101
Call
Sintxis En regla de Transacciones: call(nom-prog,par1,...,par2) if (condicin); En layout de los reports, program source de los procedures, eventos de Work Panel y eventos de Transacciones: if (condicin) 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 (segn 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 transaccin, se va a tomar en cuenta en el rbol de evaluacin 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 funcin declarar los parmetros en el objeto llamado. Sintxis: 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 implcito)
Con la regla PARM se declaran los parmetros que recibe un objeto GeneXus, estos parmetros son posicionales, se deben escribir en el mismo orden, la misma cantidad y el mismo tipo que los indicados en el CALL. Los parmetros especificados en la regla parm, cuando se est invocando al objeto con el CALL, son de entrada/salida.
103
Udp
Sintxis En reglas de Transacciones <Att|&var> = Udp(nom-prog,par1,...,parn) if (condicin); En Frmulas: <Att> = Udp(nom-prog,par1,...,parn) if (condicin); 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 (condicin) <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 frmulas, 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 parmetro 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 parmetros con la regla Parm. A diferencia con los calls, el programa llamado siempre va a tener un parmetro como mnimo (el parmetro de retorno). Ejemplo: Tenemos un procedimiento que calcula la calificacin de un funcionario FunValCalificacion = Udp(PCalif ,FunId, FunFchIngreso ); En el procedimiento PCalif, tenemos las siguiente regla parm: parm( &funid, &funfching, &ValorRetorno ); Al terminar el clculo, en el program source del procedimiento se asigna a la variable &ValorRetorno el valor de la calificacin del funcionario, y dicho valor es el devuelto por la llamada y asignado al atributo FunValCalificacion. El ltimo parmetro especificado en la regla parm, cuando se est invocando al objeto con UDP es de salida. El protocolo para el resto de los parmetros depende de la implementacin, NO se debe esperar que sean de entrada/salida.
105
Ejemplo:
FacImpDesc = udp(Pcaldto, FacTot,FacCat)

En procedimiento PCaldto: parm(&tot, &cat, &desc);
Parmetro 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 parmetro en la regla parm del objeto llamado y no debe ser especifificado en la invocacin de la UDP. En el ejemplo, se utiliza una funcin 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 cuestin, pero dicho atributo o variable no es pasado como parmetro 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
Sintxis : Sub 'RoutineName //cuerpo de la subrutina EndSub
No se permite el pasaje de parmetros. 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
Sintxis : 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 evaluacin
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 Evaluacin El conjunto de reglas y frmulas han sido definidas sin especificar su secuencia de ejecucin; pero en el momento de generar el programa GeneXus deber determinar esta secuencia. GeneXus determina las dependencias existentes entre estas reglas y frmulas, construyndose lgicamente un rbol de dependencia que determinar la secuencia de evaluacin. Podemos imaginar que el rbol se ejecuta de abajo hacia arriba, cada vez que cambia algn 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 lnea, y a partir de esto el Sub-Total, y el Descuento y el Total y la actualizacin del Total de compras del cliente. Tambin vinculado con la cantidad est el Stock, y se disparar tambin 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 decamos 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 Evaluacin, dejndose todo en el estado anterior a producirse el error. El error detiene cualquier actualizacin 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 mayora de los casos el orden de ejecucin 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 evaluacin vemos que las dependencias entre las reglas y frmulas determinan que cada vez que cambie el importe, se cambiar el total calculado que es parte de la condicin de la regla Error. Esta condicin se va a cumplir (total calculado <> total ingresado) ya para la primera lnea 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 evaluacin 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 Evaluacin, dejndose todo en el estado anterior a producirse el error. El error detiene cualquier actualizacin a la base de datos. Estos casos no son muy frecuentes, pero se dan y hay que conocerlos. A continuacin se describirn 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 lgicas que devuelven .T. or .F. Level Sintxis: 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 parmetro no sera necesario especificar el nivel ya que se tomaria el nivel del parmetro. Ejemplo: Call(Pxxx, CliCod) if Insert ; After Sintxis: After(<Event>) Donde <Event> puede ser : <Att> | <Action> | Level(<Att>) | Trn | Confirm After(Attribute) Ejemplo: A = B * C if After(C); Ejecuta la regla despus de aceptar el valor del atributo C. La condicin After(Att) tiene el mismo efecto que la condicin Level(Att) en el entorno AS/400, ya que la transmisin 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 despus de haber confirmado los datos del nivel asociado pero antes de haber realizado la actualizacin. After(Insert) After(Delete) After(Update) Se dispara despus de haber insertado, actualizado o eliminado el registro de la tabla base del nivel. Ejemplo: La siguiente transaccin llama a un procedimiento que realiza la impresin de los datos de un cliente. El procedimiento setear el atributo CliSts, para indicar que se realiz la impresin. Transaccin Clientes CliCod* Cdigo 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 an 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 despus de procesar todos los datos de la transaccin, es decir, el primer nivel y todos los subordinados. En el AS/400 la regla es disparada despus 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 validacin, 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 parmetros son de ida/vuelta del punto de vista del lenguaje, pero del punto de vista del especificador son slamente de ida. Es decir, para determinar el rbol de evaluacin de reglas y frmulas, Genexus considera a los parmetros de los calls como de ida. En el ejemplo 2, si se escribieran las reglas en orden inverso, Genexus en el rbol de evaluacin de eventos, las considerara en dicho rden (no determinara que la regla error vaya despus del call, porque los parmetros 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 disparara. Si en lugar de utilizar CALL utilizramos UDP (siendo &flag el campo de salida) el error se disparara despus del UDP, sea cual sea el orden de definicin, ya que &flag sera claramente el output de la UDP.
118
Ejemplo de transaccion de dos niveles

Level CabFac .....................................> reglas stand-alone Trasmit Screen ....................................> evaluacin de reglas y frmulas segn rbol Confirm Screen ....................................> reglas after(confirm)
Insert/Update/Delete
....................................> reglas after(insert/update/delete) Level LinFac Trasmit Screen ..........................> evaluacin de reglas y frmulas segn 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 ................................> evaluacin de reglas after (trn) EndLevel
Insert/Update/Delete
119
Eventos en las Transacciones

El cdigo permanece ocioso hasta que ocurre un evento al cual est relacionado Evento = Accin reconocida por un objeto y a la cual se le puede asociar un cdigo ejecutable
Programacin Dirigida por Eventos En las transacciones se permite la Programacin Dirigida por Eventos, que es un estilo de programacin en el que existe cdigo 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 cdigo asociado a cada evento posible, el cual se disparar slo si el evento se produce. Por ejemplo, puede haber un cdigo asociado al evento de presionar una tecla (Por ejemplo <Enter>), que se activar cuando el usuario decida presionar esa tecla. La programacin dentro del evento sigue un estilo procedural.
120
Eventos explcitos 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 opcin del men o se presiona una tecla de funcin/botn. After Trn: Es un evento del sistema y es activado una vez que la transaccin 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
Sintxis: Event Start EndEvent
Se ejecuta al principio del programa.
Ejemplo: Guardar el inicio de ejecucin del programa Event Start &entrada=Time( ) EndEvent
Generalmente es utilizado para la asignacin de variables y parmetros que interesa evaluar una sola vez en la ejecucin del programa.
122
Evento Start
Ejemplos: 1.Event Start &Mes1 = Enero EndEvent
2.-
En el Evento Start de la transaccin de Facturas : Event Start call(PFindCli,&today, CliCod) EndEvent Parmetro de salida. Se instancia el Cliente. Se accede slo 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 parmetro CliCod es de salida, es decir vuelve cargado del procedimiento. En este caso, queda instanciado el Cliente, o sea que acta como filtro. En otras palabras, el comportamiento es el mismo que si se hubiera recibido en la transaccin como parmetro al cdigo de cliente en el propio atributo (CliCod). Es decir, parm(CliCod);
123
Eventos del Usuario

Sintxis: 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 funcin asociada o el botn correspondiente. Level <att> - El evento se activa slo 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 funcin 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 transaccin.
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 evaluacin entre reglas y eventos de una transaccin, la regla se evala primero.
Eventos: Event After trn . return End event Rules: call(tvenfac,FctCod) if after(trn);
Esta convencin toma efecto cuando se presenta un conflicto en el momento de evaluacin de las reglas y eventos. Slo el evento after trn presenta ese caso. El evento Start no entra en conflicto con las reglas llamadas stand-alone ya que conceptualmente su evaluacin son en diferentes momentos. Las reglas stand-alone se evalan en el primer nivel antes del despliege de la pantalla. El evento Start se evala al comenzar el programa.
127
Ejemplos de uso de Eventos en las Transacciones

1. Desplegar el nombre de la organizacin en la pantalla al comienzo de la transaccin: Event Start &Orgnom = udp(PNombre, Orgcod) Endevent 2. Imprimir una factura al presionar F7 o presionar el botn correspondiente. Event 'Imprimir Factura' 7 call(RPFac, FacNro) Endevent 3. Podemos querer retornar al programa llamador una vez que la transaccin haya sido ingresada: Event After trn Return Endevent 4. Para contar la cantidad de veces que una transaccin ha sido invocada durante una sesin, podemos programar los siguientes eventos: Event Start &Veces = 0 Endevent Event After trn &Veces = &Veces + 1 Endevent Event Exit &Msg = 'El nmero de transacciones grabadas: + str(&Veces) msg(&Msg) Endevent
128
5. Por ejemplo, supongamos que en la transaccin de facturas queremos dar la opcin 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 evaluacin no estn asociados a modos de evaluacin activos, por lo que no son vlidas las funciones como Insert, Update , Delete, After(Event), etc. Para condicionar el disparo de eventos a los modos de ejecucin activos debemos utilizarlos en combinacin con reglas. Recomendaciones Controlar mediante variables seteadas en las reglas que los eventos de usuario hagan calls en situaciones vlidas. Los eventos de usuario pueden evaluarse en cualquier momento, sin tener en cuenta el modo en que est la transaccin. Los atributos pasados como parmetros en los calls que se ejecutan en los eventos, son de entrada/salida, por lo tanto pueden cambiar su valor instancindose 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 actualizacin de la base de datos.
Reportes Definen procesos no interactivos de extraccin de datos. Usualmente un reporte es un listado que se enva a la impresora, aunque tambin puede ser visualizado por pantalla. Procedimientos Definen procesos no interactivos de actualizacin 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 adems actualizar la base de datos.
132
Caractersticas
Definicin procedural Definicin sobre la Base de Conocimiento Independencia de la Base de Datos
Definicin 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 ejecucin, en los reportes las especificaciones son realizadas en forma procedural. Definicin 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 fsico. Esto nos permite utilizar automticamente 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 frmulas, donde aprovecharemos que GeneXus sabe como calcular el valor para este atributo. Independencia de la Base de Datos, definicin a nivel de atributos. La definicin de Reportes y Procedimientos se hace a nivel de atributos, en ningn 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 automticamente por GeneXus.
133
Comando For Each

Sintaxis:
For Each [Order] [ Atr...Atr] Where <Condition> ... Where <Condition> Defined by <Attribute List> .. Endfor
Toda la definicin del acceso a la base de datos y la estructura del reporte o procedimiento, se realizan slo con este comando. Usando el FOR EACH se define la informacin 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 definicin). Order: Lista de atributos que indican el orden de recorrida de la tabla base. Slo 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). Eleccin del ndice: GeneXus elige automticamente 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 informacin. Se pueden mencionar atributos de la tabla base y/o de la tabla extendida. Defined by: Al mencionar en esta clusula algn atributo secundario de la tabla que se desea recorrer, dicho(s) atributo(s) participar(n) en la eleccin de la tabla base del For Each. Debe quedar claro que el/los atributos mencionados en el Defined by participan en la determinacin de la tabla base as como tambin participan los dems atributos mencionados en todo el For Each. Los atributos mencionados en esta clusula no tienen ms peso que los otros atributos del For each. El objetivo de esta clusula 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 slo se desea(n) referenciar en el For Each para que participe(n) en la determinacin de la tabla base.
134
Inferencia de las tablas utilizadas en el For Each

Determinadas automticamente a travs de los atributos del grupo For Each (Order , where, defined by y cuerpo del For Each) GeneXus despus de definir los atributos que participan determina una Tabla Base y su Tabla Extendida A partir de esto define la navegacin
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 definicin:
En base a la definicin realizada para el reporte, GeneXus determina automticamente 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 informacin (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 especificacin que slo inclua los atributos a listar.
135
1. Cmo pudo GeneXus determinar qu tablas se utilizan en el reporte ? Para esto se debe determinar en qu tablas estn 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 comn 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 estn almacendos en la tabla Client y DeptoNom solo est almacenado en la tabla Depart. Por esta razn, 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. Cmo pudo GeneXus determinar qu tabla debe recorrer y qu otras tablas debe acceder para complementar la informacin ? GeneXus ha determinado que debe recorre la tabla Client y acceder a la tabla Depart para complementar la informacin, lo que se informa en el diagrama de navegacin 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 informacin. 136
Repasemos los conceptos de tabla base y tabla extendida: Toda tabla del modelo (tabla base), tiene informacin 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 estn en una relacin 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 relacin 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 relacin existente entre estas, (N para 1), la tabla elegida como tabla base ser Clientes. GeneXus puede determinar esto automticamente porque conoce la relacin entre las tablas, y puede entonces adems saber cuales son las navegaciones vlidas entre estas.
137
3. Qu orden y qu ndices deben utilizarse? El reporte saldr ordenado por Cdigo de Cliente ( CliCod ) utilizando el Indice IClient. FOR EACH Client Order : CliCod Index : IClient En la definicin 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 clusula Order del FOR EACH.
138
Ejemplo :Tabla Base y Tabla Extendida

FACTURA
FacNro* FacFch CliCod
CLIENTE
CATEGORIA
CatCod* CatDto
FACTURA1
FacNro* ProdCod* FacLinCnt
PRODUCTO
139
When None
Ejecutar determinado cdigo, cuando en un For Each no se encuentra ningn registro. Sintxis
For each //clientes Where (condiciones de filtro) (proceso el cliente) When none Msg(ningn cliente cumple condiciones) Endfor
El Msg se ejecuta slo cuando no se entra en el For Each. Tambin se aplica a For Each [Selected] Line, XFor Each y XFor First, los cuales veremos ms adelante. Importante: Si se incluyen For Eachs dentro del When None no se infieren Joins ni filtros de ningn tipo con respecto al For each que contiene el When None ya que son considerados dos For Each paralelos .
140
Report Wizard
Permite disear el layout de un reporte (o procedimiento) de una forma mucho ms fcil. Se define a partir de una estructura de datos muy similar a las transacciones.
El diseo 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 parntesis se usan para indicar niveles de For Each (en vez de niveles de una transaccin) 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 botn de Next para pasar al siguiente paso. 2.- Permite definir otras caractersticas del layout. Se permite elegir los fonts para representar los atributos o textos, tambin se permite definir si los cabezales de los atributos para cada uno de los niveles se despliegan horizontalmente o verticalmente. Presionando el botn de Finish se graban las definiciones y se sale del dilogo del Report Wizard. Una vez que todas las opciones del Wizard fueron aceptadas, se genera el layout del reporte, el cul puede ser modificado como cualquier otro reporte. Tambin es posible editar el Wizard mediante la opcin : 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 ningn atributo relacin 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 estn 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 navegacin 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 ms atributos
For Each [CliCod] [CliNom] For Each [FacNro] [FacTot] Endfor Endfor Atributo relacin: 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 comn tienen ambas tablas extendidas (dndole prioridad a los atributos de la tabla base), y definir que estos atributos actuarn 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 estn 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 ningn 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 informacin 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 resolucin de este reporte puede hacerse accediendo nicamente a las facturas, recorriendo la tabla ordenada por cliente. En este caso imprimiramos 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 tendrn como tabla base la tabla de facturas. Para lograr esto se puede utilizar la clusula DEFINED BY del For each o el comando PRINT IF DETAIL. En el ejemplo podramos mencionar un atributo de la tabla de facturas en el Defined by , con lo que estaramos diciendole explcitamente a GeneXus que utilizara esta tabla. Si utilizamos Print if detail debemos definirlo en el primer For Each. Se debe definir adems en el orden de recorrida del primer for each (clusula ORDER), los atributos por los que se quiere realizar el corte (en el ejemplo CLICOD). Este es un requerimiento debido a que GeneXus no podra saber cual es el criterio de agrupacin que queremos ya que en una misma tabla pueden ser varios, por ejemplo podramos querer realizar el corte de control por Fecha de factura, totalizando el total facturado cada da. Debido a esto es que la definicin de la clusula 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 navegacin de Facturas por Fecha. Cuando ejecutemos este reporte, generar un ndice temporal por fecha, sobre la tabla Facturas. La navegacin 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 navegacin
Where Condition Parm(Atr ... Atr) - Atributos recibidos como parmetros
Como filtrar la informacin a recuperar de la base de datos. Muchas veces es necesario filtrar la informacin a incluir en el reporte, por ejemplo supongamos que el reporte deber listar slo aquellos clientes cuyo cdigo est comprendido en un rango determinado. Para resolver esto, tenemos dos opciones: * El uso de condiciones (Item Conditions) * El uso de la clusula where en el FOR EACH La nica diferencia entre usar Conditions o la clusula Where, es que la primera es global para todos los FOR EACH que definamos en el layout y la segunda se cumple slo 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 utilizacin de atributos en la regla PARM() determina una condicin por igual global para todo el reporte o procedimiento. Ejemplo: PARM(CliCod) .
For Each [ CliCod] [CliNom] Endfor
El reporte slo podr acceder al cliente cuyo cdigo sea igual al recibido como parmetro. 148
Diseo de la salida
MT
Header ... End

PL
CP [nlinea] Lineno [nlinea] Eject Noskip Footer MB : End
MT [nlnea]: nlneas es el nmero de lnea 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 [nlnea]: nlneas es el nmero de lneas que se desea dejar como margen inferior. En caso de no especificarse un valor se asume el valor por defecto que es 6. PL [nlnea] : Setea el largo de pgina. El nmero de lneas que ser impreso es el nmero especificado menos el margen de abajo (valor por defecto es 6). Ej: PL 66 Setea el largo de pgina a 66 lneas, aunque slo 60 lneas sern impresas en el form, con un margen inferior de 6 lneas. CP [nlnea] : Si queda en la pgina actual un nmero de lneas mayor o igual al nmero especificado, contina imprimiendo en la misma pgina. De lo contrario, pasa a imprimir en la prxima pgina (fuerza a un salto de pgina). Lineno [nlnea] : Define el nmero de lnea donde va a ser impresa la siguiente lnea. Si el nmero de lnea actual es mayor al nmero especificado, entonces, la lnea ser impresa en la prxima pgina. Eject : Fuerza a un salto de pgina. Noskip : Tiene que estar inmediatamente despus de un printblock. Si el comando se encuentra entre dos lneas, este comando las imprimir en la misma lnea. 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 extensin *.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 automticamente cuando se ejecuta cualquier reporte, o se puede ejecutarlo Standalone ejecutando el utilitario GxRView.
150
PROCEDIMIENTOS
151
Insercin de registros
Ejemplo: Insercin 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 insercin 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 accin tomar cuando se detecta que el valor de la clave en un alta ya existe en la tabla correspondiente.
152
Actualizacin
For Each Atr = <Exp> ... Endfor Actualiza atributo de la tabla extendida
La actualizacin se realiza en el EndFor.
Los atributos actualizables dentro de un grupo For Each, son todos los pertenecientes a la tabla extendida. La actualizacin fsica se realiza cuando se encuentra el EndFor del grupo For Each correspondiente.
153
Delete
For Each defined By FacFch Delete endFor slo Tabla Base
La ejecucin real del comando se produce cuando se encuentra el Delete y no cuando se llega al EndFor .
La eliminacin 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 frmulas 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 insercin 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 mltiples 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 dilogos con el usuario.
158
Entry Panel - Panel de Entrada
Paneles de Entrada Son paneles de entrada/salida. A travs de ellos se aceptan y se despliegan valores. Por ejemplo, un panel de entrada puede ser una pantalla previa a una impresin, donde se piden los parmetros 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 lneas por pantalla permitiendo que el usuario se desplace hacia arriba y hacia abajo (scrolling).
160
Seleccin Unica/Seleccin Mltiple/Listas de Accin
Area Fija
Subfile
Teclas de
Eventos y funcin
Listas de Seleccin de opcin nica Una lista de seleccin de opcin nica contiene un grupo de opciones de las que los usuarios pueden seleccionar solamente una. La forma de hacer la seleccin es teclear algn valor en la lnea a ser seleccionada. Una accin puede ser entonces ejecutada sobre el contenido de la lnea seleccionada. Listas de Seleccin de opcin mltiple Una lista de seleccin de opcin mltiple contiene un grupo de posibilidades de las que los usuarios pueden seleccionar cualquier nmero de ellas. Una lista de este tipo permite que una accin (solamente una) sea ejecutada en varias lneas simultaneamente. Lista de Accin Se pueden elegrir acciones diferentes a aplicar a cada una de las lneas.
161
Comando For Each Line

Sintxis: For Each Line .. EndFor
Recorre todas las lineas del subfile
En caso de querer recorrer slo 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 slo las lineas que fueron seleccionadas del Subfile. Los generadores no visuales slo permiten seleccin nica. En Visual FoxPro, no es posible seleccionar varias lineas en los grids a diferencia de Visual Basic (es una limitacin de VFP, no del generador).
162
Programacin dirigida por Eventos

El cdigo del programa permanece ocioso hasta que se invoca su ejecucin mediante acciones tomadas por el operador del programa frente a la pantalla .
Ejemplo: Event Enter Cdigo en respuesta a pulsar la tecla Enter EndEvent
La forma de programar los paneles de trabajo est inspirada en la programacin de los ambientes grficos, especialmente en la llamada Programacin Dirigida por Eventos (Event Driven Programming). Por Programacin Dirigida por Eventos se entiende un estilo de programacin en el cual las aplicaciones contienen cdigo que permanece ocioso hasta que es llamado para responder eventos provocados por el usuario o por el sistema. Los Work-Panels se definirn entonces de una manera menos procedural que en la programacin clsica, y orientada a eventos. Los eventos son acciones que pueden suceder o no. Tendremos un cdigo asociado a cada evento posible, el cual se disparar slo 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 botn refresh cuyo efecto es cargar nuevamente el subfile. Comando Refresh: En algunos casos, desde otro evento tambin puede ser necesario cargar nuevamente el subfile. Por ejemplo cuando en un evento se llama a una transaccin que actualiza los datos (Ejemplo "Ingresar" (F6)) que se estn desplegando en el subfile, lo que se hace entonces es ejecutar el comando refresh luego del call a la transaccin. Tambin se necesita hacer un refresh cuando una variable que aparece en las Conditions es modificada por el usuario. Estas variables determinan qu datos se cargarn en el subfile, si una condicin 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 despus 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 funcin o a un botn. De esta manera el evento ocurre cuando el operador presiona la tecla de funcin o el botn 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 ms importantes
Order Noaccept Search Hidden Workfile_lines
Order Define cul es el orden de los datos en el subfile. Es equivalente a la clusula ORDER del For Each y se aplica todo lo dicho en la seccin de Reportes sobre el tema (incluida la creacin 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 ningn 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 lnea determinada del mismo, en forma directa, sin tener que avanzar pgina por pgina. 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 presentacin, 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 lmite en la cantidad de lneas a cargar en ellos en PC o LAN , puede traer problemas si la tabla base asociada tiene muchos registros ya que el archivo temporal tendra todos los registros de la tabla base. Usando esta regla, se menciona en MaxLine la mxima cantidad de lneas que se permite cargar en el subfile. Si el lmite expecificado se excede, se despliega el siguiente mensaje Number of lines exceeded xxxx .
166
Propiedades ms 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 despus 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 slo variables, cuando uno desea que se haga automticamente 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 automticamente si el usuario no efectu ninguna operacin 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 navegacin: 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 slo 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
Dilogo Modal/No Modal

Property Modal dialog
En transacciones y work panels (llamados).
Opciones:
Yes if parameters specified Yes No
Slo generadores Visuales.
Esta propiedad permite indicar para cada objeto, si utilizar dilogo modal o no modal. Dilogo modal significa que mientras el objeto llamado no se cierre, el objeto llamador se mantiendr inactivo. Dilogo 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 simultneamente. Los valores posibles de esta propiedad son: Yes if parameters specified: Es la opcin por defecto. Significa que si el objeto recibe parmetros, el dilogo ser modal, mientras que si no recibe parmetros el dilogo sera no-modal. Yes: Dialogo modal. No: Dialogo no modal.
169
SUBTIPOS
170
Subtipos
Ejemplo: Transferencias entre Bancos. Atributos similares que cumplen roles diferentes. Transaccin de Bancos: BcoCod* BcoNom Transaccin de Transferencia : TrnNro* TrnFch Problema BcoCod Atributos BcoNom con el BcoCod mismo BcoNom nombre TrnImp
Cdigo de Banco Nombre de Banco
Nmero de transaccin 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 transaccin. Esto no es correcto pues tengo que poner atributos con el mismo nombre en la misma transaccin. 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 relacin Subtipo/Supertipo siempre comparten la misma definicin. Se realizan los controles de integridad referencial. La tabla extendida que se obtiene con la definicin del subtipo, es la misma que se obtendra en el caso que se utilizara directamente el supertipo.
172
Subtipos: Grupos
Almacenado Inferido
TrnBcoOriCod TrnBcoOriNom
Grupo TrnBcoOri
Almacenado TrnBcoDestCod Inferido TrnBcoDestNom
Grupo TrnBcoDest
Todava queda algo por determinar. Tenemos dos bancos y dos nombres pero en ningn lugar indicamos el nombre a que banco corresponde. Es ac donde aparece la necesidad de definir grupos. Decimos que el Cdigo de Banco Origen y el Nombre pertenecen al mismo Grupo.
173
Algunas Consideraciones
El subtipo y supertipo sern definidos del mismo tipo, GeneXus lo determina as y cuando se quiere definir un subtipo este "hereda" la definicin del supertipo. No incluir subtipo y supertipo en la misma transaccin, 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
Distribucin
Se genera el archivo Respaldo.xpw en la raiz de la KB
176
Consolidacin
Pide el path del archivo .xpw a ser consolidado
177
BUSINESS OBJECTS
178
Qu es un Business Object ?
Representacin de un objeto de la realidad: producto, persona, factura, moneda, pais Para su definicin se toman en cuenta: atributos que definen al objeto, operaciones que le son relevantes, cmo se relaciona con otros objetos.
Un Business Object es la representacin de un objeto de la realidad. Para su definicin se toman en cuenta: qu atributos lo definen, qu operaciones le son relevantes y cmo 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 especfica (ejemplo de BO: moneda). Un Business Object no debe estar directamente "ligado" a ninguna aplicacin en particular, de esta manera se asegura su portabilidad. Cada Business Object es autocontenido, es decir, su definicin no depende de otros objetos, sin embargo esta implementado de tal manera de que pueda interactuar con otros Business Objects.
179
Cmo 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 bsicos 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
Caractersticas de un BO
Independiente No ligado a ninguna aplicacin Standard y simple Fcilmente adaptable Documentado Bien testeado
182
Cundo usar BO?

Al crear nuevas aplicaciones Al agregar nuevas funcionalidades a una aplicacin existente
183
Ventajas de su uso
Reusabilidad :
aumenta productividad disminuye esfuerzo de desarrollo
Proveer soluciones rpidamente Facilitar la ampliacin de las funcionalidades de una aplicacin Compartir conocimiento
184
Algunos BO Genexus
Paises Productos Personas Monedas Tipos de IVA Numeradores
Disponibles en el Web Site de Artech
185
Distribucin de los BO
Exportar el folder que contiene el BO Envar exportacin (xpw) por mail a webmaster@artech.com.uy Datos importantes que deben ser incluidos en la documentacin enviada:
Breve descripcion del BO (objetos que lo componen y su funcionalidad) (objetos funcionalidad) Documentacin adicional que se desee adjuntar. ocumentaci adjuntar. Autor Fecha de ltima actualizacin actualizaci Versin 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 ncleo y que tienen realmente el conocimiento que hace a la solucin y hay objetos secundarios, que le dan forma a esa solucin.
A partir de la versin GeneXus 7.0 aparecen los objetos privados. El objetivo de esta nueva caracterstica 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 podrn ser modificados por el comprador. Aquellos objetos que no se privaticen seguirn siendo pblicos.
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 algn objeto privado se ingresar:
Copyright by: Derechos de autor del dueo del objeto. Buyer: Casa de software a la cual se esta licenciando. Purpose: Texto general.
Objetos Pblicos Un objeto podr ser pblico sin restriccin 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 dems usuarios (aquellos que licencien conocimiento de aquel) slo podrn 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, dnde se debe marcar el check Private Object. Slo se puede marcar un objeto como Privado en diseo. En prototipo y produccin no est habilitada esa facilidad ya que se heredar en la siguiente actualizacin de ese modelo (impacto). Esto slo indica que el objeto ser Privado, pero no se har ningn proceso con l, hasta el momento de su exportacin (distribucin).
189
Objetos Privados
Operativa de los objetos privados: son generables y algunas partes visibles y/o editables
Si al momento de exportar, se seleccion algn objeto, se habilitar un nuevo botn, Copyrigth Notice, para ingresar la siguiente informacin:
Copyright by: Derechos de autor del dueo del objeto. Buyer: Casa de software a la cual se esta licenciando. Purpose: Texto general.
Esta informacin, en un XPW, es la misma para todos los objetos privados, ya que se agrupa a una aplicacin.
Recin luego de ingresar esta informacin, el XPW ser encriptado en su totalidad, incluso aquellos objetos pblicos que tambin se hayan seleccionado. Si no se indica la informacin de Copyright, se har una distribucin 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 informacin de Copyrigth.
190
EFICIENCIA Y PERFORMANCE DE LAS APLICACIONES
191
Puntos a Considerar
Optimizacin de la Entrada-Salida Uso de Calls Open y Close de archivos Uso de Indices Temporales
Optimizacin de Entrada-Salida: Dado que el acceso a las tablas es costoso, vamos a ver cmo minimizarlo. Uso de Calls: Veremos cundo debemos empezar a preocuparnos por el uso de este comando. Open y Close de archivos: Cunto y cmo influyen las operaciones de apertura y cierre de archivos en el tiempo de respuesta de nuestra aplicacin. Uso de ndices temporales: Evaluacin del costo de creacin de ndices temporales vs. el costo de mantenimiento de ndices permanentes.
192
Optimizacin de Entrada-Salida Definicin 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 caractersticas comunes, por ejemplo, todas las facturas de un determinado cliente, o las ventas de una clase de artculos. Estas caractersticas comunes, se establecen a travs 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 frmula Aggregate/Select, parametros , etc. Ejemplo: De todos los clientes, quiero imprimir los datos de aquellos cuyo cdigo este en un rango determinado. El tiempo necesario para realizar el proceso con los registros que cumplen las condiciones, determina el grado de "optimizacin" que tiene la estrategia de acceso elegida. Decimos que una estrategia de acceso esta ms "optimizada" que otra, cuando es necesario un menor tiempo para leer todos los registros que cumplen las condiciones establecidas. La optimizacin 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 condicin.En estos casos, la mejor estrategia consiste en tener el menor intervalo tal que cubra a todos los registros que cumplirn la condicin. Igualmente las lecturas se realizarn para todos los registros de este intervalo, pero solamente se considerarn aquellos que cumplan con las condiciones.
193
Definicin de Filtros
Clusula Where en For Each

Conditions en Prcs, Rpts, Wkps. Parm() en Trns, Prcs, Rpts, Wkps
Where: La clausula "Where" permite filtrar registros en la navegacin de un determinado grupo FOR EACH. Por ejemplo: Para establecer los filtros descritos anteriormente, utilizaramos la siguiente especificacin: 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 condicin. Cuando se establece una condicin sobre atributos, afecta a todos los grupos FOR EACH que contengan ese atributo. Reports, Work-panel y Procedures poseen esta posibilidad. Se prevee la implementacin a nivel de Transacciones en prximas versiones. Parmetros: Es otra forma de establecer una condicin en forma global, pero solamente por igualdad. Cuando se recibe un parmetro en un atributo, obtenemos una especificacin equivalente a una condicin. Por ejemplo: un procedimiento tiene la siguiente regla: Parm(CliCod); Esta regla es equivalente a tener: parm(&Cliente);y la condicin:CliCod = &Cliente; 194
Definicin 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 posicin 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.
Definicin de la estrategia de acceso con GeneXus Para definir una buena estrategia de acceso, GeneXus cuenta con una inteligencia razonable. A contnuacin se explica cmo 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 posicin inicial y una posicin 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 posicin de comienzo (Start). Posicionarse lo ms cerca posible del primer registro que cumple las condiciones. 3. Leer secuencialmente, descartando los registros que no cumplan las condiciones, hasta alcanzar la posicin de fin. 4. Fijar la posicin de fin (End). Se dice de aquellas condiciones, tales que a partir del primer registro que no las cumple, no existen ms 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" determinarn la mejor estrategia de acceso. El orden puede considerarse como una condicin previa, para la definicin de la optimizacin 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 optimizarn las condiciones que sean posibles. Excepcin: 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 relacin 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 relacin 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 especificacin: 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 condicin implcita que indica que:Tipos.TypCod =Cliente.TypCod
198
Esto ocurre cuando se tienen FOR EACHs anidados, cuyas tablas bases tienen alguna relacin; GeneXus la encuentra y determina en forma automtica una condicinde filtro. Esta relacin slo 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 ms de una tabla. Esta condicin (Tipos.TypCod = Cliente.TypCod) establecida en el for each de clientes, slo es optimizable si el orden es TypCod. Pero decamos que el no especificar ningn orden implica que el orden a tomar es el de la clave primaria (CliCod), por lo que no sera posible entonces la optimizacin.Pero en este caso, como nica excepcin, se elige el orden que permita optimizar la condicin de filtro.
199
Posicin de Comienzo
Consideraciones para su definicin.
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
Posicin de Comienzo
Ejemplos:
Orden: A B C Condiciones : A>= 5 .and. C > 3 Posicin de comienzo: A>=5 Orden: A B C Condiciones : A > 5 .and. B < 2 .AND. C > 3 Posicin de comienzo: A > 5
201
La Posicin Final
Consideraciones para su definicin
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 Navegacin
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 Navegacin
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
Tambin influyen en la performance:
Calls Apertura y Cierre de Archivos Uso de Indices Temporales
- Calls : En qu casos deberamos considerar el costo de la ejecucin de un Call? En la gran mayora de los casos no es necesario que nos preocupemos por esto. Sin embargo en algn 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 ejecucin de la aplicacin o si.no si se lleg al lmite de cursores para usar, los que ya fueron usados, son marcados como borrables, a fin de cerrarlos slo si es necesario, si se vuelven a utilizar la definicin ya est, por lo que el tiempo de creacin 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 realizarn 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, despus 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 haban 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 ms rapidamente que en File/Server, ya que solo se indexarn los registros que cumplan las condiciones y no requiere un uso exclusivo de la tabla. En File/Server, se construye el indice para la ejecucin del programa y luego se borran. El tiempo de creacin es considerable dependiendo del nmero de registros de la tabla y de la cantidad y largo de los campos. En el AS/400 se usa la instruccin OPNQRYF para definir ndices temporales. Dependiendo de todo eso es que conviene o no crearse un ndice de usuario.
207
MULTIPLES FORMS
208
Mltiples Forms por Objeto

Poder tener N pantallas por objeto. Permitir dentro de una misma KB tener modelos en los que se genera para ambiente grfico 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, automticamente se crea un form de esa clase en el mismo. Cuando se importa, se genera automticamente un form para cada clase que sea Autocreate. Puede haber una o ms 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
Mltiples Forms por Objeto

Form Classes
Graphic y Text (son del sistema) Definidas por el usuario (modo texto o grfico)
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.
Opcin: 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
Cundo decide GX el form a utilizar ?

En tiempo de Especificacin 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 cul 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 (grfico 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 especificacin aparece cul fue la form class que se eligi para cada objeto. 2.- Al abrir el objeto, para decidir cul mostrar en forma inicial
212
STYLES
213
Propiedades de los Styles

Permiten la definicin de standards. La definicin 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 normalizacin o generacin de programas. Slo se utilizan para definir standards, sin la necesidad de tener que disear Form por Form. Pueden ser modificados, y automticamente 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 tambin para Prompts y los Styles de Report y Procedure que pueden usarse para cualquiera de los dos. Nota: No existen Styles de Styles
214
Definicin de un Style
Object/New Object. Ejemplo de un Style de transaccin.
215
Style
Style Area
Data Area
Este espacio se puede usar para poner comentarios
Se ven en los forms unas lneas que definen diferentes reas. Lo que est dentro del rectngulo 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 aparecern solas. De todas maneras tambin se pueden hacer aparecer con un botn de la toolbar. Los controles que estn completamente comprendidos en un sector conservan su posicin relativa a ste, cuando se mueven las lneas. Aquellos controles que pasan desde un lado de una lnea hacia el otro, conservan su posicin relativa a la lnea (se mueven junto con la lnea). Si un control pasa por encima de 2 lneas paralelas (o dicho de otra manera, comienza antes de la lnea de borde izquierdo de la data area y termina despus de la lnea del borde derecho, o bien la misma situacin 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 posicin relativa a la primera de las lneas que cruza. B). Es un control sin "autoresize". El control se agranda o se achica tanto como se separen o acerquen las lneas, manteniendo cada uno de los extremos del control su posicin relativa a la lnea ms 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 slo en caso de inicializacin (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
Creacin de un objeto basado en un Style

Al momento de crear el objeto, en el Information/Style se elige el Style deseado. Relacin entre objeto y Style:
Form y Properties: Relacin dinmica Otras partes del objeto: Relacin esttica
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 excepcin del Information, obviamente). Excepto para el Form y las properties, la relacin entre las partes del objeto y del Style es esttica (si se cambia el Style no se cambia el objeto). Pero tanto para el Form como para las properties puede ser dinmica (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 asociacin 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 dinmico, pero dinamismo con la default data area slo si el objeto es un transaccin. En las prximas transparencias veremos cmo es que se pierde el dinamismo. El estado de dinamismo se puede ver por el color con el que estn dibujadas las lneas. Si son rojas, est dinmico. Si no est dinmico, son azules.
218
Creacin de un objeto basado en un Style
Las lneas 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 transaccin 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
Cmo 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 (slo 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 slo 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 provenan del Style asociado anteriormente (controles del usuario), permanecern 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 clculo de la Default Data Area (control que viene de la DDA), se pierde el dinamismo en sta (por ej.: si en una transaccin se modific uno de los controles correspondientes a los atributos de la estructura, al agregar nuevos atributos en la misma no aparecern automticamente en la Data Area). Anlogamente, 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 diseando. 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 tamao de la Data area

Para agrandar o achicar la data area, slo sirve mover los bordes derecho y/o inferior.
El form del Style tiene la capacidad de adaptarse al tamao 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 tamao de la data area definido en el form del style (y por lo tanto tambin el tamao del frame) se considera como tamao mnimo de la data area del form del objeto.
222
Consideraciones para el diseo 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 mltiples forms. (Ej.: definir un form grfico 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, cul de los styles existentes en el modelo se desea que sea considerado como Master Style (es decir, cul 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 declaracin 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 estn disponibles los styles existentes y la opcin (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 definicin de Menu Bar y Tool Bar
Object/New Object/Menu Bar
Add y Delete de Items

Edit/Insert y Edit/Delete respectivamente Subitems Personalizacin del item Help/About
Slo en generadores grfico:

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 definicin de la Tool Bar es exactamente igual a la del Menu Bar, slo que en los items de la Tool Bar se debe definir tambin 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 informacin deseada.
227
Tipo de objeto Menu Bar

Definicin 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 ejecutarn en todos los objetos que utilicen el Menu Bar. Por esta razn 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 vlidas para cada control. Segn el tipo de control, las properties que tiene asociadas. Slo en generadores grficos:
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 ttulo 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 posicin del vector para diferenciarlas.
231
Dilogo: Select Property

Se accede a travs de la opcin Insert/Property cuando se editan:
Rules, Eventos, Subrutinas, etc en transacciones, work panels y web panels
No disponibles en reports y procedures
232
Dilogo: 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 diseando 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 cdigo asociado a dicho evento se ejecuta al hacer doble click sobre el campo. Click: El cdigo asociado a dicho evento se ejecuta al hacer click sobre el campo. Right Button: Se dispara cuando se presiona el botn derecho del mouse. IsValid: Se dispara cuando se hace la validacin del control.
234
Evento OnLineActivate
Evento asociado al control subfile Se dispara cuando se activa una lnea en el subfile:
al clickear una lnea con el mouse moverse a travs de la grilla con el teclado cuando se hace refresh de la grilla.
Los valores son los de la lnea 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 estarn 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 diseando. Event: Despliega la lista de eventos que se pueden aplicar al control seleccionado.
236
METODOS
Se aplican a los controles. Sintxis: Nombre del Control.Method([<Parms>]) Segn el tipo de control (edit, check box, etc) son los mtodos que se pueden asociar. Se accede a travs de la opcin Insert/Methods cuando se editan: Rules, Eventos, Subrutinas en transacciones, work panels y web panels. Slo en generadores grfico:VB, VFP, JAVA A excepcin del mtodo 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 mtodos en tiempo de especificacin.
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 comn) 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 debera cambiar el call al programa PImpClis por un call a un ejecutable ImpClis, con lo que deberamos regenerar estos objetos.
Para evitar la regeneracin 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 slo contiene el Call al Ejecutable correspondiente Genera otro programa que es el que contiene la lgica 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 slo el llamado al ejecutable se le denomina STUB.
242
STUBS
Tenemos entonces 2 programas generados, asociados a un mismo objeto GX. Para la denominacin del programa STUB se siguen las convenciones de siempre (P=Procs, W=Work Panels etc.) Para la denominacin del programa que ser el principal del ejecutable (el que contiene realmente el cdigo) se usan las siguientes convenciones: Transaccin 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= extensin 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 Definicin Global Uniformizacin 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 transaccin interna asociada, o no. Data View con transaccin 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 transaccin 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 tamaos 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 transaccin interna asociada. Asimismo se deben indicar las correspondencias entre los atributos internos y los campos externos. Tambin se debe ingresar en el Data View, informacin relacionada al Archivo Externo como ser la plataforma y ubicacin (esto debe ser indicado tanto en el caso que el Data View tenga una transaccin 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 transaccin de clientes, esta no provoca la creacin de una tabla fsica por estar asociada a un DataView. Esta transaccin se especifica y genera como cualquier objeto de la Base de Conocimiento y en ejecucin, accede en forma interactiva a los registros de la tabla externa en forma transparente.
Data View sin transaccin interna asociada En este caso, se debe crear un Data View, sin crear previamente una transaccin interna. La forma de acceder al Archivo Externo es nicamente mediante la definicin de procesos batch utilizando los External File Commands: XFOR EACH, XNEW, etc.
248
Definicin 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 direccin 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 aplicacin. Plataform Specific Information: Aqu se debe completar informacin del archivo externo (como ser la plataforma y ubicacin).
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 aplicacin. Nota: Este es un nombre interno del ndice, es decir, no tiene por qu ser el nombre del ndice fsico. Genexus hace un mapeo entre el nombre interno del ndice y el nombre externo de acuerdo a la composicin 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 ubicacin para el modelo de Prototipo Fox y para el modelo de Produccin Fox, debe seleccionarse DBFCDX(model2) y DBFCDX(model 3) indicando la ubicacin para cada uno de los modelos. En cambio, si se quiere la misma ubicacin para todos los modelos Fox debe seleccionarse la plataforma DBFCDX.
252
Platform Specific Information / Edit
Estas propiedades varan 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 ms 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 relacin 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 ms atributos que el Archivo Externo no es vlida la asociacin.
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 tambin como datos del Cliente el E-Mail y la direccin.
258
Asociacin Dinmica
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 composicin).
En este caso coincide todo. Si ocurre esto no hay que detallar composicin 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 Definicin
Archivos Externos Data View Definicin Global
CON Tablas Asociadas
SIN Tablas Asociadas
Asociacin Dinmica
Asociacin Definida
260
REORGANIZACIONES DATA VIEWS

1. EXISTE TABLA ASOCIADA Si cambia la estructura de la tabla asociada, el cambio es detectado en el Anlisis de Impacto. No se generan programas de reorganizacin.
2. NO EXISTE TABLA ASOCIADA No aparece en el anlisis de impacto.
261
WEB PANEL
Permite construir pginas WEB dinmicas que interactan 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. Restriccin: Con el generador C/SQL no puede usarse el dbms AS/400.
262
GeneXus Intermedio.
Optimizando Aplicaciones. Relator : Hctor 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
PUNTOS IMPORTANTES EN LA DEFINICION DE TRANSACCIONES

Definicin de Modos
Modo Inicial
El modo inicial de un nivel de una Transaccin depende de la plataforma y puede ser modificado en cada nivel usando la rule Default_Mode.
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
Loop Once
La transaccin recibe la variable &Mode como parmetro (Update o Delete)
y
La Primary Key se recibe como parmetro: parm(<att1>, , <attn>); Ningn atributo es aceptado
Delete Cascade
La opcin Delete en una Transaccin realiza un Delete Cascade del nivel subordinado, al que se esta eliminando. Se eliminan slo aquellos registros includos en la estructura de la Transaccin que se esta ejecutando. Si el nivel subordinado del nivel que se esta eliminando posee un nivel subordinado, el Delete Cascade no es vlido.
EJEMPLO: Delete Cascade

Orden de Compra OrdNro* OrdFch PrvCod PrvNom AnaNro AnaNom (PrdCod* PrdDsc OrdCnt OrdPrc PrdPrc) OrdImpTot Entregas OrdNro* PrdCod* (EntFch* EntImporte) - Transaccin Orden
Se desea eliminar una Orden
Tabla Orden
Tabla Entregas Tabla Entrega1
- Transaccin Orden
Se desea eliminar una Linea de la Orden
- Transaccin Entregas
Se desea eliminar una Linea de la Orden
Uso de &Mode
La modalidad de una Transaccin puede instanciarse recibiendo como parmetro la variable &Mode de GeneXus. Valores vlidos 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 Transaccin, para poder utilizarla debe ser recibida como parmetro.
EJEMPLO: Transaccin 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
Nmero 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
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

Definicin de Prompts y Refcalls
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 transaccin que permite visualizar y elegir un registro de la tabla base del nivel de una Transaccin.
Activacin segn la plataforma:

Prompt : PC > F4 AS/400 > F4
Autoprompt : PC > Botn 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 parmetros <Par1> .. <ParN> pueden ser tanto atributos como variables. Los atributos se deben corresponder con una foreign key .
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 parmetros <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 ms de uno, habilita el F4 sobre el primero en la estructura de la transaccin. Variables Si es una sola, habilita el F4 sobre la misma. Sin son ms de una, habilita el F4 sobre la primera en ser aceptada (en las rules).
Reglas para el prompt por defecto

Los parmetros no instanciados se utilizan como condiciones de bsqueda con >=, con un mximo de 8. Los parmetros instanciados aparecen como condiciones de bsqueda pero no modificable. Los atributos del subfile aparecen de acuerdo al orden en que estn en la tabla, si uno excede el tamao 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 descripcin .
Ejemplo
TRANSACCIONES:
Categora CatCod* CatNom SubCategora 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 Transaccin Categora 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.

Disparo de Rules
11
EJEMPLO: Transaccin 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);
Frmulas:
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 segn las GeneXus se encarga de determinar el orden de Disparo de las reglas segn 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 mayora 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 lneas de una Factura Transaccin 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 impresin 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;
Segn el rbol de evaluacin cada vez que el importe cambie, cambiar el total calculado.
TOT CALC
IVA 0.22 STOT

SUM
IMP
PRECIO
CANT
15
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: Numeracin Automtica 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 Lneas de Factura despus 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 lneas 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 validacin resulta negativa, el error no se dispara.
18
Eventos en una Transaccin 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 travs 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

Con la definicin de subtipos se establece la siguiente relacin:
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 definicin de grupos de subtipos.
21

Utilizacin de atributos secundarios del supertipo definiendo atributos subtipos dentro de un grupo
CiuCodOri CiuNomOri CiuCodDes CiuNomDes CiuCod CiuNom CiuCod CiuNom (Origen) (Origen) (Destino) (Destino)
Definicin de Subtipos
22
B. Especializacin 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. Especializacin 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

Historico de Compras PrvCod* PrvNom PrdCod* PrdTxt HisCnt Ordenes de Compra OrdCmpNro* PrvCod PrdCod Productos PrdCod* PrdTxt
24

PrvCod* PrvNom PrdHisCod* (Subtipo de PrdCod) PrdHisTxt (Subtipo de PrdTxt) HisCnt OrdCmpNro* PrvCod PrdCod

Historico de Compras PrvCod* PrvNom PrdHisCod* PrdHisTxt HisCnt Ordenes de Compra OrdCmpNro* PrvCod PrdCod Productos PrdCod* PrdTxt
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 slo va a estar almacenado en la tabla de empresas
TABLA EXTENDIDAHERENCIA
Subtipos mltiples
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
DptoCod* SeccCod* SeccNom
ExpNro* DptoCodIni SeccCodIni DptoCodAct SeccCodAct

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

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.
DptoCod* SeccCod* SeccNom
ExpNro* DptoCodIni SeccCodIni DptoCodAct SeccCodAct
28
Consideraciones
El subtipo y supertipo sern definidos del mismo tipo, GeneXus lo determina as y cuando se quiere definir un subtipo este "hereda" la definicin del supertipo. El supertipo debe ser identificador en alguna transaccin o al menos algn atributo del grupo. Si al definir el grupo, uno de los atributos inferidos queda como secundario ( S ), es porque hubo un error en la definicin del grupo. No es aconsejable incluir subtipo y supertipo en la misma transaccin, ni tampoco en la misma tabla extendida. Los subtipos no pueden participar en la definicin 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, slo son vlidos 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 frmula son:
La tabla en la que est definido el atributo frmula (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 solucin es definirse como redundantes (en la Tabla de Llegada) a dichos atributos.
30
FUNCION FIND
Sintxis:
ATT = FIND(<At de retorno>, <Condicion de bsqueda>, <Val.def>) if <Condicin de disparo>
FIND RECURSIVO
Se llaman finds recursivos a aquellos que para resolverse recorren la misma tabla sobre la que esta definida la frmula.
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 comparacin en la bsqueda 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 Seleccin de Productos
Rules parm(&V15 ) ; order(ProdId ) ; Conditions ProdId >= &C15 ; ProdDsc .LIKE. &C16 ;
Event Enter &V15 = ProdId Return EndEvent
Work Panel de Seleccin 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 slo 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 explcita,
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-accin)
PUNTOS A PROFUNDIZAR EN REPORTES Y PROCEDIMIENTOS
37
Frmulas en Procedimientos
Frmulas 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
Frmulas 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 slo es invlido para generadores xbase . Inferencia: Atributos instanciados por el For Each y no instanciados especificamente en el New son inferidos para la insercin 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

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

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

Dos ordenes distintos para la misma tabla
Resultado de la navegacin 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

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 Actualizacin
No se puede realizar ninguna actualizacin 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 ningn 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
Creacin 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 reorganizacin

Frmulas que dejan de serlo. Sacar atributos de la llave. Indice contenido en otro.
Reorganizaciones en ms 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 lneas. Crear un atributo frmula y definirlo redundante.
44
Reorganizacin en AS/400
Se genera en PC y se transfiere al AS. Son 8 pasos con retoma Bloqueo de informacin Se genera SAVF GXIMPDBR Data areas
Reorganizacin en PC/CS
MENU y RMENU Setup Wizard (Exportacin )
45
Recomendaciones finales
Siempre antes de hacer una reorganizacin 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 Tericos
Control de Concurrencia Tipos de Dilogo Conversacional Pseudo Conversacional Integridad Transaccional Unidad de Trabajo Lgico (UTL)
Conceptos Tericos
Control de Concurrencia: controles para evitar inconsistencias en los datos cuando se trabaja en ambiente multiusuario
47
Conceptos Tericos
Dilogo Conversacional Esquema: 1. aceptar datos 2. validar usando locks 3. pedir confirmacin 4. actualizar la base de datos 5. liberar locks
Conceptos Tericos
Dilogo Pseudo Conversacional 1. aceptar datos 2. validar 3. pedir confirmacin 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 Tericos
Integridad Transaccional Un conjunto de actualizaciones a la base de datos tiene integridad transaccional cuando en caso de una finalizacin anormal la base de datos permanece en estado consistente.
Conceptos Tericos
Unidad de Trabajo Lgica (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
Cmo 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
Consideraciones por DBMS en la lectura:
AS/400, DB2/400 y SQL Server: leen la ltima informacin 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
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 Dilogo
Obtener Datos Lockear Validar datos Pedir Confirmacin Confirma? Evento After(confirm) Grabar BD Eventos After Ins/Upd/Del Commit
Deslockear Evento After(TRN)
52
Tipos de Dilogo
Obtener Datos Validar datos Pedir Confirmacin Confirma? Evento After(confirm) Validar cambios No hubo cambios? Grabar BD Eventos After Ins/Upd/Del Commit Evento After(TRN) Deslockear
Pseudo
Lockear
Preference Lock Mode Valores:
Conversacional
Do not specify lock level (*) Use page level locking Use row level locking
Vlida solo para Informix
53
Preference Isolation Level Valores:
Read Committed (*) Read Uncommited
Vlida para todos los DBMSs excepto Oracle y SQL Server
Caso Particular: Locks en SQL Server SQL Server 6.5 Lockeo a pgina 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 Dinmico
54
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 operacin. En SQL Server no se despliega mensaje y queda esperando indefinidamente hasta que se libera el registro.
Qu sucede cuando un programa que actualiza la BD encuentra un registro lockeado? Procedimientos Se intenta indefinidamente la operacin hasta que se libera el registro. No despliega mensaje.
55
- Time-out
Desde GeneXus no es posible configurarlo Comportamiento en cada DBMS: Oracle e Informix: instantneo 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 pgina siempre

256 bytes, no configurable
56
UTL en GeneXus
UTL en Transacciones Por defecto se define el alcance de la UTL como toda la transaccin 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

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

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 reorganizacin 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
Vlida solo en AS/400

Ejemplo property Commitment
Facturas
If insert and after(confirm)
Numerador
Tabla Numeradores
Commitment=Disabled Tabla Facturas
60

Commit on Exit
Valores:
Yes (*) No
Consideraciones
No es vlida si tiene Commitment = Disabled

Ejemplo property Commit on Exit
Commit on Exit = No
Facturas Refcall(Tcliente,
CliCod INS)
Cliente
Tabla Facturas
COMMIT
Tabla Clientes
61

Confirm Transaction
Valores:
Yes No (*)
Consideraciones
Es vlida si tiene
Commitment = Enabled y Commit on Exit = Yes
DEFINICION Y MANTENIMIENTO DE REDUNDANCIAS
62
Definicin de Redundancias
Redundancia Referencial
Para definicin de ndices de usuario Por lmites en la definicin de una frmula Aggregate/Select
Redundancia por Frmulas

Por optimizacin de performance en el clculo de frmulas verticales
Mantenimiento de Redundancias
GeneXus mantiene automticamente las redundancias definidas - Transacciones que definen la tabla. Se llama a un programa GXUnnn GeneXus genera programas para reconstruir las redundancias a travs de:
La ejecucin del Redundancy Load Program Utility(GXLRED)
63
Redundancy load Utility

Se genera un programa, GXLRED (GeneXus Load Redundancy) que recalcula todas las frmulas 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 anlisis 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 nmero de la tabla:
Table Factur load redundancy procedure -------------------------------------------------Redundant attributes: FacTotal Procedure name: GXR24
64
Mantenimiento a travs de Transacciones

Toda transaccin 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 nmero de tabla
Actualizan la redundancia de un registro de la tabla. Reciben como parmetro la clave de la tabla.
Consideraciones
Las frmulas Aggregate Select no se pueden definir como redundantes (ni ninguna frmula 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= Frmula1(Frmula2) => debe definirse primero la redundancia para Frmula2 para recin despus poder definir como redundante att. Para cambiar una frmula redundante primero hay que hacer el UNDO de la redundancia.
65
EFICIENCIA Y PERFORMANCE DE LAS APLICACIONES
Tips de optimizacin
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 optimizacin
Utilizacin 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 optimizacin
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 exista )
Usado para creacin y reorganizacin de la base de datos. File/Edit Model/Generator
Generador por Default para los objetos

En un principio coincide con el de la Reorg., pudindose elegir otro. File/Edit Model/Tab de Generators
Generadores secundarios
File/Edit Model/Tab de Generators
Se controlan combinaciones vlidas
Generador por Objeto

Definir en cada objeto Main el generador a utilizar.
Opcin: Information/Tab de Options/Generator
69
Cmo 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 distribucin de procesos: el proceso cliente y el proceso servidor, que se conectan mediante algn mtodo de comunicacin entre procesos. Es decir, se realiza una distribucin 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 * Lgica
Server
Red
73
Arquitectura Client / Database Server

Disminuye fuertemente el trnsito en la red, en comparacin con Client / File Server. Permite mantener una integridad transaccional completa.
Qu obtienen los usuarios GX de Client/Server ?

Acceso a ltima tecnologa sin necesidad de incurrir en altos costos de entrenamiento Plataformas y bases de datos:
Oracle SQL Server DB2 Common Servers DB2/400 Informix Mltiples plataformas (Unix, Windows, Novell, etc.). Windows NT y Alpha Mltiples plataformas (Unix, Windows, etc.) AS/400 Mltiples plataformas (Unix, Windows, etc.)
Uso de PCs 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
Pginas grficas con hipertexto Dos tipos fundamentales:
Pginas estticas
HTML standard. Generacin con algunas herramientas.
Pginas dinmicas
GeneXus ASP
76
Web - Pginas Estticas

Informacin general Marketing Informacin similar a la que se distribuye en folletos y documentos Acceso rpido y cmodo a informacin Direcciones de correo electrnico para informacin y soporte Mantencin de alto costo Sin valor agregado
Web - Pginas Dinmicas

Interactivas: Comunicacin de ida y vuelta Interactan con la base de datos (Access, Oracle, DB2, Informix, SQL Server) Actualizacin automtica en GeneXus Entregan informacin segn el requerimiento Elementos tcnicos diferenciadores
77
Pginas Dinmicas - Ejemplos

Home Banking Divulgacin de informacin (con y sin costo) Comunicacin con proveedores Intranet (Informacin dentro de la empresa) Intercambio de datos y documentos VENTA DIRECTA
Pginas Estticas y Dinmicas

WWW - World Wide Webs
Pginas Estticas
Pginas Dinmicas
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: Ubicacin y nombre del documento en el servidor [parm1,...,[parmn]] Informacin opcional para consultas
Protocolo HTTP
Conexin/Solicitud
Respuesta/Cierre
79
HTML
<HTML> <HEAD> <TITLE>Esta es mi primera pgina</TITLE> </HEAD> <BODY> Esto muestra de una forma muy <I>simple</I>, la estructura bsica 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 Pginas HTML Cliente : BROWSER NetScape, MS Internet Explorer
81
Topologa Topologa
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
Interaccin con la Base de Datos Interfase similar a Work Panel Desarrollo Inmediato Mantencin bajo el mismo esquema de una aplicacin tradicional GeneXus
Web Panels VS. Work Panels

El evento ENTER es el nico al que se le puede asignar un botn y en l las variables cuyos valores ingres el usuario son transferidas al programa No pueden asignarse teclas de funcin a eventos El evento Refresh y Exit no estn implementados La ergonometra puede ser diferente
83

Algunas propiedades deben setearse desde cdigo Algunas propiedades de objetos no estn implementadas o no funcionan El display final no corresponde necesariamente con el de diseo No se han implementado todos los controles de Windows El tamao de pantalla no est limitado a una resolucin en particular

Siempre se hace loadAll Se puede programar paginacin 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 caractersticas de los Web panels

Son permitidos calls a (botones y eventos):
Otros Web Panels o a s mismo Procedimientos
Son permitidos links a (Subfiles y labels):

Web Panels Pginas HTML estticas
Cdigo 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
Cdigo embebido:
JavaScript Ej.:
Event Start &c=<Script lenguage=JavaScript> alert(Bienvenido a nuestra pgina Web)</script> mensaje.caption=&c EndEvent
Permite realizar acciones sobre el browser, cuando no se pueda hacer directamente con GeneXus.
Seguridad
Es segura mi aplicacin en Internet?
es segura la comunicacin en Internet? quin puede acceder a mi base de datos? quin puede acceder a mi aplicacin?
87
Seguridad a nivel de Web Server

Criptografa Solucin: servidores seguros
Seguridad a Nivel de DBMS

Como en cualquier aplicacin desarrollada con GeneXus Dos esquemas de validacin:
Sistema operativo DBMS
DBMS
88
Seguridad a Nivel de Aplicacin

Sesin, cliente
Login
Registro
Sesin, cliente
Operacin
Sesin, cliente
Generacin de sesin
Ingreso de usuario
Validacin
Generadores - Servidores
Windows NT C/SQL VB RPG UNIX X X AS/400 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 (slo 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 .dlls Cliente Servidor Controles bsicos VB (OCXs).
90
Configuracin 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) (slo 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 Microsofts website: http://msdn.microsoft.com/library/default.asp?url=/downloads/list/netdevframework.asp. It can also be downloaded from the Download Center at GXTechnical website: http://www.gxtechnical.com/main/hdcenter.aspx?2,5,36,1035
Page 4 of 47
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 Microsofts website: http://msdn.microsoft.com/library/default.asp?url=/downloads/list/netdevframework.asp. It can also be downloaded from the Download Center at GXTechnical website: http://www.gxtechnical.com/main/hdcenter.aspx?2,5,36,1035
3
You can obtain Visual J# Distribution Package 1.1 from Microsofts website: http://msdn.microsoft.com/vjsharp/downloads/howtoget/default.aspx
Page 5 of 47
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
Installation and Setup

This section explains how to use the Setup program to install GeneXus Trial on a computer. The Setup program includes a wizard to help you make the correct choices. To start the GeneXus Setup program: 1. Start Windows. 2. Run GeneXus Trial Setup. 3. Follow the Setup Wizard instructions to install the selected products (Development Environment and Generators).
Setup Wizard
The first screen you will come across is the setup wizard welcome screen: click Next if you wish to continue with the installation. The following screen is a License agreement that you should read carefully before continuing to the next one. After selecting the I accept the License Agreement option and clicking Next, the following dialog asks you to register your name and company name. Once you have entered that information, click Next to display the following dialog box:
Figure 1 Setup wizard for GeneXus Trial
In this dialog you select the destination folder where GeneXus will be installed (a directory called gxw80Trial is suggested). By clicking the Browse button you will be able to change the default one. Click Next to go to this dialog:
Page 7 of 47
Figure 2 Product selection dialog box
Once you have selected the destination folder, you will be asked for the products you want to install (i.e. Development Environment and the different Generators). Then, click Next to begin the installation. After all the files you need have been copied to your system, the Setup program places GeneXus icons in a GeneXus group that will be automatically incorporated to your Program Manager's window.
Page 8 of 47
Trial Version Authorization

This is a detailed description of the steps to authorize GeneXus: 1. Execute GeneXus 8.0 Trial Version from the desktop shortcut for GeneXus 8.0 or from the programs menu. 2. Copy the Site Code:
Figure 3 Registration dialog box
3. In order to activate the GeneXus Trial version, go to www.genexus.com/trial/authorize and enter the Site Code obtained in step 2. Then, click Submit to have the activation key generated and sent to your e-mail address. 4. After receiving the activation key, proceed with the product activation. Then you will be able to start using GeneXus Trial.
Page 9 of 47
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 companys 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
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
Step 4: Viewing the Completed Objects Form

Once all the attributes have been defined and saved, your object form will look as follows: 1. Select the Form tab of the transaction.
Figure 7 Transaction form tab
When defining a Transaction, a default Form is automatically created by GeneXus to specify the way the end user will access data in Windows applications. This form can be changed by the developer.
Page 12 of 47
2. Select the Web Form tab of the transaction.
Figure 8 Transaction web form tab
When defining a Transaction, a default Web Form is automatically created by GeneXus to specify the way the end user will access data in Web applications. This Web Form is based on a default Theme object, which is a new object introduced in the latest GeneXus version. The Theme object improves the development and maintenance of Web applications by separating the developers work from the designers.
Step 5: Defining Formulas in GeneXus

Now lets 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
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
Step 6: Inserting a Business Rule

In this case we want to have the Invoice Date defaulted to Todays 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 todays date. 5. Click Save.
Figure 12 Transaction rule
Page 15 of 47
Step 7: Reviewing the Database after Creating the Invoice Object

1. On the Tools menu, click List Database. 2. Clear the Modified check box. 3. In the Select Object dialog box, click Select All and then click OK.
Figure 13 Select Object dialog box
Page 16 of 47
Figure 14 Impact Analysis Report
You can see that GeneXus automatically normalizes the tables, and creates two tables to support the Invoice object, Header & Detail: Table Invoice and Table Invoice1 (marked in the image above), with the following structure: <Invoice> InvoiceId InvoiceDate CustomerId CustomerNm <Invoice1> InvoiceId ItemId ItemDsc ItemPrice ItemQty
In addition, you will see that GeneXus automatically removes from the tables those attributes that we made as formulas, and makes them global formulas so you can access them automatically anywhere. Note: From the Menu: Advanced \ Table you can change a table name, add new indexes, or define redundancies.
Page 17 of 47
Step 8: Creating a Customer Object

To create the Customer Transaction follow Steps 2 and 3. The following attributes will be inserted in the Customer Transaction Structure: ATTRIBUTE 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
Figure 16 Customer transaction Win form
Figure 17 Customer transaction Web form
Step 9: Viewing Table Structure Changes

By reviewing the Database (Step 7) after the Customer Object was created you can see that GeneXus has automatically normalized the tables for you. You will see that GeneXus automatically moved the CustomerNm and CustomerAddress attributes from the Invoice table to the Customer Table.
Figure 18 Customer table structure
Page 19 of 47
Figure 19 Invoice table structure
The database structure is now the following: <Invoice> InvoiceId InvoiceDate CustomerId <Invoice1> InvoiceId ItemId ItemDsc ItemPrice ItemQty <Customer> CustomerId CustomerNm CustomerAddress CustomerEmail
Step 10: 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 wont 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
Step 12: Creating the Tables with the Database Manager

At this stage GeneXus launches its Database Manager, a GeneXus-generated program, to create the database, perform a data transfer (refactor the database when reorganizations are performed), rename tables, create indexes and update models. 1. In the GeneXus Database Reorganization dialog box, click Execute. The reorganization program is generated depending on your language selection in the GeneXus Create Model Wizard (Step 10). In this case the Database Manager is running a Visual Basic program to perform the tasks. 2. Click Exit.
Figure 26 Completed Database Reorganization
Page 23 of 47
Step 13: Specifying and Generating your Code

After the Database has been created, you can have GeneXus specify your objects and generate the programs in the language you selected (Visual Basic Code in this example). 1. On the Build menu, click Build All. You can also click Build All in the GeneXus toolbar.
Figure 27 GeneXus toolbar
2. Select the Type: Check specification and Other Options: Specify & Generate.
Figure 28 Build All dialog box
GeneXus presents you with a specification report for each program it will generate. The specification reports 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
Referential Integrity: It means that when you delete a customer from the Customer Transaction, the program will check that there arent 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
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.
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 wont 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 transactions windows and Web forms, respectively.
Figure 34 Item transaction win form
Figure 35 Item transaction web form
Page 28 of 47
Step 16: Viewing Table Structure Changes

After the Item object is saved, GeneXus will reorganize the tables again. The new database structure will be: <Invoice> InvoiceId InvoiceDate CustomerId <Invoice1> InvoiceId ItemId ItemQty <Customer> CustomerId CustomerNm CustomerAddress CustomerEmail <Item> ItemId ItemDsc ItemPrice
Reviewing the Database after the Item Object has been created allows you to see that GeneXus automatically normalizes the tables for you. You will see that GeneXus has automatically moved the ItemDsc and ItemPrice attributes from the Invoice1 (Invoice Detail) table to the Item Table.
Step 17: Impacting the Database

Now we will go back to Prototype as we did in Step 10, and GeneXus will perform an Impact to the application. 1. Select Prototype in the drop-down menu of the GeneXus toolbar. You will see that GeneXus automatically moves the attributes from the InvoiceHeader to the Item. 2. In the dialog box that is displayed, click OK.
Page 29 of 47
3. In the Impact Analysis Report dialog box, click Reorganize.
Step 18: Refactoring the Data and Generating the Programs

GeneXus will automatically transfer the data that was stored in the Invoice (Item data) to the Item Table.
Figure 38 Database reorganization dialog box
Page 30 of 47
1. On the Build menu, click Build\Specify or press SHIFT + F8 to display the Select Object dialog box. Note that only the Item object will appear (if the Edited Only checkbox is selected). Click OK.
Figure 39 Object selection dialog box
2. In the Specify Objects dialog box, select the Check specification option and click OK.
Figure 40 Object specification dialog box
3. In the Specification Report dialog box, click Generate to generate the program associated to the Item transaction.
Figure 41 Specification Report dialog box
Page 31 of 47
Step 19: Running your Application

Now lets 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 lets 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
Figure 52 Invoice Report Viewer
CONGRATULATIONS, you have successfully created an Invoice application in GeneXus; our next step is to show you how to move your application to another platform, .NET and/or JAVA.
Page 37 of 47
How to Move your Application to .NET and JAVA Step 1: Deploying your Application to .NET with Microsoft SQL Server
Note: Refer to the chapter: System Requirement / Generator Requirements / .NET, and make sure that you have all the software required to execute the application Next we will deploy the application to .NET with a SQL DB. 1. Select Design in the drop-down menu of the GeneXus toolbar. 2. On the File Menu, click New Model to display the GeneXus Create Model Wizard. 3. Name the model: Prototype .NET. 4. Select .NET with a Web interface and SQLServer as the DBMS. 5. Click Next.
Figure 53 Create Model Wizard, Step 1
6. In Step 2, select Driver and SQL Server 7. Write the name of the Database and the Server. In the example, the Database name is demo 5 and the Server name is (local) 8. Click Next.
The creation of the database is not performed by GeneXus when the creation process is carried out, so the database must be created manually before GeneXus actually creates the database tables. Please refer to your SQL Server manual for information on how to create the database.
Page 38 of 47
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
13. In Step 4, enter the Compiler and Virtual Directory paths and click Next. 14. In Step 5, click Finish.
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 applications menu will look like Fig. 60.
Figure 60 Application menu
Page 41 of 47
Step 2: Viewing the .NET Application Running
Figure 61 Invoice
Step 3: Deploying your Application to Java with Microsoft SQL Server

Note: Refer to the chapter: System Requirement / Software Requirements / JAVA Generator, and make sure that you have all the software required to execute the application. Next we will deploy the application to Java with a SQL DB. 1. In the GeneXus toolbar, select Design.
Page 42 of 47
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.
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.
The database is not created by GeneXus when the creation process is performed, so you must create the database manually before GeneXus actually creates the database tables. Please refer to your SQL Server manual for information on how to create the database.
Page 43 of 47
8. In Step 3, enter the user id and password for the DBMS login. In the example the User Id is user_name 8 9. Select the SQL Server version. 10. Click Next. 11. Enter the Servlet directory (the Servlet directory allows to specify the directory where the servlets generated will be transferred). In the example we use Resin and the Servlet directory is: C:\resin-2.1.7\doc\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.
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.
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
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
Step 4: Viewing the JAVA Application Running
Figure 66 Invoice
Page 46 of 47
Online Resources
GeneXus Community
The GeneXus Community provides a variety of ways to get answers to your questions, solutions to your problems, and to share your own expertise. Find the list of community resources available to you at: www.genexus.com/community
Support
ARTech offers a wide range of support services and resources: Self-Service Online Support These resources are available to anyone online. However, the information that you access depends on your GXTechnical Access Level. Interactive Support Services Interact with other members of the Community and with our Support Team. www.genexus.com/support
How to Buy
The GeneXus Technologies are sold through a network of distributors worldwide. Find a distributor near you at: www.genexus.com/distributors Otherwise, please contact sales@genexus.com
Page 47 of 47

Tuturial - Genexus (Vision General)

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Tuturial - Genexus (Vision General)

Cargado por

Copyright:

Formatos disponibles

GeneXus Visin General

Ta bla de Con t e n ido

Una implementacin del desarrollo incremental: GENEXUS

A cont inuacin se det alla cada una de est as t areas:

GeneXus trabaja con el conocimiento puro

Mltiples Plataformas / Arquitectura de Mltiples Capas

Impacto de los cambios sobre la base de datos:

Impacto de los cambios sobre los programas:

Consolidacin de varias aplicaciones y reutilizacin de conocimiento.

Caractersticas nicas de GENEXUS

Quines son los usuarios de GENEXUS?

Copyright ARTech Consultores 1988-1999. All rights reserved.

DISEO DE APLICACIONES CON GENEXUS

GENEXUS- DISEO DE APLICACIONES

GENEXUS- DISEO DE APLICACIONES

DESARROLLO DE UNA APLICACIN

GENEXUS DISEO DE APLICACIONES

Definir el equipo de trabajo

Obtener una imagen global

GENEXUS- DISEO DE APLICACIONES

Definir el alcance de la aplicacin

Mantener el diseo simple

Orientarse a los datos

GENEXUS DISEO DE APLICACIONES

GENEXUS- DISEO DE APLICACIONES

GENEXUS DISEO DE APLICACIONES

GENEXUS- DISEO DE APLICACIONES

Variables Eventos Help

Estructura de una transaccin

que componen la informacin que se quiere tener de un proveedor.

GENEXUS DISEO DE APLICACIONES

GENEXUS- DISEO DE APLICACIONES

GENEXUS DISEO DE APLICACIONES

Relacin entre la estructura y el modelo de datos

GENEXUS- DISEO DE APLICACIONES

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

GENEXUS DISEO DE APLICACIONES

GENEXUS- DISEO DE APLICACIONES

Dynamic List Box

GENEXUS DISEO DE APLICACIONES

Definicin de la transaccin de pedidos

Total del pedido

GENEXUS- DISEO DE APLICACIONES

Reglas para nombres de atributos

Integridad referencial en las transacciones

GENEXUS DISEO DE APLICACIONES

Niveles de una transaccin

Cantidad pedida Precio pedido Valor del articulo

GENEXUS- DISEO DE APLICACIONES

Nivel del cabezal Nivel de las lneas

Fecha de entrega Importe a pagar

GENEXUS DISEO DE APLICACIONES

porque existen dos lneas del Pedido con el mismo ArtCod.

GENEXUS- DISEO DE APLICACIONES

GENEXUS DISEO DE APLICACIONES

Tipos de relacin entre los objetos

GENEXUS- DISEO DE APLICACIONES

Form de una transaccin

GENEXUS DISEO DE APLICACIONES

Atributos que sern aceptados o desplegados en la pantalla

GENEXUS- DISEO DE APLICACIONES

Dilogo campo a campo

Barra o Botones de Men