Documentos de Académico
Documentos de Profesional
Documentos de Cultura
Página 2 de 14
Introducción
GeneXus es una herram ient a int eligent e, desarrollada por ARTe ch, cuyo obj et ivo es asist ir
al analist a y a los usuarios en t odo el ciclo de vida de las aplicaciones.
El diseño y prot ot ipo son realizados y probados en un am bient e Windows. Cuando el
prot ot ipo es t ot alm ent e aprobado por sus usuarios, la base de dat os y los program as de
aplicación son generados y/ o m ant enidos en form a t ot alm ent e aut om át ica, para el
am bient e de producción.
La idea básica de GeneXus es aut om at izar t odo aquello que es aut om at izable:
norm alización de los dat os y diseño, generación y m ant enim ient o de la base de dat os y de
los program as de aplicación. De est a m anera se evit a que el analist a deba dedicarse a
t areas rut inarias y t ediosas, perm it iéndole poner t oda su at ención en aquello que nunca un
program a podrá hacer: e nt e nde r los pr oble m a s de l usua r io.
Com o un subproduct o, GeneXus ofrece una docum ent ación rigurosa, aut osuficient e y
perm anent em ent e act ualizada.
Est e docum ent o t iene com o obj et ivo ilust rar al lect or sobre GeneXus y los problem as que
resuelve.
• El problem a t eórico - en est e capít ulo se hace una descripción com parada de las
m et odologías t radicionales de desarrollo de sist em as y el desarrollo increm ent al.
• Una im plem ent ación del desarrollo increm ent al: GeneXus.
Página 3 de 14
El problema teórico
La form a t radicional de desarrollar aplicaciones part e de una prem isa básica: e s posible
const r uir un m ode lo de da t os e st a ble de la e m pr e sa . Basándose en esa prem isa, la
prim era t area que se encara es el análisis de dat os, donde se est udia la realidad en form a
abst ract a y se obt iene com o product o el m odelo de dat os de la em presa. La segunda t area
es diseñar la base de dat os. Es m uy sencillo diseñar la base de dat os part iendo del m odelo
de dat os ya conocido.
Una vez que se ha est udiado la realidad desde el punt o de vist a de los dat os, se hace lo
propio desde el punt o de vist a de las funciones ( análisis funcional) . Sería deseable que el
est udio de la realidad t uviera com o product o una especificación funcional que dependiera
sólo de dicha realidad. Lo que se hace en las m et odologías m ás usadas, sin em bargo, es
obt ener una especificación funcional que se refiere a los archivos de la base de dat os ( o
bien a las ent idades del m odelo de dat os, lo que es esencialm ent e equivalent e) .
Una vez que se t iene la base de dat os y la especificación funcional, se pasa a la
im plem ent ación de las funciones, exist iendo t radicionalm ent e para ello varias opciones
( lenguaj es de 3ª . o 4ª generación, generadores, int erpret adores) .
Sin em bargo, t odas las form as de im plem ent ación vist as t ienen un problem a com ún:
part en de la enunciada prem isa: e s posible const r uir un m ode lo de da t os e st a ble de
la e m pr e sa , y est a prem isa es fa lsa .
Realm ent e no es posible hacer, de una form a abst ract a, un m odelo de dat os det allado de
la em presa y con el suficient e nivel de det alle y obj et ividad, porque nadie la conoce com o
un t odo.
Por ello es necesario recurrir a m últ iples int erlocut ores, y cada uno de ellos proyect a sobre
el m odelo, su propia subj et ividad. Una consecuencia de est o es que, durant e t odo el ciclo
de vida de la aplicación, se producen cam bios en el m odelo.
Pero aún si se considerara la sit uación ideal, donde se conocen exact am ent e las
necesidades y, ent onces, es posible definir la base de dat os ópt im a, el m odelo no podrá
perm anecer est át ico porque deberá acom pañar la evolución de la em presa
Todo est o sería poco im port ant e, si la especificación funcional y la base de dat os fueran
independient es. Sin em bargo, dado que la especificación funcional se refiere a la base de
dat os, las inevit ables m odificaciones en ést a im plican m odificaciones ( m anuales) en
aquella.
La m ayor consecuencia de lo ant erior est á const it uida por los m uy alt os cost os de
m ant enim ient o: en la m ayoría de las em presas que t rabaj an de una m anera convencional
se adm it e que el 80% de los recursos que t eóricam ent e est án dest inados al desarrollo,
realm ent e se ut ilizan para hacer m ant enim ient o de las aplicaciones ya im plem ent adas.
Cuando se t rat a de aplicaciones grandes la sit uación es aún peor: est e m ant enim ient o
com ienza m ucho ant es de la im plem ent ación, lo que hace que los cost os de desarrollo
crezcan en form a hiperlineal con respect o al t am año del proyect o.
Página 4 de 14
Dado que es m uy difícil, en est e cont ext o, det erm inar y propagar las consecuencias de los
cam bios de la base de dat os sobre los procesos, es habit ual que, en vez de efect uarse los
cam bios necesarios, se opt e por int roducir nuevos archivos redundant es, con la
consiguient e degradación de la calidad de los sist em as y el increm ent o de los cost os de
m ant enim ient o.
Metodología incremental
Una m anera alt ernat iva de resolver el problem a pasa por la sust it ución de la prem isa
básica enunciada: asum ir que no e s posible const r uir un m ode lo de da t os e st a ble de
la e m pr e sa y, en cam bio, ut ilizar una filosofía increm ent al.
Un esquem a increm ent al parece m uy nat ural: no se encaran grandes problem as, sino que
se van resolviendo los pequeños problem as a m edida que se present an.
¿Cuál será la repercusión de est e t ipo de esquem a sobre los cost os de m ant enim ient o?.
Si se ut ilizaran, con est e enfoque, las m et odologías ant eriorm ent e reseñadas, esa
repercusión sería m uy grande: el m odelo de dat os se m odificaría const ant em ent e y los
cost os de m ant enim ient o serían aún m ucho m ayores que los enunciados.
Puede verse, sin em bargo, lo siguient e:
No se conoce la base de dat os pero, cada usuario, conoce m uy bien las visiones de los
dat os que él ut iliza cot idianam ent e.
Esas visiones de los dat os pueden ser de varios t ipos: pant allas, list ados, et c. que
com ponen el aspect o ext erior de la aplicación: Aquello que es t angible para el usuario.
¿Cóm o puede ayudar el conocim ient o de est as visiones a obt ener el m odelo de dat os?
¿Puede t ransform arse el asunt o en un problem a m at em át ico?. Si ello fuera posible, la
m at em át ica podría brindar una am plia gam a de recursos para ayudar a resolverlo
aut om át icam ent e y, com o consecuencia, se sim plificaría m ucho la t area del analist a. Una
reflexión int eresant e es la siguient e: si se conociera la base de dat os, las visiones de los
dat os que t ienen los diferent es usuarios deberían poder derivarse de ella. O, dicho de ot ra
m anera, la base de dat os debe sat isfacer a t odas las visiones conocidas. Puede
dem ost rarse que, dado un conj unt o de visiones de dat os de usuarios, exist e siem pre una
base de dat os m ínim a que las sat isface, la cual, adem ás, es única. En est e est ado, el
problem a se ha t ransform ado en un problem a m at em át ico y, ent onces es preciso
resolverlo, para hallar esa base de dat os.
Pe r o, ¿cóm o se im ple m e nt a e st a t e or ía ?.
Se t rat a de capt urar el conocim ient o que exist e en las visiones de los usuarios, y
sist em at izarlo en una base de conocim ient o. La caract eríst ica fundam ent al de est a base de
conocim ient o, que la diferencia de los t radicionales diccionarios de dat os, es su capacidad
de inferencia: se pret ende que, en cualquier m om ent o, se puedan obt ener de est a base de
conocim ient o, t ant o elem ent os que se han colocado en ella, com o cualquier ot ro que se
pueda inferir a part ir de ellos.
Página 5 de 14
Si est e obj et ivo se logra, la base de dat os y los program as de aplicación pasan a ser
t ransform aciones det erm iníst icas de dicha base de conocim ient o y ello perm it e:
x Generarlos aut om át icam ent e.
x Ant e cam bios en las visiones de los usuarios:
Det erm inar el im pact o de dichos cam bios sobre dat os y procesos
Propagar esos cam bios generando:
⇒ los program as necesarios para convert ir los dat os;
⇒ los program as de la aplicación afect ados por los cam bios.
Página 6 de 14
A cont inuación se det alla cada una de est as t areas:
Diseño
Est a t area es realizada conj unt am ent e por el analist a y el usuario, y consist e en ident ificar
y describir las visiones de dat os de los usuarios.
El t rabaj o se realiza en el am bient e del usuario. Est e esquem a perm it e t rabaj ar con un
baj o nivel de abst racción, ut ilizando t érm inos y concept os que son bien conocidos por el
usuario final.
Una consecuencia m uy im port ant e, es que la act it ud del usuario se t ransform a en
francam ent e part icipat iva. El sist em a pasa a ser una obra conj unt a y, com o el usuario
sigue perm anent em ent e su evolución, su calidad es m ucho m ej or que la habit ual.
De acuerdo a lo vist o, GeneXus capt ura el conocim ient o por m edio de visiones de obj et os
de la realidad del usuario.
Los t ipos de obj et os soport ados por GeneXus son: Tr a nsa ccione s, Re por t e s,
Pr oce dim ie nt os, W or k Pa ne ls, W e b Obj e ct s, M e núe s, D a t a Vie w s, St yle s y
Tr a nsa ccione s de D a t a W a r e house .
La t area de diseño consist e, fundam ent alm ent e, en ident ificar y describir est os obj et os. A
part ir de est as descripciones, y aut om át icam ent e, GeneXus sist em at iza el conocim ient o
capt urado y va const ruyendo, en form a increm ent al, la Base de Conocim ient o.
Est a Base de Conocim ient o es un reposit orio único de t oda la inform ación del diseño, a
part ir de la cual GeneXus crea el m odelo de dat os físico ( t ablas, at ribut os, índices,
redundancias, reglas de int egridad referencial, et c.) , y los program as de aplicación.
Así, la t area fundam ent al en el análisis y diseño de la aplicación se cent ra en la descripción
de los obj et os GeneXus.
Veam os en det alle las clases de obj et os GeneXus m ás im port ant es:
Transacciones
Página 7 de 14
Una t ransacción es un proceso int eract ivo que perm it e a los usuarios crear, m odificar o
elim inar inform ación de la base de dat os.
Ej em plos:
Pant alla para crear, m odificar o elim inar los Client es de la Em presa.
Pant alla de fact uración: proceso que perm it e a un usuario crear fact uras e incluso
im prim irlas.
Una pant alla perm it e al usuario t om ar diferent es acciones com o insert ar, act ualizar,
elim inar, im prim ir sin t ener que volver al m enú para hacerlo.
Reportes
Un inform e es un proceso que perm it e visualizar los dat os de la base de dat os. La salida
del list ado puede ser enviada a pant alla o a la im presora ( y con ello t enem os un list ado
convencional) .
Con est e obj et o se pueden definir desde list ados sim ples ( por ej em plo, list ar los
client es) hast a m uy sofist icados, en donde exist an varios cort es de cont rol, m últ iples
lect uras a la base de dat os y param et rización.
Sin em bargo un I nform e no puede act ualizar la base de dat os.
Procedimientos
Est e obj et o t iene t odas las caract eríst icas de los Report es, y adem ás perm it e act ualizar
la base de dat os. Los Procedim ient os son com únm ent e usados para dos t ipos de
procesos:
x Procesos bat ch de act ualización. Por ej em plo: elim inar t odas las fact uras de fecha
ant erior a una fecha dada y que ya fueron pagadas.
x 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')
x Procesos a ej ecut ar en un servidor de aplicaciones o servidor de base de dat os:
procesos ( generalm ent e escrit os en C/ SQL, Java o .NET) para una Mult i Tier
Archit ect ure, para ser ej ecut ados en un servidor de aplicaciones o de bases de
dat os.
Work Panels
Un Work Panel es una pant alla que perm it e al usuario realizar consult as int eract ivas a la
base de dat os. Cuant o m ás los usuarios ut ilizan el com put ador para su t rabaj o, se t orna
m ás necesaria la ut ilización de diálogos sofist icados, que le perm it an sent arse a pensar
frent e al m ism o.
Los work panels perm it en diseñar est e t ipo de diálogos del usuario.
Por ej em plo: Un work panel que m uest ra la list a de client es y que perm it e ( a elección
del usuario) ver cuales son sus fact uras o su deuda.
Web Objects
Son sim ilares al conj unt o de Work Panels y Transacciones, pero son usados en browsers
en am bient e I nt ernet / I nt ranet / Ext ranet .
Menúes
Página 8 de 14
Un m enú es una pant alla que cont iene una serie de opciones fij as que el usuario
selecciona para ej ecut ar.
Data Views
Perm it en considerar correspondencias ent re t ablas de bases de dat os preexist ent es y
t ablas GeneXus y t rat ar aquellos con la m ism a int eligencia com o si fueran obj et os
GeneXus.
Styles
El est andarizar lo m ás posible una aplicación es un reconocido buen crit erio de diseño.
En part icular, la int erfaz de usuario de una aplicación result a crít ica para const ruir
sist em as am igables. Cuant o m ás est ándar sean los diálogos, m ás fácil de usar será la
aplicación.
Los St yles const it uyen un t ipo de obj et o GeneXus orient ado a la definición de int erfaces
de usuario y est ándares de program ación. Los St yles ofrecen una serie de m ecanism os
para definir form at os de pant allas, reglas del negocio y event os que serán ut ilizados
luego por GeneXus en form a aut om át ica, obt eniendo sist em as de m ayor calidad y
dism inuyendo sensiblem ent e los t iem pos de desarrollo.
Página 9 de 14
Hoy es com ún que una m ism a aplicación debe t ener algunas part es corriendo en una
plat aform a y alguna en ot ras, y que t odas se puedan com unicar correct am ent e.
El desarrollo con GeneXus perm it e que una aplicación pueda ser dividida para ser
ej ecut ada en diferent es plat aform as y generada, para cada una, en el lenguaj e m ás
adecuado, obt eniendo así arquit ect uras de m últ iples part es ( m ult i- t ier) y que hagan un
m ej or uso de los recursos disponibles.
Prototipo
En las t areas de diseño est án im plícit as las dificult ades de t oda com unicación hum ana:
x El usuario olvida ciert os det alles;
x El analist a no t om a not a de algunos elem ent os;
x El usuario se equivoca en algunas apreciaciones;
x El analist a int erpret a m al algunas explicaciones del usuario.
Pero, adem ás, la im plem ent ación de sist em as es, habit ualm ent e, una t area que insum e
bast ant e t iem po, por lo que:
x Com o m uchos de est os problem as sólo son det ect ados en las pruebas finales del
sist em a, el cost o ( t iem po y dinero) de solucionarlos es m uy grande;
x 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;
x la consecuencia de la congelación de las especificaciones, es que se acaba
im plem ent ando una solución relat ivam ent e insat isfact oria.
El im pact o de est os problem as dism inuiría m ucho si se consiguiera probar cada
especificación, inm ediat am ent e, y saber cual es la repercusión de cada cam bio sobre el
rest o del sist em a.
Una prim era aproxim ación a est o, ofrecida por diversos sist em as, es la posibilidad de
m ost rar al usuario form at os de pant allas, inform es, et c. anim ados por m enúes. Est o
perm it e ayudar al usuario a t ener una idea de qué sist em a se le const ruirá pero,
post eriorm ent e, siem pre se present an sorpresas.
Una sit uación bast ant e diferent e sería la de poner a disposición del usuario para su
ej ecución, inm ediat am ent e, una aplicación funcionalm ent e equivalent e a la deseada, hast a
en los m ínim os det alles.
Est o es lo que hace GeneXus: Un prot ot ipo GeneXus es una aplicación pront a,
funcionalm ent e equivalent e a la aplicación de producción.
La diferencia ent re prot ot ipación y producción consist e en que la prim era se hace en un
am bient e de m icrocom put ador, m ient ras que la producción se realiza en el am bient e
obj et o del usuario ( I BM iSeries, Client e / Servidor, JAVA, .NET) .
El prot ot ipo perm it e que la aplicación sea t ot alm ent e probada ant es de pasar a producción.
Durant e est as pruebas, el usuario final puede t rabaj ar con dat os reales, o sea que prueba,
de una form a nat ural, no solam ent e form at os de pant allas, inform es, et c. sino t am bién
fórm ulas, reglas del negocio, est ruct uras de dat os, et c.
La filosofía de GeneXus es de de sa r r ollo incr e m e nt a l. Cuando se t rabaj a en un am bient e
t radicional, los cam bios en el proyect o hechos durant e la im plem ent ación y, sobre t odo,
aquellos que son necesarios luego de que el sist em a est á im plant ado, son m uy onerosos.
GeneXus resuelve est e problem a: const ruye la aplicación con una m et odología de
Página 10 de 14
aproxim aciones sucesivas que perm it e, una vez det ect ada la necesidad de cam bios,
prot ot iparlos y probarlos inm ediat am ent e por part e del usuario, sin cost o adicional.
Implementación
GeneXus genera aut om át icam ent e el código necesario para:
x Crear y m ant ener la base de dat os;
x Generar y m ant ener los program as para m anej ar los obj et os descrit os por el
usuario.
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.
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.
Mantenimiento
Est a es quizás la caract eríst ica m ás im port ant e de GeneXus, y la que lo diferencia de
m anera m ás clara de sus com pet idores: el m ant enim ient o, t ant o de la base de dat os
( est ruct ura y cont enido) com o de los program as, es t ot alm ent e aut om át ico.
A cont inuación se explicará el proceso de m ant enim ient o, ant e cam bios en la descripción
de algún obj et o GeneXus ( visión del usuario) :
Aná lisis de im pa ct o:
Una vez descrit os los cam bios de las visiones de usuarios, GeneXus analiza
aut om át icam ent e cual es el im pact o de los m ism os sobre la base de dat os y produce un
inform e donde explica com o debe hacerse la conversión de los dat os y, si cabe, qué
problem as pot enciales t iene esa conversión ( inconsist encias por viej os dat os ant e
nuevas reglas, et c.) . El analist a decide si acept a el im pact o y sigue adelant e o no.
Página 11 de 14
Ge ne r a ción de pr ogr a m a s de conve r sión:
Una vez que los problem as han sido solucionados o bien se ha acept ado la conversión
" default " , que GeneXus realiza en form a est ándar, se generan aut om át icam ent e los
program as para hacer la conversión ( est ruct ura y cont enido) de la viej a base de dat os a
la nueva.
Ej e cución de los pr ogr a m a s de conve r sión:
A cont inuación, se pasa al am bient e de ej ecución que corresponda ( prot ot ipo,
producción I nt ernet , producción Client e / Servidor, et c.) y se ej ecut an los program as de
conversión.
Aná lisis de im pa ct o:
A cont inuación, GeneXus analiza el im pact o de los cam bios sobre los program as, y
produce un diagnóst ico inform ando qué program as deben generarse o re- generarse y
proporcionando t am bién, para el nuevo program a, o bien el diagram a de navegación o
bien un pseudo- código, a elección del analist a.
Documentación
Todo el conocim ient o provist o por el analist a, o inferida por GeneXus, est á disponible en
un reposit orio act ivo, que const it uye una m uy com plet a docum ent ación on- line,
perm anent em ent e act ualizada.
Página 12 de 14
Características únicas de GENEXUS
GeneXus t iene algunas caract eríst icas únicas que lo dist inguen de sus com pet idores. Ent re
ellas pueden dest acarse:
x I nt eract ivo: El punt o de part ida es la descripción nat ural del usuario de los obj et os.
x La descripción de cada obj et o es t ot alm ent e independient e de la de los dem ás por lo
que, en el caso de que se deba m odificar la descripción de uno, ello no im plicará la
necesidad de m odificar m anualm ent e la descripción de cualquier ot ro. Est a caract eríst ica
exclusiva de GeneXus es la que perm it e un m ant enim ient o t ot alm ent e aut om át ico de las
aplicaciones.
x La curva de aprendizaj e es cort a.
x Diseño, creación y m ant enim ient o de la base de dat os son t ot alm ent e aut om át icos.
x La aplicación ( base de dat os y program as) t iene siem pre, sean cuales sean las
m odificaciones que haya sufrido, la m ej or calidad:
La base de dat os es siem pre la ópt im a,
No se m odifican program as: cuando ya no son adecuados, se generan ot ros nuevos,
ópt im os y no rem endados, que los sust it uyen.
x Lenguaj es poderosos y de m uy alt o nivel para la definición de PROCESOS, WORK
PANELS y WEB OBJECTS, así com o una definición de MENUES m uy sim ple. En est os
lenguaj es las descripciones de los procesos se hacen sin referirse a los archivos
involucrados, los que son inferidos aut om át icam ent e en t iem po de generación. Est a
caract eríst ica perm it e una t ot al independencia ent re los dat os y dichas especificaciones.
Com o consecuencia, las especificaciones de alt o nivel de GeneXus no necesit an
m odificaciones de la base de dat os.
x Ut ilización los archivos o bases de dat os preexist ent es com o propios de GeneXus.
x 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.
x GeneXus funciona en PC’s, dej ando el com put ador de producción t ot alm ent e libre para
el procesam ient o de las aplicaciones.
x Fácil dist ribución del conocim ient o corporat ivo para facilit ar el desarrollo de nuevas
aplicaciones.
x Sim ple y poderosa solución para Dat a Warehousing.
x Verificación aut om át ica de consist encia, y consolidación, ent re aplicaciones desarrolladas
separadam ent e.
x I ndependencia de plat aform a y arquit ect ura.
x 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.
Página 13 de 14
Ent re los client es exist en em presas de t odo t ipo y área de act ividad. Los client es
generalm ent e desarrollan con GeneXus grandes aplicaciones corporat ivas de m isión crít ica.
Generalm ent e desarrollan con GeneXus el 100% de las m ism as.
Exist en m ás de 1.000 casas de soft ware, en t odo el m undo, que desarrollan sus
aplicaciones 100% con GeneXus, lo que represent a algunos m iles de client es indirect os
que usan aplicaciones GeneXus.
GeneXus and ARTech are trademarks or registered trademarks of ARTech Consultores S.R.L.
ARTech recognizes that all other trademarks contained herein are property of their respective holders
Página 14 de 14
GENEXUS
Diseño de Aplicaciones
INTRODUCCIÓN
El presente documento es una introducción al desarrollo de aplicaciones utilizando
GENEXUS. Está dirigido a profesionales de informática que se inician en el uso de
GENEXUS.
GENEXUS es una herramienta para el desarrollo de aplicaciones. Su objetivo es ayudar a
los analistas de sistemas a implementar aplicaciones en el menor tiempo y con la mejor
calidad posible.
A grandes rasgos, el desarrollo de una aplicación implica tareas de análisis, diseño e
implementación. La vía de GENEXUS para alcanzar el objetivo anterior es liberar a las
personas de las tareas automatizables (por ejemplo, la implementación), permitiendoles
así concentrarse en las tareas realmente difíciles y no automatizables (análisis y diseño).
Desde un punto de vista teórico, GENEXUS es más una metodología de desarrollo de
aplicaciones que una herramienta de software. Como metodología, tiene algunos puntos
de contacto con las metodologías tradicionales, pero también aporta enfoques bastante
diferentes en otros.
En común con las metodologías tradicionales, se mantiene la importancia del análisis y
diseño de la aplicación sobre la implementación. Quizás con GENEXUS este enfoque se
resalta más aún, ya que el usuario de GENEXUS estará la mayor parte del tiempo
realizando tareas de análisis y GENEXUS, en sí, tareas de implementación (por ejemplo,
normalización de la base de datos, generación de programas, etc.).
Por otro lado, algunos de los enfoques metodológicos son bastante diferentes que los
habituales, como, por ejemplo, el comenzar el análisis de la aplicación por la interfase del
mismo con el usuario, la casi nula referencia a la implementación física del sistema, etc.
Para presentar estos nuevos conceptos, y a los efectos de no realizar una presentación
demasiado abstracta del tema, se ha elegido una aplicación que se irá desarrollando a
través de los distintos capítulos.
El primer capítulo presenta la aplicación y los aspectos iniciales de un desarrollo con
GENEXUS.
El segundo capítulo trata el diseño de Transacciones, el tercero de Reportes, el cuarto de
Procedimientos, el quinto de Paneles de Trabajo y por último se trata el diseño de
Menúes.
Debido a que en todos los capítulos se asume cierto conocimiento sobre Bases de Datos
Relacionales, se ha incluido un anexo sobre el tema que describe los conceptos necesarios
para este documento. Se recomienda su lectura antes de leer el segundo capítulo.
Por razones didácticas, en este documento no se tratan los siguientes temas:
• Ciclo de vida de una aplicación: Una aplicación tiene un ciclo de vida, que
comienza cuando se planifica la misma y termina cuando la aplicación sale de
producción. GENEXUS acompaña todo este ciclo. Este tema es tratado en el
documento Visión General, que recomendamos leer previamente.
1
GENEXUS DISEÑO DE APLICACIONES
2
GENEXUS- DISEÑO DE APLICACIONES
Definir el objetivo
No se debe olvidar que los computadores son meras herramientas. Los usuarios de los
sistemas tienen objetivos específicos. Ellos esperan que la aplicación los ayude a
alcanzarlos mas rápido, mas fácil, o a un menor costo. Es parte del trabajo de análisis, el
conocer esos propósitos y saber por medio de que actividades los usuarios quieren
alcanzarlos.
Este objetivo debe poder ser expresado en pocas palabras (uno o dos párrafos) y ser
conocido por todas las personas involucradas con el sistema.
En el ejemplo, alguno de los propósitos posibles son:
De todos los objetivos posibles se debe elegir uno como el objetivo principal o
prioritario. Esto es muy importante para el futuro diseño de la aplicación. Basta con
observar como los distintos objetivos anteriores conducen a diseños diferentes.
3
GENEXUS DISEÑO DE APLICACIONES
Para nuestro ejemplo elegiremos el primer objetivo, dado que en la situación real el
analista de compras no tenia toda la información que necesitaba. Por lo tanto, debía
consultar una serie de planillas manuales y llamar por teléfono a los empleados del
deposito para que realizaran un conteo manual del stock.
No se debe confundir el objetivo de la aplicación (el QUE) con la funcionabilidad de la
misma (COMO se alcanzará el objetivo).
• El analista de sistemas.
• Y un usuario.
Los analistas de sistemas que trabajen en el desarrollo de la aplicación deben cumplir dos
condiciones:
Se recomienda que dichos analistas pasen algún tiempo trabajando con los usuarios en el
comienzo del proyecto a los efectos de familiarizarse con los conceptos, vocabulario,
problemas existentes, etc.
Como la aplicación se desarrolla de una manera incremental, es MUY IMPORTANTE la
participación de los usuarios en todas las etapas del desarrollo. Se recomienda tener un
usuario principal disponible para la prueba de los prototipos y tener acceso a los demás
usuarios de una manera fluida.
Dado que con GENEXUS los miembros del equipo estarán la mayor parte del tiempo
trabajando en tareas de diseño y no de codificación, se debe tomar como criterio general
el trabajar en equipos PEQUEÑOS, por ejemplo, no más de cinco personas.
4
GENEXUS- DISEÑO DE APLICACIONES
En el ejemplo, una vez que una orden de compra es enviada a un proveedor, se debe
controlar como y cuando se fueron entregando efectivamente los productos. Sin embargo
vemos que esto no es imprescindible para cumplir el objetivo de la aplicación y por lo
tanto no será tratado.
Las funciones de un sistema tienden a evolucionar con el tiempo, y por lo tanto, un diseño
basado en las funciones será más difícil de mantener.
La idea que una aplicación se puede definir por una única función es muy controvertida
en aplicaciones medias o grandes.
Frecuentemente se descuida el análisis de las estructuras de datos.
No facilita la integración de aplicaciones.
Si, por el contrario, el diseño se basa en los datos, se puede obtener las siguientes
ventajas:
5
GENEXUS DISEÑO DE APLICACIONES
Más estabilidad. Los datos tienden a ser más estables que los procesos y en consecuencia
la aplicación será más fácil de mantener.
Sin embargo, si bien vemos que orientarse a los datos es beneficioso, la pregunta es como
analizar los datos?. La respuesta de GENEXUS es analizar directamente los datos que el
usuario conoce, sin importar como se implementarán en el computador.
El diseño comienza -como veremos más en detalle en el siguiente capítulo- estudiando
cuales son los objetos que el usuario manipula. Para cada uno de estos objetos se define
cual es su estructura de datos y posteriormente cual es su comportamiento.
De esta manera se alcanzan dos objetivos importantes: el análisis se concentra en hechos
objetivos, y este puede ser evaluado directamente por los usuarios, utilizando la facilidad
de prototipación de GENEXUS.
6
GENEXUS- DISEÑO DE APLICACIONES
DISEÑO DE TRANSACCIONES
El análisis mismo de la aplicación comienza con la definición de las transacciones. De
cualquier manera es importante tener en cuenta que todo el proceso de desarrollo es
incremental y por lo tanto no es necesario definir en esta etapa todas las transacciones y
cada una de ellas en su mayor detalle. Por el contrario lo importante aquí es reconocer las
mas relevantes y para cada una de ellas cual es la estructura mas adecuada.
Para poder definir cuales son las transacciones se recomienda estudiar cuales son los
objetos (reales o imaginarios) que el usuario manipula. Afortunadamente es posible
encontrar la mayor parte de las transacciones a partir de:
Analistas de compras
Pedidos
Proveedores
Artículos
Ordenes de Compra
Estructura
De que atributos (campos en la metodología tradicional) esta compuesta y que
relación tienen entre si.
Pantalla o Form
Cual es el form que tiene. Esto se realiza con un editor especializado.
Fórmulas
Que atributos se calculan a partir de otros atributos. Por ejemplo: Valor = Cantidad *
Precio.
Reglas
7
GENEXUS DISEÑO DE APLICACIONES
Conjunto de reglas que debe cumplir la transacción. Por ejemplo cuales son los
valores por defecto de los atributos, cuales son los controles en los datos que hay que
realizar, etc.
Eventos
Las transacciones soportan la programación dirigida por eventos. Este tipo de
programación permite el almacenamiento de código ocioso el cual es activado luego
de ciertos eventos - provocados por el usuario o por el sistema.
Propiedades
Reglas que definen el comportamiento general de la transacción.
Form Classes
Cada objeto puede tener asociado mas de un form que pertenece a una determinada
Form Class. Existen dos Form Classes predefinidas: Graphic y Text. Tipicamente la
Form Class Graphic se usa para los ambientes graficos (por ejemplo: Windows) y la
form class Text se usa para los ambientes que trabajan en modo texto (por ejemplo:
AS/400) El combo box que se muestra en la siguiente figura permite seleccionar un
form (de determinada Form Class) de los que se hayan asociado al objeto.
Style Asociado
Styles son básicamente objetos GENEXUS (su forma de definición es similar a los
otros objetos), pero no son tenidos en cuenta en la normalización o generación de
programas; sólo se utilizan para definir estándares. Un ejemplo puede aclarar la idea:
supongamos que se quiere definir las transacciones con botones con bitmaps en vez de
los usuales de texto. Cuando se crea una transaccion se puede asociar un style en el
cual se basara la transaccion.
Ayuda
Texto para la ayuda a los usuarios en el uso de la transacción.
Documentación
Texto técnico que se incluye para ser utilizado en la documentación del sistema.
8
GENEXUS- DISEÑO DE APLICACIONES
Forms
Estructura
Form
Fast Access Toolbar
Cuando se bare un objeto esta toolbar se habilita con las siguientes opciones:
Reglas
Propiedades
Variables
Eventos
Help
9
GENEXUS DISEÑO DE APLICACIONES
Atributos
Para cada atributo se debe definir:
10
GENEXUS- DISEÑO DE APLICACIONES
El tipo de dato Long Varchar (por Variable Character) permite almacenar una
cantidad de caracteres indefinida. Se utiliza normalmente para almacenar textos, por
ejemplo notas, descripciones, comentarios, etc.
Picture - Formato del campo que permite una visualización en la entrada y salida, por
ejemplo: en campos caracter @! significa que todos los caracteres se aceptan y
despliegan en mayúsculas.
1:20 30: significa que el valor debe estar entre 1 y 20 o ser mayor que 30
1 2 3 4 significa que el valor debe ser 1 o 2 o 3 o 4
'S' 'N' significa que el valor debe ser 'S' o 'N'
Dominios
Es común cuando estamos definiendo la base de datos, tener atributos que comparten
definiciones similares, y que no se puede establecer ninguna relación directa entre
ellos. Por ejemplo, es común almacenar todos los nombres en atributos de tipo
caracter y largo 25. El uso de dominios permite usar definiciones de atributos
genéricos. Por ejemplo en la transacción de proveedores tenemos el nombre
(PrvNom) y mas adelante vamos a definir el nombre del analista, entonces podemos
definir un dominio Nombres de tipo caracter con largo 25 y asociarlo a estos atributos.
Por lo tanto si en el futuro cambia la definición de este dominio, los cambios serán
propagados automáticamente a los atributos que pertenecen a él.
Atributos Clave
También es necesario definir cual es el atributo o conjunto de atributos que identifican
a la transacción (es decir que los valores de los atributos identificadores son únicos),
esto se hace poniendo un * al final del o los atributos:
PrvCod*
PrvNom
PrvDir
así se indica que no existen dos proveedores con el mismo Código de Proveedor.
11
GENEXUS DISEÑO DE APLICACIONES
En los casos en los cuales no se puede determinar un identificador se debe optar por
crear un atributo artificial (no existente en la realidad) y cuyo valor es asignado
automáticamente por el sistema.
Atributos:
PrvCod* (con * se indica clave primaria)
PrvNom
PrvDir
Indices:
IPROVEED (PrvCod) Clave Primaria
12
GENEXUS- DISEÑO DE APLICACIONES
Analista de compra:
Artículos:
ArtCod* Código de articulo
ArtDsc Descripción del articulo
ArtCnt Cantidad en Stock
ArtFchUltCmp Fecha ultima compra
ArtPrcUltCmp Precio ultima compra
ArtUnidad Unidad del articulo
ArtSize Tamaño
ArtDisponible Disponibilidad
Tabla: ANALISTA
AnlNro*
AnlNom
Tabla: ARTICULO
ArtCod*
ArtDsc
ArtCnt
ArtFchUltCmp
ArtPrcUltCmp
ArtUnidad
ArtSize
ArtDisponible
13
GENEXUS DISEÑO DE APLICACIONES
Tipos de controles
Edit
Normalmente los atributos tienen un rango de valores muy grande, (por ejemplo: un
nombre, un precio, etc). En estos casos se le permite al usuario entrar el valor del
atributo y el sistema se encarga de validarlo. A estos tipos de controles se los llama
‘Edit Box’. En el ejemplo, Artcod, ArtDsc, etc.
Sin embargo existen atributos que tienen un rango de valores muy pequeño y que
pueden ser desplegados de antemano para que el usuario seleccione uno. De esta
forma controlamos que ingresen solo valores válidos. Estos tipos de controles son los
que veremos a continuación.
Check Box
Es usado para aquellos atributos que tienen solo dos posibles valores True o False
(como en nuestro ejemplo para señalar si existe disponibilidad del artículo). Existe
14
GENEXUS- DISEÑO DE APLICACIONES
una única descripción (Disponible) y en caso que este campo este seleccionado el
valor será True y en caso contrario será False.
Radio Buttom
Los ‘Radio Buttom’, en cambio, pueden tener mas de dos valores. Todos los valores
se despliegan en el form (en realidad se despliegan sus descripciones, el valor que se
almacena es manejado internamente) y solo se puede seleccionar uno. En el ejemplo
el tamaño del articulo lo definimos como un Radio Buttom.
Combo Box
Es generalmente usado para aquellos atributos que tienen un rango grande de valores,
y que con un Radio Buttom no seria muy practico el manejo. Se despliega un campo
de tipo Edit y presionando un botón que se encuentra a la derecha del campo se
despliega una lista con todos los valores validos. No es recomendable usar este campo
como listas de selección de atributos que tienen valores que no pueden ser
determinados a priori, (que son leídos de una tabla). Para estos casos se usan los
Dynamic Combobox.
Dynamic Combobox
Un dynamic combobox es un tipo de control similar al combo box, la diferencia es
que los valores posibles se leen de una tabla de la base de datos. La forma de
operación es similar a la del combo box, solo que los valores desplegados son
descripciones leídas de una determinada tabla.
List Box
Este tipo de control tiene asociada una colección de ítems. Cada ítem tiene asociado
un par <valor,descripción>. Existe la posibilidad de cargar la colección de ítems tanto
en diseño como en runtime. El control da la posibilidad de seleccionar un solo ítem a
la vez. El atributo o variable toma el valor en el momento que se selecciona el ítem.
La selección se realiza dando click con el mouse en un ítem o con las flechas del
teclado.
15
GENEXUS DISEÑO DE APLICACIONES
Total 18000
16
GENEXUS- DISEÑO DE APLICACIONES
Proveedores y los Pedidos y también entre los Analistas y los Pedidos, en particular
aquí estamos indicando que un Pedido solo tiene UN Proveedor y solo UN Analista.
Se tiene así que la forma de indicar a GENEXUS la relación entre las distintas
transacciones se base en los nombres de los atributos.
Tabla: PEDIDOS
PedNro*
PedFch
PrvCod
AnlNro
PedTot
Índices:
17
GENEXUS DISEÑO DE APLICACIONES
que tiene a PrvCod como clave primaria, y la PEDIDOS que lo tiene como clave
extranjera. La relación, que llamaremos de integridad referencial, es:
PedNro*
PedFch
PrvCod
PrvNom
AnlNro
AnlNom
ArtCod
ArtDsc
PedCnt Cantidad pedida
PedPre Precio pedido
PedImp Valor del articulo
PedTot
porque esto significaría que para cada pedido existe solo UN articulo, lo que no se
corresponde con el formulario. La estructura correcta es:
18
GENEXUS- DISEÑO DE APLICACIONES
PedNro*
PedFch
PrvCod
PrvNom
AnlNro Nivel del
AnlNom cabezal
( ArtCod*
ArtDsc Nivel de las
PedCnt líneas
PedPre
PedImp )
PedTot
donde el identificador es PedNro y para cada numero de pedido existe solo una fecha,
un código y nombre de proveedor, un número y nombre del analista y un solo total,
pero muchos Artículos, cantidades pedidas, precios y importes de la línea .
Los paréntesis indican que para cada Pedido existen muchos Artículos. Cada grupo de
atributos que se encuentra encerrado por paréntesis diremos que pertenece a un
NIVEL de la transacción.
Cabe notar que el primer nivel queda implícito y no necesita un juego de paréntesis.
Así, la transacción de Pedidos tiene dos niveles: PedNro, PedFch, PrvCod, PrvNom,
AnlNro, AnlNom y PedTot pertenecen al primer nivel y ArtCod, ArtDsc, PedCnt,
PedPre y PedImp pertenecen al segundo nivel.
Una transacción puede tener varios niveles y ellos pueden estar anidados o ser
paralelos entre si. Por ejemplo si el Pedido tiene varias fechas de entrega:
PedNro*
PedFch
PrvCod
PrvNom
AnlNro
AnlNom
( ArtCod*
ArtDsc
PedCnt
PedPre
PedImp )
( PedFchEnt* Fecha de entrega
PedImpPag ) Importe a pagar
PedTot
19
GENEXUS DISEÑO DE APLICACIONES
Con esta estructura se define que un Pedido tiene muchos Artículos y muchas
Entregas, pero no hay relación directa entre ambas (a no ser el hecho de pertenecer al
mismo Pedido). Si por el contrario las fechas de entrega son por articulo (cada
articulo tiene sus fecha de entrega particulares), la estructura correcta es:
PedNro*
PedFch
PrvCod
PrvNom
AnlNro
AnlNom
( ArtCod*
ArtDsc
PedCnt
PedPre
PedImp
( PedFchEnt*
PedImpPag ) )
PedTot
Así como la transacción tiene un identificador, cada nivel de la misma también debe
tener uno. Por ejemplo en el Pedido tenemos que el identificador del segundo nivel es
ArtCod. Con esto se indica que dentro de cada Pedido no existen dos líneas del
Pedido con el mismo ArtCod, y por lo tanto el siguiente Pedido no es valido:
Total 18000
20
GENEXUS- DISEÑO DE APLICACIONES
Aquí también se deben tener en cuenta los criterios sobre identificadores que se
mencionaron previamente. En particular, es común definir atributos artificiales cuando
no hay identificadores naturales, por ejemplo, para el caso en que si puede haber
varias veces el mismo articulo en el pedido, se debe definir el Pedido como:
PedNro*
PedFch
PrvCod
PrvNom
AnlNro
AnlNom
( PedLinNro*
ArtCod
ArtDsc
PedCnt
PedPre
PedImp )
PedTot
en donde el PedLinNro lo puede digitar el usuario o se puede incluir una regla para
que lo haga automáticamente la transacción.
Tabla: PEDIDOS
PedNro*
PedFch
PrvCod
AnlNro
PedTot
Tabla: PEDIDOS1
PedNro*
PedLinNro*
ArtCod
PedCnt
PedPre
PedImp
21
GENEXUS DISEÑO DE APLICACIONES
PrvCod*
PrvNom
....
(PedNro*
....
)
PedNro*
....
PrvCod
PrvNom
....
Vemos que generalmente para cada relación N-1 habrá una relación simétrica 1-N. En
estos casos se debe definir la estructura N-1 y no la 1-N.
Otro caso muy común son las relaciones M-N, por ejemplo entre los pedidos y los
Artículos:
22
GENEXUS- DISEÑO DE APLICACIONES
PedNro*
PedFch
PrvCod
PrvNom
AnlNro
AnlNom
( ArtCod*
ArtDsc
PedCnt
PedPre
PedImp )
PedTot
o:
ArtCod*
ArtDsc
( PedNro*
PedFch
PrvCod
PrvNom
AnlNro
AnlNom
PedTot
PedCnt
PedPre
PedImp )
Se debe definir solo una de las dos estructuras, en este caso la correcta es la primera,
porque el usuario ingresa los pedidos con sus Artículos y no para cada articulo que
pedidos tiene.
23
GENEXUS DISEÑO DE APLICACIONES
agregar o quitar forms a través de las opciones Edit/Add New Form o Edit/Select Forms.
Tambien se puede seleccionar el form con el cual se desea trabajar seleccionándolo del
combo box que aparece en la toolbar.
También se puede asociar un style y aplicarlo. El style se asocia en cada objeto en las
propiedades del mismo.
Para los Proveedores la pantalla por defecto (en este caso en modo gráfico) es:
Utilizando solo esta pantalla el usuario final puede crear, modificar o eliminar
proveedores. Para ello la pantalla tiene un Modo, que indica cual es la operación que se
esta realizando (Insertar, Modificar, etc.) y el usuario puede pasarse de un modo a otro sin
tener que abandonar la pantalla.
GENEXUS puede generar dos tipos de diálogo para las transacciones, full-screen o campo
a campo.
Diálogo full-screen
Este tipo de diálogo se genera para las plataformas donde se utilizan terminales no
programables, por ejemplo para el IBM AS/400.
El funcionamiento básico del diálogo full-screen es:
24
GENEXUS- DISEÑO DE APLICACIONES
Este proceso tiene leves alteraciones según el modo (Insertar, Modificar, etc.), ya que
si se encuentra en modo Insertar se aceptan los identificadores, pero si se esta en
modo Modificar no, etc.
El pasaje de un modo a otro se realiza presionando teclas de función. Por ejemplo con
F6 se pasa a modo Insertar, con F11 a modo Modificar, etc.
25
GENEXUS DISEÑO DE APLICACIONES
Vemos que hay algunos atributos que deben ser digitados (son atributos de entrada),
por ejemplo PedNro y PrvCod y otros que no, como ser PrvNom (son atributos de
salida). GENEXUS automáticamente determina que atributos son aceptados y de cuales
solo se muestra su valor, siguiendo las reglas:
Facilidad de Prompt
Para los atributos que están involucrados en la integridad referencial de la tabla base
del nivel se genera la facilidad de Prompt que permite visualizar cual es el conjunto de
valores validos para esos atributos. Por ejemplo, en la transacción de Pedidos
presionando una tecla especial se puede visualizar cuales son todos los proveedores,
con la siguiente pantalla:
26
GENEXUS- DISEÑO DE APLICACIONES
27
GENEXUS DISEÑO DE APLICACIONES
En ésta se aceptan primero los datos de entrada del primer nivel (los del cabezal del
pedido: Numero, Fecha, Proveedor y Analista), posteriormente se validan y se pide
confirmación y luego se realiza el mismo proceso para cada una de las líneas del
pedido.
Cuando se genera el form por defecto se diseña un subfile para el último nivel de la
transacción, en el ejemplo las líneas del pedido.
Trabajando con el form editor se puede transformar esta pantalla en la siguiente, que
simula mejor el formulario de pedidos:
28
GENEXUS- DISEÑO DE APLICACIONES
Form Editor
Los objetos como las Transacciones o los Work Panels, tienen uno o varios Formularios
asociados. A los efectos de permitir modificar los Formularios que GENEXUS
automáticamente crea por defecto, se provee un Form Editor. Este Form Editor es igual
para todos los objetos que tienen Formularios.
El Formulario está formado por un marco de ventana (frame) cuyo título es la descripción
de la transacción. Dentro de ella figurarán los distintos tipos de controles de edición del
Formulario.
29
GENEXUS DISEÑO DE APLICACIONES
Texto. Todo fragmento de texto fijo en la pantalla debe colocarse utilizando uno o
más controles de este tipo.
SubFile. Permite definir SubFiles. La definición de los subfiles se vera mas adelante
en el capitulo de Work Panels.
Tab. Permite definir varios controles dentro de otro. Un Tab control tiene una o
varias Paginas y cada Pagina tiene un Title y un area util donde se ponen los
controles de esa pagina. Solo una de las paginas puede estar activa a la vez y es la que
se puede ver, del resto solo se vera su titulo. Esto es util para cuando se quiere dividir
los datos ingresados en la transaccion en distintos grupos de modo que las pantallas
queden diseñadas de forma amigable al usuario (transacciones con muchos atributos).
Paleta de herramientas
Mientras se está editando un Formulario, está disponible la paleta de herramientas, en
la forma de una ventana adicional, con los botones que representan los tipos de
controles disponibles.
30
GENEXUS- DISEÑO DE APLICACIONES
• Edición de propiedades.
Toolbar
El Form Editor Toolbar nos permite ubicar los controles en el form, y copiar el
tamaño de otros controles ya definidos:
Toolbar
31
GENEXUS DISEÑO DE APLICACIONES
Atributo
Name. En esta opción se permite ingresar un nombre al control que se esta editando.
Este nombre será usado luego para asociarle propiedades o eventos al control.
Array Indices. En el caso de utilizarse variables que sean matrices, se habilitan estas
opciones, donde se pueden indicar expresiones que definan la fila y la columna.
32
GENEXUS- DISEÑO DE APLICACIONES
Frame. Se puede indicar que el atributo esté rodeado por un marco. Es posible indicar
el tipo: None, Single o 3D; el ancho de la/s línea/s (Width), si se pinta dentro de él o
no (Fill) y si el tamaño y forma deben determinarse a partir del atributo (Auto Resize).
Control Info
Fore Color. Este botón es para seleccionar el color con el que se desplegará el valor
del atributo y la/s línea/s del frame, si tuviera.
Back Color. Con este botón se puede seleccionar el color con el que se pinta el área
asignada al atributo en la pantalla. Sólo tiene efecto si está presente la propiedad Fill.
33
GENEXUS DISEÑO DE APLICACIONES
Texto
Text. Indica el texto que se quiere insertar en la pantalla. Puede consistir de una o más
líneas.
34
GENEXUS- DISEÑO DE APLICACIONES
Recuadro
Del combo box se selecciona el tipo del borde del recuadro: single, none (sin borde) o
3D.
Para el resto de las propiedades ver la explicación en el control de Atributo.
Línea
Utiliza el mismo diálogo de edición de propiedades con la salvedad de que la opción
Fill aparece deshabilitada.
35
GENEXUS DISEÑO DE APLICACIONES
Fórmulas
Se dice que un atributo es una fórmula si su valor se puede calcular a partir del valor de
otros atributos.
En cada transacción se puede definir que atributos son fórmulas, pero esta definición es
global, es decir toda vez que se necesite el atributo se calcula la fórmula, tanto en
transacciones como en los otros objetos GENEXUS (reportes, Paneles de Trabajo, etc.).
• Horizontales
• Verticales
• De agregación/selección
36
GENEXUS- DISEÑO DE APLICACIONES
Fórmulas Horizontales
Una fórmula horizontal se define como una o varias expresiones aritméticas
condicionales. Por ejemplo:
= 0 OTHERWISE;
En donde el Descuento será del 10% si el total del pedido esta entre 100 y 1000 y del
20% si es mayor y en cualquier otro caso no hay descuento (en las fórmulas con
condiciones es saludable definir siempre el OTHERWISE).
Vemos que la forma de definirla involucra a dos atributos (PedCnt y PedPre), pero no
se indica en que tablas de encuentran. GENEXUS se encarga de buscar la manera de
relacionar PedCnt y PedPre para poder calcular la fórmula (en este caso es muy fácil
porque PedCnt y PedPre se encuentran en la misma tabla). En los casos en que no es
posible relacionar a los atributos GENEXUS da un mensaje de 'fórmula invalida'.
Ahora bien, cuales son los atributos que pueden estar involucrados?. La respuesta es:
en una fórmula horizontal todos los atributos de los cuales depende la fórmula deben
estar en la misma tabla extendida que la fórmula (ver el concepto de tabla extendida
en el anexo sobre Bases de Datos Relacionales).
37
GENEXUS DISEÑO DE APLICACIONES
Cuando se define una fórmula horizontal GENEXUS 'sabe' cual es la tabla extendida y
controla que todos los atributos utilizados se encuentren en ella.
Fórmulas Verticales
Consideremos ahora el Total del pedido (PedTot), este se debe calcular sumando los
Importes (PedImp) de cada una de las líneas del Pedido. Esta fórmula se expresa
como:
Y es un caso de fórmula vertical, que se define como el tipo de fórmula en que los
atributos involucrados no se encuentran dentro de la misma tabla extendida que la
fórmula. En el caso de PedTot, si observamos el modelo de datos (usando el diagrama
de tablas de GENEXUS ):
Tabla: PEDIDOS
PedNro*
PedFch
PrvCod
AnlNro
PedTot
1
Tabla: PEDIDOS1
PedNro*
N PedLinNro*
ArtCod
PedCnt
PedPre
PedImp
38
GENEXUS- DISEÑO DE APLICACIONES
Tablas
superordinadas a
Pedidos
Existen dos operadores para fórmulas verticales: SUM que suma todos los datos y
COUNT que cuenta cuantos datos hay.
Fórmulas y Redundancia
En base a los criterios de normalización y dado que por definición una fórmula
siempre puede ser calculada, no es necesario que la misma este almacenada y basta
con recalcularla cada vez que sea necesario.
Sin embargo el hecho que la fórmula no este almacenada puede ocasionar problemas
de performance, debido al tiempo que pueda demorar el recálculo.
Para evitar este inconveniente se puede definir la fórmula como REDUNDANTE. En
este caso la fórmula se almacena en la Base de Datos y no es necesario recalcularla
39
GENEXUS DISEÑO DE APLICACIONES
cada vez que se use. Una vez que la fórmula es definida como redundante, GENEXUS
se encarga de agregar todas las subrutinas de mantenimiento de redundancia a todas
las transacciones que utilicen esa fórmula.
Tenemos entonces que la definición de fórmulas redundantes implica un balance de
performance por un lado y almacenamiento y complejidad de los programas
generados en otro, que el analista debe decidir. Si bien en teoría esta decisión puede
ser bastante difícil de tomar, en la practica vemos que la mayor parte de las fórmulas
que se definen redundantes son las verticales (mas adelante veremos que hay una
forma muy fácil de hacerlo) y pocas veces las horizontales.
La razón de esto es que el calculo de las fórmulas verticales pueden insumir un
número indeterminado de lecturas. Por ejemplo para calcular el PedTot se deben leer
todas las líneas del pedido, que pueden ser una cantidad bastante grande.
Fórmulas de Fórmulas
Una fórmula se calcula a partir del valor de otros atributos. Dichos atributos pueden
estar almacenados o ser otras fórmulas. Por ejemplo si en la transacción de
Proveedores definimos:
40
GENEXUS- DISEÑO DE APLICACIONES
Reglas
Según el Análisis Orientado a Objetos, para cada objeto del sistema se debe definir cual
es su estructura y cual su comportamiento. En el caso de las transacciones ya vimos la
definición de la estructura. Para definir el comportamiento se usan las REGLAS.
Usando reglas se definen valores por defecto, controles, etc. Veremos algunas de las
reglas:
Default
Se utiliza para definir los valores por defecto de algunos atributos, por ejemplo:
Error
Es la regla para definir los controles que deben cumplir los datos, por ejemplo si
queremos que el precio del articulo pedido sea siempre mayor que 100:
error( 'El precio debe ser mayor que 100') if PedPre <= 100 ;
Cuando se cumple la condición ( PedPre <= 100 ) se despliega el mensaje ( 'El precio
debe ser mayor que 100' ) en pantalla y no se permite continuar hasta que el usuario
ingrese un valor correcto o abandone la transacción.
Una utilización relativamente común es incluir una regla de error() para prohibir
alguna de las modalidades de la transacción:
Con esta regla se prohibe que el usuario entre en el modo eliminación y así se prohibe
la eliminación de Pedidos.
Asignación
Dentro de las reglas de la transacción se permiten definir asignaciones a atributos,
dicha Asignación implica una actualización en la tabla base del nivel o en alguna de
41
GENEXUS DISEÑO DE APLICACIONES
las tablas que pertenecen a la tabla extendida del nivel. Veamos un ejemplo, en la
transacción de Artículos:
Artículos:
ArtCod*
ArtDsc
ArtCnt
ArtFchUltCmp
ArtPrcUltCmp
En el atributo ArtPrcUltCmp se desea almacenar cual fue el precio del último pedido
realizado para ese articulo, y en que fecha fue realizado en ArtFchUltCmp. Esto se
realiza definiendo en la transacción de Pedidos las siguientes reglas:
Así cada vez que se ingrese una línea del pedido se actualiza la tabla de Artículos con
la fecha y el precio correspondiente.
Add y Subtract
Las asignaciones que vimos en la sección anterior eran relativamente fáciles, pero
existen casos mas sofisticados. Por ejemplo en la misma transacción de Artículos
tenemos el atributo ArtCnt en donde se quiere mantener cual es el stock que tenemos
de cada articulo.
Sin duda la transacción de Pedidos debe modificar ese valor, porque cada pedido
nuevo aumenta el stock. También existirá alguna otra transacción que hace disminuir
el stock, que podría ser por ejemplo una transacción de Facturación que se realiza
cuando se vende el articulo. Como esta transacción esta fuera del alcance del proyecto
solo estudiaremos la actualización del stock relacionada con la transacción de
Pedidos.
42
GENEXUS- DISEÑO DE APLICACIONES
add(PedCnt, ArtCnt);
Con esta regla si se esta insertando una línea del pedido se suma la PedCnt a ArtCnt,
si se esta eliminando se resta y si se esta modificando le resta el valor anterior de
PedCnt (que se define como old(PedCnt) ) y le suma el nuevo valor.
Existe una dualidad entre la fórmula vertical SUM y la regla ADD, mas
concretamente se puede decir que un SUM redundante es equivalente a la regla ADD.
Por ejemplo el PedTot se puede definir como:
Dado que es común que las fórmulas verticales tengan que estar redundantes para
tener buena performance se recomienda el uso de la regla ADD y no la fórmula SUM.
La regla SUBTRACT es equivalente pero realiza las operaciones contrarias, es decir
cuando se esta insertando resta, en caso de eliminación suma, etc.
Serial
Esta regla es útil cuando se quiere asignar automáticamente valores a algún
identificador de la transacción. Por ejemplo en la transacción de Pedidos tenemos el
PedLinNro y si queremos que este número sea asignado automáticamente por el
sistema se puede usar la regla:
43
GENEXUS DISEÑO DE APLICACIONES
PedNro*
....
PedUltLin
( PedLinNro*
....
)
PedTot
De esta manera para cada nueva línea del pedido el programa asigna automáticamente
su número.
En el diálogo campo a campo (donde la modalidad era inferida automáticamente), se
debe digitar un valor inexistente en PedLinNro (usualmente 0) y el programa asigna el
valor correspondiente.
En el diálogo full-screen el valor se asigna cuando el usuario presiona Enter en modo
Insertar.
Orden de evaluación
La definición de reglas es una forma DECLARATIVA de definir el comportamiento
de la transacción. El orden en el cual fueron definidas no necesariamente indica que
ese sea el orden en que se encuentran en el programa generado.
GENEXUS se encarga de determinar el orden correcto según las dependencias de
atributos existentes.
Veamos un ejemplo:
add(PedCnt, ArtCnt);
44
GENEXUS- DISEÑO DE APLICACIONES
add(PedCnt, ArtCnt);
Ya que la regla add() modifica ArtCnt y la regla msg() utiliza ese atributo.
Esto implica que en la regla msg() se debe preguntar por ArtCnt mayor que
ArtCntMax y no por ArtCnt + PedCnt mayor que ArtCntMax.
Cada vez que se especifica una transacción se puede pedir la opción -"Detailed
Navigation"- que lista cual es el orden de evaluación. En este listado se explícita en
que orden se generarán (usualmente decimos 'se disparan'), no solo las reglas, sino
también las fórmulas y lecturas de tablas.
Confirm
La regla se dispara después de haber confirmado los datos del nivel pero antes de
haber realizado la actualización. Se usa para algunos casos de numeración automática
cuando no se quiere utilizar la regla serial para evitar problemas de control de
concurrencia.
45
GENEXUS DISEÑO DE APLICACIONES
Level
Se dispara después de haber entrado todos los datos de un nivel. Se usa muchas veces
para controles de totales, por ejemplo, si cuando se entra el cabezal del Pedido se
digita un total (llamémosle PedTotDig) y se quiere verificar que este sea igual que el
total calculado la regla es:
En donde el control recién se realizará cuando se terminaron de entrar todas las líneas
del pedido.
Trn
Se dispara después de haber entrado todos los datos de una transacción. Se usa
fundamentalmente para llamar a programas que imprimen los datos o a otras
transacciones. En ambientes con integridad transaccional esta regla se dispara luego
que se realiza el commit de la transacción.
Propiedades
En el editor de propiedades de las transacciones se pueden definir reglas de
comportamiento general. A continuación vemos la pantalla para la edición de las mismas:
46
GENEXUS- DISEÑO DE APLICACIONES
Por ejemplo vamos a setear propiedades que estén asociadas con el manejo de la
integridad transaccional y con la interface. Podemos indicar si deseamos que la
transacción haga un commit al final o que no deseamos que se pidan confirmaciones cada
vez que se actualiza un nivel, etc.
47
GENEXUS DISEÑO DE APLICACIONES
DISEÑO DE REPORTES
Con Reportes se definen los procesos no interactivos de extracción de datos. Usualmente
un Reporte es un listado que se envía a la impresora, aunque también puede ser
visualizado en pantalla.
Información
Datos generales del Reporte, por ejemplo nombre, descripción, etc.
Layout
Así como las Transacciones tienen una pantalla los Reportes tienen un layout de la salida.
Condiciones
Qué condiciones deben cumplir los datos para ser impresos.
Reglas - Propiedades
Definen aspectos generales del Reporte.
Ayuda
Texto para la ayuda a los usuarios en el uso del Reporte.
Documentación
Texto técnico para ser utilizado en la documentación del sistema.
Layout
En el Layout se define simultáneamente la estructura de la navegación (que datos se
quieren listar y en que orden) y el formato de la salida. Para ello se utiliza un lenguaje
procedural muy simple que describiremos brevemente a continuación.
Comencemos por un Reporte para listar todos los proveedores:
48
GENEXUS- DISEÑO DE APLICACIONES
Literales Bloque de
impresion
Bloque de
código Atributos
En donde tenemos los comandos Header, End, For each y Endfor. Para describir más
fácilmente el funcionamiento de estos comandos veamos el resultado de ejecutar el
programa generado correspondiente:
49
GENEXUS DISEÑO DE APLICACIONES
La definición de reportes se divide en uno o varios bloques. Estos bloques pueden ser de
código o de impresión . En los bloques de impresión se diseña la salida que
posteriormente será impresa. Cada bloque de impresión puede tener un conjunto de
controles (atributos, variables, textos, etc.). Podemos ver un bloque de impresión como un
pedazo de papel. Los bloques de impresión (o Print Blocks) tienen asociadas ciertas
propiedades, que pueden seteadas desde un dialogo que se abre al hacer doble-click sobre
el bloque de impresión, como ser: los colores a usar, el tipo de papel, el tipo de letra, etc.
El dialogo es el siguiente
Para el diseño de los bloques de impresión tenemos disponible una paleta de herramientas
similar a las transacciones.
50
GENEXUS- DISEÑO DE APLICACIONES
La cual permite insertar atributos, textos, líneas, recuadros, bitmaps y nuevos bloques de
impresión. Los controles son definidos de la misma forma en que se hace en el editor del
form de las Transacciones (tipo de letra, color, tamaño, etc.).
Todos los bloques de impresión que se encuentren entre los comandos HEADER y END
son las líneas que se imprimen en el cabezal de la pagina. También existe el comando
FOOTER que permite imprimir un pie de página en cada hoja.
El comando FOR EACH indica que se impriman todos los bloques de impresión que se
encuentren entre el FOR EACH y el ENDFOR para cada uno de los datos que se
encuentren en la base de datos. En este caso:
51
GENEXUS DISEÑO DE APLICACIONES
For each
PrvCod PrvNom PrvDir
Endfor
Para clarificar el concepto hagamos un Reporte que involucre datos de varias tablas.
Por ejemplo, listar el cabezal de todos los pedidos:
Fecha: 09/08/92
Listado de Pedidos
52
GENEXUS- DISEÑO DE APLICACIONES
53
GENEXUS DISEÑO DE APLICACIONES
Endfor
54
GENEXUS- DISEÑO DE APLICACIONES
END FOR
Donde la flecha doble ( --->> ) indica cual es la tabla base de la tabla extendida y la
flecha simple ( ----> ) las tablas N-1 de la misma. Una interpretación muy práctica de
este diagrama es: para la tabla de la flecha doble se leen muchos registros y para cada
tabla con flecha simple se lee un solo registro por cada registro leído en la tabla con
flecha doble.
Orden
En los Reportes anteriores no se tuvo en cuenta en que orden se deben listar los datos.
Cuando no se indica el orden, GENEXUS busca un orden que favorezca la performance
del Reporte.
Para los casos en donde se quiere definir el orden de los datos de forma explícita se
utiliza la cláusula ORDER en el comando FOR EACH, por ejemplo, para listar los
pedidos ordenados por PrvCod:
Endfor
55
GENEXUS DISEÑO DE APLICACIONES
END FOR
Como no hay ningún índice definido en la PEDIDOS para PedFch, GENEXUS creará
un índice por PedFch cada vez que se ejecute el Reporte y lo eliminará al finalizar el
mismo y en el Listado de Navegación indicará que esta creando un 'índice temporario'.
Navegación:
A temporary index will be created for PedFch on table PEDIDOS
56
GENEXUS- DISEÑO DE APLICACIONES
No es posible recomendar, a priori, cual de las dos soluciones es la mejor, por lo tanto
se debe estudiar caso por caso la solución particular, siendo fundamental la frecuencia
con que se ejecutará el Reporte. De cualquier manera si al comienzo no se definió el
índice y posteriormente se decide cambiar y definirlo, alcanza con regenerar el
Reporte (sin modificar nada del mismo) y éste pasará a utilizarlo.
Los criterios de ordenamiento utilizado por GENEXUS son:
Cada grupo FOR EACH puede estar ordenado por CUALQUIER conjunto de
atributos pertenecientes a la tabla base del grupo, pero no se puede ordenar por
atributos que NO se encuentren en la misma. Por ejemplo el listado anterior no se
puede ordenar por PrvNom porque la tabla base del grupo es la PEDIDOS que no
tiene PrvNom.
Si no existe un índice para el orden pedido se crea un índice temporario que se
eliminará al finalizar el Reporte. Observar que este proceso es análogo a realizar un
SORT cuando se trabajaba con archivos tradicionales.
For each
WHERE PedFch = Today()
PedNro PedFch PrvNom AnlNom
Endfor
For each
WHERE PedFch = Today()
WHERE PedNro > 100
Endfor
Que significa que se deben cumplir AMBAS condiciones, o sea que se interpreta
como que ambas cláusulas están relacionadas por un AND. Si se quiere utilizar un OR
(es decir se desea que se cumpla alguna de las dos condiciones) se debe utilizar un
solo WHERE:
For each
57
GENEXUS DISEÑO DE APLICACIONES
Endfor
GENEXUS posee una serie de mecanismos para optimizar el Reporte en función del
orden del FOR EACH y de las condiciones del mismo, pero estas se aplican sólo a las
condiciones que tienen la siguiente forma:
Donde:
<atributo> debe estar almacenado en la tabla base.
<operador> debe ser = o >=.
<valor> puede ser una constante o una variable.
<código2> se ejecuta solo cuando no se entra en el For Each
58
GENEXUS- DISEÑO DE APLICACIONES
For each
Endfor
For each
PrvNom AnlNom
Endfor
se podría argumentar que la tabla extendida de PEDIDOS continúa siendo válida, sin
embargo por razones de simplicidad GENEXUS en este caso indicará que no hay
relación entre estos dos atributos y será necesario que se utilice algún atributo de la
tabla PEDIDOS para poder generar el Reporte.
También puede darse el caso que exista más de una tabla extendida mínima que
contenga a los atributos del grupo FOR EACH - ENDFOR. Ante esta ambigüedad
GENEXUS escoge la PRIMERA tabla extendida que cumpla con las condiciones
anteriores.
Para resolver estos dos problemas (no hay ningún atributo de la tabla base y hay más
de una tabla extendida mínima posible), se utiliza la cláusula DEFINED BY dentro
del comando FOR EACH, por ejemplo:
For each
Defined by PedFch
Endfor
59
GENEXUS DISEÑO DE APLICACIONES
El layout que se debe definir es (sólo se muestran los grupos FOR EACH):
60
GENEXUS- DISEÑO DE APLICACIONES
Si colapsamos todos los print blocks, queda mas claro como se definen los FOR
EACH anidados.
61
GENEXUS DISEÑO DE APLICACIONES
En este Reporte tenemos dos FOR EACH anidados. Si analizamos el primer FOR
EACH vemos que utiliza sólo los atributos PrvCod y PrvNom y por lo tanto su tabla
extendida será la de la tabla PROVEEDO, el segundo FOR EACH utiliza los atributos
PedNro y PedFch y su tabla extendida será la de PEDIDOS. Pero el segundo FOR
EACH se encuentra anidado respecto al primero y a su vez la tabla PEDIDOS esta
subordinada a PROVEEDO (por PrvCod) por lo tanto GENEXUS interpretara el
Reporte como:
Y así se listarán, para cada registro en la tabla de proveedores, cuales son sus pedidos
en la tabla de pedidos.
Más formalmente, cuando hay dos FOR EACH anidados, GENEXUS busca cual es la
relación de subordinación existente entre la tabla base del segundo FOR EACH y la
tabla extendida del primer FOR EACH (en el caso anterior la relación era que la tabla
PEDIDOS estaba subordinada a la tabla PROVEEDO por PrvCod) y establece de esta
manera la condición que deben cumplir los registros del segundo FOR EACH (en el
62
GENEXUS- DISEÑO DE APLICACIONES
ejemplo: todos los registros de la tabla PEDIDOS con el mismo PrvCod leído en el
primer FOR EACH).
Puede darse el caso en que no exista relación entre ambos FOR EACH, por ejemplo:
La tabla base del primer FOR EACH es la PROVEEDO (porque los atributos son
PrvCod y PrvNom) y la del segundo FOR EACH es la ANALISTA (porque los
atributos son AnlNro y AnlNom) y no existe relación entre estas dos tablas extendidas.
En este caso GENEXUS da el mensaje 'No existe relación directa' y hará el producto
cartesiano entre los dos FOR EACH, es decir, para cada registro de la tabla
PROVEEDO (proveedores) se imprimirán todos los registros de la tabla ANALISTA
(analistas).
63
GENEXUS DISEÑO DE APLICACIONES
Cortes de Control
Un caso particular de FOR EACH anidados son los llamados cortes de control.
Supongamos que queremos listar los pedidos ordenados por fecha:
64
GENEXUS- DISEÑO DE APLICACIONES
El layout es:
La tabla base del primer FOR EACH es la PEDIDOS (por usar PedFch) y la del
segundo FOR EACH también (por usar PedNro y PrvNom). Este es un caso de corte
de control sobre la tabla PEDIDOS y GENEXUS lo indica en el Listado de Navegación
con la palabra BREAK en vez de FOR EACH. Los cortes de control pueden ser de
varios niveles, por ejemplo, si quisiéramos listar los pedidos por fecha y dentro de
cada fecha por proveedor:
Endfor
Endfor
65
GENEXUS DISEÑO DE APLICACIONES
Los listados con FOR EACH paralelos son muy prácticos cuando se quiere hacer
listados del tipo 'Listar toda la Información que se tenga sobre un Proveedor', en
donde el Layout será del tipo:
For each
... //Información del Proveedor
For each
.... // Información sobre Pedidos
Endfor
For each
.... // Información sobre Precios
Endfor
....
Endfor
66
GENEXUS- DISEÑO DE APLICACIONES
Otros comandos
En el Layout se pueden utilizar otros comandos además de los ya vistos. Nos
limitaremos aquí a ver solo los más significativos (para un repaso exhaustivo de los
mismos sugerimos ver el Reference Manual).
Definición de Variables
Antes de describir los comandos en si es bueno detenernos en el concepto de
Variable. Ya vimos que los datos se almacenan en la base de datos en atributos, pero
muchas veces se necesita utilizar Variables, que se diferencian de los atributos por ser
locales al Reporte y no estar almacenadas en la base de datos. Una Variable es
reconocida por GENEXUS por ser un nombre que comienza con &, por ejemplo
&Today o &Aux.
Existen algunas Variables predefinidas, es decir que ya tienen un significado propio,
por ejemplo el ya visto &Today que es una variable con la fecha de hoy o &Page que
indica cual es la página que se está imprimiendo, etc.
Se deben definir las características (tipo, largo, decimales, etc.) de las variables que se
estén utilizando en el Reporte, con excepción de las predefinidas.
67
GENEXUS DISEÑO DE APLICACIONES
Asignación
Este comando permite asignar valores a variables. Por ejemplo si queremos mostrar
totales en un listado:
68
GENEXUS- DISEÑO DE APLICACIONES
69
GENEXUS DISEÑO DE APLICACIONES
El layout es:
Comandos de Control
Los comandos de control son IF-ELSE-ENDIF y DO WHILE-ENDDO. El comando
IF-ELSE-ENDIF es muy utilizado para impresión condicional, es decir, imprimir una
línea solo cuando se cumple alguna condición.
70
GENEXUS- DISEÑO DE APLICACIONES
En el ejemplo anterior:
71
GENEXUS DISEÑO DE APLICACIONES
Con el comando DO se llama a una subrutina que se encuentra dentro del mismo
Layout. En este caso no son necesarios los parámetros porque están disponibles para
la subrutina los mismos datos (variables) que están disponibles en el lugar donde se
hace el DO.
....
DO 'Nombre-Subrutina'
....
Sub 'Nombre-Subrutina'
....
EndSub
Print if detail
Volvamos al listado de Pedidos por Proveedor:
Recordemos que el primer FOR EACH tenía como tabla base la PROVEEDO y el
segundo la PEDIDOS.
72
GENEXUS- DISEÑO DE APLICACIONES
Ahora bien, el primer FOR EACH es independiente del segundo y por lo tanto se
imprimirán los datos del primer FOR EACH ANTES de determinar si hay datos en el
segundo nivel y como consecuencia se van a imprimir TODOS los proveedores,
independientemente de si tienen o no pedidos.
Si se quiere que SOLO se impriman los proveedores que sí tienen pedidos se debe
usar el comando Print if detail:
Este comando define que el FOR EACH en donde se encuentre debe usar como tabla
base la misma tabla base del siguiente FOR EACH. En el ejemplo el primer FOR
EACH pasará a estar basado en la tabla PEDIDOS y no en la PROVEEDO y por lo
tanto solo se imprimirán los proveedores que tienen pedidos.
Se debe tener en cuenta que, al pasar a estar los dos FOR EACH basados en la misma
tabla base, se está definiendo implícitamente un corte de control. Por lo tanto se
DEBE definir explícitamente el ORDEN en el primer FOR EACH.
Existen otros comandos como ser EJECT (salta de hoja), NOSKIP, etc. que se
detallan en el Reference Manual.
Condiciones
Aquí se definen las condiciones que se quiere imponer a los datos a listar.
73
GENEXUS DISEÑO DE APLICACIONES
Es equivalente a la cláusula WHERE del comando FOR EACH (incluso tienen la misma
sintaxis), con la diferencia que el WHERE se aplica a un solo FOR EACH y las
condiciones definidas aquí se aplicarán a TODOS los FOR EACH que correspondan. En
el Listado de Navegación se indica a que FOR EACH se están aplicando.
Muchas veces se requiere que las condiciones no sean con valores fijos, sino que el
usuario elija los valores cuando se ejecuta el Reporte. Por ejemplo, si en el Reporte que
lista proveedores deseamos que liste un rango de ellos:
Reglas
Se utilizan para definir aspectos generales del listado. Algunas de las reglas para Reportes
son:
Default
Define el valor por defecto de los ask(). En el ejemplo anterior:
default(&ask1, 1);
default(&ask2, 9999);
74
GENEXUS- DISEÑO DE APLICACIONES
Parm
Es una lista de atributos o variables que recibe el Reporte como parámetros. Por
ejemplo, si hacemos un Reporte para imprimir un pedido inmediatamente después de
haberlo digitado, en la Transacción se utiliza la regla:
y el Reporte será:
Layout
FOR EACH
// Imprime el cabezal del pedido
....
FOR EACH
// Imprime las líneas del pedido
....
ENDFOR
ENDFOR
Reglas
Parm(PedNro);
Layout
FOR EACH
WHERE PedNro = &Pedido
....
ENDFOR
Reglas
Parm(&Pedido);
75
GENEXUS DISEÑO DE APLICACIONES
Report Wizard
El Report Wizard permite realizar el diseño del layout de los Reportes y Procedimientos
de manera mas sencilla. Diseñemos nuevamente el reporte de pedidos por proveedor.
Paso 1: Requiere que se provea de una estructura de datos. Notar que dicha estructura de
datos debe incluir atributos definidos en las transacciones. La estructura de datos usará
una estructura sintáctica similar a la usada en las transacciones, sin embargo, los
paréntesis se usan para indicar niveles de FOR EACH (en vez de niveles de una
transacción) y el asterisco (‘*’) se usa para indicar el orden deseado (y no para indicar la
unicidad como en las transacciones). Las reglas que son usadas para definir la estructura
de una transacción también se aplican al definir la estructura del layout.
Para diseñar nuestro reporte definimos una estructura en donde en el primer nivel tenemos
los datos del proveedor y en el segundo los del pedido. Esto va a generar dos for each
anidados en donde el exterior va a estar ordenado por código de proveedor y el interno
por numero de pedido.
Una vez que se ha definido correctamente la estructura, se presiona el botón de Next para
pasar al siguiente paso.
76
GENEXUS- DISEÑO DE APLICACIONES
Paso 2: Permite definir otras características del layout. Se permite elegir los fonts para
representar los atributos o textos, también se permite definir si los cabezales de los
atributos para cada uno de los niveles se despliegan horizontalmente o verticalmente.
Como se puede ver, el nivel para el cual estamos definiendo el tipo del layout se
presenta en un color diferente. Para este nivel, seleccionaremos el tipo vertical de layout y
para el segundo nivel nos aseguraremos que el check box correspondiente al tipo de
layout vertical no este marcado, de esta manera el display del nivel interior será
horizontal. En nuestro ejemplo cambiamos los fonts de los títulos, mientras que los de los
atributos dejamos el default.
Presionando el botón de “Finish” se graban las definiciones para el paso actual y se sale
del dialogo del Report Wizard.
77
GENEXUS DISEÑO DE APLICACIONES
Una vez que todas las opciones del Wizard fueron aceptadas, se genera el layout del
reporte, el cual puede ser modificado como cualquier otro reporte. Vemos que el diseño
del layout es idéntico al que definimos anteriormente en forma manual.
Properties
En el editor de propiedades de los reportes podemos definir:
78
GENEXUS- DISEÑO DE APLICACIONES
79
GENEXUS DISEÑO DE APLICACIONES
DISEÑO DE PROCEDIMIENTOS
Los Procedimientos son el objeto GENEXUS con el que se definen todos los procesos no
interactivos de actualización de la base de datos y las subrutinas de uso general.
Este objeto tiene todas las características de los Reportes (cualquier Reporte se puede
realizar como un Procedimiento) más algunas características particulares para la
actualización de la base de datos. Por esta razón se recomienda haber leído previamente
el capítulo Diseño de Reportes.
Vamos a ver entonces los comandos disponibles en los procedimientos para la
actualización de la base de datos
Modificación de datos
La modificación de datos de la base de datos se realiza de forma implícita, ya que no
hay un comando específico de modificación (como podría ser REWRITE), sino que
basta con asignar un valor a un atributo dentro de un For Each para que
automáticamente se realice la modificación.
Por ejemplo supongamos que queremos tener un proceso batch que actualiza el
atributo ArtPrcUltCmp para adecuarlo según la inflación para todos los Artículos
almacenados:
Programa:
For each
ArtPrcUltCmp = ArtPrcUltCmp * (1 + &Inf)
Endfor
Reglas:
Parm( &Inf );
Se puede modificar más de un atributo dentro del mismo FOR EACH, por ejemplo, si
también queremos modificar el atributo ArtFchUltCmp, poniéndole la fecha de hoy:
For each
ArtPrcUltCmp = ArtPrcUltCmp * (1 + &Inf)
ArtFchUltCmp = Today( )
Endfor
80
GENEXUS- DISEÑO DE APLICACIONES
------>> + ARTICULO
Eliminación de datos
Para eliminar datos se utiliza el comando DELETE dentro del grupo FOR EACH-
ENDFOR. Por ejemplo, si queremos eliminar todos los pedidos con fecha anterior a
una fecha dada:
For each
where PedFch < ask('Eliminar pedidos con fecha menor')
defined by PedFch
For each
defined by PedCnt
Creación de datos
Para crear nuevos registros en la base de datos se usan los comandos NEW-
ENDNEW. Tomemos por ejemplo un Procedimiento que recibe como parámetros
AnlNro y AnlNom e inserta estos datos en la tabla de analistas:
81
GENEXUS DISEÑO DE APLICACIONES
Programa:
New
AnlNro = &Nro
AnlNom = &Nom
Endnew
Reglas:
Parm( &Nro, &Nom );
Con este procedimiento se pueden crear registros en la tabla de analistas utilizando una
subrutina.
El comando NEW realiza el control de duplicados, y solo creará el registro si ya no se
encuentra en la tabla. Con la cláusula WHEN DUPLICATE se programa la acción a
realizar en caso de duplicados. Por ejemplo, en el caso anterior si se quiere que si el
analista ya estaba registrado se actualice el AnlNom:
New
AnlNro = &Nro
AnlNom = &Nom
When Duplicate
For each
AnlNom = &Nom
Endfor
Endnew
82
GENEXUS- DISEÑO DE APLICACIONES
Información
Datos generales del Panel de Trabajo, por ejemplo nombre, descripción, etc.
Form
Al igual que las transacciones, se debe definir el form con el que interactuará el usuario.
Eventos
Aquí se define la respuesta a los eventos que pueden ocurrir durante la ejecución del
Panel de Trabajo. Por ejemplo que respuesta dar cuando el usuario presionó Enter o un
botón, etc.
Condiciones
Define que condiciones deben cumplir los datos para ser presentados en la pantalla. Son
equivalentes a las Condiciones de los Reportes y Procedimientos.
Reglas
Definen aspectos generales del Panel de Trabajo, por ejemplo orden de los datos a
mostrar, parámetros, etc.
Ayuda
Texto para la ayuda a los usuarios en el uso del Panel de Trabajo.
Documentación
Texto técnico para ser utilizado en la documentación del sistema.
Propiedades
Propiedades generales del Work Panel.
83
GENEXUS DISEÑO DE APLICACIONES
En este capítulo solo se presentarán las características y usos más salientes de los Paneles
de Trabajo, pero se recomienda leer el capítulo de Paneles de Trabajo en el Manual de
Usuario GENEXUS, para una visión más profunda.
Ejemplo
Para ilustrar más fácilmente el uso de Paneles de Trabajo, vamos a realizar una serie de
consultas encadenadas.
Estas consultas comienzan con un Panel de Trabajo de proveedores, donde el usuario
selecciona para luego realizar alguna acción, en este caso para cada proveedor
seleccionado se puede:
El form será:
si, por ejemplo, el usuario presiona el botón de Visualizar en el proveedor 125, se abre
una ventana donde se muestran los datos del proveedor:
84
GENEXUS- DISEÑO DE APLICACIONES
Si se presiona el botón de pedidos se presentará la siguiente pantalla con los pedidos del
proveedor:
A su vez este Panel de Trabajo podría extenderse, permitiendo seleccionar algún pedido
para visualizar qué artículos fueron pedidos y así sucesivamente.
Las acciones que vimos en el primer Panel de Trabajo se aplican a una línea, pero existen
otras acciones que no se aplican a ninguna línea en particular, por ejemplo Insertar un
85
GENEXUS DISEÑO DE APLICACIONES
Subfile
Este form se define de una manera similar a los forms de las transacciones.
86
GENEXUS- DISEÑO DE APLICACIONES
Cuando se define un subfile en el form se está indicando que se va a mostrar una cantidad
indefinida de datos (en este caso los proveedores). Si bien sólo se pueden ver
simultáneamente las líneas presentes en la pantalla, GENEXUS provee todos los
mecanismos para que el usuario se pueda 'mover' (llamaremos 'paginar') dentro de la lista,
como por ejemplo ir a la primera página, a la siguiente, etc.
El Panel de Trabajo anterior tiene un SubFile compuesto de PrvCod y PrvNom. Los
SubFile pueden contener además de atributos, variables y arrays de una y dos
dimensiones.
Subfile
Si seleccionamos el botón de “subfile” nos va a permitir incorporar un subfile en el
form del work panel y definir el tamaño que deseamos.
Insertar el control
tipo Subfile
87
GENEXUS DISEÑO DE APLICACIONES
Para seleccionar los atributos que van a ser incluidos en el subfile se debe presionar el
boton “Add”. Con el tab “Column” vamos a poder cambiar los títulos de las columnas
(por defecto se define el titulo del atributo). Los botones “MoveUp” y “Move Down”
nos van a permitir cambiar el orden en que se van a desplegar los atributos. Con los
tabs “Colors” y “Fonts” podemos cambiar los colores y el tipo de letra de las
columnas. Con el tab Control Info se selecciona el tipo de control a utilizar, y dado el
tipo, indicar la información necesaria para ese tipo, las opciones disponibles son: Edit,
Check box, Combo y Dynamic Combo (o el default del atributo o variable de la
columna).
88
GENEXUS- DISEÑO DE APLICACIONES
Eventos
La forma tradicional de programar la interfaz entre el usuario y el computador (incluídos
los lenguajes de cuarta generación) es subordinar la pantalla al programa. Es decir, desde
el programa se hacen 'calls' a la pantalla. En Paneles de Trabajo es lo opuesto: el
programa está subordinado a la pantalla, ya que una pantalla realiza 'calls' al programa
para dar respuesta a un evento.
Esta forma de trabajar es conocida como EVENT DRIVEN (dirigida por eventos) y es
típica de los ambientes GUI (Interfaz de Usuario Gráfica), en donde ya ha demostrado su
productividad, fundamentalmente porque se necesita programar sólo la respuesta a los
eventos y no la tarea repetitiva que implica el manejo de toda la interfaz.
La estructura de eventos es, de forma resumida, la siguiente:
Comienzo
Evento Start
Evento Refresh
Evento Enter
Evento Exit
Fin
Para programar cada uno de los eventos se utiliza el mismo lenguaje que ya vimos en
Reportes y Procedimientos, aunque no están permitidos ni los comandos relacionados con
la impresión (Header, etc.) ni los de actualización de la base de datos (New, Delete, etc.).
También existen comando específicos para Paneles de Trabajo.
89
GENEXUS DISEÑO DE APLICACIONES
Evento Start
Event Start
&Fecha = &Today
Endevent
En este caso, se utiliza el evento Start para mover la fecha actual a la variable &Fecha
que por ejemplo se podrá mostrar en la pantalla. Esta técnica es muy útil para
inicializar valores por defecto, sobre todo para aquellos que son complejos (por
ejemplo, &Valor = udf('PX', ...)).
Evento Enter
Este evento se dispara cuando el usuario presiona ENTER. Consideremos el siguiente
ejemplo: borrar un conjunto de proveedores. Entonces se define una nueva variable en
el subfile, &Op, y por cada línea que se le asocie la opción 4 se llama a un
procedimiento que borra los clientes. El código asociado al evento enter en este caso
es el siguiente:
Event Enter
If &op = '4'
Call(PDltPrv, PrvCod)
Else
If &op <> ' '
&msg = concat(&op, ' no es una opción valida')
Msg( &msg )
Endif
Endif
Endfor
Endevent
El evento Enter es un poco más extenso y vale la pena detenernos en él. En primer
lugar se utiliza el comando FOR EACH LINE que realiza un FOR EACH, pero no
sobre los datos de la base de datos, sino sobre el SubFile.
90
GENEXUS- DISEÑO DE APLICACIONES
Para cada una de las líneas del SubFile, se pregunta por el valor de &op, si &op es '4'
se llama al procedimiento DltPrv, y en otro caso, da un mensaje indicando que la
opción no es válida. Notar que se podrían haber definido mas opciones y preguntar
por ellas en este evento.
Este es un evento definido por el usuario, para el cual se debe definir el nombre
('Insertar'). En este evento se llama a la transacción de proveedores (por más detalles
sobre como llamar de un Panel de Trabajo a una Transacción ver el capítulo de
Paneles de Trabajo en el Manual de Referencia). Luego de llamar a la transacción, se
ejecuta el comando Refresh, que indica que se debe cargar nuevamente el SubFile, ya
que se ha adicionado un nuevo proveedor. También se podría haber usado el comando
con el parámetro keep (Refresh Keep) que hace que una vez que el comando refresh
se ejecuta el cursor queda posicionado en la misma línea del subfile que estaba antes
de la ejecución.
Evento Refresh
Los datos que se presentan en pantalla son los cargados en el SubFile, que a su vez
fueron cargados desde la base de datos.
En un ambiente multi-usuario, los datos de una pantalla pueden haber quedado
desactualizados si desde otra terminal fueron modificados. Cuando el usuario desea
actualizar los datos, debe dar click sobre el boton Refresh (o presionar la tecla F5),
cuyo efecto es cargar nuevamente el SubFile.
En algunos casos, desde otro evento también se necesita cargar nuevamente el
SubFile. Por ejemplo, cuando en otro evento se llama a una transacción que actualiza
los datos (es el caso del Evento 'Crear Proveedor').
91
GENEXUS DISEÑO DE APLICACIONES
Tenemos, por lo tanto, que el SubFile se carga (es decir, se genera el evento Refresh)
cuando:
• Se carga la pantalla - por lo tanto después del evento Start siempre hay
un evento Refresh.
• El usuario dio click sobre el botón Refresh (o presiono la tecla F5).
• Se ejecutó el comando Refresh en otro evento.
Event Refresh
...
Endevent
FOR EACH
Event Load
...
Endevent
ENDFOR
Los datos que se leen en este FOR EACH implícito, se cargan en el SubFile, que es el
que se presenta en pantalla. Esta carga se realiza 'bajo pedido', es decir que al
92
GENEXUS- DISEÑO DE APLICACIONES
comienzo sólo se carga la primera página y, a medida que el usuario requiere más
información, se van cargando las siguientes páginas. Existe una propiedad para
indicar que se quiere cargar el SubFile de una sola vez, si fuera necesario.
Igual que en los Reportes y Procedimientos en el Listado de Navegación del Panel de
Trabajo se indica qué tablas se están utilizando, índices, etc.
Puede darse el caso que no exista el FOR EACH implícito. Esto se debe a que no hay
atributos ni en la pantalla ni en los eventos ni en las reglas Hidden y Order (porque se
usan sólo variables). En este caso se genera sólo UN evento Load y es en éste donde
se deben cargar los datos en el SubFile (utilizando el comando Load), por ejemplo:
Event Refresh
...
Endevent
Event Load
...
For each
...
Load
Endfor
Endevent
Observar que en este caso se pierde la facilidad de carga 'bajo pedido' y por lo tanto
antes de mostrar los datos se carga todo el SubFile.
Condiciones
Aquí se definen las restricciones a los datos de la misma forma que en los Reportes.
Lo interesante de las condiciones en los Paneles de Trabajo, es que en las mismas se
puede utilizar variables que se encuentran en la pantalla, de tal manera que el usuario,
cambiando los valores de estas variables, cambia los datos que se muestran en el SubFile
sin tener que salir de la pantalla.
Por ejemplo, si queremos visualizar sólo un rango de proveedores, agregamos en la
pantalla las variables:
93
GENEXUS DISEÑO DE APLICACIONES
Variables para
ingresar el
proveedor final y
inicial.
94
GENEXUS- DISEÑO DE APLICACIONES
Reglas
En Reglas se aplican la mayor parte de las reglas de los Reportes, más algunas
particulares:
Order
Define cual es el orden de los datos del SubFile. Es equivalente a la cláusula ORDER
del FOR EACH y se aplica todo lo dicho en el capítulo Diseño de Reportes sobre el
tema (incluída la creación de índices temporarios).
Por ejemplo si queremos ver los proveedores por orden alfabético:
order( PrvNom );
Noaccept
A diferencia de las Transacciones, en los Paneles de Trabajo ningún atributo es
aceptado (siempre se muestra su valor pero no se permite modificarlo). Para variables
se sigue el siguiente criterio:
noaccept( &Fecha );
Search
Cuando el SubFile es demasiado extenso, muchas veces se quiere brindar la
posibilidad de que el usuario pueda 'posicionarse' en alguna línea determinada del
mismo, en forma directa, sin tener que avanzar página por página. Por ejemplo si en
nuestro Panel de Trabajo de proveedores queremos que exista la posibilidad de buscar
un proveedor según su nombre, se debe definir la regla:
95
GENEXUS DISEÑO DE APLICACIONES
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:
96
GENEXUS- DISEÑO DE APLICACIONES
Bitmaps
Los bitmaps son usados usualmente para mejorar la presentación de las aplicaciones. Se
pueden incorporar en los forms de las transacciones, reportes y work panels. GENEXUS
provee dos métodos diferentes para agregar un Bitmap:
Fixed Bitmaps
Se puede agregar un Bitmap seleccionando el botón de Bitmap de la paleta de
herramientas. De esta forma tenemos que indicar su ubicación. Agreguemos un logo
en el work panel que permite visualizar los datos de un proveedor. El nuevo form se
vera de la siguiente forma:
Dynamic Bitmaps
Este método tiene como diferencia que el Bitmap lo asigno a una variable y usando la
función Loadbitmap puedo cargar el Bitmap que yo desee. Por ejemplo se puede
tener un Bitmap que despliegue la foto de cada proveedor.
97
GENEXUS DISEÑO DE APLICACIONES
En el evento load hay que cargar el bitmap para el proveedor pasado por parámetro.
98
GENEXUS- DISEÑO DE APLICACIONES
Gráficas
Grafiquemos el total pedido por Proveedor. Vamos a definir entonces una formula que me
calcule el total pedido en la transacción de proveedores:
99
GENEXUS DISEÑO DE APLICACIONES
Definimos entonces un nuevo atributo, “PrvTotPed” y decimos que este atributo es una
formula Sum vertical del atributo PedTot, de esta forma estamos definiendo el total
Pedido de un proveedor como la suma de todos los totales de los pedidos de ese
proveedor. Recordemos que el atributo PedTot había sido definido como una formula,
sumando todos los importes de la línea que a su vez era también una formula.
De esta forma tenemos disponible este atributo para usarlo en la definición del work
panel.
100
GENEXUS- DISEÑO DE APLICACIONES
En este work panel definimos el botón “Graficar” el cual va a tener asociado el siguiente
evento:
De esta manera cuando el usuario presiona el botón de graficar visualizara el total pedido
por los proveedores en forma gráfica. Vemos a continuación ejemplos de los tipos de
gráficos que podemos diseñar:
101
GENEXUS DISEÑO DE APLICACIONES
102
GENEXUS- DISEÑO DE APLICACIONES
Properties
103
GENEXUS DISEÑO DE APLICACIONES
Diálogos Objeto-Acción
Con el uso de Paneles de Trabajo, se tiene la oportunidad de definir para la aplicación
una arquitectura orientada a diálogos Objeto-Acción. Pero previo a introducir este
concepto veamos cual era la forma tradicional.
Si observamos una aplicación desarrollada por los métodos tradicionales, veremos que
cuanto mayor es, más grande será el árbol de menúes que se tiene para acceder a los
programas que efectivamente trabajan con los datos. La arquitectura de este tipo de
sistemas normalmente es:
Selección de la
Menúes Acción
Aplicar la
Trn Rpt Proc acción al
objeto
Esta situación se puede apreciar claramente en los sistemas con muchas consultas. En
general, todas estas consultas dependen de un menú, pero no se encadena una consulta
con las otras. Y al no estar encadenadas, se da la paradoja de que cuanto más consultas se
implementan en el sistema, menos son usados por el usuario, porque le resulta difícil
acordarse de las diferencias entre ellas.
Diremos que este tipo de aplicación tiene un diálogo Acción-Objeto, porque primero se
elige la acción a realizar (por ejemplo modificar un proveedor, o listar los pedidos) y
luego se elige el objeto al cual aplicar la acción (que proveedor o los pedidos de que
fecha).
Con Paneles de Trabajo se pueden implementar sistemas en donde el diálogo puede ser
Objeto-Acción, donde primero seleccionamos el objeto con el cual vamos a trabajar y
luego las acciones que aplicamos al mismo. En este caso la arquitectura será:
104
GENEXUS- DISEÑO DE APLICACIONES
Selección del
Menúes tipo de objeto
Aplicar la
Trn Rpt Proc acción al
objeto
De esta manera el usuario, una vez que selecciona el tipo de objeto con el que va a
trabajar, ya puede utilizar el Panel de Trabajo que le permite seleccionar el objeto en sí, y
luego, las acciones a aplicar sobre el mismo.
Esta arquitectura permite desarrollar aplicaciones complejas, pero que se mantienen
fáciles de usar.
105
GENEXUS DISEÑO DE APLICACIONES
DISEÑO DE MENÚES
Este objeto permite definir los diferentes menúes de la aplicación. La definición de un
menú es muy fácil, y prácticamente lo único que se requiere es definir las opciones del
mismo.
Ejemplo:
106
GENEXUS- DISEÑO DE APLICACIONES
107
GENEXUS DISEÑO DE APLICACIONES
Call Browser
Este browser despliega todos los objetos que se llaman a través de los comandos call y
udp.
Dado un programa podemos ver su árbol de llamadas (a que programas llama) y desde
que programas es llamado (eligiendo la opción Callees o Callers del dialogo del browser).
En nuestro ejemplo vamos a ver el árbol de llamadas del menú Compras:
108
GENEXUS- DISEÑO DE APLICACIONES
Desde este browser podemos editar cualquier objeto que aparezca en las listas.
109
GENEXUS DISEÑO DE APLICACIONES
Tablas
En una Base de Datos Relacional la única forma de almacenar información es en
Tablas.
Una Tabla es una matriz (tiene filas y columnas) con un nombre asociado (ej.
PROVEEDO). A las columnas les llamaremos Atributos, y a las filas Registros o
Tuplas. Por ejemplo la Tabla de Proveedores:
PROVEEDO
• Todos los atributos representan la misma información para cada una de las filas
(o registros). Es decir en el atributo PrvNom se almacenan los nombres de los
proveedores, y no puede ocurrir que para algunos proveedores en ese atributo
se almacene la dirección del mismo. En la práctica esta regla implica que no
existen tablas con diferentes tipos de registros.
• No existen dos registros con exactamente la misma información.
• El orden de los registros no contiene información. Es decir se pueden reordenar
los registros sin perder información.
110
GENEXUS- DISEÑO DE APLICACIONES
Tabla: PROVEEDO
Atributos:
PrvCod*
PrvNom
Tabla: PROVDIR
Atributos:
PrvCod*
PrvDir
Tanto la PROVEEDO como la PROVDIR tienen la misma clave primaria. Esto era
relativamente común cuando el criterio de diseño era separar las actualizaciones (por
ejemplo dado que PrvDir cambia mas que PrvNom, entonces es mejor definir un
archivo diferente en donde el registro que se modifica es menor, y por lo tanto de
mejor performance). Sin embargo en una Base de Datos Relacional el criterio de
diseño es diferente (ver sección de Normalización) y es preferible una sola tabla con
los tres atributos:
Tabla: PROVEEDO
Atributos:
PrvCod*
PrvNom
PrvDir
111
GENEXUS DISEÑO DE APLICACIONES
Indices
Son vías de acceso eficientes a las Tablas. Existen tres tipos de índices: Primarios,
Extranjeros y del Usuario.
El índice primario es el que se define para la Clave Primaria y, por lo tanto, se usa en
el control de unicidad de los registros. Con GENEXUS todos los índices primarios son
definidos automáticamente a partir de los identificadores de las transacciones.
Los índices extranjeros son utilizados para hacer eficientes los controles de integridad
inter-tablas. También son definidos automáticamente.
Los índices del usuario se definen, fundamentalmente, para recorrer los datos por
determinado orden de una forma eficiente. Por ejemplo en la tabla PROVEEDO se
puede definir un índice por PrvNom, que es muy útil para los listados ordenados por
nombre. Los índices del usuario NO son definidos automáticamente.
En una Base de Datos Relacional los índices se utilizan sólo por problemas de
performance, pero siempre es posible acceder a los datos de la tabla por cualquiera de
los atributos de la misma.
Integridad Referencial
Son las reglas de consistencia entre los datos de las distintas tablas.
Según vimos en el ejemplo, existe una relación entre la tabla PEDIDOS (Pedidos) y la
PROVEEDO (Proveedores):
112
GENEXUS- DISEÑO DE APLICACIONES
La relación entre estas dos tablas se determina analizando los atributos que tienen en
común, por ejemplo aquí tenemos que el atributo común es PrvCod, que es la clave
primaria de la tabla PROVEEDO (Proveedores) y se encuentra en la tabla PEDIDOS
(Pedidos) y, por lo tanto, ambas tablas están relacionadas y la relación es 1-N.
Con relación 1-N se indica que un Proveedor tiene varios Pedidos y que un Pedido
sólo tiene un Proveedor. También es usual decir que la tabla de proveedores esta
superordinada a la de pedidos, y la de pedidos esta subordinada a la de proveedores.
Esta relación implica que los datos de ambas tablas no son independientes y cada vez
que se realicen modificaciones en una de las tablas, se deben tener un cuenta los datos
de la otra tabla. A estos controles se les llama de integridad referencial y son:
Para hacer eficiente el primer control se utiliza el índice extranjero por PrvCod en la
tabla PEDIDOS y para el segundo el índice primario también por PrvCod en la tabla
PROVEEDO.
113
GENEXUS DISEÑO DE APLICACIONES
Normalización
El proceso de normalización determina en que tablas debe residir cada uno de los
atributos de la base de datos.
El criterio que se sigue es básicamente determinar una estructura tal de la base de
datos, que la posibilidad de inconsistencia en los datos sea mínima.
Por ejemplo, si tenemos que almacenar información sobre Proveedores y Pedidos, se
podría tener la siguiente estructura:
en donde vemos que ambas tablas tienen dos atributos en común (PrvCod y PrvNom).
En el caso de PrvCod es necesario que se encuentre en ambas tablas dado que es el
identificador de los Proveedores, y por lo tanto debe estar en la de Pedidos para
indicar a que Proveedor corresponde el Pedido.
La situación es diferente para PrvNom, ya que no es necesario que esté en la tabla de
Pedidos, porque si conocemos el PrvCod podemos determinar cual es su PrvNom
(basta con buscar en la tabla PROVEEDO por la clave primaria). Si de cualquier
manera se almacena el PrvNom en la tabla PEDIDOS tenemos que esta estructura
tiene más posibilidades de inconsistencia que si no estuviera allí. Por ejemplo si un
Proveedor cambia su PrvNom, el programador debe encargarse de tener un programa
que lea todos los Pedidos de ese Proveedor y le ponga el nuevo PrvNom.
114
GENEXUS- DISEÑO DE APLICACIONES
PrvCod* PedNro*
PrvNom PedFch
PrvDir PrvCod
AnlNro
PedTot
Tabla extendida
Como vimos en la sección de Normalización, el criterio de diseño de la base de datos
se basa en minimizar la posibilidad de inconsistencia en los datos. Una base de datos
diseñada de esta manera tiene una serie de ventajas importantes (tal es así que
actualmente la normalización de datos es un standard de diseño), pero se deben tener
en cuenta también algunos inconvenientes.
El inconveniente más notorio es que los datos se encuentran dispersos en muchas
tablas, y por lo tanto cuando se quieren hacer consultas mas o menos complejas a la
base de datos se debe consultar una cantidad importante de tablas. Así, por ejemplo,
para listar los Pedidos por Proveedor es necesario consultar las tablas PROVEEDO y
PEDIDOS.
Para simplificar esta tarea GENEXUS utiliza el concepto de Tabla Extendida, cuya
definición es:
Dada una tabla de la base de datos, la tabla extendida de la misma son los
atributos que pertenecen a la tabla y a todas las tablas que tengan una
relación N-1 (directa o indirectamente) con la primera. A la primera tabla
se le llama de Tabla Base y a las otras de Tablas N-1.
115
GENEXUS DISEÑO DE APLICACIONES
vemos que la tabla extendida de Pedidos comprende a todos los atributos de la tabla
Pedidos, más todos los atributos de Proveedores y todos los de Analistas, pero no los
atributos de la Linea del pedido o de Artículos (porque si bien están relacionados, su
relación no es N-1).
En el siguiente diagrama se muestra, para cada una de las tablas del modelo, cual es su
tabla extendida:
116
GENEXUS- DISEÑO DE APLICACIONES
Proveedores Proveedores
Analistas Analistas
Artículos Artículos
117
GENEXUS DISEÑO DE APLICACIONES
MANEJO DE STRINGS
Str Pasar un numérico a string
Substr Substring de un string
Concat Concatenar dos strings
Space Definir un strings con “n” blancos
Len Largo de un string
Trim Quita los caracteres en blanco de un string
Ltrim Quita los caracteres en blanco al principio de un
string
Rtrim Quita los caracteres en blanco al final de un string
Upper Convierte un string a mayúsculas
Lower Convierte un string a minúsculas
OTRAS
118
GENEXUS- DISEÑO DE APLICACIONES
119
GENEXUS DISEÑO DE APLICACIONES
REGLAS DESCRIPCIÓN T W R P
120
GENEXUS- DISEÑO DE APLICACIONES
AS/400
T = Transacciones
W = Work Panels
R = Reportes
P = Procedimientos
Las casillas que aparecen marcadas indican que la función aparece disponible para ese
objeto.
121
GENEXUS DISEÑO DE APLICACIONES
COMANDOS DESCRIPCIÓN T W R P
122
GENEXUS- DISEÑO DE APLICACIONES
T = Transacciones (eventos)
W = Work Panels (eventos)
R = Reportes
P = Procedimientos
Las casillas que aparecen marcadas indican que la función aparece disponible para ese
objeto.
123
Curso GeneXus
Parte I
DISEÑO DE TRANSACCIONES................................................ 41
NOMENCLATURA GIK .............................................................. 47
TIPOS DE DATOS ....................................................................... 49
COMANDOS DE ASIGNACIÓN .................................................. 51
DOMINIOS ................................................................................... 52
TAB CONTROL ........................................................................... 55
Objetivo : Capacitar a los usuarios para conseguir el cambio de mentalidad que GeneXus requiere
y dar elementos básicos para el diseño de Aplicaciones.
Alcance : Conceptos fundamentales y elementos básicos. No se abordan todos los temas, algunos
de ellos son abordados en el Curso Genexus Parte II.
Aprobación: Este curso es evaluado por los instructores de Artech . La evaluación consiste en la
defensa del Taller realizado y el resultado de dicha evaluación (Aprobación /No aprobación)
es comunicado a la Empresa.
Habilitado a: El alumno que aprueba dicho curso queda habilitado a desarrollar aplicaciones de
pequeño y mediano porte, sin embargo es necesario el apoyo que se brinda en el WorkShop.
4
CURSO GENEXUS PARTE II
WORKSHOP
Objetivo: Apoyo inicial a la primera aplicación real que desarrolla el cliente. El Workshop
cumple las siguientes funciones fundamentales: a) Realizar un análisis inicial junto al cliente
que redunde en una planificación para la correcta inserción de GeneXus en la empresa b)
Apoyar técnicamente el comienzo del desarrollo con la herramienta de cuyo resultado
depende en gran parte el futuro desempeño y satisfacción del cliente. c) Tener un
seguimiento del Cliente en la etapa inicial para asegurarnos que obtiene la productividad
esperada y corregir posibles desvíos en la etapa inicial.
5
DESARROLLO DE APLICACIONES CLIENT/SERVER
Objetivo: Dar los elementos necesarios para poder generar aplicaciones en una arquitectura
Cliente/ Servidor.
CURSO JAVA
Objetivo: Dar los elementos necesarios para poder generar aplicaciones Java en una
arquitectura Cliente/Servidor de 2 y múltiples capas para correr tanto en una Intranet como en
Internet.
Alcance: Información general sobre lenguaje Java, Información general sobre Generador Java,
Software necesario, Configuración del Modelo, Distribución de aplicaciones para su puesta en
producción, Ejecución en múltiples capas, Pool de conexiones, Lightweight Directory Access
Protocol (LDAP)
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.
Objetivo: Durante años hemos desarrollado sistemas operacionales y con ellos hemos resuelto
muy bien las funciones operacionales de nuestras organizaciones (fábricas de datos). Como
consecuencia de esto, en nuestras bases de datos hemos recopilado una gran cantidad de datos
y con ellas hemos ofrecido un buen nivel de información a nivel de gestión. Sin embargo, no
hemos podido usar esos datos para proveer información a los niveles más altos de nuestras
organizaciones, ni hacerlo con el dinamismo necesario. Este fenómeno es conocido como 'data
in jails' (los datos existen, pero están 'enjaulados'). Los niveles de dirección y estratégicos son
los que actualmente se encuentran más carentes de información. Necesitamos proveer
información de buena calidad, oportuna y en forma dinámica para el apoyo a la toma de
decisiones.
El objetivo de este curso es : conocer la teoría de Data Warehousing, cuales son las
componentes de la solución, técnicas y metodologías aplicadas, tecnología asociada a cada
componente, y ver como la tecnología GeneXus nos apoya en cada etapa del proceso de
construcción de la solución.
ALCANCE : Los punto principales que se tratan en el curso son los siguientes: Conocimiento
de los diferentes aspectos de la problemática, Esquema general de la solución Data
Warehousing, Componentes de la solución, Etapas en el desarrollo de un proyecto, Estudio
detallado de las metodologías aplicadas en cada etapa y Tecnología asociada a cada
componente. En forma paralela al curso teórico se irán estudiando casos prácticos y los
participantes irán aplicando sobre éstos las metodologías aprendidas. Finalmente el participante
realizará el diseño y parte de la implementación de un caso práctico con la tecnología GeneXus
- Data Warehousing.
7
CURSO WORKFLOW
Alcance: Los puntos principales que se tratan en el curso son los siguientes: Conceptos
Teóricos de Workflow, estudio de la herramienta de definición de procesos (GeneXus Process
Modeler), estudio del Workflow en ejecución (Inbox y Motor de Workflow), estudio de las
Workflow APIs, y el estudio de la integración de la solución de Workflow con el desarrollo de
los sistemas con GeneXus. En forma paralela al curso teórico se irá estudiando casos prácticos y
los participantes irán aplicando sobre éstos las metodologías aprendidas. Finalmente el
participante realizará el diseño y la implementación de un caso práctico con la tecnología
GeneXus-Workflow.
8
RECOMENDACIÓN:
A continuación detallamos una propuesta de capacitación para cada uno de los Roles que se
llevan a cabo dentro del área de informática.Reconocemos que muchas veces estos roles son
cumplidos por la misma persona o por varias , para lo cual deberán considerarse las funciones
más que las personas.
DESAROLLADOR
- CURSO GENEXUS - Al comienzo
- WORKSHOP - Inmediatamente despúes de finalizado el Curso Genexus
- CLIENT/SERVER - Después del Curso Genexus (si corresponde)
- DESARROLLO DE APLICACIONES PARA INTERNET - Después del Curso Genexus (si corresponde)
-WORKFLOW - Después del Curso Genexus (si corresponde)
-CURSO PARA GERENTES DE PROYECTOS - Tres meses después de aprobado el Curso Genexus
GERENTE DE INFORMÁTICA
- TEORICO DEL CURSO GENEXUS PARTE 1- Al comienzo
- CURSO PARA GERENTES DE PROYECTOS- Después del teórico del Curso Genexus Parte1
9
Introducción
Teórica
10
REALIDAD
Herramientas y Metodologías
?
• Desarrollo
BASE y
DE PROGRAMAS Mantenimiento
DATOS
11
Modelado de la realidad
a partir de las Visiones de Usuarios
Satisface
MODELO DE
LA REALIDAD
Ingenieria Inversa
BASE VISIONES
DE DE
PROGRAMAS
DATOS USUARIOS
Todos compartirán la afirmación de que cada usuario conoce muy bien los objetos con
los que trabaja cotidianamente, conoce claramente la información que se maneja en
ellos, que reglas deben seguirse y que cálculos deben realizarse. Por lo tanto, utilizar
estas visiones de los objetos de su realidad como fuente de información parece muy
razonable.
12
Comparación
de
Metodologías
Es bueno, para fijar ideas, comparar la metodología utilizada por GeneXus conocida
como Metodología Incremental con las metodologías tradicionales más utilizadas
actualmente.
Estas metodologías son diferentes entre sí, pero en todos los casos, separan el análisis
de los datos del de los procesos.
13
Metodología Tradicional
•.
14
REALIDAD
ANALISIS
DE
DATOS
BASE
DE
DATOS
ANALISIS
FUNCIONAL GENERACION/
INTERPRETACION
ESPECIFICACION
FUNCIONAL PROGRAMAS
PROGRAMACION
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.
Los módulos operan sin una real integración, lo que hace que exista información
redundante y como consecuencia todo intento de buscar información fuera del entorno
de cada aplicación resulte imposible o por lo menos peligroso.
15
En caso de que desearamos posteriormente realizar la integración de esos módulos es
necesario realizar modificaciones al modelo de datos (lo que a pesar de la complejidad
podríamos calificar como posible), pero las modificaciones que deberemos realizar en los
programas tienen un costo tan grande que hacen inviable la realización de la integración.
La empresa tendrá de esta forma resueltos sus problemas operativos, pero luego
aparecerán con mucha claridad los problemas de la carencia de información que permitan
orientar la gestión y la toma de decisiones de alto nivel, ya que la información que se
necesita es en general de naturaleza corporativa.
En la medida que nos orientamos cada vez más a las bases de datos corporativas, la
cantidad de objetos que integran la base de datos y sus relaciones se hacen mas
complejas. Esto lleva a que el diseño de una base de datos corporativa sea una tarea muy
complicada y en la que son muchos los errores que se pueden cometer.
Podemos ver que entre un buen modelo de datos, y el diseño de la base de datos
necesaria para soportarlo, existe una transformación trivial. Por ello, para mayor claridad
del dibujo, eliminaremos la etapa intermedia y colocaremos directamente la base de
datos.
Esta es la causa fundamental de los grandes costos de mantenimiento que deben soportar
las empresas.
16
Entre las alternativas más usadas se destacan la programación en lenguajes de 3a.
generación, y en lenguajes de 4a. generación.
Desde un punto de vista conceptual, ambos casos son idénticos. En ambos el analista
debe estudiar el problema, transformarlo en un algoritmo y codificar dicho algoritmo en
el lenguaje de programación.
Sin embargo, existe una fuerte diferencia: en los lenguajes de 4a. generación se escribe
mucho menos (probablemente 10 veces menos) y, como consecuencia, la productividad
es mucho mayor y el número de errores cometidos es mucho menor.
El problema visto, de que las descripciones de los procesos dependen de la base de datos,
afecta a ambos por igual. Como consecuencia, los lenguajes de 4a. generación
permiten aumentos de productividad muy grandes sobre los de 3a., en la tarea de
desarrollo, pero ayudan bastante poco en la de mantenimiento.
Aquí existe una diferencia conceptual muy grande con el caso anterior. En este caso el
analista describe el problema de una forma declarativa (no existe algoritmo ni
codificación procedural alguna).
Algunos ejemplos son ADELIA, AS/SET, LANSA, SYNON, TELON, etc..Existe otra
categoría de herramientas conceptualmente idéntica: la de aquellas que, simplemente,
interpretan la especificación, como por ejemplo: MAGIC y SAPIENS.
17
Podría argumentarse en contrario, como a menudo se ha hecho con las herramientas de
4a. generación, que se pierde flexibilidad con estas herramientas, lo que es cierto en
términos teóricos, pero es irrelevante en términos prácticos, dado que, hoy, estas
herramientas están dotadas de Lenguajes de Diagramas de Acción, (en la práctica
lenguajes de 4a. generación), que permiten complementar su código, por lo que su
aplicabilidad ha crecido mucho.
El problema visto, de que las descripciones de los procesos dependen de la base de datos,
afecta también a las aplicaciones generadas mediante estas herramientas. Como
consecuencia, los Generadores y los Interpretadores (como los lenguajes de 4a.
generación) ayudan bastante poco en la tarea de mantenimiento.
Generadores
Buen aumento de productividad en el desarrollo sobre L3G y L4G.
Desde el punto de vista del mantenimiento, ninguna de las herramientas ayuda mucho
dado que, en todas ellas, se utilizan descripciones de procesos que pueden perder su
validez cuando existen modificaciones de archivos y que, por ello, deben ser revisadas y
mantenidas manualmente.
Existe, sin embargo, un postulado cuyo cumplimiento evitaría este problema: PUEDE
OBTENERSE UNA BASE DE DATOS ESTABLE.
18
Metodología
19
REALIDAD
DESCRIPCION
DE OBJETOS
Desarrollo con
Desde luego que esto modifica la actividad del analista e, incluso, su perfil óptimo,
ya que lo transforma en un “Business Analyst”.
Ahora trabaja en alto nivel, discutiendo problemas con el usuario y probando con él
las especificaciones a nivel de prototipo, en vez de desarrollar su actividad a través de
tareas de bajo nivel como son: diseñar archivos, normalizar, diseñar programas,
programar, buscar y eliminar los errores de los programas.
20
REALIDAD
DESCRIPCION
DE OBJETOS
BASE
DE BASE DE
DATOS CONOCIMIENTO
Desarrollo con
PROGRAMAS
21
REALIDAD
ANALISIS DESCRIPCION
DE DE OBJETOS
DATOS
BASE
DE BASE DE
DATOS CONOCIMIENTO
ANALISIS
Comparación de
FUNCIONAL Metodologías GENERACION/
INTERPRETACION
ESPECIFICACION PROGRAMAS
FUNCIONAL
PROGRAMACION
4. Desarrollo incremental.
22
Descripción de Objetos
La primer tarea que hay que realizar es pasar a describir los objetos de la realidad,
mediante objetos Genexus.
TRANSACCIONES
Las transacciones permiten definir los objetos de la realidad. La mayor parte de las
transacciones pueden ser identificadas prestando atención a las entidades que el usuario
menciona (por ej. Clientes, Proveedores, Artículos).
A partir de las transacciones Genexus infiere el diseño de la base de datos.
PROCEDIMIENTOS
Procesos no interactivos de actualización de la base de datos (procesos batch).
REPORTES
Recuperan información a partir de los datos almacenados y no los alteran. Los reportes
son lo que conocemos habitualmente como listados.
PANELES DE TRABAJO
Permite definir consultas interactivas a la base de datos. Es un objeto muy flexible que
se presta para múltiples usos.
MENUES
Objetos organizadores del resto.
23
Sistematización del conocimiento
Base
Basede
deConocimiento
Conocimiento
Veamos ahora con más detalle el proceso de desarrollo de una aplicación con
GeneXus.
24
Inferencia de la Base de Datos
Base
Basede
deConocimiento
Conocimiento
Base
de
Datos
25
Creación de la Base de Datos
Base
Basede
deConocimiento
Conocimiento
Programas
Base
Generación
de
Datos BD
26
Generación de los Programas de la
Aplicación
Transacciones Reportes Procedimientos Work Panels Menues
(TRNs) (RPTs) (PROCs) (WKPs) (MNUs)
Base
Basede
deConocimiento
Conocimiento
27
Resultado final en la Etapa de Desarrollo
Transacciones Reportes Procedimientos Work Panels Menues
(TRNs) (RPTs) (PROCs) (WKPs) (MNUs)
Base
Basede
deConocimiento
Conocimiento
Aplicaciones
28
Las Visiones de los Usuarios Cambian
Nuevas Nuevos Nuevos Nuevos Nuevos
Transacciones Reportes Procedimientos Work Panels Menues
Base
Basede
deConocimiento
Conocimiento
29
Análisis de Impacto Totalmente Automático
Nuevas Nuevos Nuevos Nuevos Nuevos
Transacciones Reportes Procedimientos Work Panels Menues
Análisis Base
de
Basede
deConocimiento
Conocimiento
impacto
30
Generación de Programas de Reorganización
de la Base de Datos
Nuevas Nuevos Nuevos Nuevos Nuevos
Transacciones Reportes Procedimientos Work Panels Menues
Programas Base
de
Basede
deConocimiento
Conocimiento
Reorganiz.
31
Análisis Automático del Impacto de los
cambios sobre los Programas
Nuevas Nuevos Nuevos Nuevos Nuevos
Transacciones Reportes Procedimientos Work Panels Menues
Análisis
Base de
Basede
deConocimiento
Conocimiento impacto
Nuevos
Nueva Programas de Aplicacion
Base
de
(TRN, RPT, PROC, WKP y MNU)
Datos
32
Generación Automática de Nuevos
programas
Generación
Base de nuevos
Basede
deConocimiento
Conocimiento
Programas
Nuevos
Nueva Programas de Aplicacion
Base
de
(TRN, RPT, PROC, WKP y MNU)
Datos
33
Nueva Realidad , con los cambios en la
Aplicación
Base
Basede
deConocimiento
Conocimiento
Nuevos
Nueva Programas de Aplicacion
Base
de
(TRN, RPT, PROC, WKP y MNU)
Datos Aplicaciones
34
Múltiples Plataformas de ejecución a partir de una única
especificación
ARQUITECTURAS CENTRALIZADAS
Plataforma Lenguaje Generado
AS/400 COBOL/400, RPG/400
ARQUITECTURAS FILE SERVER
Plataforma Lenguaje Generado
DOS Foxpro, Clipper DBF
WINDOWS Foxpro for Windows DBF
Visual Basic ACCESS
Visual Fox DBF
ARQUITECTURA CLIENT/SERVER
Cliente Database Server Plataformas (Ejs.)
FOXPRO WIN, VB, VFP, JAVA ORACLE Unix, NT
MS SQL SERVER Alfa, WINDOWS NT y 95
INFORMIX Unix, NT
DB2 Common Servers RS6000, OS2
DB2/400 AS400
35
Metodología Incremental
DEFINICION
INICIAL
36
Ciclos Diseño-Prototipo y
Diseño-Producción
Ciclo de Prototipación:
Ciclo de Producción:
37
Prototipación Integral en PC
MODELO DE
LA REALIDAD
Construcción
Automática
Usuario probando todos los detalles
de la aplicación
BASE
DE PROGRAMAS
DATOS
Los resultados que todos quieren ver, están en forma de programas ejecutando,
lo que no es posible sin la utilización de prototipos.
38
Ventajas de la Prototipación
39
Warnier-Orr
Nro de Factura
Comienzo Emisión del Nro de Cliente
cabezal Nombre Cliente
Fecha Factura
Emisión de Comienzo
Emisión de
la Factura una Factura
(cuerpo)
Código Producto
Proceso de Emisión de Nombre Producto
emisión de una línea Precio Producto
líneas Cantidad Producto
Importe Producto
Jean Dominique Warnier y Ken Orr, formularon una teoría acerca de cómo
puede ser construida una aplicación de procesamiento de datos. Algunos de
sus enunciados fueron los siguientes:
41
Notación GeneXus para Transacciones
42
Definición del diseño de Base de Datos en 3era Forma Normal
para soportar las transaccciones definidas.
FacNro* Factura
CliCod FacNro*
CliNom CliCod
FacFch CliNom
(ProdCod* FacFch
ProdNom
ProdPre Factura1
FacLinCnt FacNro*
FacLinImp) ProdCod*
ProdNom
ProdPre
FacLinCnt
FacLinImp
Veamos el proceso de obtención de una base de datos en 3era. forma normal a partir
de las especificaciones de transacciones.
Para esto utilizaremos como ayuda las dependencias funcionales que se derivarían
de la definición de la transacción.
43
Definición de las transacciones Clientes y Productos
Clientes
CliCod*
CliNom
Trn. Clientes
Producto
CliCod*
CliNom ProdCod*
ProdNom
ProdPre
Trn. Productos
Factura
ProdCod*
ProdNom FacNro*
ProdPre CliCod
CliNom
FacFch
Factura1
FacNro*
ProdCod*
ProdNom
ProdPre
FacLinCnt
FacLinImp
GeneXus diseñará las nuevas tablas que correspondan ( Clientes y Producto ) y realizará las
modificaciones necesarias en las ya existentes ( Factura y Factura1 ) para considerar el
conjunto total de dependencias funcionales.
44
GeneXus establece las relaciones por los nombres.
Factura Cliente
FacNro*
CliFacCod NO CliCod *
45
Es conveniente usar padrones para los
nombres de atributos.
46
Nomenclatura GIK - Nombre del Atributo
Complemento
(texto libre)
Calificador (1 a 3)
Calificador (1 a 3)
Categoría Semántica (1 a 3)
Objeto ( 1 a 6 )
47
Ejemplo de Nomenclatura GIK
Cli Nom
FacVta Nro
FacCmp Nro
48
Tipos de Datos
• Long Varchar
• VarChar
– Equivalente al Character, salvo en la forma en que se
almacena en la BD.
• DateTime
– Los valores de M y N no afectan la forma de almacenar el
tipo de datos, sino la forma de aceptar o mostrar su
contenido.
Long Varchar
Permite almacenar una cantidad de caracteres indefinida. Se utiliza normalmente
para almacenar textos, descripciones, comentarios, etc.
El largo que se le asigna es considerado el largo máximo (la implementación
depende de la plataforma).
VarChar
Permiten almacenar texto de largo variable. Su función, en contraposición al
character, es la de optimizar el almacenamiento en la base de datos.
Definición: Varchar(M, N)
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.
DateTime
Permite almacenar una combinación de fecha y hora (hasta el segundo).
DateTime(M, N)
M = Largo de la fecha. Valores posibles: 0, 8 y 10.
N = Largo de la hora. Valores posibles: 2, 5 y 8.
En caso que M sea 0 (no se considera la fecha) para un campo que ha de ser
ingresado, el valor de fecha a asignar será el mínimo soportado por el DBMS y
reconocido como fecha vacía o nula en GeneXus.
En caso que N sea distinto de 8 para un campo que ha de ser ingresado, los
valores no aceptados (minutos o minutos y segundos) serán considerados en
cero.
50
Comandos de asignación
• +=
• -=
• *=
• /=
51
Dominios
52
Reglas
Según el Análisis Orientado a Objetos, para cada objeto del sistema se debe definir cual es su
estructura y su COMPORTAMIENTO.
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);
Orden de evaluación
La definición de reglas es una forma DECLARATIVA de definir el comportamiento de la
transacción. El orden en el cual fueron definidas no necesariamente indica que ese sea el orden en
que se encuentran en el programa generado. GeneXus se encarga de determinar el orden correcto
según las dependencias de atributos existentes (en este tema entraremos en detalle mas adelante).
53
Toolbar de Controles
Para el diseño de Pantallas
• Atributo / Variable
• Texto
• Línea
• Recuadro
• Subfile
• Botón
• Bitmap
• Tab Control
• Print Block
5412
16
Tab Control
• Permite definir varios controles dentro de un Tab
Control.
• Tiene una o varias páginas.
– Default: Dos páginas
– Agregar o eliminar páginas:
• Botón derecho sobre el Tab Control
– Página
• Título
• Area útil
– Check Box de Hide Tabs ==> Para diseño de Wizards
• Sólo para los generadores visuales.
Un Tab Control tiene una o varias páginas (por defecto tiene dos). Cada página
tiene un título y un área útil, es decir donde se ponen los controles de esa
página. Sólo una de las páginas puede estar activa a la vez y es la que se puede
ver. Del resto sólo se verá su título.
Las opciones Edit/Add Tab Page y Edit/Remove Tab Page son para agregar y
eliminar páginas respectivamente. Puede accederse también a estas opciones
con botón derecho sobre el Tab Control.
Hide Tabs
Para mostrar sólo la página activa y no mostrar los tabs. Util para la definición
de Wizards.
55
Generación de
HELP Tipo Windows
•El compilador de Help como se mencionó más arriba viene con el Visual
Basic/Foxpro/Visual FoxPro y se requiere como mínimo la versión 3.10.505.
5662
Generación de
HELP Tipo Windows
• Botón de Help:
– Llama al help del objeto.
• F1:
– Llama al help del atributo en donde se encuentra el
cursor.
• Si ese atributo no tiene help se llama al help del objeto.
5763
Pasemos a Prototipo...
59
Diagrama de Bachman
Catego Depart
CatCod*
CatNom DtoCod*
DtoNom
Client
CliCod*
CliNom
CatCod
DtoCod
60
Definición de Indices
Tabla Indice
Tipo Composición
Catego PK CatCod
Depart PK DtoCod
Client PK CliCod
FK DtoCod
FK CatCod
Definición de Indices
Para hacer eficientes los controles de Integridad, GeneXus crea automáticamente índices, que
son vías de acceso eficientes a las Tablas.
Existen tres tipos de índices: Primarios, Extranjeros y del Usuario.
61
CONCEPTO DE TABLA
EXTENDIDA
62
Tabla Extendida
Definición
Dada una tabla de la base de datos, se denomina
tabla extendida de la misma al conjunto de
atributos conformado por:
63
Tabla Base y Tabla Extendida
FACTURA1 PRODUCTO
FacNro* ProdCod*
ProdCod* ProdNom
FacLinCnt ProdPre
64
Tabla Base: Tabla extendida:
Categoría Categoría
Cliente Cliente
Categoría
Factura Factura
Cliente
Categoría
Factura1 Factura1
Producto
Factura
Cliente
Categoría
Producto Producto
65
ATRIBUTOS FORMULAS
66
Características
Un atributo es una fórmula si su valor se puede calcular a partir del valor de otros
atributos.
En cada transacción se puede definir qué atributos son fórmulas, pero esta definición
es global (no es local a la transacción), es decir toda vez que se necesite el atributo se
calcula la fórmula, tanto en transacciones como en los otros objetos GeneXus.
67
Clasificación
Horizontales
Una o varias expresiones aritméticas condicionales.
Verticales
SUM
COUNT
Aggregate / Select
Select
Max, Min, Find
Aggregate
Sum, Count
Fórmula Horizontal
Los atributos involucrados en la misma deben pertenecer a la tabla
extendida del atributo definido como fórmula.
Fórmula Vertical
Los atributos involucrados deben pertenecer a la tabla directamente
subordinada del atributo definido como fórmula.
Son incondicionales.
Aggregate / Select
Pueden navegar sobre cualquier tabla del modelo.
Son condicionales.
68
Fómulas Horizontales
Los atributos que participan de la expresión deben pertenecer a la tabla base y/o a
tablas que están en una relación N para 1 con la tabla sobre la que se define la fórmula
(es decir, a la tabla extendida del atributo definido como fórmula).
Cuando se define una fórmula horizontal, GeneXus sabe cual es la tabla extendida del
atributo que se está definiendo como fórmula, y controla que todos los atributos
utilizados en dicha fórmula se encuentren en ella.
69
Fómulas Horizontales
Ejemplo:
TRANSACCION TABLA
CliCod* CliCod*
CliNom CliNom
CliTotCmp CliTotCmp
CliTotPgo CliTotPgo
CliSdo = CliTotCmp- CliTotPgo
•Fórmula
La fórmula es una definición global ya que está a nivel del modelo de datos, su valor
será calculado cada vez que se utilice en cualquier objeto GeneXus ya que el atributo
no está almacenado en la tabla.
•Regla
La regla está definida a nivel local en la transacción. Cada vez que se mencione el
atributo, su valor no se calculará, sino que se tomará directamente de la tabla.
70
Importe de la Línea de la Factura
FACTURA1 PRODUCTO
FacCod* ProdCod*
ProdCod* ProdNom
FacLinCnt ProdPre
71
Fórmulas Verticales
SUM - COUNT
Sintáxis:
– AtriFla = SUM(Att)
– AtriFla = COUNT(Att)
Características:
– Att debe pertenecer a una tabla directamente
subordinada a la tabla en la que se encuentra AtriFla.
– Son incondicionales.
– Navegación vertical - Performance
Performance
El hecho que la fórmula no este almacenada, puede ocasionar en algunos casos,
problemas de performance debido al tiempo que puede demorar el recálculo.
Esto dependerá de la cantidad de registros que se sumen / cuenten.
72
Fórmulas Verticales
SUM - COUNT
Cálculo del subtotal de la Factura
Factura: Factura
FacNro*
1
FacFch
CliCod
FacSubTot = SUM(FacLinImp) N
Factura1:
Factura1
FacNro*
ProdCod*
FacLinCnt
FacLinImp = FacLinCnt * ProdPre
Precisamos una fórmula que recorra todas las líneas de la factura y las sume,
utilizamos para esto una fórmula SUM( ) perteneciente a las llamadas Fórmulas
Verticales.
73
Fórmulas Verticales
SUM(att)
N No permitido
FacLinImp FACTURA1
SUM (att)
Puede ser Fórmula
74
Fórmulas Aggregate/Select
Son fórmulas que permiten buscar, sumar, contar
atributos que cumplan determinadas condiciones, en
cualquier tabla del modelo.
Aggregate
– Sum
– Count
Select
– Max
– Min
– Find
Fórmulas Aggregate
Fórmulas Select
75
Fórmulas Aggregate/Select
Sintáxis
Sum ( atributo a ser sumado, condiciones que debe cumplir, valor por defecto )
76
Fórmulas Aggregate
.Sum( ) Aggregate
.Count( ) Aggregate
77
Factura1
FacNro*
ProdCod*
FacLinCnt
FacDscto
FacLinImp
FacTotArtDscto = 2
78
Find
Se utiliza para obtener el valor de un atributo que está en cualquier tabla del modelo,
pudiendo establecerse relaciones con cualquiera de los atributos de la tabla.
Sintáxis:
Documentos Cotizaciones
DocNro* MonCod*
DocFch MonFch*
DocImp MonCot
DocImpDolar = DocImp / DocCotDolar
DocCotDolar = Find(MonCot, MonCod = ‘U$S’ .and. MonFch = DocFch)
79
Max
Esta función determina el máximo valor de un atributo en una tabla. Obtenido este
valor, que corresponderá a una determinada fila, la función devuelve el valor de
cualquier atributo de dicha fila.
Sintáxis:
Atributo a devolver - Atributo a devolver para asignar al atributo fórmula, debe estar
almacenado en la tabla de búsqueda.
Obtener la última (máxima) cotización del dólar anterior a la fecha del documento.
Documentos Cotizaciones
DocNro* MonCod*
DocFch MonFch*
DocImp MonCot
DocImpDolar
DocCotDolar
80
Atributo a maximizar … MonFch
MonFch MonCot
10/01/94 100
11/01/94 110
12/01/94 112
13/01/94 115
16/01/94 117
81
Min
Esta función determina el mínino valor de un atributo en una tabla. Obtenido este valor,
que corresponderá a una determinada fila, la función devuelve el valor de cualquier
atributo de dicha fila.
Documentos Cotizaciones
DocNro* MonCod*
DocFch MonFch*
DocImp MonCot
DocImpDolar = DocImp / DocCotDolar
DocCotDolar = Min(MonFch, MonCod = ‘U$S’ .and. MonFch >= DocFch, ,
MonCot)
MonFch MonCot
10/01/94 100
11/01/94 110
12/01/94 112
13/01/94 115
16/01/94 117
17/01/94 118
82
Consideraciones aplicables a todas las fórmulas
Aggregate/Select
Documentos Cotizaciones
(Tabla de partida) (Tabla de llegada)
Consideraciones de performance:
Tanto las fórmulas Verticales como las fórmulas Agregate/Select, implican la realización
de navegaciones en la Base de Datos, por lo que es importante considerar la forma en que
esto es realizado.
Las fórmulas Verticales cuentan o suman los valores que estan en "memoria“,
es decir, no recorren la tabla subordinada de nuevo, en caso de insertar, actualizar o
eliminar una línea.
Las fórmulas Aggregate/Select en cambio, recorren cada vez los registros para hacer el
recálculo.
83
USO DE LA FORMULA MAX( ).
84
USO DE LA FORMULA MAX( ).
85
Ejemplo
Transacción de Cotizaciones
MonId*
CotMes*
MonDsc Hacer lo siguiente:
(CotDia*
CotImp)
A. Buscar la cotización de la moneda para la
Transacción de Asientos fecha del Asiento.
AsiNro*
AsiFch
AsiMes B. En caso de que no exista, dar un aviso y
AsiDia buscar la última ingresada anterior a la fecha
(AsiIdLin* del asiento.
MonId
AsiImpME
AsiImpNS
AsiTipDH
CtaId
AsiFndCot)
86
A. Transacción de Cotizaciones:
MonId*
CotMes*
MonDsc
(CotDia*
CotImp)
Transacción de asientos :
AsiNro*
AsiFch
AsiMes = Month(AsiFch)
AsiDia = Day(AsiFch)
(AsiIdLin*
MonId
AsiImpME
AsiImpNS
AsiTipDH
CtaId
AsiFndCot) = Find(CotImp, CotMes=AsiMes .and. CotDia=AsiDia)
if MonId<>’NS’;
1 otherwise;
87
B. Transacción de Asientos :
AsiNro*
AsiFch
AsiMes =Month(AsiFch)
AsiDia =Day(AsiFch)
(AsiIdLin*
MonId
AsiImpME
AsiImpNS = AsiImpME*AsiFndCot if AsiFndCot<>0;
AsiImpME*AsiMaxCot if AsiMaxCot<>0;
1 otherwise;
AsiTipDH
CtaId
AsiFndCot a=Find(CotImp, CotMes=AsiMes .and. CotDia = AsiDia)
if MonId <> “NS”;
1 otherwise;
AsiMaxCot) = Max(CotDia, CotMes= AsiMes .and. CotDia <= AsiDia, 0 , CotImp)
if null (AsiFndCot) ;
0 otherwise;
88
1. Condiciones involucradas en una
Fórmula Aggregate Select
Condición de Búsqueda
Es la condición a la cual está sujeta la búsqueda.
Condición de Disparo
Es la condición que determina si la fórmula se ejecuta.
89
2. Inferencias en el caso de una
Fórmula Aggregate Select
90
En el ejemplo:
Transacción de Cotizaciones:
MonId*
CotMes* Given : MonId
MonDsc
(CotDia*
CotImp)
Transacción de Asientos :
AsiNro*
AsiFch
AsiMes =Month(AsiFch)
AsiDia = Day(AsiFch)
(AsiIdLin*
MonId
AsiImpME
AsiImpNS
AsiTipDH
CtaId
AsiFndCot) =Find(CotImp, CotMes=AsiMes .and. CotDia = AsiDia)
if MonId <> “NS”;
1 otherwise;
91
3.Cómo se determina la tabla sobre la cual
efectuar la búsqueda (tabla de llegada)
• Atributo de Búsqueda
• Atributos que están en la condición y que no pertenecen a la
tabla extendida del Atributo Fórmula
• Atributo de Retorno
De otra forma:
<Atr.Fórm.> - Fórmula Inválida
92
Ejemplo de determinación de la tabla sobre
la cual buscar:
93
Ejemplo de determinación de la tabla sobre
la cual buscar:
94
4. Fórmulas Aggregate Select no pueden participar en
fórmulas SUM y COUNT simples
No se permite definir una fórmula SUM que suma un atributo que es
una Aggegate/Select o depende de ella.
Ejemplo:
95
5. Dependencia física de las fórmulas
Aggregate Select
EJEMPLO :
Transacción de Asientos
AsiNro*
AsiFch
AsiTotDeb = Sum(RengImp, RengTipDH=“D” , 0)
AsiTotHab = Sum(RengImp, RengTipDH=“H” , 0)
(RengId*
MonCod
RengImpNS
RengImp
RengTipDH
CtaCod )
96
Diferencias entre fórmulas aggregate
select y fórmulas verticales
1. Las fórmulas agg/sel actúan sobre cualquier tabla de la base de datos y las fórmulas
verticales solamente sobre tablas directamente subordinadas.
3. Las fórmulas verticales cuentan o suman los valores que estan en "memoria". Las
aggregate/select no.
4. Las fórmulas verticales cuentan o suman atributos que pueden ser fórmulas (pero esta
fórmula no puede ser agg/sel ni involucrar en su definición una fórmula agg/sel).
Los atributos mencionados en las fórmulas aggregate/select y pertenecientes a la tabla de
llegada deben estar ALMACENADOS FISICAMENTE en la tabla de llegada
5. Las fórmulas agg/sel no se pueden definir como redundantes. Las verticales sí.
97
COMUNICACION
ENTRE OBJETOS
98
Objetos GeneXus
TRN
RPT PROC
MENU WKP
99
Reglas y Comandos
para implementar la comunicación
• CALL
La diferencia entre los UDP y UDF es que los programas llamados por la función
UDF no deben abrir ninguna tabla, mientras que los llamados por la función
UDP sí lo pueden hacer.
Esta diferencia existe SOLAMENTE en el generador Fxp 2.6 y VFP (en los
demás generadores no existe diferencia entre los udp y udf), las UDF al regresar
no reabren/reposicionan las tablas, por lo tanto no soportan que el programa
llamado abra tablas. Por otro lado, el Call es un poco más rápido. Las UDP
restauran las tablas al volver y se usan para llamar a programas que abren tablas.
100
Cuál es la convención usuada para el nombre de los
objetos GeneXus en las llamadas?
Los programas llamados con las reglas o comandos mencionados pueden ser
cualquier objeto GeneXus (Transacciones, Procedimientos , etc.), o un programa
externo escrito por el usuario.
El nombre de dichos objetos a utilizar en la llamada (call , udp) se forma por un
prefijo (identificando el tipo de objeto) seguido por el nombre del objeto truncado
de acuerdo a la tabla de más arriba.
En caso de que el objeto llamado sea un programa externo, debe mencionarse el
nombre del programa entre comillas; en caso de ser un objeto GeneXus va sin
comillas.
Ejemplo:
Por ejemplo, si luego del ingreso de una Factura se quiere un listado de la misma,
lo que habría que poner en las Rules de la Transacción Factura es:
call(RImpFac, FacNro) if insert .and. after(TRN);
donde ImpFac es el nombre del Report que imprime la factura recibida como
parámetro.
101
Call
Sintáxis
En regla de Transacciones:
call(nom-prog,par1,...,par2) if (condición);
El momento del disparo del call va a depender del lugar donde se encuentra.
Si el call está en las reglas de la transacción, se va a tomar en cuenta en el
árbol de evaluación de las reglas. Si está en el layout o program source de un
reporte o procedimiento, o en los eventos (tanto de transacciones como work-
panels) se va a ejecutar proceduralmente en el lugar donde fue escrito.
102
Call - Regla Parm
La regla PARM tiene como función declarar los parámetros en
el objeto llamado.
Sintáxis: Parm(atributo/variable);
Con la regla PARM se declaran los parámetros que recibe un objeto GeneXus,
estos parámetros son posicionales, se deben escribir en el mismo orden, la
misma cantidad y el mismo tipo que los indicados en el CALL.
103
Udp
Sintáxis
En reglas de Transacciones
<Att|&var> = Udp(nom-prog,par1,...,parn) if (condición);
En Fórmulas:
<Att> = Udp(nom-prog,par1,...,parn) if (condición);
Las Udps pueden ser utilizadas en las reglas de los objetos, en las fórmulas, en
el program source de procedimientos, en el layout de reportes, y en los eventos
de transacciones o work-panels.
104
Udp - Regla Parm
El último parámetro en la regla parm es el valor de
retorno.
Ejemplo:
parsal = udp(PAltaCli, par1, … , parn)
Al igual que en los programas llamados con call, en los programas llamados por
UDPs se deben declarar los parámetros con la regla Parm. A diferencia con los
calls, el programa llamado siempre va a tener un parámetro como mínimo (el
parámetro de retorno).
Ejemplo:
Tenemos un procedimiento que calcula la calificación de un funcionario
105
Ejemplo:
En procedimiento PCaldto:
Parámetro de retorno
En el ejemplo, se utiliza una función externa (por ser externa es que el nombre se
pone entre comillas) para calcular el descuento dado el total de una factura y la
categoria del cliente.
Ejemplo: &A = 1
&A = UDP(PXXX)
106
SUBRUTINAS
107
Comando SUB
Sintáxis :
Sub 'RoutineName’
//cuerpo de la subrutina
EndSub
108
Comando DO
Sintáxis :
Do 'RoutineName'
109
ARBOL DE EVALUACION Y
EVENTOS
110
R.
Arbol de evaluación
Add(FctTot, CliTotCmp) ;
F. FctTot = FctSubTot - FctDto + FctFleVal CliTotCmp
F. FctDto = FctSubTot * CatDto
F. FctFleVal = MAX( FctFleFch, FctFleFch <= FctFch, ...
F. FctSubTot = SUM ( FctImp)
F. FacImp = FacCnt * ArtPrc FctTot
R. Subtract(FctCnt, ArtStk) ;
R. Error( ‘Stock Insuficiente’) if ArtStk < 0 ;
FctDto FctFleVal
error (‘No hay Stock’)
FctSubTot
FctFch
ArtStk FctImp CatDto
FctCnt ArtPrc
Arbol de Evaluación
El conjunto de reglas y fórmulas han sido definidas sin especificar su secuencia de
ejecución; pero en el momento de generar el programa GeneXus deberá
determinar esta secuencia.
111
Es importante mencionar que cuando se encuentra un error se desarma el Arbol
de Evaluación, dejándose todo en el estado anterior a producirse el error. El
error detiene cualquier actualización a la base de datos.
El árbol es en realidad una red pero donde no pueden haber ciclos, si los hubiera
en algunos casos se dispara con el valor anterior. Ejemplo: A = 1/A, se ejecuta
en realidad con el valor anterior de A.
A = 1 / Old(A)
112
Alteraciones del orden de disparo
de las Reglas
Error
PrvCod*
FctNro* Total Total
... Calculado Ingresado
FctTotIng Total ingresado
( ArtCod*
Fact Impt
FctCnt
FctPrc
FctImp = FctPrc * FctCnt)
...
FctTotCalc = SUM (FctImp) Total calculado
En la mayoría de los casos el orden de ejecución de las reglas definido por GeneXus a
partir de nuestras especificaciones es el deseado. Pero en algunos casos puedo querer
cambiar el momento de disparo de una Rule.
Por ejemplo:
En las facturas que recibimos de nuestro proveedor queremos controlar que el total
que viene impreso en la factura (FctTotIng) sea correcto, por lo que lo calculamos
nuevamente (FctTotCalc), y emitimos un error si no es así.
Si construimos el arbol de evaluación vemos que las dependencias entre las reglas y
fórmulas determinan que cada vez que cambie el importe, se cambiará el total
calculado que es parte de la condición de la regla Error.
Esta condición se va a cumplir (total calculado <> total ingresado) ya para la primera
línea ingresada en la factura y se va a disparar el error en ese momento.y no podré
seguir adelante.
113
Entonces le marco el evento de disparo After(level(ArtCod))
Estos casos no son muy frecuentes, pero se dan y hay que conocerlos.
A continuación se describirán cada una de estas funciones que permiten resolver casos
como este, en el que el momento que GeneXus definió para ejecutar la regla no es el
deseado.
// INCORRECTO
Error('El total de la factura no coincide con el ingresado') if FctTotIng <>
FctTotCalc;
// CORRECTO
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
Sintáxis: Level(Atributo)
Retorna True o False dependiendo del nivel en que se encuentre en la
estructura el atributo especificado.
Ejemplo: Call(‘Pxxx’) if Insert .and. level(CliCod) ;
Si se mencionara un atributo como parámetro no sería necesario especificar el
nivel ya que se tomaria el nivel del parámetro.
Ejemplo: Call(‘Pxxx, CliCod’) if Insert ;
After
Sintáxis: After(<Event>)
Donde <Event> puede ser :
<Att> | <Action> | Level(<Att>) | Trn | Confirm
After(Attribute)
Ejemplo: A = B * C if After(C);
Ejecuta la regla después de aceptar el valor del atributo C.
La condición After(Att) tiene el mismo efecto que la condición Level(Att) en
el entorno AS/400, ya que la transmisión es a pantalla completa y no atributo a
atributo como en PC.
115
Insert, Update, Delete
Para condicionar el modo de disparo
After(Confirm)
Dispara la regla después de haber confirmado los datos del nivel asociado pero antes de
haber realizado la actualización.
After(Insert)
After(Delete)
After(Update)
Ejemplo:
La siguiente transacción llama a un procedimiento que realiza la impresión de los datos de
un cliente. El procedimiento seteará el atributo CliSts, para indicar que se realizó la
impresión.
Transacción Clientes
CliCod* Código de Cliente
CliNom Nombre de Cliente
CliSts Status cliente
Llamadas Incorrectas:
Caso 1: Call('pficha', CliCod) if Insert .and. After(Confirm);
El cliente no existe, por lo que falla la lectura.
Llamadas Correctas:
After(Trn)
Dispara la regla después de procesar todos los datos de la transacción, es decir, el primer
nivel y todos los subordinados.
En el AS/400 la regla es disparada después del Commit.
116
Reglas que ocurren en el mismo evento
Son disparadas en el orden en que fueron definidas
Ejemplo
Ejemplo
Ejemplo 1
Se ejecuta un Call y luego el otro
Ejemplo 2
Se quiere llamar a un procedimiento que realiza determinada validación, y que
retorna en la variable &flag, el resultado (S o N). En caso de que el resultado sea
negativo se quiere mostrar un mensaje de error.
Importante:
En los calls los parámetros son de ida/vuelta del punto de vista del lenguaje, pero
del punto de vista del especificador son sólamente de ida. Es decir, para
determinar el árbol de evaluación de reglas y fórmulas, Genexus considera a los
parámetros de los calls como de ida.
117
En otras palabras, si se escribieran las reglas del ejemplo 2 en orden inverso, y la
&flag resultara negativa, el error no se dispararía.
118
Ejemplo de transaccion de dos niveles
Level CabFac
.....................................> reglas stand-alone
Trasmit Screen
....................................> evaluación de reglas y fórmulas según árbol
Confirm Screen
....................................> reglas after(confirm)
Insert/Update/Delete
....................................> reglas after(insert/update/delete)
Level LinFac
Trasmit Screen
..........................> evaluación de reglas y fórmulas según árbol
Confirm Screen
..........................> after(confirm) .and. level(<att de 2do. nivel>)
Insert/Update/Delete
....................................> reglas after(insert/update/delete) .and.
level(<att de 2do. nivel>)
EndLevel
....................................> after( level (<att de 2do. nivel>))
Commit
................................> evaluación de reglas after (trn)
EndLevel
119
Eventos en las Transacciones
Los eventos son acciones que pueden suceder o no. Nosotros tendremos un código
asociado a cada evento posible, el cual se disparará sólo si el evento se produce. Por
ejemplo, puede haber un código asociado al evento de presionar una tecla (Por
ejemplo <Enter>), que se activará cuando el usuario decida presionar esa tecla.
120
Eventos explícitos en las
Transacciones
Evento Start
Evento ‘User-Event’
Evento Exit
User Defined Event: Es un evento definido por el usuario, que es activado una vez
que se selecciona una opción del menú o se presiona una tecla de función/botón.
After Trn: Es un evento del sistema y es activado una vez que la transacción ha
terminado.
Es similar a la regla AFTER(TRN) usada en las transacciones.
121
Evento Start
122
Evento Start
Ejemplos:
Event Start
call(PFindCli,&today, CliCod)
EndEvent
En el Evento Start no hay atributos disponibles como para ser evaluados y/o usados.
123
Eventos del Usuario
Sintáxis:
Event ’User-event-name’ <Key>
Level <att>
Endevent
Ejemplo
Event ‘Deuda Cliente’ 2
Level FacId
if .not. null(CliId)
call(wdeucli,CliId)
endif
Endevent
124
Evento After Trn
Event After trn
EndEvent
Ejemplo:
Event After trn
Return
EndEvent
Equivalente a la función After(trn), pero permite agrupar todas las acciones que se
deseen evaluar en el after(trn) sin tener que condicionarlas por separado (rules).
Ejemplo:
125
Evento Exit
Event Exit
…………….
EndEvent
Event Exit
&user = userid()
&salida = Time()
call(‘pcontrol’, &entrada, &salida, &user)
EndEvent
En el Evento Exit no hay atributos disponibles como para ser evaluados y/o usados.
126
Rules / Eventos
En caso de conflicto de evaluación entre reglas
y eventos de una transacción, la regla se evalúa
primero.
Eventos: Rules:
Event After trn call(tvenfac,FctCod) if after(trn);
…….
return
End event
127
Ejemplos de uso de Eventos en las Transacciones
3. Podemos querer retornar al programa llamador una vez que la transacción haya sido
ingresada:
Event After trn
Return
Endevent
4. Para contar la cantidad de veces que una transacción ha sido invocada durante una sesión,
podemos programar los siguientes eventos:
Event Start
&Veces = 0
Endevent
Event Exit
&Msg = 'El número de transacciones grabadas: ’ + str(&Veces)
msg(&Msg)
Endevent
128
5. Por ejemplo, supongamos que en la transacción de facturas queremos dar la opción de
visualizar otras compras del cliente.
Definimos entonces un evento del usuario:
Cuando el usuario presione la tecla F4, llamaremos al work panel 'VerCompras' que
mostrará las otras compras del cliente.
129
Consideraciones
Restricciones
•No se permiten comandos asociados a otros eventos existentes en los work panels
(load, refresh,etc.).
Recomendaciones
•Controlar mediante variables seteadas en las reglas que los eventos de usuario hagan
calls en situaciones válidas.
•Los eventos de usuario pueden evaluarse en cualquier momento, sin tener en cuenta
el modo en que está la transacción.
•Los atributos pasados como parámetros en los calls que se ejecutan en los eventos,
son de entrada/salida, por lo tanto pueden cambiar su valor instanciándose con el
valor devuelto por el programa llamado.
130
REPORTES
Y
PROCEDIMIENTOS
131
Reportes y Procedimientos
Reportes
• Procesos no interactivos de consulta de la base
de datos.
Procedimientos
• Procesos no interactivos de actualización de la
base de datos.
Reportes
Procedimientos
132
Características
• Definición procedural
•Definición Procedural.
133
Comando For Each
Sintaxis:
For Each [Order] [ Atr...Atr]
Where <Condition>
...
Where <Condition>
Defined by <Attribute List>
…..
Endfor
Toda la definición del acceso a la base de datos y la estructura del reporte o procedimiento, se realizan
sólo con este comando.
Usando el FOR EACH se define la información que se va a leer de la base de datos, pero la forma de
hacerlo se basa en nombrar los atributos a utilizar y NUNCA se especifican nombres de tablas ni
nombres de índices. Con este comando se define QUE atributos se necesitan y en qué ORDEN se
quieren recuperar, y GeneXus se encarga de encontrar COMO hacerlo.
El acceso a la base de datos queda especificado por los atributos que son utilizados dentro de un grupo
FOR EACH - ENDFOR. Para ese conjunto de atributos GeneXus buscará la tabla extendida que los
contenga (el concepto de tabla extendida es muy importante en este comando y sugerimos repasar su
definición).
Order: Lista de atributos que indican el orden de recorrida de la tabla base. Sólo pueden mencionarse
atributos almacenados en la tabla base. El Order es opcional, en caso de no especificarse se asume el
orden de la clave primaria de la tabla base (si es que el for each no está anidado a otro for each).
Elección del índice: GeneXus elige automáticamente el índice a utilizar para satisfacer el
orden, en caso de que no exista, se crea el índice en forma temporal.
Defined by: Al mencionar en esta cláusula algún atributo secundario de la tabla que se desea recorrer,
dicho(s) atributo(s) participará(n) en la elección de la tabla base del For Each. Debe quedar claro que
el/los atributos mencionados en el Defined by “participan” en la determinación de la tabla base así
como también participan los demás atributos mencionados en todo el For Each. Los atributos
mencionados en esta cláusula no tienen más peso que los otros atributos del For each. El objetivo de
esta cláusula es permitir “mencionar” cierto(s) atributo(s) en el cuerpo del For each (sin actuar como
filtros, ni ordenar por ellos, ni imprimirlos) sino que sólo se desea(n) referenciar en el For Each para
que participe(n) en la determinación de la tabla base.
134
Inferencia de las tablas utilizadas en
el For Each
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.
135
1. Cómo pudo GeneXus determinar qué tablas se utilizan en el reporte ?
Para esto se debe determinar en qué tablas están los atributos que se han mencionado
dentro del comando FOR EACH.
Con la base de datos en 3era Forma Normal podemos definir dos conceptos, atributos
primarios y secundarios:
Atributo Primario: Es aquel atributo que es parte de la clave primaria de alguna tabla
del modelo. El atributo puede pertenecer a varias tablas, como un atributo común o
como parte de la clave. Por ejemplo DptCod que es un atributo primario, está en las
tablas de Client y Depart.
Por esta razón, se puede determinar en que tabla está un atributo si es un atributo
secundario. Dado que en el FOR EACH hemos mencionado atributos secundarios de
dos tablas Client y Depart, éstas son las que deben usarse en el reporte, con lo cual
hemos respondido la interrogante planteada.
2. Cómo pudo GeneXus determinar qué tabla debe recorrer y qué otras tablas
debe acceder para complementar la información ?
GeneXus ha determinado que debe recorre la tabla Client y acceder a la tabla Depart
para complementar la información, lo que se informa en el diagrama de navegación del
reporte.
------------------->Client ( CliCod )
------------>>Depart ( DptoCod )
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.
136
Repasemos los conceptos de tabla base y tabla extendida:
Toda tabla del modelo (tabla base), tiene información que le permite acceder a todas
las tablas del modelo con las cuales está relacionada. La Tabla Base define su Tabla
Extendida con todas las tablas que estén en una relación de cardinalidad N para 1 con
dicha tabla. Es decir que para cada instancia de la tabla base existe una única instancia
de cada tabla de la tabla extendida.
Aplicando estos conceptos al ejemplo, vemos que la tabla de Clientes está en una
relación de N para 1 con la tabla de Departamentos:
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.
GeneXus puede determinar esto automáticamente porque conoce la relación entre las
tablas, y puede entonces además saber cuales son las navegaciones válidas entre estas.
137
3. Qué orden y qué índices deben utilizarse?
En la definición del listado se asume que será ordenado por la clave primaria de la
tabla elegida como tabla base del FOR EACH.
GeneXus conoce los índices de las tablas de la Base de Datos, y entonces puede elegir
el índice a utilizar para satisfacer este orden.
Es posible listar en un orden diferente utilizando la cláusula Order del FOR EACH.
138
Ejemplo :Tabla Base y Tabla Extendida
FACTURA1 PRODUCTO
FacNro* ProdCod*
ProdCod* ProdNom
FacLinCnt ProdPre
139
When None
También se aplica a For Each [Selected] Line, XFor Each y XFor First, los
cuales veremos más adelante.
140
Report Wizard
• Permite diseñar el layout de un reporte (o
procedimiento) de una forma mucho más fácil.
1.- Requiere de una estructura de datos en la cual hay que incluir atributos.
Dicha estructura es muy similar a la usada en las transacciones, sin embargo,
los paréntesis se usan para indicar niveles de For Each (en vez de niveles de
una transacción) y el asterisco (*) se usa para indicar el orden deseado (y no
para indicar la unicidad como en las transacciones). Una vez que se definió
correctamente la estructura, se presiona el botón de “Next” para pasar al
siguiente paso.
2.- Permite definir otras características del layout. Se permite elegir los fonts
para representar los atributos o textos, también se permite definir si los
cabezales de los atributos para cada uno de los niveles se despliegan
horizontalmente o verticalmente.
Presionando el botón de “Finish “ se graban las definiciones y se sale del
diálogo del Report Wizard.
•Una vez que todas las opciones del Wizard fueron aceptadas, se genera el layout del
reporte, el cuál puede ser modificado como cualquier otro reporte. También es posible
editar el Wizard mediante la opción : Edit / Report/Proc. Wizard.
•El Wizard permite que los niveles tengan o no orden . El atributo que indica el orden
no tiene por qué ser el primero del nivel.
141
For Each paralelos
EndFor
EndFor
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
La tabla base queda determinada estudiando los atributos utilizados en el cuerpo del
For Each en el caso de los For Each principales (no anidados).
Para el caso de los For Each subordinados la tabla base queda establecida por los
atributos utilizados en el cuerpo del For Each siempre y cuando estos atributos no
esten contenidos en la tabla extendida del For Each principal. Si el conjunto de
atributos utilizados en el For Each están contenidos en la extendida ya calculada, el
for each anidado tendrá la misma tabla base del for Each principal. Este caso se
distingue en el diagrama de navegación utilizando BREAK en lugar de For Each para
todo grupo For Each subordinado que no defina una nueva tabla base.
143
For Each anidados
• Caso 1 : Tablas extendidas de los For Each
distintas pero relacionadas por uno o más
atributos
[CliCod] [CliNom]
For Each
CliCod
[FacNro] [FacTot]
Endfor
Endfor Atributo relación: CliCod Facturas
Cuando se definen For Each anidados GeneXus intentará establecer que atributos en
común tienen ambas tablas extendidas (dándole prioridad a los atributos de la tabla
base), y definirá que estos atributos actuarán como condiciones de filtro en la
recorrida de la tabla anidada.
En este ejemplo, la tabla base del primer for each es la de clientes, y la del segundo, la
de facturas. Ambas tablas están relacionadas por el atributo CliCod.
FOR EACH Client
Order : CliCod
Index : I00101
Navigation filters:
Start from: First record
Loop while: Not end of table
144
For Each anidados
Producto Cartesiano: Para cada registro de la tabla base del primer For Each se recorre
toda la tabla asociada al For Each anidado.
145
Corte de Control
• Caso 3 :
Procesar información por grupos.
Ej: Procesar facturas por cliente. Cada vez que cambia
el cliente se define un nuevo grupo.
For Each Orden CliCod
(tabla Factura) orden - determina
For Each corte de control
(tabla Factura)
EndFor
EndFor -> Defined by, Print if detail
Corte de Control
La resolución de este reporte puede hacerse accediendo únicamente a las facturas, recorriendo
la tabla ordenada por cliente. En este caso imprimiríamos solo aquellos clientes que tienen
facturas.
De todas maneras es necesario utilizar dos for eachs, ya que se necesita una instancia de corte,
es decir un momento en el que se cambia de cliente y se puede operar en consecuencia, por
ejemplo imprimir el total facturado al cliente.
Lo interesante del caso dos for eachs tendrán como tabla base la tabla de facturas. Para lograr
esto se puede utilizar la cláusula DEFINED BY del For each o el comando PRINT IF
DETAIL.
Se debe definir además en el orden de recorrida del primer for each (cláusula ORDER), los
atributos por los que se quiere realizar el corte (en el ejemplo CLICOD). Este es un
requerimiento debido a que GeneXus no podría saber cual es el criterio de agrupación que
queremos ya que en una misma tabla pueden ser varios, por ejemplo podríamos querer realizar
el corte de control por Fecha de factura, totalizando el total facturado cada dìa.
146
Para resumir, un corte de control queda definido de la siguiente manera:
Existen dos grupos FOR EACH anidados sobre la misma Tabla Base, los
atributos de corte quedan definidos por el conjunto de atributos especificados
en el comando ORDER.
Para hacer un corte de control, necesitamos hacer una navegación de Facturas por
Fecha.
Cuando ejecutemos este reporte, generará un índice temporal por fecha, sobre la tabla
Facturas.
BREAK Factur
Order : CliCod, FacNro
Navigation filters:
Loop while:
CliCod = CliCod
FacNro = FacNro
------->> Factur ( FacNro )
END BREAK
END FOR
La particularidad de esto es que el segundo For each se muestra como un BREAK.
147
Filtros en la navegación
• Where
• Condition
La regla PARM()
La utilización de atributos en la regla PARM() determina una condición por igual
global para todo el reporte o procedimiento.
Ejemplo: PARM(CliCod) .
For Each
[ CliCod] [CliNom]
Endfor
El reporte sólo podrá acceder al cliente cuyo código sea igual al recibido como
parámetro.
148
Diseño de la salida
MT
Header
…...
End
PL
CP [nlinea]
Lineno [nlinea]
Eject
Noskip
Footer
MB :
End
MB [nlínea]: nlíneas es el número de líneas que se desea dejar como margen inferior.
En caso de no especificarse un valor se asume el valor por defecto que es 6.
Lineno [nlínea] : Define el número de línea donde va a ser impresa la siguiente línea.
Si el número de línea actual es mayor al número especificado, entonces, la línea será
impresa en la próxima página.
149
Report Viewer
• Permite:
– Imprimir
– Visualizar el reporte mientras se está generando
– Paginado
– Zoom
– Salvado a un archivo
– Find
150
PROCEDIMIENTOS
151
Inserción de registros
Ejemplo: Inserción en tabla de resumen de
ventas anuales
Tabla: CliCod*
VtaAno*
VtaTot
New
CliCod = &CliCod
VtaAno = &Ano
VtaTot = &Total
When Duplicate
For each
VtaTot = VtaTot + &Total
Endfor
EndNew
Cuando hacemos una inserción en una tabla, GeneXus controla que no hayan claves
duplicadas. Si quisieramos aplicar un tratamiento especial para estos casos, podemos
usar el comando When Duplicate para decir que acción tomar cuando se detecta que el
valor de la clave en un alta ya existe en la tabla correspondiente.
152
Actualización
For Each
Los atributos actualizables dentro de un grupo For Each, son todos los
pertenecientes a la tabla extendida.
153
Delete
For Each
defined By FacFch
Delete sólo Tabla Base
endFor
154
Restricciones
Consideraciones:
•Si no incluimos la clave primaria en el New, ese New se realiza con valor nulo de
clave.
2. Si el New está dentro de un For Each, los atributos instanciados por el For
Each y no mencionados en el New son inferidos para la inserción del registro.
155
WORK PANELS
156
Work Panels
157
Diferentes tipos de Paneles
- Entry Panel
- Display Panel
- Single Choice Selection List
- Multiple Choice Selection List
- Action List
Las normas Common User Acces de IBM definen diversos tipos de pantallas,
estandarizando los diálogos con el usuario.
158
Entry Panel - Panel de Entrada
Paneles de Entrada
159
Display Panel - Panel de Salida
Paneles de Despliegue
160
Selección Unica/Selección Múltiple/Listas de Acción
Area Fija
Subfile
Eventos y
Teclas de función
Una lista de selección de opción única contiene un grupo de opciones de las que los
usuarios pueden seleccionar solamente una. La forma de hacer la selección es teclear
algún valor en la línea a ser seleccionada. Una acción puede ser entonces ejecutada
sobre el contenido de la línea seleccionada.
Lista de Acción
Se pueden elegrir acciones diferentes a aplicar a cada una de las líneas.
161
Comando For Each Line
Sintáxis:
For Each Line
…….. Recorre todas las lineas
EndFor del subfile
•El comando For Each Line permite recorrer el Subfile (no la base de datos). Para
cada una de las lineas del subfile, se ejecuta el cuerpo del For Each Line.
•El comando For Each Selected Line permite recorrer sólo las lineas que fueron
seleccionadas del Subfile.
162
Programación dirigida por Eventos
El código del programa permanece ocioso hasta que se
invoca su ejecución mediante acciones tomadas por el
operador del programa frente a la pantalla .
Ejemplo:
Event Enter
Código en respuesta a pulsar la tecla Enter
EndEvent
163
Eventos
• Start
• Refresh
• Load
• Enter
• User-defined
• Exit
Evento Start: Es un evento del sistema, ocurre cuando se comienza a ejecutar el work panel.
Es usado comunmente para asignar valores a variables, generalmente para dar valores por
defecto a las variables del área fija de la pantalla.
Evento Refresh: Es un evento del sistema, ocurre inmediatamente antes de comenzar la carga
del subfile. En un ambiente multiusuario, los datos de la pantalla pueden estar desactualizados
si fueron modificados desde otra terminal. En este caso, cuando el usuario desee actualizarlos,
deberá presionar el botón refresh cuyo efecto es cargar nuevamente el subfile.
Comando Refresh: En algunos casos, desde otro evento también puede ser necesario cargar
nuevamente el subfile. Por ejemplo cuando en un evento se llama a una transacción que
actualiza los datos (Ejemplo "Ingresar" (F6)) que se están desplegando en el subfile, lo que se
hace entonces es ejecutar el comando refresh luego del call a la transacción.
También se necesita hacer un refresh cuando una variable que aparece en las Conditions es
modificada por el usuario. Estas variables determinan qué datos se cargarán en el subfile, si
una condición cambia, el subfile debe ser cargado nuevamente.
Evento Load: Es un evento del sistema que ocurre cuando un subfile está siendo cargado.
Para cada registro que se cargará en él, se disparará este evento.Este evento es usado
generalmente para cargar variables en el subfile. Los valores de estas variables pueden ser
calculados o leidos de la base de datos usando el comando For Each.
Se puede hacer referencia a cualquier atributo que pertenezca a la tabla extendida asociada al
panel de trabajo.
Evento Enter: Este evento ocurre cuando el usuario presiona Enter.
Evento Exit: Este evento ocurre después que el usuario presionó la tecla de salida (ESC o
F12), o el comando "return" es ejecutado en cualquier evento.
User Defined Event:: Se pueden definir eventos del usuario, los que pueden estar asociados a
una tecla de función o a un botón. De esta manera el evento ocurre cuando el operador
presiona la tecla de función o el botón asociado al evento.
164
Estructura de los eventos
Comienzo
Evento Start
Evento Refresh
Evento Load
Mostrar datos en
pantalla
Evento Enter
Evento 'User Defined'
Evento Exit
Fin
165
Reglas más importantes
• Order
• Noaccept
• Search
• Hidden
• Workfile_lines
Order
Define cuál es el orden de los datos en el subfile. Es equivalente a la cláusula ORDER del
For Each y se aplica todo lo dicho en la sección de Reportes sobre el tema (incluida la
creación de índices temporales).
Por ejemplo, si quisieramos ver los clientes ordenados por nombre:
Order(CliNom);
Noaccept
A diferencia de las Transacciones, en los paneles de trabajo ningún atributo es aceptado.
En cambio las variables presentes en la pantalla son aceptadas, a no ser que tengan la regla
NOACCEPT.
Search
Cuando el subfile es demasiado extenso, muchas veces se quiere brindar la posibilidad de que
el usuario pueda 'posicionarse' en alguna línea determinada del mismo, en forma directa, sin
tener que avanzar página por página.
Por ejemplo, para buscar un cliente por su nombre se debe definir la regla:
Search(CliNom >= &Nom);
Hidden: Esta regla es usada para indicarle a GeneXus cuales atributos o variables deben
incluirse en el subfile sin estar presentes en el mismo. Se usa cuando por razones de
presentación, no es conveniente mostrar un atributo en el área de subfile de la pantalla, pero
se quiere capturar su valor cuando se haga el load de la misma.
Workfile_lines (<MaxLine>): Dado que los subfiles se cargan en archivos temporales y que
no existe un límite en la cantidad de líneas a cargar en ellos en PC o LAN , puede traer
problemas si la tabla base asociada tiene muchos registros ya que el archivo temporal
tendría todos los registros de la tabla base. Usando esta regla, se menciona en MaxLine la
máxima cantidad de líneas que se permite cargar en el subfile. Si el límite expecificado se
excede, se despliega el siguiente mensaje “ Number of lines exceeded xxxx ”.
166
Propiedades más importantes
Loading
Load Records
Load at Startup
Automatic Refresh
Refresh Timeout (FoxPro only)
Load Records: Los posibles valores son ‘Load on request’ o ‘Load all records’.
Load on request: A medida que se va paginando va cargando los registros del
subfile (‘Carga a pedido’).
Load all records: Carga todos los registros.
Refresh Timeout: Esta property es para que se haga un refresh del subfile
automáticamente si el usuario no efectuó ninguna operación en el lapso de tiempo
especificado. No hay valores predefinidos. Debe especificarse un valor en segundos
(lapso de tiempo).
167
Work-Panel con o sin Tabla Base ?
• Panel
• Reglas Hidden y Order
• Eventos ( fuera de comandos For Each)
En este caso se genera sólo un Evento Load, y es en él donde se deben cargar los datos
en el subfile, haciendo for each a la (s) tabla(s) deseadas cargando las variables del
form.
168
Diálogo Modal/No Modal
• Property Modal dialog
– En transacciones y work panels (llamados).
• Opciones:
– Yes if parameters specified
– Yes
– No
• Sólo generadores Visuales.
•Esta propiedad permite indicar para cada objeto, si utilizar diálogo “modal” o
“no modal”.
169
SUBTIPOS
170
Subtipos
Ejemplo: Transferencias entre Bancos.
Transacción de Bancos:
BcoCod* Código de Banco
BcoNom Nombre de Banco
Transacción de Transferencia :
TrnNro* Número de transacción
TrnFch Fecha
‘Problema’ BcoCod Banco Origen
Atributos BcoNom Nombre del Banco Origen
con el BcoCod Banco Destino
mismo BcoNom Nombre del Banco Destino
nombre TrnImp Importe
Esto no es correcto pues tengo que poner atributos con el mismo nombre en la
misma transacción.
Para estos casos GeneXus provee los Subtipos, los cuales permiten definir que
dos atributos que se llaman diferente, corresponden al mismo concepto.
171
Transferencia:
TrnNro*
TrnFch
Subtipos
Bancos: TrnBcoOriCod
BcoCod* TrnBcoOriNom
BcoNom
TrnBcoDestCod
TrnBcoDestNom
Subtipo Supertipo
TrnBcoOriCod BcoCod
TrnBcoOriNom BcoNom
TrnBcoDestCod BcoCod
TrnBcoDestNom BcoNom
Hay que definir atributos con distinto nombre y que tengan una dependencia
funcional.
•La tabla extendida que se obtiene con la definición del subtipo, es la misma que se
obtendría en el caso que se utilizara directamente el supertipo.
172
Subtipos: Grupos
Todavía queda algo por determinar. Tenemos dos bancos y dos nombres pero en
ningún lugar indicamos el nombre a que banco corresponde.
Es acá donde aparece la necesidad de definir grupos.
173
Algunas Consideraciones
174
KNOWLEDGE
MANAGER
175
Distribución
176
Consolidación
177
BUSINESS
OBJECTS
178
Qué es un Business Object ?
Algunos ejemplos concretos de Business Objects son: producto, persona, factura, moneda,
pais.
179
Cómo representar un Business
Object con Genexus?
zReportes
relevantes
180
Business Object GeneXus
Cada BO es un folder que contiene todos objetos GeneXus necesarios para definir el
comportamiento y el uso de dicho BO.
181
Características de un BO
zIndependiente
zNo ligado a ninguna aplicación
zStandard y simple
zFácilmente adaptable
zDocumentado
zBien testeado
182
Cuándo usar BO?
183
Ventajas de su uso
Reusabilidad :
z
–aumenta productividad
–disminuye esfuerzo de desarrollo
zProveer soluciones rápidamente
zFacilitar la ampliación de las funcionalidades de
una aplicación
zCompartir conocimiento
184
Algunos BO Genexus
zPaises
zProductos
zPersonas
zMonedas
zTipos de IVA
zNumeradores
185
Distribución de los BO
186
OBJETOS PRIVADOS
187
Objetos Privados
• Objetivo: proteger el conocimiento
188
Objetos Privados
• Al momento de “distribuir”, si existe algún
objeto privado se ingresará:
Objetos Públicos
Un objeto podrá ser público sin restricción alguna, en cuyo caso puede seguir
siendo utilizado libremente. En este caso no es necesario hacer nada con el
objeto.
Objetos Privados
En el caso de que el propietario del objeto decida definirlo como privado,
únicamente en la KB origen se podrá acceder libremente y modificarlo. Los
demás usuarios (aquellos que licencien conocimiento de aquel) sólo podrán
editar sus pantallas, ver el cabezal del mismo (Information) y generarlo.
Esto sólo indica que el objeto será Privado, pero no se hará ningún proceso
con él, hasta el momento de su exportación (distribución).
189
Objetos Privados
• Operativa de los objetos privados: son
“generables” y algunas partes visibles y/o
editables
190
EFICIENCIA Y PERFORMANCE DE
LAS APLICACIONES
191
Puntos a Considerar
• Optimización de la Entrada-Salida
• Uso de Calls
• Open y Close de archivos
• Uso de Indices Temporales
Optimización de Entrada-Salida:
Dado que el acceso a las tablas es costoso, vamos a ver cómo minimizarlo.
Uso de Calls:
Veremos cuándo debemos empezar a preocuparnos por el uso de este
comando.
192
Optimización de Entrada-Salida
Definición de Filtros
Peor Estrategia Estrategia Optima
Begin of File Begin of File
READ
READ
READ < Start Point
READ READ
READ READ
READ READ
READ READ
READ < End Point
READ
READ
READ
End of File End of File
Normalmente los programas procesan registros agrupando aquellos que tengan ciertas
características comunes, por ejemplo, todas las facturas de un determinado cliente, o las
ventas de una clase de artículos.
Estas características comunes, se establecen a través de condiciones que determinan un
filtro sobre los registros. Tales condiciones se especifican en GeneXus de diversas
formas; asi pueden ser por ejemplo WHEREs en un FOR EACH, condiciones en una
fórmula Aggregate/Select, parametros , etc.
Ejemplo: De todos los clientes, quiero imprimir los datos de aquellos cuyo código este
en un rango determinado.
El tiempo necesario para realizar el proceso con los registros que cumplen las
condiciones, determina el grado de "optimización" que tiene la estrategia de acceso
elegida. Decimos que una estrategia de acceso esta más "optimizada" que otra, cuando
es necesario un menor tiempo para leer todos los registros que cumplen las condiciones
establecidas.
La optimización consiste en posicionarse lo mas cerca posible del primer registro del
grupo que cumple las condiciones y desde alli leer secuencialmente hasta el último que
las cumpla. Lo que se establece en definitiva, es un intervalo que cubre todos los
registros que cumplen las condiciones.
En este intervalo no necesariamente todos los registros cumplen la condición.En estos
casos, la mejor estrategia consiste en tener el menor intervalo tal que cubra a todos los
registros que cumplirán la condición. Igualmente las lecturas se realizarán para todos
los registros de este intervalo, pero solamente se considerarán aquellos que cumplan
con las condiciones.
193
Definición de Filtros
Where:
La clausula "Where" permite filtrar registros en la navegación de un determinado
grupo
FOR EACH.
Por ejemplo: Para establecer los filtros descritos anteriormente, utilizaríamos la
siguiente especificación:
FOR EACH
W HERE CliCiu = 'Montevideo' .AND. CliCod >= 1 .AND. CliCod<= 100
...
ENDFOR
Conditions:
Las "Conditions" sirven para establecer un filtro en forma global, es decir que solamente
se podrá acceder a los registros que cumplan con esta condición. Cuando se establece
una condición sobre atributos, afecta a todos los grupos FOR EACH que contengan ese
atributo. Reports, Work-panel y Procedures poseen esta posibilidad. Se prevee la
implementación a nivel de Transacciones en próximas versiones.
2. Fijar la posición de comienzo (Start). Posicionarse lo más cerca posible del primer
registro que cumple las condiciones.
4. Fijar la posición de fin (End). Se dice de aquellas condiciones, tales que a partir del
primer registro que no las cumple, no existen más registros que sí la cumplan.
195
Orden de Recorrida
Importancia del Orden en que se leen los
registros.
Ejemplo: Condiciones de Filtro compatibles con el Orden
Cod Nombre
1 Smith
*2 Jones <----- Starting Point Read &IniCod = 2
*3 Ball Read &FinCod = 4
*4 King <----- Ending Point Read
5 Ander
El orden en que deban considerarse los registros, junto con las condiciones de
"filtro" determinarán la mejor estrategia de acceso.
El orden puede considerarse como una condición previa, para la definición de
la optimización de las condiciones de filtro. Es decir, que la estrategia de
acceso se define, tomando en cuenta como primera cosa el orden que se haya
definido.
196
Orden de Recorrida
Importancia del Orden en que se leen los registros.
Cod Nombre
*3 Ander <----- Starting Point Read &CodIni = 2
5 Ball Read &CodFin = 4
6 Churchill Read
1 King Read
*4 Smith Read
*2 William <----- Ending Point Read
197
Orden de Recorrida
Si no se define un Orden se elige el de la Primary Key
For each
Where Clinom >= &IniNom .and. Clinom <= &FinNom
Endfor
198
Esto ocurre cuando se tienen FOR EACHs anidados, cuyas tablas bases tienen alguna
relación; GeneXus la encuentra y determina en forma automática una condiciónde
filtro. Esta relación sólo puede establecerse entre atributos primarios (aquellos que
forman parte de la clave primaria de alguna tabla), ya que es el único caso en que un
atributo puede estar en más de una tabla. Esta condición (Tipos.TypCod =
Cliente.TypCod) establecida en el for each de clientes, sólo es optimizable si el orden
es TypCod. Pero decíamos que el no especificar ningún orden implica que el orden a
tomar es el de la clave primaria (CliCod), por lo que no sería posible entonces la
optimización.Pero en este caso, como única excepción, se elige el orden que permita
optimizar la condición de filtro.
199
Posición de Comienzo
Consideraciones para su definición.
Se consideran las condiciones compatibles con el orden y que
sean por:
Si el orden es ascendente
• Mayor (>)
• Mayor o Igual ( >=)
• Igual (=)
Si el orden es descendente
• Menor (<)
• Menor o Igual (<=)
• Igual(=)
• Las condiciones deben estar relacionadas por .And.
200
Posición de Comienzo
Ejemplos:
Orden: A B C
Condiciones : A>= 5 .and. C > 3
Posición de comienzo: A>=5
Orden: A B C
Condiciones : A > 5 .and. B < 2 .AND. C > 3
Posición de comienzo: A > 5
201
La Posición Final
Consideraciones para su definición
Si el orden es ascendente
• Menor (<)
• Menor o Igual (<=)
• Igual (=)
Si el orden es descendente
• Mayor (>)
• Mayor o Igual (>=)
• Igual (=)
202
Diagrama de Navegación
For each CliCod
Where CliCod >= &IniCli .AND. CliCod <= &EndCli
[ CliCod ] [CliNom ]
Endfor
203
Diagrama de Navegación
For each CliCod
[ CliCod ] [CliNom ]
Endfor
END FOR
204
También influyen en la performance:
• Calls
205
For each Cuenta
Where Cuenta > &cta
Call('Pvalida', ... )
Endfor
En el AS/400 las funciones resueltas con Calls en los programas generados son: Time() , Today()
(se ejecuta una vez por programa) , Cdow(), Cmonth(), Userid(), Usercls(), Wrkstn()
Los calls en XBASE no tienen en sí mismos un gran costo, pero pueden generar cierres y
reaperturas de tablas que sí importan. Se implementaron dos esquemas distintos de calls
(entendiendo por Call : el call propiamente dicho y las UDP y UDF ), los que dependen del tipo de
indice que se está utilizando.
Indices NTX/IDX/NDX - a) Cuando el Objeto llamado no utiliza ninguna tabla abierta por el
objeto llamador: En este caso el objeto llamador (X) no cierra ninguna de las tablas que utiliza
para realizar el llamado (call) , y el objeto llamado (Y) abre y cierra únicamente las tablas que
utiliza.
b) Cuando el Objeto llamado (Obj.Y), utiliza alguna tabla abierta por el objeto llamador.
En las llamadas (calls) a otros objetos, el programa llamado cierra las tablas que necesita, que
hayan sido abiertas por el programa llamador y las abre con los índices que deba utilizar. Antes de
retornar, el programa llamado cierra todas las tablas que usó. El programa llamador, después de
retornar del programa llamado, abre aquellas tablas que necesita y fueron cerradas por el
programa llamado.
Resumiendo: El llamado siempre cierra lo que usa y el llamador se tiene que preocupar de reabrir
lo que corresponda, el peor caso es cuando los dos usan las mismas tablas y el mejor es cuando
usan todas distintas.
206
Indices CDX: En este caso, en los objetos llamados, no se cierran las tablas
que habían sido abiertas en los objetos llamadores y solamente reabren los
índices de la forma que los necesita.
Pgma X Pgma Y
Open A, B, C Open D, E
……. Reposiciona Indices B,C
Call Y ....
Restaura todo a como Close D, E
estaba antes del call
...
Close A, B, C
Indices Temporales:
207
MULTIPLES FORMS
208
Múltiples Forms por Objeto
20945
41
42
Form Classes
•New Class:
Classes definidas por el usuario que pueden ser tanto Graphic como
Text.
210
Múltiples Forms por Objeto
• Form Classes
– Graphic y Text (son del sistema)
– Definidas por el usuario (modo texto o gráfico)
• Cada objeto tiene forms que pertenecen a
alguna de las form classes y cada Modelo tiene
asociado una lista de Form Classes para cada
generador del mismo.
– Opción: File/ Edit Model/ Model Forms
•El default de un form puede ser en base a otro form o en base al default de
Genexus.
211
¿Cuándo decide GX
el form a utilizar ?
• En tiempo de Especificación
212
STYLES
213
Propiedades de los Styles
• Permiten la definición de standards.
Los Styles son otro objeto GeneXus, su forma de definir es similar a la de los
otros objetos, pero con la particularidad de que NO son tenidos en cuenta en la
normalización o generación de programas.
Sólo se utilizan para definir standards, sin la necesidad de tener que diseñar
Form por Form.
Pueden ser modificados, y automáticamente se reactualizan los forms
necesarios.
Hay Styles para transacciones, work panels, etc. , pero un style es de un solo
tipo. Las excepciones a esta regla son los Styles de Work Panels que sirven
también para Prompts y los Styles de Report y Procedure que pueden usarse
para cualquiera de los dos.
214
Definición de un Style
• Object/New Object.
• Ejemplo de un Style de transacción.
215
Style
Style Area
Data Area
Se ven en los forms unas líneas que definen diferentes áreas. Lo que está dentro
del rectángulo es la denominada "Data Area" (área de datos). El resto del form es
la "Style Area". A su vez, la Style Area está dividida en 8 sectores (ver figura).
Cuando el desarrollador empiece a usar styles las lineas de la data area
aparecerán solas. De todas maneras también se pueden hacer aparecer con un
botón de la toolbar.
216
Tres Tipos de Controles
• Controles que vienen de la default Data Area
•Los controles en la Data Area del style se pasan al objeto sólo en caso de
inicialización (cuando el objeto es creado basado en el style y no en futuras
reaplicaciones) y una vez en el objeto es considerado como un control de
usuario dentro de éste.
217
Creación de un objeto basado en un Style
• Al momento de crear el objeto, en el
Information/Style se elige el Style deseado.
El estado de dinamismo se puede ver por el color con el que están dibujadas
las líneas. Si son rojas, está dinámico. Si no está dinámico, son azules.
218
Creación de un objeto basado en un
Style
Las líneas de la data area estan en azul indicando que se perdió el dinamismo
con la default data area.
Las lineas de la style area estan en rojo indicando que existe dinamismo entre
la style area de la transacción de clientes y la style area del style.
NOTA: Se puede perder el dinamismo con la style area del Style y seguir
teniendo dinamismo con las properties del Style (siendo esto último “por
property”; es decir, teniendo dinamismo con algunas properties y no con
todas).
219
Cómo asociar Styles
a objetos existentes
• Opciones
– Object/Information/Style
– Reapply Form Style
Antes de aplicar el Style, hay que tener en cuenta que aquellos controles que no
provenían del Style asociado anteriormente (controles del usuario), permanecerán
en el form del objeto, con lo que pueden ocurrir superposiciones.
220
Qué pasa con el dinamismo ?
• Cuando se pierde ?
– Cuando se modifican
• los controles que vienen de la DDA
• los controles que vienen de la “style area” del Style
• el seteo de una property
• Opciones:
– Edit \ Default Data Area
– Edit \ Reapply Style Form
Una vez que se pierde el dinamismo con la Data Area o con el Style, se puede
recuperar utilizando las opciones de menu Edit – Default Data Area y Edit –
Reapply Form Style, respectivamente.
221
Cambio en el tamaño
de la Data area
El form del Style tiene la capacidad de adaptarse al tamaño de la Data Area del
objeto en el que se lo utiliza. Cuando la Data Area se agranda (ya sea debido al
calculo de Default Data Area o a la accion del usuario) el mecanismo de
aplicacion dinamica del Style se encarga de agrandar tambien el frame, y
mover hacia la derecha y hacia abajo los controles que estan a la derecha y
abajo de la Data Area respectivamente. Similar comportamiento se observa al
achicar la Data Area (se achica el frame y los controles se mueven hacia la
izquierda y hacia arriba).
El tamaño de la data area definido en el form del style (y por lo tanto también
el tamaño del frame) se considera como tamaño mínimo de la data area del
form del objeto.
222
Consideraciones para
el diseño de Styles
• Los controles que queden dentro de la Data Area del Style
son considerados como “Controles del usuario”.
• Definir forms para diferentes form classes si los objetos
que lo usan tienen múltiples forms. (Ej.: definir un form
gráfico y uno de texto en el style).
• Cuando se ponen Eventos y Rules incluir comentarios al
principio sobre que cambios se deben realizar en el
objeto.
223
Master Style
• Objetivo: Style default
•Master Style
Existe la posibilidad de declarar, para cada tipo de objeto, cuál de los styles existentes
en el modelo se desea que sea considerado como Master Style (es decir, cuál se desea
utilizar en lugar del “default style”). No es que se tenga que “crear un Master Style”
sino que entre aquellos que ya existen, se puede elegir uno y declararlo como Master.
Esta declaración es de caracter opcional: es posible no declarar a ninguno como Master
y simplemente funcionará todo como hasta ahora (utilizando el “default style”).
•En File/Edit Model/Master Styles se designa el Master Style para cada tipo de objeto.
En cada caso están disponibles los styles existentes y la opción “(None)”.
Si bien al momento de crear un objeto style, se puede elegir tanto crear un Report Style
como un Procedure Style, el tipo del style que en definitiva se crea es siempre
Procedure Style. Los Procedure Style pueden ser usados como style tanto para Reports
como para Procedures. De la misma manera pueden ser elegidos tanto como para
Master Style de Reports como para Master Style de Procedures. Por otro lado, los
Work Panel Style pueden ser usados como style tanto para Work Panels como para
Prompts.
224
Master Style
• Precedencia:
– Style asociado
– Master Style
– Default
225
MENU BAR Y TOOL
BAR
226
Tipo de objeto Menu Bar
Cada objeto GeneXus que tenga Form puede tener su propio Menu Bar y Tool Bar.
Para definirlos, se usa el tipo de objeto GeneXus Menu Bar.
Para agregar o borrar opciones (items) del Menu Bar, se utilizan las opciones
Edit/Insert y Edit/Delete respectivamente.
La definición de la Tool Bar es exactamente igual a la del Menu Bar, sólo que en los
items de la Tool Bar se debe definir también el bitmap correspondiente.
227
Tipo de objeto Menu Bar
Definición de Eventos
Los eventos definidos en el Menu Bar son generales, por lo cual se ejecutarán
en todos los objetos que utilicen el Menu Bar. Por esta razón es que no se
permite el uso de atributos en los mismos.
228
PROPIEDADES, EVENTOS
Y METODOS ASOCIADOS A LOS
CONTROLES
229
PROPIEDADES DE LOS CONTROLES
• Cada control en un Form tiene un ‘nombre’ y
‘propiedades’ asociadas.
• Insert/Property: despliega la lista de
propiedades válidas para cada control.
• Según el tipo de control, las properties que tiene
asociadas.
• Sólo en generadores gráficos:
– VB, VFP, JAVA
•Algunos controles tienen un nombre por defecto, pero hay otros que no; por
lo cual si se les quiere aplicar alguna property hay que asociarles un nombre ya
que de lo contrario no aparecen en la columna “Control” al hacer
Insert/Property.
•En el caso del Form el nombre del control (por defecto) es Form.
Si se desea cambiar el título de un Form, la forma es:
230
Propiedades de los Controles
• El ‘nombre del control’ para atributos/variables
es el nombre del atributo/variable.
• NOTA: Si una variable es un vector, debe
indicarse un nombre a cada posición del vector
para diferenciarlas.
231
Diálogo:
Select Property
• Se accede a través de la opción Insert/Property
cuando se editan:
– Rules, Eventos, Subrutinas, etc en transacciones,
work panels y web panels
232
Diálogo:
Select Property
•Form:
Permite seleccionar para que tipo de form (Graphic, Text o de Usuario)
se le asignará una propiedad a un control.
•Control:
Muestra la lista de controles que hay en el form que se está diseñando y
que tienen un nombre asociado.
•Property:
Despliega la lista de propiedades que se pueden aplicar al control
seleccionado y en la segunda columna se despliegan los tipos de cada
property.
233
EVENTOS EN CONTROLES
• Insert/Events
•DblClick:
El código asociado a dicho evento se ejecuta al hacer “doble
click” sobre el campo.
•Click:
El código asociado a dicho evento se ejecuta al hacer “click”
sobre el campo.
•Right Button:
Se dispara cuando se presiona el botón derecho del mouse.
•IsValid:
Se dispara cuando se hace la validación del control.
234
Evento OnLineActivate
• Evento asociado al control “subfile”
• Se dispara cuando se activa una línea en el subfile:
– al clickear una línea con el mouse
– moverse a través de la grilla con el teclado
– cuando se hace refresh de la grilla.
• Los valores son los de la línea “nueva”
• Los for each incluidos en este evento se anidan a
la tabla base del workpanel.
• Disponible en transacciones y work panels.
OnLineActivate
Es un evento asociado al tipo de control subfile.
Los For Eachs que se incluyan en dicho evento estarán anidados a la tabla base
del work panel, es decir, se comportan igual a los For Eachs del evento Enter.
235
Eventos en Controles
•Form:
Permite seleccionar para que tipo de form se le asociará una evento a
un control.
• Control:
Muestra la lista de controles que hay en el form que se está diseñando.
•Event:
Despliega la lista de eventos que se pueden aplicar al control
seleccionado.
236
METODOS
• Se aplican a los controles.
• Sintáxis:
Nombre del Control.Method([<Parms>])
• Según el tipo de control (edit, check box, etc) son los métodos que
se pueden asociar.
• Se accede a través de la opción Insert/Methods cuando se editan:
Rules, Eventos, Subrutinas en transacciones, work panels y web
panels.
• Sólo en generadores gráfico:VB, VFP, JAVA
– A excepción del método SetFocus que será implementado en
todos los generadores.
237
OBJETOS MAIN
238
Objetos Main
• GeneXus genera ejecutables por cada objeto
Main.
239
Llamadas a objetos Main
240
¿Qué ocurre si un objeto que no es
Main pasa a serlo?
• Ejemplo:
– Trn A Wpanel B
Call(PImpClis) Call(PImpClis)
– PImpClis no es main: GeneXus generó entonces en los programas
asociados a la Trn A y Wpanel B un call al programa PImpClis
• El Proc ImpClis pasa a ser Main:
– En los programas asociados a la Trn A y Wpanel B GeneXus
debería cambiar el call al programa PImpClis por un call a un
ejecutable “ImpClis”, con lo que deberíamos regenerar estos
objetos.
• Para evitar la regeneración de todos los objetos llamadores:
GeneXus usa un concepto llamado STUBS
241
STUBS
• Cuando el objeto ImpClis pasa a ser Main, GeneXus en lugar de
generar un único programa asociado al objeto, realiza lo
siguiente:
– Genera el programa “PimpClis” que sólo contiene el Call al Ejecutable
correspondiente
– Genera otro programa que es el que contiene la lógica del objeto
ImpClis y será el principal del ejecutable.
• Esto permite no tener que regenerar todos los objetos que llaman
al objeto ImpClis.
• Al programa que contiene sólo el llamado al ejecutable se le
denomina STUB.
242
STUBS
• Tenemos entonces 2 programas generados, asociados a un mismo objeto GX.
• Para la denominación del programa STUB se siguen las convenciones de siempre
(P=Procs, W=Work Panels etc.)
• Para la denominación del programa que será el principal del ejecutable (el que contiene
realmente el código) se usan las siguientes convenciones:
» Transacción N
» Work Panel U
» Report O
» Procedure A
» Menu L
» Web Panel H
243
DATA VIEWS
244
DataViews - Archivos Externos
Los Data Views de GeneXus permiten manejar Archivos
Externos como si fueran Archivos pertenecientes a la Base
de Conocimiento.
Propiedades
• Definición Global
• Uniformización de la nomenclatura
245
DataViews - Archivos Externos
Para trabajar con Archivos Externos en GeneXus
tenemos dos posibilidades:
DATA VIEWS
» Sin tabla Asociada
» Con tabla Asociada
246
Data Views
GENEXUS DATA VIEW EXTERNAL
DA DEFINITION ENVIRONMENT
TABASE
Los Data Views de GeneXus permiten manejar Archivos Externos como si fueran
archivos pertenecientes a la Base de Conocimiento.
En el Data View se puede indicar que se manejará una transacción interna asociada, o
no.
- Codigo*
- Nombre
- Dir
- Tel
1) Se debe crear una transacción de clientes definiendo los atributos que se deseen
manejar de la tabla externa. Estos atributos internos deben coincidir en lo que se
refiere a tipos y tamaños con los campos externos, pero los nombres pueden ser
redefinidos respetando la nomenclatura GIK.
247
2) Se debe crear un Data View e indicar en él, cual es la transacción interna
asociada. Asimismo se deben indicar las correspondencias entre los atributos
internos y los campos externos.
248
Definición de un Data View
Assoc. table: En este punto se debe seleccionar la tabla interna asociada al Data
View.
Composition: Aquí se deben indicar las correspondencias entre los atributos internos
y los campos externos.
Indices: En esta lista, se deben definir los índices internos que GeneXus usará en la
aplicación.
249
Composition
• Ejemplo:
Dados los siguientes Archivos Externos:
CLIENTES PRODUCTO
Codigo* Codigo*
CliNom ProDsc
CliDir ProPre
Composition Composition
CliCod 'Codigo' ProCod 'Codigo'
CliNom ProDsc
CliDir ProPre
Se uniformiza la nomenclatura
250
Indices
Nota: Este es un nombre interno del índice, es decir, no tiene por qué ser el nombre
del índice físico. Genexus hace un mapeo entre el nombre interno del índice y el
nombre externo de acuerdo a la composición del mismo.
251
Platform Specific Information /
Add
Las propiedades del Data View pueden definirse para cada plataforma o por
modelo.
Esto nos brinda la posibilidad de especificar diferentes ubicaciones del mismo Data
View dentro de la misma plataforma pero para diferentes modelos.
Por ejemplo, si se quiere darle diferente ubicación para el modelo de Prototipo Fox y
para el modelo de Producción Fox, debe seleccionarse DBFCDX(model2) y
DBFCDX(model 3) indicando la ubicación para cada uno de los modelos. En cambio,
si se quiere la misma ubicación para todos los modelos Fox debe seleccionarse la
plataforma DBFCDX.
252
Platform Specific Information /
Edit
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
-----
EXTERNAL
INTERNAL
TABLE ----- FILE
-----
-----
-----
INTERNAL
----- EXTERNAL
INDEX ------ --- INDEX
----
Se trata al archivo externo como una tabla más del modelo. Se pueden utilizar los
mismos comandos utilizados para acceder a las Tablas Internas (For Each, etc.) Se
deben mencionar los atributos internos y Genexus al generar los programas, utilizará
los campos externos de forma transparente.
254
Associated Table
Tabla Interna = Tabla Externa
-------
INTERNAL
TABLE
--- EXTERNAL
FILE
-------
Existe una relación de uno a uno entre los atributos de la Tabla Interna del Data View
y los del Archivo Externo.
255
Associated Table
Tabla Interna < Tabla Externa
Not Accessed
---
INTERNAL EXTERNAL
TABLE ----- 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
----
NOT ALLOWED
INTERNAL
EXTERNAL
FILE
----- FILE
----
257
Associated Table
Tabla Interna > Tabla Externa
USO DE SUBTIPOS
CliCod*
CliNom
---- Codigo
Nombre
ALLOWED
INTERNAL
TABLE A
--- EXTERNAL
FILE
----
Subtype
CliCodSub*
CliNom
CliDir
CliEMail
INTERNAL
TABLE B
En el ejemplo, se pide tener también como datos del Cliente el E-Mail y la dirección.
258
Asociación Dinámica
En este caso coincide todo. Si ocurre esto no hay que detallar composición ni de
índices del Data View. Lo único que hay que hacer es asociar el Data View a la tabla
externa (Platform Specific Information).
Tener en cuenta que el índice y archivo externo deben estar ubicados en el mismo
directorio.
259
Arbol de Definición
Archivos
Externos
Data View
Definición Global
CON SIN
Tablas Asociadas Tablas Asociadas
Asociación Asociación
Dinámica Definida
260
REORGANIZACIONES -
DATA VIEWS
1. EXISTE TABLA ASOCIADA
261
WEB PANEL
• Permite construir páginas WEB dinámicas que
interactúan con la base de datos.
• C/SQL
– Con todos los DBMS, excepto AS/400
• Visual Basic
– Access
• RPG/400
– AS/400
• Java
•Los web panels pueden generarse tanto con Visual Basic como con C/SQL.
Por lo tanto, pueden ejecutarse en un servidor Windows NT (VB, C/SQL) o en
servidores UNIX (usando C/SQL).
•En caso de generar con RPG, el servidor de Internet debe ser al AS/400
262
GeneXus Intermedio.
Optimizando Aplicaciones.
1
PUNTOS IMPORTANTES EN LA
DEFINICION
DE TRANSACCIONES
Definición de Modos
Modo Inicial
2
Micro/LAN:
AS/400
• El modo para el PRIMER NIVEL se define con:
– DEFAULT_MODE para el nivel
» SIN SUBFILE
- No se acepta la Primary Key: update
- La Primary Key es aceptada: insert
3
Loop Once
Delete Cascade
4
EJEMPLO: Delete Cascade
Orden de Compra
OrdNro*
OrdFch
PrvCod
PrvNom Tabla Orden
AnaNro
AnaNom
(PrdCod*
PrdDsc
OrdCnt
OrdPrc
PrdPrc)
OrdImpTot
Entregas
OrdNro* Tabla Entregas
PrdCod*
(EntFch* Tabla Entrega1
EntImporte)
- Transacción Orden
Se desea eliminar una Orden
- Transacción Orden
Se desea eliminar una Linea de la Orden
- Transacción Entregas
Se desea eliminar una Linea de la Orden
Uso de &Mode
'INS' - Insert
'UPD' - Update
'DLT' - Delete
5
EJEMPLO: Transacción de pedidos
PedNro*
PedFch
PrvCod
PrvNom
PedImpTot
(PrdCod*
PrdDsc
PedCnt
PrdPrc)
2 = Modificar 4 = Eliminar
F6 = Ingresar Pedidos
6
Eventos:
Event Enter
For each line
if &Op = '2' // Modificar
call(TPedido,PedNro, 'UPD')
endif
if &Op = '4’ // Eliminar
call(TPedido,PedNro, ‘DLT’)
endif
endfor
refresh
EndEvent
PUNTOS IMPORTANTES EN LA
DEFINICION
DE TRANSACCIONES
Definición de Prompts y Refcalls
7
PROMPTS
• Prompt
– La facilidad de prompt despliega todos los valores posibles que pueden ser
asignados a foreign keys, permitiendo al usuario seleccionar el valor deseado.
• Autoprompt
– Existe una autoprompt para cada nivel de una transacción que permite
visualizar y elegir un registro de la tabla base del nivel de una Transacción.
– Prompt : PC > F4
AS/400 > F4
Rule Refcall
Refcall('Pgm_Nombre', <Par1>,....<ParN>);
8
Rule Prompt
Prompt('Pgm_Nombre', <Par1>,....<ParN>);
•Esta rule se utiliza para llamar un programa que permita al usuario seleccionar
valores posibles de una lista.
•Los parámetros <Par1> .. <ParN> pueden ser tanto atributos como variables.
Si son atributos no tienen porqué formar una FK.
Foreign Key
Sustituye al Prompt que genera GeneXus por defecto.
Atributos Secundarios
Si es uno solo, habilita el F4 sobre el mismo.
Si son más de uno, habilita el F4 sobre el primero en la estructura de la
transacción.
Variables
Si es una sola, habilita el F4 sobre la misma.
Sin son más de una, habilita el F4 sobre la primera en ser aceptada (en las
rules).
9
Ejemplo
TRANSACCIONES:
TABLAS:
SubCateg
*CatCod
*SubCatCod
SubCatNom
Movimien
*MovNro
CatCod
SubCatCod
10
EJEMPLO: Se elimina la Transacción Categoría
Tablas:
SubCateg *CatCod
*SubCatCod
SubCatNom
Movimien
*MovNro
CatCod
CatNom
SubCatCod
PUNTOS IMPORTANTES EN LA
DEFINICION
DE TRANSACCIONES
Disparo de Rules
11
EJEMPLO: Transacción Factura
FacId*
FacFch
CliCod
CliNom
CliSdo Reglas:
CliDir default(FacFch ,today() ) ;
(PrdCod* error('No hay Stock suficiente') IF PrdStk< 0;
PrdDsc subtract(FacLinCnt,PrdStk);
FacLinCnt
FacLinPrc
PrdPrc Fórmulas:
PrdStk
PrdStkMin FacLinImp=FacLinCnt*FacLinPrc
FacSubTot = SUM (FacLinImp)
FacLinImp)
FacSubTot FacIva = FacSubTot * 0.22
FacIva FacTotCal = FacSubTot + FacIva
FacTotCal
DISPARO DE RULES
GeneXus
GeneXusse
seencarga
encargade
dedeterminar
determinarelelorden
ordende
deDisparo
Disparodedelas
lasreglas
reglassegún
segúnlas
las
dependencias
dependenciasde
delos
losatributos
atributosindicados
indicados
–– ORDEN
ORDENDE
DEDECLARACION:
DECLARACION:
error('No
error('Nohay
hayStock
Stocksuficiente')
suficiente')IF
IFPrdStk
PrdStk<<0;
0;
subtract(FacLinCnt,PrdStk);
subtract(FacLinCnt,PrdStk);
–– ORDEN
ORDENDE
DEEVALUACION:
EVALUACION:
subtract(FacLinCnt,PrdStk);
subtract(FacLinCnt,PrdStk);
error('No
error('Nohay
hayStock
Stocksuficiente')
suficiente')IF
IFPrdStk
PrdStk<<0;
0;
12
Orden de Disparo
TOT
FECHA
IVA FECHA
SISTEMA
.
0.22
ERROR
STOT
SUM
STOCK
IMP
subtract
PRECIO CANT
13
Level(Atributo)
Transacción Factura
FacId*
CliCod
...
( PrdCod*
FacLinCnt
PrdPrc
FacLinImp)
...
FacTotCal
Regla:
Error('No puede modificar la linea') IF Modified() .and.
Level(PrdCod);
CliCod*
CliNom
CliSdo
CliDir
CliSts
Llama a un procedimiento que realiza la impresión de los datos del cliente
y setea el atributo Status.
LLAMADAS INCORRECTAS
call('pficha', CliCod) if Insert .and. After(Confirm);
call('pficha', CliCod) if Update .and. After(Confirm);
LLAMADAS CORRECTAS
Si cada uno constituye una UTL:
call('pficha', CliCod) if After(Trn) .and. (Insert .or. Update) ;
Si ambos programas se consideran una única UTL:
call('pficha', CliCod) if After(Insert) .or. After(Update);
14
After(Level(Atributo))
EJEMPLO:
Factura__Proveedor
Factura
PrvCod*
FacId*
...
FacTotIng
( PrdCod*
FacLinCnt
PrdPrc
FacLinImp)
...
FacTotCal=SUM(FacLinImp)
– Rule:
Error('El total ingresado no coincide con el total
calculado') IF FacTotIng<> FacTotCal;
After(Level(Atributo))
Según el árbol de evaluación cada vez que el importe cambie,
cambiará el total calculado.
TOT CALC
IVA
0.22
STOT
SUM
IMP
PRECIO CANT
15
After(Level(Atributo))
After(Confirm)
EJEMPLO: Numeración Automática
Caso1
FacNro = udp(’PNumera’, ‘FAC’) IF insert ;
Caso2
FacNro = udp(’PNumera’, ‘FAC’) IF after(insert );
Lo correcto es :
FacNro = udp(’PNumera’, ‘FAC’) IF insert .and.
after(Confirm);
16
After(Trn)
EJEMPLO 1:
Queremos llamar a Líneas de Factura después de
ingresar el Cabezal de la Factura.
CabezalFactura LineasFactura
FacId* FacId*
FacDatos (PrdCod*
CliCod FacLinCnt
FacLinImp)
FacTot
Si se considera el cabezal como una UTL y las líneas como otra UTL.
Call ('TLinfac', FacId) IF after(Trn);
After(Trn)
– EJEMPLO 2:
Factura Cliente
FacId* CliCod*
FacFch CliNom
CliCod CliSdo
CliNom CliDir
CliSdo
CliDir
(PrdCod*
PrdDsc
FacLinCnt
FacLinPrc
PrdPrc
PrdStk
PrdStkMin
FacLinImp)
FacSubTot = SUM(FacLinImp)
FacIva = FacSubTot * 0.22
FacTot= FacSubTot + FacIva
17
Rules de la trn Facturas:
add(FacTotal, CliSdo);
call('pgmname', CliCod)
IF After(Level(PrdCod)); INCORRECTA
call('pgmname', CliCod)
IF After(trn); CORRECTA
• EJEMPLO 1:
• EJEMPLO 2:
| call('pgmname',&var1,&var2,&flag) if After(Confirm);
|
| error('xx') if After(Confirm) .and. &flag = 'N';
v
18
Eventos en una Transacción de dos niveles
FacId*
FacFch ---------> AFTER (FacFch)
CliCod
CliNom
CliSdo
CliDir ------> | AFTER (CliDir)
(PrdCod* | AFTER(CONFIRM).AND.LEVEL(FacId)
PrdDsc | AFTER (INSERT|UPDATE|DELETE)
FacLinCnt
FacLinPrc
PrdPrc
PrdStk
PrdStkMinimo
FacLinImp) --> | AFTER (LEVEL(PrdCod))
FacSubTotal | AFTER (TRN)
FacIva
FacTotal
USO Y RECOMENDACIONES
EN EL USO DE SUBTIPOS
19
USO DE SUBTIPOS
• Consideraciones generales.
20
A. Atributos conceptualmente iguales
que cumplen roles diferentes.
RESERVAS CIUDADES
ResNro* CiuCod*
CiuCod (orig) CiuNom
CiuCod (dest)
RESERVAS CIUDADES
ResNro* CiuCod*
CiuCodOri CiuNom
CiuCodDes
RESERVAS CIUDADES
21
A. Atributos conceptualmente iguales
que cumplen roles diferentes.
• Utilización de atributos secundarios del supertipo
definiendo atributos subtipos dentro de un grupo
Definición de Subtipos
22
B. Especialización de atributos
• Se definen PrvNro y CliNro como subtipos
EMPRESAS PROVEED CLIENTES
EmpNro* PrvNro* CliNro*
EmpNom PrvSal CliSal
EmpRuc
EmpTel
EmpDir Proved.
Empresas Clientes
B. Especialización de atributos
23
C. Evitar controles de integridad
referencial
Historico de Compras Productos
PrvCod* PrdCod*
PrvNom PrdTxt
PrdCod*
PrdTxt
HisCnt
24
C. Evitar controles de integridad
referencial
PrvCod*
PrvNom
PrdHisCod* (Subtipo de PrdCod)
PrdHisTxt (Subtipo de PrdTxt)
HisCnt
OrdCmpNro*
PrvCod
PrdCod
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
TABLA EXTENDIDA-
HERENCIA
• Subtipos múltiples
SECCIONES
DptoCod* tabla Depart
DptoNom
(SeccCod* tabla Seccion
SeccNom)
EXPEDIENTE
ExpNro* tabla Exped
DptoCodIni ST de DptoCod
SeccCodIni ST de SeccCod
DptoCodAct ST de DptoCod
SeccCodAct ST de SeccCod
26
TABLA EXTENDIDA-
HERENCIA
DptoCod*
SeccCod*
SeccNom
ExpNro*
DptoCodIni
SeccCodIni
DptoCodAct
SeccCodAct
27
TABLA EXTENDIDA- HERENCIA
TABLA EXTENDIDA-
HERENCIA
DptoCod*
SeccCod*
SeccNom
ExpNro*
DptoCodIni
SeccCodIni
DptoCodAct
SeccCodAct
28
Consideraciones
•El subtipo y supertipo serán definidos del mismo tipo,
GeneXus lo determina así y cuando se quiere definir un
subtipo este "hereda" la definición del supertipo.
Consideraciones
• No se pueden actualizar los subtipos inferidos (Add,
Subtract) -
29
FORMULAS
AGGREGATE SELECT
Consideraciones
30
FUNCION FIND
Sintáxis:
FIND RECURSIVO
Se llaman finds recursivos a aquellos que para resolverse
recorren la misma tabla sobre la que esta definida la
fórmula.
EJEMPLO:
MovNro*
MovFch
BcoId
MovNroChe
MovImpChe
FndNroChe
MovNroAux
BcoIdAux
MovNroCheAux
MovFndOtroChe = Find(MovNro, BcoId= BcoIdAux .and.
MovNroChe = MovNroCheAux
.and. MovNro<>MovNroAux, 0)
31
FIND RECURSIVO
Se llaman finds recursivos a aquellos que para resolverse
recorren la misma tabla sobre la que esta definida la
formula.
PUNTOS A PRODUNDIZAR EN
EL MANEJO DE WORK PANELS
32
DETERMINACION DE LA TABLA BASE
DE UN WORK PANEL
• PANEL A PARTIR
• EVENTOS DE LOS
• REGLAS ATRIBUTOS
PANEL
– TODO ATRIBUTO QUE INTERVENGA EN EL PANEL
EVENTOS
– TODO ATRIBUTO QUE ESTE FUERA DE UN GRUPO FOR
EACH
REGLAS
– TODO ATRIBUTO QUE ESTE EN UNA REGLA
» HIDDEN( )
» ORDER( )
Ejemplo:
Trn Productos
ProdId* Tabla: PRODUCTO
ProdDsc
Trn Facturas
FacNro* Tabla: FACTURA
FacFech
(FacLinNro* Tabla: FACTURA1
ProdId
ProdDsc
FacLinCnt)
33
Work Panel de Selección de Productos
Rules
parm(&V15 ) ;
order(ProdId ) ; Event Enter
Conditions &V15 = ProdId
ProdId >= &C15 ; Return
ProdDsc .LIKE. &C16 ; EndEvent
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
34
WORK PANELS SIN TABLA BASE
Ejemplo: Mostrar para cada cliente el total facturado, pero sólo de los
clientes que tienen facturas.
Event Load
for each CliId
defined by FacFch
&cli =CliNom
&tot =0
for each
&tot =&tot
+FacTotal
endfor
load
endfor
EndEvent
BREAK FACTURA
Order : CliId
Navigation filters:
Loop while:
CliId = CliId
---->> FACTURA ( FacId )
END FOR
END FOR
END EVENT
35
WORK PANELS SIN TABLA BASE
Consideraciones
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
PUNTOS A PROFUNDIZAR EN
REPORTES Y PROCEDIMIENTOS
37
Fórmulas en Procedimientos
• Fórmulas no redundantes
– Se calculan en todos los objetos que se utilizan. En un
procedimiento, se calculan con el valor que tiene el registro el el
momento de leerlo, no luego que se actualiza
• Fórmulas redundantes
– No se actualizan. Hay que calcularlas y actualizarlas en forma
manual.
38
New en la misma tabla de For Each
Tabla de Medicos Tabla de Consulta
MedCod* TurFch*
MedNom TurCod*
EspCod MedCod*
EspDsc ConNro
END NEW
END FOR
39
New en la misma tabla de For Each
SOLUCION:
40
New en la misma tabla de For Each
NEW CONSUL
Key : TurFch, TurCod, Medcod
41
Restricciones en la Actualización
• No se puede realizar ninguna actualización en
un For Each que recorre una tabla por índice
temporal
– En ese caso se debe construir el índice de usuario o elegir
otro orden por un índice existente
• No se puede actualizar ningún atributo del
índice que se esta utilizando en el For Each
• (XBase) Se pierde el puntero al actualizar
atributos de un índice que se esta utilizando en
el programa llamador.
For Each A B C For Each
defined by C defined by C
call(‘rprog2,A,& nuevo) 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
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)
44
Reorganización en AS/400
Reorganización en PC/CS
• MENU y RMENU
45
Recomendaciones finales
INTEGRIDAD TRANSACCIONAL
Y
CONTROL DE CONCURRENCIA
46
Conceptos Teóricos
• Control de Concurrencia
• Tipos de Diálogo
– Conversacional
– Pseudo Conversacional
• Integridad Transaccional
• Unidad de Trabajo Lógico (UTL)
Conceptos Teóricos
• Control de Concurrencia:
– controles para evitar inconsistencias en
los datos cuando se trabaja en ambiente
multiusuario
47
Conceptos Teóricos
• Diálogo Conversacional
– Esquema:
1. aceptar datos
2. validar usando locks
3. pedir confirmación
4. actualizar la base de datos
5. liberar locks
Conceptos Teóricos
• Diálogo Pseudo Conversacional
1. aceptar datos
2. validar
3. pedir confirmación
4. lockear los datos y validar que no hayan sido
modificados
5. si los datos no cambiaron actualizar la BD y
liberar los locks
6. sino informar al usuario que los datos fueron
cambiados.
48
Conceptos Teóricos
• Integridad Transaccional
Conceptos Teóricos
49
Enfoque GeneXus
• Control de Concurrencia
– Locks
– Ambiente Client/Server
– Ambiente Centralizado
• UTL
• Integridad Transaccional
Control de Concurrencia
50
Control de Concurrencia
Concurrencia en Client/Server
– Lock Mode
– Isolation Level
51
Concurrencia en Client/Server
• Valores:
– Use Conversational Dialog
– Check Updated Tables only (*)
– Check all accessed tables
Co n v e r s a c i o n a l
Tipos de Diálogo
Obtener
Datos
Grabar BD
Lockear
Eventos After
Ins/Upd/Del
Validar
datos
Commit
Pedir
Confirmación
Deslockear
Confirma?
Evento
After(TRN)
Evento
After(confirm)
52
Tipos de Diálogo
Obtener
Datos Validar
cambios
Validar
datos No hubo
cambios?
Pedir
Confirmación
• Grabar BD
Confirma?
Eventos After
Ins/Upd/Del
Evento
After(confirm)
Commit Deslockear
Pseudo
Lockear
Evento
After(TRN)
Concurrencia en Client/Server
• Valores:
– Do not specify lock level (*)
Conversacional
53
Concurrencia en Client/Server
– Read Uncommited
Concurrencia en Client/Server
54
Concurrencia en Client/Server
• ¿Qué sucede cuando un programa que actualiza
la BD encuentra un registro lockeado?
Transacciones
Cuando expira el time-out despliega un mensaje
indicando que el registro esta siendo usado por
otro usuario. El usuario puede reintentar la
operación.
En SQL Server no se despliega mensaje y queda
esperando indefinidamente hasta que se libera el
registro.
Concurrencia en Client/Server
Procedimientos
55
Concurrencia en Client/Server
- Time-out
Desde GeneXus no es posible configurarlo
Concurrencia en Access
56
UTL en GeneXus
• UTL en Transacciones
– Por defecto se define el alcance de la UTL
como toda la transacción
• UTL en Procedimientos
– Por defecto se define el alcance de la UTL
como toda el programa.
• Comandos
– Commit
– Rollback
Integridad Transaccional
57
Integridad Transaccional en
Client/Server
• Transactional Integrity
• Yes (*)
• No
• File Views
• siempre tienen IT o no depedendiendo del valor de
la preference
• Transactional Integrity = No
• DB2/400 e Informix desactivan la IT
• El resto de los DBMSs entran en modo autocommit
Integridad Transaccional en
Client/Server
• Base de datos centralizadas
• Todas las tablas en el servidor
• El DBMS asegura la IT
58
Integridad Transaccional en
Client/Server
• Base de datos Informix
– ANSI
• Siempre se trabaja con IT independientemente del valor de la
preference Transactional Integrity
– Buffered Logged
• Se trabaja con IT dependiendo del valor de la preference
Transactional Integrity, excepto en la reorganización donde no
tendrá IT
– Not Logged
• No se trabaja con IT independientemente del valor de la
preference Transactional Integrity
Integridad Transaccional
– Commitment
– Commit on Exit
– Confirm Transaction
59
Integridad Transaccional
Object Properties
• Commitment
– Valores:
• Enabled (*)
• Disabled
• Consideraciones
– Válida solo en AS/400
Integridad Transaccional
Object Properties
• Ejemplo property Commitment
Commitment=Disabled
Tabla
Facturas
60
Integridad Transaccional
Object Properties
• Commit on Exit
– Valores:
• Yes (*)
• No
• Consideraciones
– No es válida si tiene Commitment = Disabled
Integridad Transaccional
Object Properties
• Ejemplo property Commit on Exit
Commit on Exit = No
61
Integridad Transaccional
Object Properties
• Confirm Transaction
– Valores:
• Yes
• No (*)
• Consideraciones
– Es válida si tiene
Commitment = Enabled y
Commit on Exit = Yes
DEFINICION Y MANTENIMIENTO
DE REDUNDANCIAS
62
Definición de Redundancias
• Redundancia Referencial
– Para definición de índices de usuario
– Por límites en la definición de una fórmula Aggregate/Select
Mantenimiento de Redundancias
63
Redundancy load Utility
64
Mantenimiento a través de
Transacciones
• Toda transacción que defina una tabla cuyos atributos
secundarios estan definidos redundantes en otras tablas
llamará a un programa para actualizar las redundancias
Consideraciones
65
EFICIENCIA Y PERFORMANCE
DE LAS APLICACIONES
Tips de optimización
• New con When duplicate vs. For each con New.
New &Existe=‘N’
Cliente=X For each
Saldo =Y Where Cliente=X
When duplicate Saldo=Y
For each &Existe=‘S’
Saldo=Y Endfor
Endfor If &Existe=‘N’
Endnew New
Cliente=X
Saldo= Y
Endnew
Endif
66
Tips de optimización
Tips de optimización
67
ARQUITECTURA DE
MULTIPLES CAPAS
• Generador C/SQL
68
Generadores del Modelo
• Generador para la Reorg. (el que existía )
– Usado para creación y reorganización de la base
de datos.
– File/Edit Model/Generator
• Generador por Default para los objetos
– En un principio coincide con el de la Reorg.,
pudiéndose elegir otro.
– File/Edit Model/Tab de “Generators”
• Generadores secundarios
– File/Edit Model/Tab de “Generators”
• Se controlan combinaciones válidas
69
Cómo decide GX el generador
para cada objeto ?
• Objetos Main
– Por defecto se generan con el generador Default.
– Si se quiere generar con otro generador:
• Information/Tab de Options/Generator
• Objetos no Main
– Se utilizan los generadores de los objetos Main que
lo llamen (directa o indirectamente).
70
INTRODUCCION A
CLIENT/SERVER
Qué es C/S ?
71
Tipos de Client/ Server
72
Client / File Server
FILE / Servidor
SERVER
Clientes de Datos
Archivos
Red
Server
Red
73
Arquitectura Client / Database
Server
DB2/400 AS/400
74
Model Properties
• Tables in Server
• Local Tables
• Connect to Server
• Data Source Name
•Outer Join -> Es posible generar con Outer Join para: Oracle,
DB2/400, DB2 Common Servers e Informix.
75
INTRODUCCION A
PAGINAS WEBS
Web
• Páginas gráficas con hipertexto
• Dos tipos fundamentales:
– Páginas estáticas
HTML standard.
Generación con algunas herramientas.
– Páginas dinámicas
GeneXus
ASP
···
76
Web - Páginas Estáticas
• Información general
• Marketing
• Información similar a la que se distribuye en
folletos y documentos
• Acceso rápido y cómodo a información
• Direcciones de correo electrónico para
información y soporte
• Mantención de alto costo
• Sin valor agregado
77
Páginas Dinámicas - Ejemplos
• Home Banking
• Divulgación de información (con y sin
costo)
• Comunicación con proveedores
• Intranet (Información dentro de la empresa)
• Intercambio de datos y documentos
• VENTA DIRECTA
Páginas Páginas
Estáticas Dinámicas
78
URL
protocol://host/path/filename[?parm1,…,[parmn]]
protocol:
Especifica el protocolo de acceso.
Ejemplos: file, ftp, http, telnet
host:
Nombre del host al cual deseamos conectarnos.
Ejemplo: www.artech.com.uy
path/filename:
Ubicación y nombre del documento en el servidor
[parm1,...,[parmn]]
Información opcional para consultas
Protocolo HTTP
Conexión/Solicitud
Respuesta/Cierre
79
HTML
<HTML>
<HEAD>
<TITLE>Esta es mi primera página</TITLE>
</HEAD>
<BODY>
Esto muestra de una forma muy <I>simple</I>,
la estructura básica de un documento HTML.
</BODY>
</HTML>
80
Browser WWW
(cliente)
APLICACION
• So
CGI
m
et
‚
er GI
un llC
fo Ca
rm
l
de I
FORM ta G ƒ
u es a C
p m
e s ra
R rog
Respuesta del P
Programa CGI
Servidor
INTERNET
Servidor : WEB SERVER
Microsoft Internet Information Server
Netscape Server
Links
Páginas
HTML
Cliente : BROWSER
NetScape, MS Internet Explorer
81
Topología
Topología
Servidor Web
Windows NT
Web Browser UNIX
AS 400
Internet
Intranet
Servidor de
Base de Datos
DB2, Informix,
Microsoft SQL Server,
Web Browser Oracle, Access
Web Servers
• Windows NT • Windows 95
– Microsoft Internet – WebSite Professional
Information Server – Fnord
– Netscape – Personal Web Server
• UNIX (FrontPage 97 y 98)
– Netscape
– Oracle
• AS/400
– IBM
82
WEB PANELS
• Interacción con la Base de Datos
• Desarrollo Inmediato
83
Web Panels VS. Work Panels
• Algunas propiedades deben setearse desde
código
• Algunas propiedades de objetos no están
implementadas o no funcionan
• El display final no corresponde
necesariamente con el de diseño
• No se han implementado todos los controles
de Windows
• El tamaño de pantalla no está limitado a una
resolución en particular
84
Web panel
85
Algunas características de los
Web panels
Son permitidos call’s a (botones y
eventos):
• Otros Web Panels o a sí mismo
• Procedimientos
Código embebido:
• Html
Ej.:
Event Start
86
Código embebido:
• JavaScript
Ej.:
Event Start
&c=‘<Script lenguage=“JavaScript”> alert(“Bienvenido a nuestra página
Web”)</script>’
mensaje.caption=&c
EndEvent
Seguridad
• ¿Es segura mi aplicación en Internet?
– ¿es segura la comunicación en Internet?
– ¿quién puede acceder a mi base de datos?
– ¿quién puede acceder a mi aplicación?
87
Seguridad a nivel de Web Server
• Criptografía
DBMS
88
Seguridad a Nivel de Aplicación
Sesión, cliente
Sesión,
cliente
Sesión, cliente
Generadores - Servidores
DBMS
VB Access, Oracle, MS SQL Server, Informix, DB2 (NT, RS/6000, OS/2)
C/SQL Oracle, MS SQL Server, DB2/6000
RPG AS/400
89
Requerimientos (Visual Basic)
• Servidor Windows 95, NT 3.5 o NT 4.0
– WEB Server
– Visual Basic 4.0 32 bits en adelante
– Webifce.dll (sólo VB 4.0)
• Cliente desarrollo GeneXus
– Visual Basic 32 bits en adelante
– Web Browser
• RED TCP/IP
90
Configuración del Modelo
GeneXus
MODEL
– PROPERTIES
– PREFERENCES
– EXECUTION
Model Properties
91
Model Properties:
EXECUTE (VB)
Model Properties:
PREFERENCES
• GENERAL
– VISUAL BASIC VERSION: 4.0 (32 BITS)
• WEB INFORMATION
– PROTOCOL SPECIFICATION (sólo para
VB y C/SQL)
• CLIENT SERVER INFORMATION
– Connect to Server
– Data Base Name
– Data Source Name
92
Getting Started
with GeneXus 8.0
November, 2003
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.
1
The .NET Framework 1.1 Redistributable Package can be downloaded from Microsoft’s website:
http://msdn.microsoft.com/library/default.asp?url=/downloads/list/netdevframework.asp.
It can also be downloaded from the Download Center at GXTechnical website:
http://www.gxtechnical.com/main/hdcenter.aspx?2,5,36,1035
Page 4 of 47
Getting Started with GeneXus
Generator Requirements
This section contains the requirements to generate and execute applications with the different
GeneXus generators:
Generator Requirements
.NET • Microsoft .NET Framework 1.1 Redistributable Package 2
• For generating Web interface applications you will need IIS 5.0 or higher
(available on Windows 2000 or XP)
• For generating Windows interface applications or printing PDF reports,
you will need Visual J# Distribution Package 1.1 3
• ODBC Driver for the DBMS used
Java • Sun and/or Microsoft JDK (we recommend having both)
• For generating Web interface applications:
o Web Server
o Servlet Engine
o JavaServer Web Development Kit
• For generating 3-tier Windows interface applications:
o HTTP: you will need a Web server and a servlet engine
o CORBA: you will need Visibroker
• JDBC Driver for the DBMS used
Visual Basic • Microsoft Visual Studio 6.0, with Service Pack 5 or higher
• MDAC 2.6 or higher
• If you use Sheridan Data Widgets, you will need version 3.0 or higher
installed
• ODBC Driver for the DBMS used (except if you are working with Microsoft
Access)
In addition, to create the database and execute the generated applications, you must have some
of the following DBMSs installed:
Generator DBMS
.NET • DB2 Universal Database
Java • DB2 UDB for iSeries
• Informix
• Oracle
• PostgreSQL
• SQL Server
Visual Basic • Access
• DB2 Universal Database
• DB2 UDB for iSeries
• Informix
• Oracle
• PostgreSQL
• SQL Server
2
The .NET Framework 1.1 Redistributable Package can be downloaded from Microsoft’s website:
http://msdn.microsoft.com/library/default.asp?url=/downloads/list/netdevframework.asp.
It can also be downloaded from the Download Center at GXTechnical website:
http://www.gxtechnical.com/main/hdcenter.aspx?2,5,36,1035
3
You can obtain Visual J# Distribution Package 1.1 from Microsoft’s website:
http://msdn.microsoft.com/vjsharp/downloads/howtoget/default.aspx
Page 5 of 47
Getting Started with GeneXus
It is not possible to open a knowledge base developed with GeneXus standard version from
GeneXus Trial or vice versa.
Support for GeneXus Trial is limited. If you have any doubts or problems –about version
installation and activation only–, please send an e-mail to gxtrial@genexus.com. For any
additional information, we recommend contacting your local distributor
(www.genexus.com/distributors).
Page 6 of 47
Getting Started with GeneXus
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:
In this dialog you select the destination folder where GeneXus will be installed (a directory called
gxw80Trial is suggested). By clicking the Browse button you will be able to change the default
one. Click Next to go to this dialog:
Page 7 of 47
Getting Started with GeneXus
Once you have selected the destination folder, you will be asked for the products you want to
install (i.e. Development Environment and the different Generators). Then, click Next to begin
the installation.
After all the files you need have been copied to your system, the Setup program places GeneXus
icons in a GeneXus group that will be automatically incorporated to your Program Manager's
window.
Page 8 of 47
Getting Started with GeneXus
1. Execute GeneXus 8.0 Trial Version from the desktop shortcut for GeneXus 8.0 or from the
programs menu.
4. After receiving the activation key, proceed with the product activation. Then you will be able to
start using GeneXus Trial.
Page 9 of 47
Getting Started with GeneXus
Page 10 of 47
Getting Started with GeneXus
Page 11 of 47
Getting Started with GeneXus
When defining a Transaction, a default Form is automatically created by GeneXus to specify the
way the end user will access data in Windows applications. This form can be changed by the
developer.
Page 12 of 47
Getting Started with GeneXus
When defining a Transaction, a default Web Form is automatically created by GeneXus to specify
the way the end user will access data in Web applications. This Web Form is based on a default
Theme object, which is a new object introduced in the latest GeneXus version.
The Theme object improves the development and maintenance of Web applications by separating
the developer’s work from the designer’s.
4
Note: Most likely you will want to read the tax % from a table, but in this example we will just hardcode
the tax % for simplicity.
Page 13 of 47
Getting Started with GeneXus
1. Choose the Line Total attribute (ItemLnTot) and double-click the Formula field.
Page 14 of 47
Getting Started with GeneXus
1. Select the
Rules tab.
5. Click Save.
Page 15 of 47
Getting Started with GeneXus
3. In the Select Object dialog box, click Select All and then click OK.
Page 16 of 47
Getting Started with GeneXus
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> <Invoice1>
InvoiceId InvoiceId
InvoiceDate ItemId
CustomerId ItemDsc
CustomerNm ItemPrice
ItemQty
In addition, you will see that GeneXus automatically removes from the tables those attributes
that we made as formulas, and makes them global formulas so you can access them
automatically anywhere.
Note: From the Menu: Advanced \ Table you can change a table name, add new indexes, or
define redundancies.
Page 17 of 47
Getting Started with GeneXus
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:
Page 18 of 47
Getting Started with GeneXus
Page 19 of 47
Getting Started with GeneXus
1. Select Prototype.
3. Click OK.
Page 20 of 47
Getting Started with GeneXus
6. Click Next.
8. Click Next.
Page 21 of 47
Getting Started with GeneXus
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.
Page 22 of 47
Getting Started with GeneXus
2. Click Exit.
Page 23 of 47
Getting Started with GeneXus
1. On the Build menu, click Build All. You can also click Build All in the GeneXus toolbar.
GeneXus presents you with a specification report for each program it will generate.
The specification report’s objective is to show you in a high level how the program will execute,
which tables it will access and which operations it will perform.
In this case you are viewing the specification report of the transactions; notice that transactions
are programs that will enable the user to Insert, Update, and Delete functions on the database.
It also ensures that referential integrity and record locking are handled.
Page 24 of 47
Getting Started with GeneXus
GeneXus automatically takes charge of referential integrity. That is, transactions have the
necessary knowledge to avoid data inconsistency due to updates (for example, a parent with
children has been deleted, or a child without a parent has been entered).
However, an integrity check alone would not be enough because a check failure and a "Client
does not exist" message would not be useful for the user. It is necessary to help the user find
the valid values!
For this reason, GeneXus not only provides integrity controls, but also creates Prompt type
objects that give the user a set of valid values to choose from.
Although the Prompts are initially created by GeneXus, they can be modified by the user.
Page 25 of 47
Getting Started with GeneXus
Page 26 of 47
Getting Started with GeneXus
4. Next, enter some data into the Invoice. You will notice a couple of things here:
2. Create the Item Transaction by following Steps 2 to 4. The following attributes will be inserted
in the Item Transaction Structure:
Note that when you press the Save button, GeneXus won’t ask for the attribute definition of any
of them.
Page 27 of 47
Getting Started with GeneXus
3. Now click the Form and Web Form tabs to see the transaction’s windows and Web forms,
respectively.
Page 28 of 47
Getting Started with GeneXus
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.
You will see that GeneXus automatically moves the attributes from the InvoiceHeader to the Item.
Page 29 of 47
Getting Started with GeneXus
Page 30 of 47
Getting Started with GeneXus
Page 31 of 47
Getting Started with GeneXus
1. Follow Step 2 to
create the new
Report object, but
this time click on
Report and type
Invoice in the
Name field.
Page 32 of 47
Getting Started with GeneXus
Page 33 of 47
Getting Started with GeneXus
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.
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.
In order to make the communication between the two objects we will make a call from the Invoice
Transaction to the Invoice Report.
6. Write
“parm(InvoiceId);”
7. Click Save.
Page 35 of 47
Getting Started with GeneXus
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.
Page 36 of 47
Getting Started with GeneXus
CONGRATULATIONS…, you have successfully created an Invoice application in GeneXus; our next
step is to show you how to move your application to another platform, .NET and/or JAVA.
Page 37 of 47
Getting Started with GeneXus
5. Click Next.
7. Write the name of the Database and the Server. In the example, the Database name is
“demo” 5 and the Server name is “(local)”
8. Click Next.
5
The creation of the database is not performed by GeneXus when the creation process is carried out, so the
database must be created manually before GeneXus actually creates the database tables. Please refer to
your SQL Server manual for information on how to create the database.
Page 38 of 47
Getting Started with GeneXus
6
The user needs CREATION rights to the database tables. For simplicity, we recommend assigning OWNER
rights.
Page 39 of 47
Getting Started with GeneXus
Page 40 of 47
Getting Started with GeneXus
Page 41 of 47
Getting Started with GeneXus
Figure 61 Invoice
Page 42 of 47
Getting Started with GeneXus
5. Click Next.
7. Click Next.
7
The database is not created by GeneXus when the creation process is performed, so you must create the
database manually before GeneXus actually creates the database tables. Please refer to your SQL Server
manual for information on how to create the database.
Page 43 of 47
Getting Started with GeneXus
8. In Step 3, enter the user id and password for the DBMS login. In the example the User Id is
“user_name” 8
8
The user needs CREATION rights to the database tables. For simplicity we recommend assigning OWNER
rights.
Page 44 of 47
Getting Started with GeneXus
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.
9
In the example:
• Compiler Path = C:\Program Files\Microsoft SDK for Java 4.0\bin\jvc.exe
• Make Path = C:\Program Files\Microsoft SDK for Java 4.0\bin\nmake.exe
• Interpreter Path = C:\WINDOWS\system32\jview.exe
• Classpath = gxclassr.zip;.;C:\resin-2.1.7\lib\jsdk23.jar;C:\jdbc\sqlserver\Una2000.jar
• Web Application Base URL = http://localhost:8080/servlet/
Page 45 of 47
Getting Started with GeneXus
Figure 66 Invoice
Page 46 of 47
Getting Started with GeneXus
Online Resources
GeneXus Community
The GeneXus Community provides a variety of ways to get answers to your questions, solutions to
your problems, and to share your own expertise. Find the list of community resources available to
you at:
www.genexus.com/community
Support
ARTech offers a wide range of support services and resources:
• Self-Service Online Support
These resources are available to anyone online. However, the information that you access
depends on your GXTechnical Access Level.
• Interactive Support Services
Interact with other members of the Community and with our Support Team.
www.genexus.com/support
How to Buy
The GeneXus Technologies are sold through a network of distributors worldwide.
Page 47 of 47