Pattern

K2BEntityServices

1
1 Introducción: ______________________________________________________ 6
1.1 ¿Qué es un patrón? ___________________________________________________ 6
1.2 ¿Qué es GeneXusPatters? _____________________________________________ 6
1.3 Trabajando con GeneXus Patterns: _____________________________________ 8
1.4 Entrando a GeneXus Patterns __________________________________________ 9
1.5 Introducción Pattern K2BEntityServices ________________________________ 13
2 Guía de uso rápido del pattern K2BEntityServices: _______________________ 14
2.1 Paso 1 : Generación de la instancia por defecto de Pais ____________________ 14
2.2 Paso 2 : Modificación de la instancia por defecto _________________________ 15
2.3 Paso 3: Aplicación de la instancia ______________________________________ 16
2.4 Vista objetos generados ______________________________________________ 16
2.4.1 WWPAIS: ______________________________________________________________ 17
2.4.2 Reportes asociados al selection: _____________________________________________ 19
2.4.3 ViewPAIS:______________________________________________________________ 20
2.4.4 PaisGeneral:_____________________________________________________________ 22
2.4.5 PaisCiudadWC: __________________________________________________________ 22
2.4.6 PromptPais: _____________________________________________________________ 23
2.4.7 Actualización de transacción de Pais: _________________________________________ 24
3 Pautas previas: ____________________________________________________ 25
3.1 Pautas previas antes de la aplicación del Pattern K2BEntityServices: ________ 25
3.1.1 Transacciones: ___________________________________________________________ 25
3.1.2 Atributos: _______________________________________________________________ 26
3.1.3 Determinación de instancia por defecto: _______________________________________ 26
3.1.4 Posicionamiento de atributos en las pantallas:___________________________________ 27
3.1.5 Determinaciones de descripciones de atributos en las pantallas:_____________________ 27
3.1.6 Determinaciones de tipos de control en atributos: ________________________________ 28
3.1.7 Generación de filtros por defecto: ____________________________________________ 28
3.2 Pautas antes de aplicar la instancia: ____________________________________ 29
4 Actualización de transacciones: ______________________________________ 30
4.1 Update Transaction = Apply K2BWWStyle: _____________________________ 30
4.1.1 Actualización de web form:_________________________________________________ 30
4.1.2 Actualización de código: ___________________________________________________ 34
4.1.3 Instanciación automática de la clave foránea: ___________________________________ 38
4.2 Propiedades en la instancia sobre la transacción: _________________________ 40
4.2.1 Update Transaction:_______________________________________________________ 40
4.2.2 GenerateSlotsForFK: ______________________________________________________ 41
4.2.3 Navigation: _____________________________________________________________ 41
4.3 Propiedades avanzadas para la transacción: _____________________________ 41
5 Objetos con Grilla _________________________________________________ 42

2
 5.1 Filtros y condiciones: ________________________________________________ 44
5.1.1 Mecanismo genérico para la definición de variables: _____________________________ 44
5.1.2 Propiedades asociadas a los filtros: ___________________________________________ 45
5.1.3 Forma de agregado de los filtros: ____________________________________________ 45
5.1.4 Tipo de control asociado a los filtros: _________________________________________ 46
5.1.5 Propiedad Prompt asociada a un filtro _________________________________________ 47
5.2 Órdenes:___________________________________________________________ 48
5.3 Atributos:__________________________________________________________ 49
5.3.1 Variables:_______________________________________________________________ 50
5.3.2 Seteo de propiedades de los atributos: _________________________________________ 50
5.4 Modos y Acciones:___________________________________________________ 51
5.4.1 Acciones de usuario: ______________________________________________________ 52
5.4.2 Propiedad RowSelection:___________________________________________________ 55
5.4.3 Algunas otras propiedades: _________________________________________________ 56
5.4.4 Acciones en vistas tabulares: ________________________________________________ 57
5.4.5 Condiciones asociadas a las acciones _________________________________________ 58
5.4.6 Nodo Standard Actions (K2BEntityServices.config) _____________________________ 59
5.4.7 Avanzado: Invocación acciones standards______________________________________ 60
5.5 Paginado: __________________________________________________________ 61
5.6 Propiedades del selection _____________________________________________ 62
6 Objecto View: _____________________________________________________ 64
6.1 Nodo Tabs. _________________________________________________________ 66
6.1.1 Generación por defecto:____________________________________________________ 66
6.1.2 Propiedades de los tabs:____________________________________________________ 67
6.1.3 Tipos de tabs:____________________________________________________________ 68
6.2 Avanzado: _________________________________________________________ 69
6.2.1 Parámetros de los tabs: ____________________________________________________ 69
6.2.2 User Defined Vs Referenced Tab: ____________________________________________ 70
6.3 Vistas Planas: ______________________________________________________ 70
6.3.1 Tab General: ____________________________________________________________ 71
6.3.2 Propiedad NoSkip:________________________________________________________ 72
6.3.3 Forma de generar la tabla: __________________________________________________ 73
6.3.4 NoSkip Fixed Data: _______________________________________________________ 74
6.4 Nodo Preview Fixed Data: ____________________________________________ 75
7 Reportes _________________________________________________________ 78
7.1 Inclusión de reportes en la instancia: ___________________________________ 81
7.2 Títulos de los reportes: _______________________________________________ 82
7.3 Reportes Excel: _____________________________________________________ 82
7.3.1 XmlWriter Vs ExcelDocument ______________________________________________ 82
7.4 Reportes PDF: ______________________________________________________ 83
7.4.1 Atributos que se visualizan:_________________________________________________ 83
7.4.2 Configuración avanzada: ___________________________________________________ 85
8 Propiedades avanzadas del pattern K2BEntityServices: ___________________ 88

3
 8.1 Instancias __________________________________________________________ 88
8.1.1 Atributos _______________________________________________________________ 88
8.1.2 Distribución de instancias __________________________________________________ 88
8.2 Archivo de configuración (K2BEntityServices.config) _____________________ 89
8.3 Master Pages _______________________________________________________ 90
8.4 Manejo de sesión ____________________________________________________ 91
8.5 Objeto Home _______________________________________________________ 91
8.6 Objetos básicos _____________________________________________________ 92
8.6.1 Customización de objetos básicos ____________________________________________ 92
8.6.2 Recursos _______________________________________________________________ 93
8.6.3 Consolidación objetos básicos _______________________________________________ 93
8.6.4 Avanzado, crear objetos básicos propios para ser consolidados _____________________ 96
8.7 Organización de objetos en folders._____________________________________ 96
8.8 Nomeclatura de objetos ______________________________________________ 97
9 Propiedades avanzadas de la grilla ____________________________________ 99
9.1 Manejo de parámetros _______________________________________________ 99
9.2 Fixed data en el selection _____________________________________________ 99
9.3 Componentes ______________________________________________________ 101
9.3.1 Web Component ________________________________________________________ 102
9.3.2 Attributes/Variables: _____________________________________________________ 103
9.4 Eventos ___________________________________________________________ 104
9.5 Reglas ____________________________________________________________ 106
9.6 Variables _________________________________________________________ 106
9.7 Tabs en los filtros __________________________________________________ 107
9.8 Trucos____________________________________________________________ 110
9.8.1 Creación de grilla sin tabla base. ____________________________________________ 110
9.8.2 Acción que invoca a un evento de usuario. ____________________________________ 110
9.8.3 Cambiar acción standard por acción de usuario_________________________________ 110
10 Propiedades avanzadas de otros objetos _____________________________ 112
10.1 Propiedades avanzadas en los views ___________________________________ 112
10.2 Propiedades avanzadas de los tabs tabulares ____________________________ 112
10.3 Propiedades avanzandas para la generación de la instancia por defecto _____ 113
10.3.1 Hidden Attributes _____________________________________________________ 113
11 Integración con WorkFlow _______________________________________ 115
11.1 Relevant Data: _____________________________________________________ 115
11.2 Slot en la transacción:_______________________________________________ 116
11.3 Stub de salida: _____________________________________________________ 117
11.4 Importante: _______________________________________________________ 117

4
 11.5 Objetos básicos:____________________________________________________ 117
12 Seguridad _____________________________________________________ 118
12.1 Método IsAuthorized _______________________________________________ 118
12.2 Seguridad basada en actividades: _____________________________________ 120
12.2.1 Nombramiento de actividades____________________________________________ 122
12.2.2 Invocación a programas de seguridad ______________________________________ 124
12.2.3 Seguridad en los tabs subordinados _______________________________________ 126
12.2.4 Alta de actividades ____________________________________________________ 126
12.2.5 Otra Configuración ____________________________________________________ 127
12.2.6 Integración con GXPortal _______________________________________________ 127
12.2.7 Obtención de GAMPRoEnvId, GamProId __________________________________ 128
12.2.8 Permisos backend GXPortal _____________________________________________ 129

5
1 Introducción:

El pattern K2BEntityServices es un patrón creado por el equipo de K2B para facilitar el

desarrollo de aplicaciones web complejas.
Tomando la filosofía del pattern WorkWith, genera para una entidad paneles que
permiten el acceso a los servicios de mantenimiento de la entidad, así como la
exploración con sus entidades relacionadas.

1.1 ¿Qué es un patrón?

Un patrón es una solución genérica a un problema que se repite. Dentro del desarrollo
web se ha encontrado que hay un patrón que se repite en los objetos que se construyen,
uno de ellos al que se le podría llamar “trabajar con” consiste en una vista de grilla con
todos los registros de la entidad y sus posibles operaciones, así como también la vista de
esa entidad con aquellas relacionadas.

1.2 ¿Qué es GeneXusPatters?

Para el desarrollo basado en patrones existe una herramienta que permite la generación
automática de objetos GeneXus, esta herramienta se llama GeneXus Patterns.

Básicamente GeneXus Patterns es una herramienta que dado un patrón, una base de
conocimiento, y una parametrización, genera objetos GeneXus,
¿Cómo los genera?, pues bien genera una distribución de objetos que los consolida
automáticamente en la KB.

Para aquellas personas que nunca usaron GeneXus Patters quizás sea complicado
entender estos conceptos, así que a continuación se dará una explicación de todo esto:

• GeneXus Patterns es una herramienta separada de GeneXus.

• GeneXus Patterns lee una base de conocimiento a través de GXPublic.

6
 • La base de conocimiento no puede estar abierta al mismo tiempo en GeneXus y
en Patterns por lo que hay que cerrar la KB para abrir patterns.
• Dentro del modelo de diseño en GeneXus, existe una tool que permite abrir
GeneXus Patters automáticamente, esta tool cierra la KB y abre patterns.
o Si no tienes esta tool habilitada en diseño, ve en DOS al directorio de
instalación de GeneXus Patterns (c:\Program Files\ArTech\Patterns11) y
ejecuta GeneXusPatterns /register

La filosofía embebida dentro del pattern es la que se muestra en la siguiente figura:

Se parte de una base de conocimiento en una versión inicial, a esta se le aplica un patrón
según cierta parametrización, llamada instancia, y a partir de esa parametrización se

7
generan los diferentes objetos. Estos objetos se consolidan en la base de conocimiento
creando una kb en versión 2 y el resto lo hace GeneXus a partir de los generadores,
creando la nueva aplicación.

1.3 Trabajando con GeneXus Patterns:

Supongamos que se tiene un patrón que dada una transacción genera un listado de todos
los registros de su tabla base. Ej: Se tiene la transacción de País, se aplica el patrón, y se
desea que se genere un objeto con una grilla conteniendo todos los países.

Así se tiene:

Input: Transacción Pais

Output: WWPais (objeto con la grilla de País).

Los pasos entonces que hay que seguir son los siguientes:

1. Abrir GeneXus Patterns.

2. Seleccionar el patrón a aplicar
3. En el KBExplorer seleccionar la transacción a la que se le quiere aplicar el
pattern.
4. Dar doble click en esa transacción.
5. Salvar el xml que se genera (instancia predeterminada)
6. Seleccionar Apply & Consolidate

Así se obtienen los objetos.

Veremos esto gráficamente en la siguiente figura

8
Instancia: Xml que indica la parametrización del patrón. . Ej; para el caso de países es un
xml con los atributos de país que se van a mostrar.

Instancia Predeterminada: El patrón dado una transacción genera una paremetrización

inicial del objeto. Por ejemplo la instancia predeterminada de país puede ser un xml con
todos los atributos de la transacción.

Instancia Especifica: Instancia obtenida luego de la intervención del usuario en la

instancia predeterminada. En el caso de Países el usuario podría eliminar aquellos
atributos que no desea mostrar en la grilla.

Archivo de configuración: Existe en GeneXus Patterns otro archivo que parametriza el

patrón, que es el de configuración. Este es genérico para todas las instancias. Por ejemplo
si se le aplica el patrón a la instancia de país, existen ciertos comportamientos genéricos
que valen para todos los objetos. Por ejemplo si en el evento Start se llama a un programa
de seguridad para chequear si el usuario está autorizado o no, ahí se almacena el nombre
del programa de seguridad al que deben llamar todos los objetos que el pattern genera.

1.4 Entrando a GeneXus Patterns

9
Al ingresar a la herramienta GeneXus Patterns, uno se enfrenta a una pantalla con
diferentes secciones.

En la parte izquierda aparece una pantalla con dos tabs, uno es el KBExplorer y otro es el
Fólder Explorer.
En el KB Explorer se muestran las diferentes transacciones que hay en la base de
conocimiento donde a partir de ellas se puede seleccionar una transacción para generar
una instancia por defecto, en el Fólder Explorer se muestran las instancias que al
seleccionarlas son abiertas en la pantalla principal.
Abajo del todo a la izquierda hay una pantalla colapsable, OutPutWindow, donde se
muestran mensajes cuando se están realizando las acciones de generación de los objetos
GeneXus.

Configuración del modelo:

10
Si en el menú del pattern se va a Build -> Configure GX Integration se accede a un menú
que permite configurar información de cómo se va a integrar Patterns con la KB.
En Model se selecciona el modelo en el que se impactarán los cambios, en Apply &
Consolidate se configura la acción a realizar al efectuar Apply & Consolidate, y se puede
seleccionar entre:
• Import Only
• Impact Model
• Impact, Specify, Compile
• Impact, Specify, Compile, Run.

ShowConsolidationLog: Si se va a visualizar el log de consolidación o no.

11
En la parte superior de la pantalla se cuenta con un conjunto de herramientas
Que permiten:

Apply Pattern: genera la exportación a consolidar en la KB bajo el directorio

Templates\Import de la KB.
Apply and Consolidate: efectúa la acción seleccionada en la configuración de integración
con la KB.
Impact Model
Specify and Generate.

12
Compile
Run.

1.5 Introducción Pattern K2BEntityServices

El Pattern K2BEntityServices a partir de una instancia genera los siguientes objetos:

• Selection
• View
o General
o Tabs con datos relacionados.
• Prompt
• Reportes PDF/Excel
• Actualiza la transacción

Está basado en el pattern WorkWith pero con el agregado de mayor funcionalidad para
hacer que se pueda mantener la mayor parte de los objetos del estilo trabajar con dentro
del patrón.

En la siguiente sección se comenzará con un ejemplo simple en el que se mostrará la

aplicación de patterns a una transacción.

13
2 Guía de uso rápido del pattern K2BEntityServices:

En esta sección se mostrará la aplicación del Pattern K2BEntityServices a una trasacción

de Pais.

Supongamos que en la KB tenemos la siguiente estructura:

Y le queremos aplicar el Pattern K2BEntityServices a la instancia de Pais.

Para esto vamos a realizar los siguientes pasos.

2.1 Paso 1 : Generación de la instancia por defecto de Pais

1) Abrir la base de conocimiento con GeneXus Patterns

a. Desde diseño tools->GeneXus Patterns
2) Seleccionar el pattern K2BEnttiyServices (si es que ya no está seleccionado)

3) Seleccionar el tab KBExplorer

14
 4) Seleccionar la transacción de Pais y dar doble click sobre ella.

5) Generar la instancia por defecto de Pais.

2.2 Paso 2 : Modificación de la instancia por defecto

Cada nodo del xml representa un objeto que se va a generar.

Selection representa el trabajar con, View representa una vista de un registro de país, con
sus tabs relacionados, esto es el tab general donde se muestra información del país, y el
tab de ciudades donde se muestran las ciudades de ese país. El Pattern K2BEntityServices
crea un tab por cada tabla directamente subordinada a la de país.

Una vez que se tiene la instancia, se van a modificar algunas cosas. El nodo level
representa un nivel de la transacción, en este caso País tiene un nivel sólo por lo cual en
la instancia se genero un único level. La descripción del level es tomada en los títulos de
los reportes y en las descripciones del trabajar con que tienen en description la propiedad
<default>. Esta descripción debe estar en plural por lo tanto se modificará la descripción
de la instancia por defecto para que aparezca en plural.

15
2.3 Paso 3: Aplicación de la instancia
1) Salvar la instancia y dar Apply & Consolidate

2) Cerrar la KB ir a GeneXus.
3) Pasar al modelo de ejecución, impactarlo y especificar los objetos modificados.
4) Compilar y ejecutar. Así rápidamente se tendrá la aplicación corriendo.

2.4 Vista objetos generados

Los objetos generados por el Pattern K2BEntityServices son generados por defecto en la
carpeta Generated.

16
Compararemos en ejecución lo generado con su respectiva instancia.
A partir de País se generan los objetos:

2.4.1 WWPAIS:

Generado a partir del nodo Selection:

Atributos:

Se colocan los atributos que se van a mostrar en la grilla.

Filtros y condiciones:

17
Son los filtros que va a poseer la grilla.

Órdenes:

Atributos por los cuales se va a poder ordenar.

Actions:

Acciones que se pueden realizar.

Modes:

Acciones que van sobre la transacción:

18
Insert: (Top)
Update, Delete, Display: (Ingrid)

2.4.2 Reportes asociados al selection:

Imprimen lo que se muestra en la grilla tomando en cuenta, los filtros y órdenes.

En el reporte PDF, se muestran solo los atributos que entran en la hoja.

(Excel)

(PDF)

19
2.4.3 ViewPAIS:

Generado a partir del nodo view

20
Se encarga de mostrar información de la entidad. Posee dos tabs, uno general y otro por
cada tabla directamente subordinada a la tabla base de la transacción, en este caso el tab
que se muestra es el de ciudad.

Fixed Data:

Es el atributo que aparece en el título del view.

21
2.4.4 PaisGeneral:

Muestra información plana asociada a una transacción.

El nodo tab con la propiedad type = Tabular indica que la vista es tabular.
Las acciones que se pueden hacer son las de update, delete, y la impresión plana y
reportes Excel planos, que replican la misma información que se muestra en pantalla.

2.4.5 PaisCiudadWC:

Tab de ciudades del País. El tab tiene la propiedad type = grid, se muestra como forma de
grilla. Su comportamiento y funcionalidad es exactamente igual que la del selection.

22
2.4.6 PromptPais:

23
Para ser invocado como prompt, el formato del nodo es similar al del selection, permite
seleccionar un país.

2.4.7 Actualización de transacción de Pais:

El web form, reglas y eventos del Pattern K2BEntityServices son generados por defecto
en la transacción.base de la instancia.

24
3 Pautas previas:

3.1 Pautas previas antes de la aplicación del Pattern

K2BEntityServices:

Antes de aplicar el pattern K2BEntityServices existen ciertas pautas que hay que seguir
para ayudar al usuario a que al pattern realice las inferencias correctas a la hora de
generar la instancia por defecto.

3.1.1 Transacciones:

• Las descripciones de las transacciones y de sus niveles deben ser descriptivos

y deben estar en singular.
o Ej: Trn001: Pais
• Setear el Description Attribute de cada transacción.
• Ordenar los atributos en las transacciones según el órden en que se desean
mostrar en pantalla.
o Las FK deben estar juntas con su descripción.
• En transacciones de varios niveles, atributos de resumen de nivel inferior,
colocarlos a continuación del nivel inferior.
o Ej: Factura total resumen de nivel Línea. Factura Lìnea Total resúmen
de nivel CentroCosto.

25
3.1.2 Atributos:

• Los titles y column titles de los atributos deben describir a ellos mismos.
o Ej: Código de País : Código.
• Asignar dominio a los atributos de tipo Fecha. Es recomendable que cada atributo
tenga definido un dominio.
• Asignar a los atributos el tipo de control que corresponda cuando va a ser
referenciado como clave foránea.

3.1.3 Determinación de instancia por defecto:

El cumplimiento de estas pautas ayudan al Pattern K2BEntityServices a la determinación

de la instancia por defecto.

26
3.1.4 Posicionamiento de atributos en las pantallas:

El Pattern determina el posicionamiento de los atributos según el órden como han sido
definidos los atributos en la transacción.
En las transacciones de varios niveles el Pattern K2BEntityServices les da a los atributos
de resúmen un look & feel especial además de posicionarlos por debajo de las grillas que
resumen.
Ej:

3.1.5 Determinaciones de descripciones de atributos en las

pantallas:

El pattern K2BEntityServices determina la descripción de los atributos en las pantallas,

utilizando el siguiente algoritmo.
• Title, en las vistas planas.
• Column title, en las vistas de griila.
• Excepción DA: En caso de ser un atributo DA inferido se toma la descripción del
nivel de la transacción del cual el atributo es DA.

Ejemplo (determinación descripción DA):

Se tiene el atributo ClienteNombre, en el WWCliente se mostrará como
descripción Nombre, en cambio en el WWFactura se tomará como descripción la palabra
Cliente.

27
Atributos que son subtipos:
Por defecto se toma como descripción de subtipos inferidos cuyo supertipo es DA , la
descripción de la transacción del cual el supertipo es DA. Este comportamiento se puede
modificar en el archivo K2BEntityServices.config y colocar
DefaultSubtypeForeingDADescription en SubTypeGroupDescription para que tome el
nombre de la descripción del grupo de subtipos. Por algunos problemas esta propiedad
ahora está tomando momentáneamente la descripción del atributo en el grupo de
subtipos.

3.1.6 Determinaciones de tipos de control en atributos:

El Pattern K2BEntityServices le asocia el tipo de control correspondiente a los atributos

que aparecen en pantalla. Aquellos atributos que aparecerán como readonly(ej dentro de
las grillas) les fuerza el tipo de control a edit.
De esta forma en la instancia si por ejemplo ProductoId es un DynamicCombo,
ItemValues = ProductoId, ItemDescription = ProductoNombre, si en el nodo attributes de
una instancia se coloca ProductoId, se mostrará el productoId. Si esto es colocado en los
filtros mostrará el producto id con su tipo de control asociado.
En la generación del web form de la transacción, el tipo de control será forzado a edit
cuando el atributo es clave de la transacción ej: ProductoId en la transacción Producto.
En las transacciones que el atributo es referenciado como foráneo se toma el tipo de
control del atributo.
A la hora de generar la transacción el Pattern K2BEntityServices coloca en el web form
todos los atributos que aparecen en la transacción menos aquellos que ya han sido
visualizados mediante el control info de otro atributo.
Ej:

Categoría Producto

CategoríaID*
CategoriaNombre
ProductoId
ProductoNombre

El atributo ProductoNombre no será colocado en el web form dado que ya ProductoId al

tomar como control info el dynamic combo lo estaría mostrando.

3.1.7 Generación de filtros por defecto:

Por defecto el pattern genera filtros por:

• Description Attribute.

28
 • Description Attribute de los atributos foráneos no instanciados.
o Por no instanciado se referiere por ejemplo: Filtro de PaisNombre en
Ciudades de un Pais.
• Fechas desde y hasta por cada atributo que este definido con dominio fecha.
o En el archivo K2BEntityServices.config se puede configurar si se quiere
que por defecto se generen los filtros por fecha. Template/Filters :
GenerateDateFilters, GenerateDateTimeFilters.

3.2 Pautas antes de aplicar la instancia:

• Pasar la description del nodo level al plural.

o Esta descripción será mostrada como título de los reportes y como
títulos de los objetos que poseen la propiedad description en <default>
• Por cada tab subordinado pasar el caption del tab al plural.

29
4 Actualización de transacciones:

La transacción es el único objeto del pattern K2BEntityServices que puede ser

actualizado tanto desde Patterns como de GeneXus.
Mediante la propiedad update transaction se indica de que manera el pattern va a
actualizar la transacción.
Como predeterminado se tiene la propiedad update transaction; que indica como se va a
actualizar la transacción; en Apply K2BWWSytle. Esta es la forma normal de trabajar y
esta primera parte consistirá en explicar como es el comportamiento con update
transaction en ese valor.

4.1 Update Transaction = Apply K2BWWStyle:

4.1.1 Actualización de web form:

El Web Form de la transacción va a tener una sección a la que llamaremos área de datos.
En este lugar el usuario puede ubicar todos los atributos y hacer las modificaciones que el
desee en esa área, sin que el pattern a la hora de volver a ser aplicado le sobrescriba los
cambios hechos.

30
El Data Area está deliminado por la primera fila de la tabla K2BTableTrnDataContent
y la última fila de esta tabla, según como se visualiza en la figura.
El Pattern K2BEnttityServices a la hora de generar el web form coloca los atributos en el
orden que fueron definidos en su estructura, asociando el tipo de control especificado en
la KB para los atributos foráneos.

Para las transacciones de varios niveles el Pattern K2BEntityServices también genera un

look & feel especial. Para transacciones de n niveles el Pattern K2BEntityServices genera
grillas para niveles hojas y freestylegrids para los niveles intermedios. El nivel superior
siempre es plano.

Ej: Sea la transacción factura.

31
El primer nivel será plano el segundo un Freestyle grid y el tercero un grid.
La ubicación del DataArea es similar a la ubicación del DataArea en transacciones de un
nivel.

32
El Pattern K2BEntityServices asume que los atributos de un nivel superior ubicados a
continuación de un nivel inferior son atributos de resumen de ese nivel y los genera con
un look & feel especifico para esto.
En el ejemplo de la factura el Pattern infiere que el atributo FacturaTotal es un resumen
del nivel Línea y lo coloca al finalizar la línea. También asume que el atributo
FacturaLineaTotal es un resúmen del nivel Centro de Costo y lo coloca al final de este.
En ejecución:

33
La idea en cuanto a la generación del web from de la transacción por el Pattern
K2BEntityServices es que el pattern genera un web form por defecto, y luego el usuario
debe modificar el área de datos para adaptarlo a como va a ser el ingreso.

4.1.2 Actualización de código:

34
El Pattern K2BEntityServices genera el códgio en determinadas secciones llamadas slots,
a continuación pasaremos a describir qué son los slots.

4.1.2.1 Slot:

Nomeclatura: //+ <propietario>.<funcionalidad>[.Fixed]

Los slots generados por este pattern se generan con nombre de propietario =
K2BWorkWith
El .Fixed es opcional he identifica que ese slot es fijo y que no puede ser modificado.

Cuando el Pattern K2BEntityServices genera código, luego al volver a aplicar pasa lo

siguiente:

Los slots de tipo fixed se vuelven a generar completamente. Esto quiere decir que si el
usuario realizó modificaciones dentro de un slot de tipo fixed los perderá.
Los slots que no son fixed si no aparecen en el código el pattern los vuelve a generar y si
los encuentra los deja como estaba. Esto quiere decir que el usuario puede colocar el
código que desee en los slots no fixed, y el pattern no le pasa por arriba (nota esto solo en
transacciones).
El código por fuera de los slots no es sobrescrito por el pattern. O sea todo el código que
el usuario escriba por fuera de los slots, no lo pierde.

4.1.2.2 Actualización de reglas:

El Pattern K2BEntityService genera las siguientes reglas,

Slot: Parameters

Esta sección es generada por defecto y el usuario la puede modificar cuando quiera.

35
En ella se encuentra la regla parm, por defecto la genera con el modo y la clave primaria
de la transacción, y setea el valor del atributo si este está instanciado.
Dado que no es posible tener dos reglas parms en la transacción el pattern también busca
una regla parm por fuera de esta sección y de encontrarla la comenta.

Slot fixed para el manejo de la clase del error viewer.

En caso de mostrar un error, coloca un formato diferente si el error se da al eliminar.

Slot para el manejo de la clave, hace que la clave no pueda ser seteada, o sea para el caso
de autoenumerados el usuario nunca debe setear la clave,.

También hay un slot correspondiente a la instanciación automática de la clave foránea,

esto lo veremos después.

Para las transacciones de varios niveles genera reglas

Lo que hace esto es que si el modo en insert ya agrega la primera línea en la grilla de
cada uno de los niveles. Si es update o delete deja simplemente las que tienen que estar.
Esto lo hace para cada grilla correspondiente a cada subnivel de la transacción.

36
4.1.2.3 Actualización de eventos:

El Pattern K2BEntityServices genera el siguiente código para los eventos:

Esto es para el seteo del título de la transacción y los seteos del caption de los botones.

En las transacciones de varios niveles genera un slot para el seteo del tooltip de los
botones asociado al agregar líneas de cada una de las grillas.

37
Slots fixed en el after trn que al culminar invocan a la subrutina k2bclose que se encarga
de hacer un link al último objeto del stack.
En las transacciones de varios niveles genera un slot por defecto para el evento que se
ejecuta cuando se presiona el botón de agregar una linea para alguno de los niveles.

4.1.3 Instanciación automática de la clave foránea:

38
Supongamos que tenemos el ejemplo de facturas y clientes, y se quiere dar de alta una
factura en el tab facturas de un cliente, cuando se invoca a la transacción de facturas, se
va a querer que el cliente ya este instanciado. Esto presupondría modificar la regla parm,
lo cual implicaría modificar la invocación de todos los objetos que llaman a la
transacción.
Sin embargo existe otra forma de tener esto instanciado automáticamente sin tener que
hacer modificaciones en la regla parm. El Pattern K2BEntitySErvices hace uso de la web
session, en el panel invocador guarda aquellos atributos que están instanciados, y estos
son leídos en la transacción.

Ej: Se tiene las facturas del proveedor, antes de invocar a la transacción de factura se
ejecuta la subrutina preparetransaction que se encarga de almacenar en un sdt los
atributos que ya están instanciados. En este caso almacena el proveedor en un sdt de
nombre TrnContext.

Se guarda el nombre de la transacción que se va a invocar, y los nombres y valores de

atributos instanciados.

Para esto en el evento Start de la transacción factura el pattern K2BEntityServices genera

un slot fixed

39
Lo primero que hace es preguntar si el nombre de la transacción que está guardado en la
sesión es el mismo que el nombre del programa, en caso de serlo recorre todos los
atributos y hace un case con todos los atributos foráneos de la factura en este caso el
único foráneo es el proveedor pero podrían ser más.

Luego en las reglas se genera otro slot para igualar el atributo con la variable obtenida de
la sesión

En muchos casos la instanciación de las claves foráneas ya se tiene resuelto modificando

la regla parm, para esto es posible deshabilitar la generación de estos slots, desde la raíz
de la instancia yendo a la propiedad GenerateSlotsForFK. El valor <default> lo lee del
archivo de configuración. En la siguiente sección veremos bien como funciona esto.

4.2 Propiedades en la instancia sobre la transacción:

Estas propiedades se encuentran en la raíz de la instancia.

4.2.1 Update Transaction:

Indica como se va a actualizar la transacción. Hasta ahora se vio su comportamiento con

el valor Apply K2BWWStyle
• Do Not Update: No actualiza la transacción.

40
 • Only rules and events: Actualiza solo las reglas y los eventos. El web form lo deja
como lo puso el usuario.
• Create Default: Vuelve a generar todas las secciones default de nuevo. Esto es:
vuelve a generar el web form completo, todas las secciones de código tanto fixed
como por defecto.

4.2.2 GenerateSlotsForFK:

Se puede configurar aquí si se va a generar el slot para la instanciación automática de las

claves foráneas.

4.2.3 Navigation:

Se especifica la navegación dentro del pattern luego de hacer las diferentes operaciones
sobre la transacción.
Estas son After<Operation>:
• Return to caller : Vuelve al web panel llamador.
• Go To View: Va al view de la instancia determinada por esa transacción.
• Continue In Transaction: Para inserts sigue en la transacción para agregar otro
registro.

AfterInsert: {Return to caller, GoToView, Continue In Transaction}

AfterUpdate: {Return to caller, Go To View}
AfterDelete: {Return to caller}

Todas estas propiedades poseen el valor <default>, esto lo toma del config. Para esto
existe en el K2BEntityServices.config el nodo transaction, de donde se toman los valores
por defecto.

4.3 Propiedades avanzadas para la transacción:

CancelEvent: Permite indicar el evento que se va a ejecutar al presionar cancel. Esto

permite al usuario escribir en el cancel otro evento completamente diferente al que genera
Patterns por defecto.

En el K2BEntityServices.config:

41
GenerateGetContextForBC: Si el código que invoca al programa PK2BGetContext se
genera dentro de un tag web o no. Esto es para el caso en que se desee utilizar el context
dentro de los bc.
GenerateCheckButton: Indica si a la hora de generar la transacción se va a generar el
botón verificar o no.
GenerateOptionalKeySlots: Permite configurar la invocación a procedimientos que se
encargan de numerar automáticamente claves no numéricas. Estos procedimientos deben
ser implementados por el usuario del pattern, y deben ser referenciados desde las
propiedadades:
GetNumeratorProc: Programa que obtiene el numerador.
SetNumeratorProc: Programa que setea el numerador.

El pattern genera dentro del slot K2BWW.Key el siguiente código:

La function GetCódigo debe recibir como parámetro el nombre del atributo clave y
devolver cuál es el próximo numerador que se va a utilizar.
La función SetCódigo deberá dado el nombre del atributo clave setear el nuevo
numerador y devolverlo.

Los slots que están comentados son para tener una clave generada sugerida, y el último
para tener una clave manual.

5 Objetos con Grilla

El Pattern K2BEntityServices genera objetos con grilla en los tabs de tipo grid y en el
selection. Veremos aquí las propiedades más importantes que podemos encontrar en estos
objetos.

42
Estudiaremos cada uno de los componentes de los objetos con grilla:

Estos son los componentes comunes:

• Filtros

43
 • Órdenes
• Atributos
• Acciones
• Modos

En otro capítulo posterior estudiaremos componentes avanzados que también se

pueden agregar a un objeto con grilla.

5.1 Filtros y condiciones:

Nodo Filters and conditions.

El nodo filtros permite al usuario definir filtros.

Estos filtros se pueden definir basados en atributos o basados en algún dominio.
Patterns infiere el tipo de datos del filtro según el mecanismo genérico para la definición
de variables que se explica a continuación.

5.1.1 Mecanismo genérico para la definición de variables:

Esto es válido para todas las secciones donde se permiten ingresar variables, esto es:
• Nodo Filters
• Nodo Variables (se verá en capítulos posteriores)

44
 • Variables en la grilla.
• Componentes de la grilla (se verá en capítulos posteriores)

Patterns infiere el tipo de datos de la variable de la siguiente manera:

• Si su nombre es igual al nombre del atributo, crea la variable basada en ese
atributo.
• Si su nombre no es igual al atributo se debe colocar en la propiedad domain el
nombre del dominio. Patterns define la variable con ese dominio.

5.1.2 Propiedades asociadas a los filtros:

SaveState:
El pattern automáticamente para cada filtro salva el estado, esto es si el usuario en
ejecución define determinados filtros, y luego navega por otras pantallas, cuando vuelva
al objeto con grilla, los filtros van a seguir estando. Esto se puede modificar, utilizando la
propiedad savestate asociado al filtro, su valor <default> o true indica que se salva el
estado correspondiente a ese filtro, seteando en false se puede configurar para no salvar el
estado correspondiente a dicho filtro.
Enabled:
Permite definir filtros readonly.
NoSkip: Se verá más adelante.
ThemeClass: Clase de tema que tomará el filtro. En caso de no especificarlo toma por
defecto la clase que es encuentra en ThemeClasses/K2BAttributeThemeClass, según el
tipo de datos. Si es fecha, tomará el valor de la propiedad FilterDate, si es date time
tomará el valor de la propiedad FilterDateTime, sino tomará el valor de la propiedad
Filter.
Default: Expresión a ejecutarse en el evento start.
Conditions:
Permite al usuario ingresar condiciones en el grid, que pueden o no estar asociados a
algún filtro. Ej: Filtros por Empresa obtenido del contexto (EmpresaId =
&Context.Empresa)

5.1.3 Forma de agregado de los filtros:

Para agreagar un filtro y que automáticamente se infiera su condition se puede utilizar la

propiedad select attributes, parado en el nodo attributes del filtro, abre una pantalla de
selección de atributos, automáticamente genera la condition correspondiente a ese
atributo.

45
5.1.4 Tipo de control asociado a los filtros:

El tipo de control asociado a los filtros es obtenido por defecto del tipo de control del
atributo o dominio en el que está basado el filtro. Si el tipo de control asociado al filtro es
un combo, se le puede colocar la propiedad All al fitro en true. En ese caso agrega un
nuevo elemento al combo que representa el todos, o sea no se filtra por esa variable. El
label asociado al todos se puede configurar en el archivo de configuración, bajo
“Labels/AllInCombo”.

En caso de que el tipo de control asociado al filtro se desea que sea otro o que este
condicionado al valor de otro filtro ya seleccionado, parado en el filtro se puede
seleccionar agregar un control info.

46
Las propiedades que se pueden asignar, son las mismas que aparecen en el diálogo de
control info que aparece en GeneXus. Como limitación de GeneXus en los filtros no se
puede utilizar un suggets con InputType description.

5.1.5 Propiedad Prompt asociada a un filtro

Otra forma de generar el ingreso de datos de un filtro es mediante la propiedad prompt

del fitro. Esto hace que se pueda seleccionar el valor del filtro desde un prompt. Existen
dos formas de realizar la invocación al prompt según el valor ingresado en la propiedad
prompt.

47
Solo nombre de objeto: Se pone solamente el nombre de objeto (Ej:HPromptProveedor),
de esta forma patterns genera la regla prompt pasándo como parámetro el filtro.
Regla prompt completa: En muchos casos el prompt retorna más de un parámetro, en
tal caso con pasar como parámetro el filtro no alcanza. De esta forma se puede escribir la
regla prompt completa
Prompt(HPromtProveedor, &ProveedorId, &ProveedorNombre).
No se debe poner ; luego de poner la regla prompt sino dará error.
Para ambos casos patterns genera la imagen del prompt asociado al filtro y en la regla le
concatena el on imagePrompt;

Acá vemos un ejemplo de un WWFactura donde para seleccionar un proveedor se coloca

un prompt.

5.2 Órdenes:

El nodo órdenes permite definir los diferentes órdenes que se pueden seleccionar para
visualizar la grilla.

48
Cada orden tiene un caption que es lo que se muestra en ejecución en el combo. Además
cada orden esta compuesto por un conjunto de atributos, para cada atributo se puede
setear si el orden es ascendente o descendente utilizando la propiedad ascending.

5.3 Atributos:

Es el nodo principal de las vistas con grilla. Indica que atributos se mostrarán dentro de la
grilla.

49
Las propiedades que tienen son nombre, la descripción que es lo que se mostrará en el
título de la columna.
El atributo puede ser visible o no, en caso de ser invisible se coloca como hidden dentro
de la grilla.
ThemeClass:
Indica la clase del tema que tendrá el atributo por defecto toma la clase del tema ubicada
en ThemeClasses/K2BAttributesThemeClass, dependiendo del tipo de control, si es un
combo tomará el valor de ComboBoxInGrid, si es un varchar tomará el valor de
VarCharInGrid, si es un checkbox tomará el valor de CheckBoxInGrid, y sino tomará el
valor de SelectionGrid.
Autolink:
En true, si el atributo es DA genera el link dirigido al view correspondiente a la instancia.
LinkTo, Level:
Es posible establecer un link a un view de un nivel de la instancia, para esto en LinkTo se
debe poner el nombre de la instancia y level se debe indicar cuál es el nivel.

5.3.1 Variables:

En los atributos es posible también ingresar variables. Para esto se coloca el & adelante
para indicar que va a ser una variable.
La definición de variables está explicada en la sección 5.1.1 Mecanismo genérico para la
definición de variables:
ReadOnly:
Por defecto todas las variables son de solo lectura. Se puede modificar esta propiedad
para que el usuario puede ingresarle valor a esta variable.
Value:
Lo que se coloque en value será generado en el evento load de la grilla.
En particular se generará &Variable = <Value>
Domain:
Permite seleccionar un dominio.

5.3.2 Seteo de propiedades de los atributos:

Autoresize: Por defecto el Pattern K2BEntityServices para una correcta visualización de

la grilla, coloca el primer atributo visible de la grilla con autoresize en false, y el resto de
los atributos los coloca con autoresize en true.
La propiedad autoresize del primer atributo visible de la grilla es seteada en false, cuando
el largo de su tipo de datos es menor o igual que la propiedad dentro del archivo de
configuración Grid/FirstColumnResizeValue.

50
ReturnOnClick: En los prompts patterns determina en qué atributo se va a hacer return
on click. El atributo por defecto para hacer return on click es en el DA de la instancia de
la que cuelga el nodo prompt, si no hay DA o el atributo no está visible en la grilla, se
toma el primer atributo visible de la grilla .

5.4 Modos y Acciones:

En los objetos con grilla, el Pattern K2BEntityServices permite realizar las siguientes
acciones:

• Insert.
• Update
• Delete
• Display
• Print
• Excel

Estas son las acciones por defecto que genera el pattern en todos sus objetos. Las cuatro
primeras acciones están relacionadas con la forma en el que el pattern invoca al objeto
transacción. Esto es configurado en el modo modes,
donde se puede indicar a nivel de
instancia o de archivo de configuración, cuales de estas operaciones se pueden hacer
sobre la instancia. El valor defaul es leído del archivo de configuración en la propiedad
StandardAction/<Mode>/DefaultMode ej:StandardAction/Update/DefaultMode.

Las otras dos acciones standards son configurables a través de actions:

Las acciones print y Excel indican que se van a generar acciones de imprimir atributos en
formato pdf y Excel . La ausencia de alguno de estos nodos indica que la acción no se va
a generar.

51
En StandardActions/<Print|Excel>/DefaultMode se puede configurar a la hora de la
generación de la instancia por defecto si las acciones Print y Excel acciones se van a
incluir en:
• Todos los objetos (default mode = true)
• Solo en los selection (default mode = OnlyInSelection)
• En todos menos en vistas tabulares (default mode =
OnlyInSelectionAndGridTabs)

La ubicación por defecto de las acciones es:

Las acciones de update, delete y display se encuentran en la grilla, las acciones de Print y
Excel se encuentran en Top, y la acción Insert en Top(Right).

5.4.1 Acciones de usuario:

El usuario puede definir sus propidas acciones que invoquen a sus propios objetos. Esto
lo puede hacer agregando elementos dentro del nodo actions. Para esto hay que indicar en
la propiedad GXObject el objeto al que se va a invocar y agregar en parameters, los
parámetros con el que se invocará a dicho objeto.

Aquí veremos paso por caso cada una de las propiedades.

52
 Layout: Indica la ubicación de las acciones. Las opciones de Layout son las siguientes:
• Top
• Top (Right)
• Top(Left)
• Ingrid
• Bottom

Top Top (Right)

Top(Left)

InGrid

Bottom

Un punto importante es que en todos los layouts se generan imágenes, menos en el layout
bottom, donde se colocan botones.
Target: En target se especifica en qué lugar se va a abrir la ventana correspondiente a la
acción. Las opciones son:
• Standard: Se abre en la misma ventana que se está ejecutando.
• Popup: Se abre en una nueva ventana.
Las acciones por defecto de Print y Excel están configuradas por defecto para tener un
target Popup.
Caption: Solo para los botones. Indica el caption que se va a mostrar correspondiente al
botón.
ToolTip: Solo para las imágenes. Indica el tool tip asociado a la imagen.

53
Image: Solo para imágenes. Nombre de la imagen correspondiente a la acción.
DisableImage: En caso de tener una condition, nombre de la imagen en caso de no
cumplirse con la condición.

Además de estas acciones, para administrar mejor la pantalla existe lo que se llama el
ComboAction, que da la posibilidad de agrupar los distintos tipos de acciones dentro de
un combo.

Esto se puede hacer con un combo action, especificando adentro cada una de las acciones
que va a poseer.

Ahí se especifican las combo actions con cada una de las acciones que van a tener.

54
Las propiedades que puede poseer son nombre, caption y layout.
Caption; Es el nombre que aparece al comienzo del combo.
Los Layouts que posee con Top(Left) y Bottom. En la figura se especifica donde se
encuentran estos layouts.

Top(Left)

Bottom
Para las acciones combo, solo se tomará el GXObject y parameters. Las propiedades
correspondientes a interfaz serán ignoradas dado que la acción se visualizará dentro de un
combo en el layout especificado en las propiedades de la combo action.

5.4.2 Propiedad RowSelection:

55
Permite agregar una columna con un checkbox a la izquierda de la grilla, donde se le
permite seleccionar al usuario las diferentes filas.
Esto es válido solo para acciones de Layout Bottom, y acciones combo.
• None: La acción no tiene row selection definido.
• Single: Se permite seleccionar una sola fila en caso contrario error. (solo para
acciones combo).
• Multiple: Se permiten seleccionar múltiples filas.

Para las acciones múltiples la acción es invocada con los parámetros que se le indican a la
acción, más un parámetro implícito que es un SDT con las líneas seleccionadas. Este
SDT es generado por defecto por el pattern, y deberá ser recibido como primer parámetro
de la acción. El nombre de este SDT será <NombredelObjeto>+SDT. Y será de tipo
collection.
En el caso del proveedor se llamará WWProveedorSDT, en la siguiente figura se muestra
una vista de ese SDT.

El programa generado por patterns invocará a dicho objeto con el sdt cargado de las filas
seleccionadas.

GeneXus Patterns, da un error si el GXObject no existe, sin embargo para acciones con
RowSelection = Multiple, muchas veces es necesario tener el SDT con las filas
seleccionadas para crear el objeto. Para esto es recomendable poner un objeto cualquiera
en GXObject, consolidar para que cree el SDT luego programar el objeto correspondiente
a la acción en GX, y finalmente poner en patterns en GXObject el objeto real.

5.4.3 Algunas otras propiedades:

SelectAllCheckBox: Si se va a crear un checkbox para seleccionar todas las líneas.

ErrorNotSelectedLines: Si se va a mostrar algún mensaje de error en caso de que no se
seleccione ninguna línea.
ErrorMessage: Mensaje de error en caso de que no se seleccione ninguna línea.
Esto se puede ver en el archivo de configuración
UserDefinedActions/ErrorNoneRowsSelected.

56
Para las acciones con RowSelection =Single se dispara un error en caso de que más de
una línea haya sido seleccionada. El mensaje de error se puede modificar en el archivo de
configuración UserDefinedActions/ErrorMoreThanOneRowSelected.

Cuando se genera una acción con un combo, se coloca una imagen a la derecha del
combo donde según el item del combo seleccionado se ejecuta la acción correspondiente,
la ubicación de esa imagen se puede configurar en el nodo UserDefinedActions

SelectActionInComboToolTip permite configurar el tooltip asociado a la imagen.

5.4.4 Acciones en vistas tabulares:

En las vistas tabulares (vistas tabulares se verá en la próxima sección) las acciones de
Update y Delete son generadas como botones debajo del tab y se especifican mediante
acciones. Estas acciones tienen que tener el valor en la propiedad Name de Update y
Delete para que sean mapeandos con las acciones standards de Update y Delete.

57
5.4.5 Condiciones asociadas a las acciones

Cada acción de usuario, tiene su propiedad condition. Además debajo de modes se cuenta
con el nodo InsertCondition, UpdateCondition, DeleteCondition, y DisplayCondition.

En todos estos lugares donde se puede escribir una condición, esta condición puede ser
denotada por una expresión booleana, o la invocación a un udp que retorna una variable
de dominio K2BBoolean. Para el segundo caso, dado que no se puede en GeneXus, hacer
If Udp, el pattern genera la invocación al udp en dos partes, primero lo asigna a una
variable temporal y luego hace el If &tempboolean. = K2BBoolean.True.

La forma de trabajo del pattern con condiciones es la siguiente:

• Si la condición se cumple el pattern muestra la imagen.
• Si la condición no se cumple:
o Si la acción es un boton (layout bottom) se pone invisible.
o Si la acción es una imagen.

Si tiene seteada una imagen de deshabilitada se muestra la imagen
de deshabilitada

Si no tiene seteada una imagen de deshabilitada entonces se pone
invisible la acción.
Para las acciones, el valor de la imagen deshabilitada se coloca en la propiedad
disableimage, para los modos esto se encuentra en el archivo de configuración, en
StandardActions/Action/DisabledImage.

58
Además de estas condiciones para todas las acciones se controla si se pueden visualizar
según un procedimiento de seguridad, este procedimiento en caso de dar falso, pone
invisible la acción. El procedimiento de seguridad tiene mayor prioridad sobre las
condiciones esto es si una acción no está permitida por el proc de seguridad pero sí lo
está por la condition, la acción quedará inhabilitada.

5.4.6 Nodo Standard Actions (K2BEntityServices.config)

En esta sección se estuvo referenciando a este nodo. Este nodo se configura todo lo
relativo a una acción standard.

En la raíz del nodo standard actions, se puede configurar la alineación de las acciones
standard top. En caso de poner en layout Left, estas acciones aparecerán a la izquierda.

Este es un ejemplo de cómo quedarían las imágenes a la izquierda.

Otras opciones que se pueden configurar son

59
Caption: Caption del botón en caso de que la acción sea un botón.
Tooltip: Tooltip de la imagen.
Image: Imagen.
DisabledImage: Imagen en caso de que no se cumpla la condición para esa acción.
DefaultMode: Si por defecto se va a generar la acción.

5.4.6.1 Default Mode para Update y Delete.

En muchos casos la propiedad default mode tiene valores distintos a true o false. En los
tabs tabulares por ejemplo se tienen las acciones standards de Update y Delete. Estas
acciones de pronto se quieren deshabilitar solo para cuando están en la grilla, pero no
desde los tabs tabulares. Para tal caso, las acciones stantandard update y delete cuentan en
default mode con los valores OnlyInGrid y OnlyInTabular, para indicar que es sólo válida
en una de estas vistas.

Nota importante: Las propiedades DefaultMode para las acciones standard configurada
a través de modes, esto es acciones standard que invocan a la transacción en la grilla, son
tomadas en cuenta a la hora de aplicación de la instancia al tratar de machear el valor
<deafult> de la instancia con DefaultMode del archivo de configuración. Para el caso de
las acciones update y delete en la vista tabular el Default Mode es tomado en cuenta a la
hora de la generación de la instancia por defecto. Lo mismo va a suceder con los default
mode para las acciones de Print y Excel.
Default Mode para Print y Excel será expicado en la sección reportes pdf y Excel.

5.4.7 Avanzado: Invocación acciones standards

Por defecto las acciones update, delete e insert invocan a la transacción con el modo, y la
PK.
Esta información se obtiene dentro del nodo transaction. El nodo transaction a tomar en
cuenta es en el selection el de la instancia; mientras que en los tabs subordinados se toma
en cuenta el nodo transaction asociado a ese tab.

El nodo transaction indica como se va a invocar la transacción por las acciones standards
especificadas en modes. La variable &Mode indica el modo con que se invoca, este es
sustituído a la hora de generar la acción por TrnMode.Insert, TrnMode.Update o

60
TrnMode.delete. Los siguientes argumenos, se toman de los sucesivos parámetros del
nodo transaction.
Para la acción insert la propiedad que interesa es el NullValue. Por defecto siempre está
en true. Si es seteado en false, el valor del parámetro no es pasado como nulo.Si está
seteado en true se pasa como nulo. En el caso de una transacción de ciudad definida
como llave compuesta :

PaisId*
CiudadId*

Si el país está instanciado, el primer parámetro debería tener NullValue en false, y el

segundo en true.

5.5 Paginado:

En el nodo correspondiente al objeto con gird se encuentran dos propiedades.

La propiedad Page sirve para indicar si va a haber paginado o no, y en caso de haber
paginado, la cantidad de filas que se van a mostrar por página. El valor <unlimited>
indica que no se va a paginar, el valor <default> lee del archivo de configuración; esto es
leído desde Grid/Page. Por defecto la propiedad Page toma el valor de K2BPage.Rows
que es un dominio que viene dentro los objetos básicos del pattern.
Aquí vemos un ejemplo de una grilla con paginado. En este panel se definieron cuatro
registros por página.

La propiedad PageCount indica si se va a invocar desde el pattern a la función que

calcula la cantidad de páginas (Grid.PageCount). Muchas veces si hay muchos registros
el cálculo de esto puede enlentecer la performance por lo que se puede configurar que no
se calcule el page count. El valor <default> es leído del config desde Grid/PageCount.

61
En caso de setearle a dicha propiedad false no aparecerá la cantidad total de páginas
como se muestra en la siguiente figura

Dado que no se sabe cuál es la última página la flecha de Last desaparece. La

deshabilitación de la flecha de siguiente página (Next), se hace de manera heurística, si la
cantidad de registros que se está mostrando es menor que el valor de la propiedad page,
entonces se sabe que no hay más registros y la flecha se deshabilita. En caso contrario
queda habilitada. El caso que se escapa es cuando la cantidad que se muestra es igual a la
cantidad de filas por página, en tal caso no hay forma de determinar si se puede seguir
paginado, o no. Ahí se habilita el botón de next y en caso de que el usuario lo presione
aparecerá la siguiente página con la grilla vacía.

5.6 Propiedades del selection

Algunas propiedades del nodo selection.

IsMain: Permite configurar si el objeto trabajar con es main o no.

Caption: Texto que se va a mostrar en el título del trabajar con.
Description: Texto que se va a mostrar en el título del trabajar con cuando el caption es
vacío. Si tiene un texto se muestra ese texto. Si tiene la propiedad <default> se
visualizará la description del nodo level.

62
Se muestra como título del objeto generado:

63
6 Objecto View:

El view presenta información asociada a un registro.

Muestra en los tabs los datos relacionados.
Es el objeto que se invoca cuando se presiona el link del DescriptionAttribute.
El primer tab que se muestra en el view es un tab plano donde se visualiza información
asociada a la transacción base de la instancia. A este tipo de tab se le da el nombre de tab
tabular.

Por lo general el resto de los tabs son de tipo grid como se muestra en la siguiente figura.

64
El nodo View está compuesto de los siguientes nodos:

• Fixed Data
• Parameters
• Tabs

Los parameters son los parámetros del view que por lo general es la PK de la transacción
base de la instancia.
La fixed data esta formada por atributos fijos, que se muestran siempre
independientemente de cuál sea el tab seleccionado. En este caso la fixed data es el
nombre de Pais.

65
Por defecto la fixed data es generada con el DA de la transacción base de la instancia, y
está configurado para que aparezca en el título del view. Sin embargo el usuario tocando
la instancia puede hacer que este atributo se muestre abajo o colocar más de un atributo
en la fixed data. En la siguiente figura se muestran atributos de la fixed data por debajo
del título del view. La configuración de la distribución de atributos en la fixed data será
vista en la sección noskip.

6.1 Nodo Tabs.

6.1.1 Generación por defecto:

A la hora de generar la instancia por defecto, patterns genera un tab general, y luego un
tab por cada transacción directamente subordinada a la transacción base de la instancia.
También puede generar otros tabs de tipo tabular por cada transacción paralela, si la
propiedad en el archivo de configuración Template/GenerateTabsForParallelTransactions
está configurada en true. Si la transacción es de dos niveles, se genera además un tab con
el segundo nivel y si se configura la propiedadad
Template/GenerateTabsForParallelLevels se genera un tab por cada nivel paralelo.

66
6.1.2 Propiedades de los tabs:

El view es un objeto que tiene un componente que se carga según el tab seleccionado.
Aquí veremos las propiedades de cada uno de estos tabs.

ComponentName: Nombre del web panel Genexus, que va a estar como componente
dentro del tab.
Page, PageCount: Igual que en el selection. Tiene sentido en tabs de tipo grid.
Type: Tipo de tab. Se verá más adelante.
Caption: Nombre que se visualizará en el tab. Por defecto se toma la descripción de la
transacción.
Code: Código que va a tener el tab, la única condición que debe cumplir es que debe ser
único.
Description: Descripción del tab.
Condition: Permite poner una condición para la visualización o no de determinado tab.
En caso de la condición estar en false no se muestra el tab. Se puede poner en la
condition un udp, de la misma forma que se puede hacer en las conditions de las

67
acciones.

6.1.3 Tipos de tabs:

En el ejemplo que estuvimos mostrando, los tabs que se muestran son los siguientes

El primer tab es de type tabular, dado que muestra información plana de un registro y el
segundo de type grid, donde se muestran varios registros de la entidad relacionada.
Existen además otros tipos de tabs. Listaremos aquí todos y explicaremos los restantes.
• Grid
• Tabular
• UserDefined
• DefaultGrid
• ReferencedTab

DefaultGrid: En muchos casos una vez que patterns genera el tab por defecto, se deben
eliminar algunos atributos, modificar descripciones para llegar a lo que se quiere ver en la
grilla. Si un tab es subordinado a muchas transacciones esto debería ser hecho en cada
uno de los tabs. El tipo de tab defaultgrid es una forma que permite mantener de manera
centralizada, los atributos que se desean mostrar.
Al poner type = DefaultGrid, se debe completar la propiedad BaseInstance, que
representa la instancia base de cuyo selection se van a tomar los atributos.

68
Esto funciona de la siguiente manera, el nodo attributes del tab es ignorado y se toma el
nodo attributes del selection de la instancia referenciada.
Existen casos en los que en el selection se muestran atributos que no tiene sentido
mostrarlos en el tab ya que se encuentran instanciados.
Ej:

Supongamos que se tiene la entidad Ciudad. Y supongamos que en el selection de la

ciudad se muestran los siguientes atributos:

CiudadId
CiudadNombre
PaisId
PaisNombre

Supongamos que se está en el tab ciudades de un país. Dado que los datos de PaisId y
PaisNombre ya se encuentra instanciados no es necesario mostrarlos en la grilla ya que
además lo estamos mostrando en la fixed data.
Patterns a la hora de seleccionar que atributos mostrar muestra solamente:
CiudadId
CiudadNombre

La inferencia de que atributos mostrar es la siguiente:

Patterns muestra todos los atributos se la instancia base menos:

• Atributos que aparecen en la fixed data
• Atributos que pertenecen a la PK de la transacción.

Limitación: El selection referenciado, no puede contener variables. Si tiene variables se

desplegará un mensaje de error de consolidación.

UserDefined: Existen casos en el que la información que se desea mostrar, corresponde a

un objeto externo no generado por patterns, o generado por otra instancia de patterns,
para esto, se le puede poner al type UserDefined. En component name se debe poner el
nombre del objeto genexus que será mostrado al seleccionar el tab. El tab será invocado
con la PK de la transacción base de la instancia.
Referenced Tab: Será explicado en la parte Avanzado.

6.2 Avanzado:

6.2.1 Parámetros de los tabs:

69
Cada tab puede tener un nodo parameters. Esto indica la regla parm que va a tener el tab.
El view invoca a cada tab con su nodo parameters, que por defecto es la PK de la
transacción base de la instancia. En la mayoría de los casos, la regla parm del tab es igual
a la del view.
La ausencia de nodo parameteres en el tab indica que toma como parámetros el nodo
parameters del view.
El caso en el que la regla parm de un tab es diferente a la de un view, se da cuando la
relación de subordinación se da a través de subtipos. En este caso dentro del tab aparece
un nodo parameter generado a partir de un subtipo del atributo del view.

6.2.2 User Defined Vs Referenced Tab:

El tab user defined, es invocado con el nodo parameters del view. Existen casos en el que
queremos reutilizar diferentes tabs en varias instancias, donde su regla parm no es
necesariamente ni la PK de la transacción, ni un subtipo de la PK de la transacción, pero
sí su parm consiste en atributos que están instanciados dentro del view. Un ejemplo de
esto puede ser:

FacturaId*
FacturaFecha
ClienteId
ClienteNombre

Supongamos que se cuenta con un tab genérico que muestra información de un cliente, y
se desea mostrar desde el view de facturas. El problema que encontramos si lo ponemos
user defined es que el view va a crear ese componente pasándole como parámetro el
atributo FacturaId, cuando el componente necesita recibir ClienteId.
Para esto en el tab referenced tab, se coloca el nodo parameters y este nodo será
interpretado como la forma en que el view invocará a dicho tab.
Así si se coloca en ese Tab como parámetros ClienteId, el view invocará al tab con ese
atributo.
Tanto en el tab UserDefined como Referenced tab el resto de las propiedades serán
ignoradas.

6.3 Vistas Planas:

Son secciones donde se muestran atributos o variables que no se encuentran adentro de

una grilla.
Existen propiedades comunes para agrupar estos atributos. Antes veremos algún ejemplo
de vistas planas.

70
6.3.1 Tab General:

Muestra información asociada a un registro. En su nodo se pueden mostrar tanto atributos

como variables. Para mostrar variables se debe colocar un & antes del nombre y definir
su propiedad value y domain, o su nombre debe tener el nombre de un atributo. Este
comportamiento es igual a la 5.1.1Mecanismo genérico para la definición de variables:

El tab general además tiene acciones. Las acciones por defecto son las acciones standards
de modificar y eliminar. Y también se generan acciones standards de imprimir reportes
PDF y Excel.
Las acciones Update y Delete son colocadas como botones debajo de los atributos
(Layout Bottom) mientras que las acciones de impresión son colocadas arriba a la
derecha (Top) como se muestra en la siguiente figura.

Layout Top

Layout
Bottom

71
Es posible también definir en los tabs tabulares acciones de usuario de la misma forma
que se hacía en los tabs de tipo grilla. Los Layouts posibles son Top y Bottom. En caso
de colocar una acción top (right) o top(left) será colocada como top. Aquí mostramos un
ejemplo de la misma grilla con diferentes acciones. Las acciones top se muestran como
imágenes, y es posible especificarle su propiedad Target.

Acciones Usuario
Layout = Top

Acción Usuario
Layout = Bottom

6.3.2 Propiedad NoSkip:

La propiedad NoSkip es una propiedad válida para todas las vistas tabulares y permite
agrupar atributos dentro de una pantalla

Esta propiedad es válida para:

• Fixed Data
• Atributos en los tabs de tipo tabular
• Filtros
• Componentes ( esto se verá en avanzado).

Por defecto patterns genera todos los atributos planos en filas diferentes (noskip= false).
La propiedad noskip en true, indica que el atributo permanecerá en la misma línea que el
atributo anterior.

72
A partir de esto Patterns determina los posicionamientos de los atributos y la forma de
generar la tabla.

6.3.3 Forma de generar la tabla:

El objetivo a la hora de generar la tabla con los diferentes atributos es mantener siempre
la alineación de las descripciones y los atributos; esto es que en una misma columna no
haya descripciones y atributos dado que estos tienen diferente alineación y hacen que el
web form quede de forma incorrecta.
El procedimiento para generar el web form es el siguiente:
Dado un atributo:
• NoSkip en false => a la siguiente línea.
• NoSkip en true:
o Tiene Descripción => Se cierra la celda del atributo anterior y se generan
dos celdas, en una se coloca la descripción y en otra se coloca el atributo-
o No tiene descripción => No se cierra la celda del atributo anterior y se
coloca este atributo al lado.
Dado que cada fila puede tener distinto número de columnas, patterns genera la última
celda de una fila, con el colspan restante para que todas las filas posean el mismo tamaño.

Ejemplo:

Atributo Descripción NoSkip

PaisId País False
PaisNombre True
PaisPoblacion Población False
PaisPresidente Presidente False

73
PaisVicePresidente Vice-Presidente True

Resultado:

6.3.4 NoSkip Fixed Data:

Dentro de un view podemos distinguir dos secciones. Una el título del view, y otra debajo
del título del view.

74
 Título del view

Debajo del título del view

Dentro de estas secciones lo que se visualiza es la fixed data. La pregunta que usted se
puede hacer es como se configura para un atributo de la fixed data este en el título del
view o este debajo del título del view.

Pues bien, la respuesta es la siguiente. El nodo fixed data es el único nodo donde la
propiedad noskip en true del primer atributo tiene sentido. Dado que en caso de estar en
true es colocado en el título del view.
En primer lugar se coloca la descripción del view, (propiedad description del nodo) y
luego todos los atributos que esten en la primera fila uno al lado del otro ignorando su
descripción. A partir de la fila siguiente se aplicará el mismo algoritmo del noskip pero
los atributos serán posicionados en la fila de abajo y su descripción será tenida en cuenta.
Acá se muestra un ejemplo de cómo fue generada la sección noskip del view de facturas.

Atributo Descripción NoSkip

FacturaId Id True
FacturaFecha Fecha True
ProveedorId Proveedor False
ProveedorNombre True
FacturaTotal Total False

6.4 Nodo Preview Fixed Data:

75
En Patterns antes de aplicar, es posible visualizar como quedarán agrupados los atributos
que tienen noskip mediante la propiedad preview.

En este caso se levanta una pantalla que permite visualizar como quedará en la pantalla
los atributos de la fixed data.

76
77
7 Reportes

Todos los web panels generados por patterns a excpeción de los prompts tienen reportes
asociados. Estos reportes son de dos tipos: los reportes pdf y excel.
El objetivo de los reportes es mostrar lo mismo que se está mostrando en el web pannel.
Si el web panel que se está mostrando es un objeto con grilla se van a mostrar los
atributos del grid ordenados por el órden seleccionado por el usuario, filtrado por el valor
de los filtros en ese momento.

Supongamos que se tiene el siguiente trabajar con países:

Sus reportes asociados:

78
Si se cambia el orden y se agrega un filtro se mostrará lo siguiente:

79
Los atributos que se muestran son todos los del grid para los reportes Excel, mientras que
en los reportes PDF donde se tiene la limitante del ancho de la página, solo se muestran
los atributos que entran en la hoja.

80
Para los reportes asociados a web pannels tabulares, se muestra toda la información en
filas acorde con la propiedad noskip. En los reportes pdf solo se muestran los atributos
que entran en la fila.
Aquí mostramos un ejemplo de reportes asociados a vistas planas.

7.1 Inclusión de reportes en la instancia:

Para incluir un reporte dentro de una instancia, tal como vimos en el capítulo de las
acciones, se debe en el nodo de patterns correspondiente al web pannel, agregar una
action de nombre Print de Layout Top y una action de nombre Excel con Layout Top,
para los reportes pdf y excel respectivamente.
Para la generación de la instancia por defecto es posible configurar en Patterns en
Standard Actions la propiedad default mode correspondiente a los nodos Print y Excel.
Un valor true indica que los reportes son generados para todas las instancias en todos los
web pannels, en False nunca se generan los reportes, OnlyInSelection?, genera los

81
reportes solo para el nodo selection, OnlyInSelectionAndGridTabs? genera los reportes,
menos para los tabs de tipo tabular.

7.2 Títulos de los reportes:

En los reportes asociados al selection, se muestra como título la descripción del nodo
level. Por esto en las pautas previas se recalca que el valor de esta propiedad se encuentre
en plural.
Para los reportes asociados a un tab de tipo Grid el título es el caption del tab.
Para los reportes de tipo tabular se muestra como título la descripción del view, más la
primera fila de la fixed data (lo mismo que se muestra como título del view). Para los
reportes que están asociados a vistas paralelas, se muestra un subtítulo con el caption del
tab correspondiente a esa vista.

7.3 Reportes Excel:

Se imprimen todos los atributos que se muestran en la grilla en los web pannels de tipo
grid, en las vistas tabulares se muestran todos los atributos en filas según la propiedad
noskip.

7.3.1 XmlWriter Vs ExcelDocument

La implementación por defecto de estos reportes Excel es generando un xml y

permitiendo que ese xml sea abierto por el Excel. Esto puede traer aparejado algunos
problemas con java y ambientes linux en cuanto a los tildes.
Para solucionar esto se puede modificar el archivo de configuración, en
StandardActions/Excel/Generate se puede escoger entre generarlo como XmlWriter o
ExcelDocument. Utilizando el Excel Document los tildes quedarán correctamente
generados en cualquier ambiente, aunque se cuenta con alguna pequeña desventaja.
La primera es que estos archivos se almacenan en el servidor y permanecen ahí, cualquier
persona que conozca la url puede acceder a esa url y visualizar dichos reportes, la
segunda es que las celdas no se agrandan con el tamaño de los datos.
Esto está a estudio por sopote GeneXus.
Aquí vemos el WWPais en un reporte Excel, generado con Excel document.

82
Si se usa xml writter también se puede configurar el look & feel correspondiente a las
celdas. Esto puede ser hecho en el nodo Spredsheetconfiguration. Ahí se puede
configurar el color de las diferentes celdas.

7.4 Reportes PDF:

La diferencia con respecto a los reportes Excel es que los pdf requieren una mayor
configuración, según tipos de fuentes, papel a utilizar, tamaño, etc. Además que los
atributos a mostrar pueden no entrar en la hoja por los que estos se deben recortar.

7.4.1 Atributos que se visualizan:

Por defecto, Patterns selecciona los atributos que se van a mostrar en el orden que se

83
encuentran definidos en el nodo attributes. Aquellos atributos que no entran no son
mostrados. Si esto no es lo que el usuario desea es posible agregar un nodo report para
modificar el comportamiento de patterns por defecto y poder indicar que se muestren
otros atributos. Patterns de toda maneras seleccionará de estos atributos solo los que
entren en la hoja. Para agregar el nodo report y que automáticamente se coloquen los
atributos que entran en la hoja, se cuentra con la opción AddReportAttributes?, mediante
la cual se ingresa un nodo report con los atributos del nodo attributes que entran en el
reporte. Esta ayuda es buena cuando el usuario quiere hacer pocos cambios con respecto
al reporte que viene por defecto.
Si el nodo Report no posee atributos, patterns seguirá tomando como atributos el nodo
attributes.

84
7.4.2 Configuración avanzada:

Es posible en los reportes PDF configurar el tipo de letras, formato del papel, etc. Estas
configuraciones se pueden definir a nivel de config y algunas también a nivel de
instancia. A nivel de Config, la configuración es dentro del nodo Report, a nivel de
instancia es necesario agregar un nodo Report y allí configurar esas propiedades.
Detallaremos las propiedades y si se pueden configurar por instancia mediante el nodo
report y config o solo por config.

• Paper Type: Tamaño del papel. Determina el alto y ancho de la página. Se

despliega en un combo los tamaños de papel más comunes. (instancia y config).

Orientation: Es posible configurar si se quiere el reporte apaisado o no. (instancia y

config).

• LeftImage: Imagen para mostrar en la esquina superior izquierda del reporte.

(instancia y config).
• RightImage: Idem pero a la derecha. (instancia y config).

Vemos aquí un ejemplo de un reporte con imágenes a la izquierda y a la derecha

85
Las siguientes propiedades, permiten seleccionar los fuentes para las diferentes secciones
del reporte. Para la fuente se puede seleccionar su tipo, su tamaño y si es negrita o italica.

• ReportTitleFont: Fuente utilizada para los títulos del reporte. (config)

• ReportSubTitleFont: Fuente utilizada para los subtítulos del reporte. Esta es
tenida en cuenta solo para los tabs correspondiente a transacciones paralelas.
(config)
• HeaderLabelFont: Labels que aparecen en el header del reporte (Fecha, Página,
etc). (config)
• HeaderFieldFont : Fuente correspondiente a los valores de los campos que
aparecen en el header (&Time, &Date, etc). (config)
• TitleFont : Fuente que se utiliza para los títulos correspondiente a los atributos en
las vistas tabulares. (config)
• ColumnTitleFont : Fuente que se utiliza para los títulos de las columnas
correspondiente a los atributos de las vistas de tipo grid. (config)
• FieldFont: Fuente correspondiente a los atributos que se visualizan en el reporte.
(config)
• DscFilterFont: Fuente correspondiente a la descripción de los filtros. (config)
• FieldFilterFont: Fuente correspondiente al valor de los filtros. (config)

86
87
8 Propiedades avanzadas del pattern
K2BEntityServices:

8.1 Instancias

Las instancias, son archivos xml que se encuentran ubicados bajo el directorio templates
de la KB. Estos se pueden agrupar dentro de carpetas.

8.1.1 Atributos

Dentro de las instancias, cuando se menciona un atributo, no se almacena sólo su nombre

sino que también se almacena el id. El id del atributo es un identificador interno que
utiliza GeneXus para los atributos. Patterns, en primera instancia usa el id y accede al
nombre solo cuando el id no existe en la base de conocimiento.
El hecho de referenciar los atributos mediante el id, permite que la instancia sea
actualizada por ejemplo cuando se renombra un atributo. En un escenario donde solo se
guardan los nombres, cada vez que se renombra un atributo habría que recorrer las
instancias y cambiar el nombre a mano.
En el único caso donde no se almacena el id, son en las conditions, así que en caso de
renombrar un atributo que participa dentro de una condition habría que buscar allí su
viejo nombre y modificarlo.

8.1.2 Distribución de instancias

El referenciar los atributos mediante un id, hace inválida esa referencia dentro de otra
KB. Para esto, existe lo que se llama distribución de instancias.
Esto lo que hace es eliminar el id de cada atributo y dejar solamente el nombre. La opción
de distribuir se encuentra parándose en una instancia en el Tab Folder Explorer y ahí con
el botón derecho seleccionar distribute.

88
Para la consolidación de las instancias simplemente lo que hay que hacer es copiar dicha
instancia a la carpeta templates en la KB destino.

8.2 Archivo de configuración (K2BEntityServices.config)

El archivo de configuración permite setear metadata válida para todas las instancias.
En la instalación de patterns, viene con un archivo de configuración por defecto, el cual
puede ser modificado desde el directorio de instalación de patterns o copiado a la KB
para ser modificado desde allí. En este último caso es posible manejar diferentes archivos
de configuración por base de conocimiento.
Patterns a la hora de determinar que archivo de configuración tomar, se fija si existe un
archivo de configuración en la KB, si existe toma ese, sino busca el que se encuentra en
el directorio de instalación de patterns.

El archivo de configuración se modifica desde Tools->Change Pattern Configuration, si

el archivo de configuración no existe en la KB aparece el siguiente diálogo.

Si se selecciona que sí, se crea un archivo de configuración basado en el archivo por

defecto, en la KB. Si se selecciona que no permite editar el archivo de configuración.

89
Si solo se quiere modificar el archivo de configuración por defecto sin la aparición de
este diálogo, esto puede ser hecho a través de Tools->change default pattern
configuration.

8.3 Master Pages

Por defecto pattern genera cada web panel (selection, view, transacción y prompt) con
una master page específica.
La master page puede ser especificada por instancia. Este propiedad se encuentra en el
nodo principal de cada uno de estos objetos. El valor <default> indica que este valor se
va a tomar del archivo de configuración.
Dentro del archivo de configuración hay un nodo master page que permite seleccionar la
master page adecuada para cada uno de estos objetos.

La master page por defecto cuenta con un llamado al IsAuthorized, programa de

seguridad. Se chequea la seguridad por ese objeto y en caso de no estar autorizado
redirecciona a una pantalla de error.
Luego crea el componente header, que es el que se muestra en todos los objetos y además
tiene toda la lógica correspondiente a los recent links.

Estos objetos pueden ser customizados y adaptados a la lógica que el desarrollador desee.
Para por ejemplo agregar un footer, modificar la interfaz del header ,etc.

90
8.4 Manejo de sesión

Por defecto Patterns en el evento start de cada objeto invoca al procedimiento

PK2BGetContext(&Context). Este procedimiento lo que hace es cargar la información de
sesión en una variable de tipo context para que sea accedida dentro de los objetos
generados por patterns. La información que se puede almacenar en esta variable puede
ser el usuario conectado, la empresa con la que se está trabajando, etc. Por defecto, la
variable Context está basado en un SDT de nombre &Context..

Patterns provee además un objeto para setear el context, PK2BSetContext, de dada una
variable de tipo Context la setea en el contexto. Por lo general el programa
PK2BSetContext puede ser utilizada en una pantalla de login para setear en la sesión el
usuario cuando este se loguea.

Es posible por cada aplicación definir un context propio. Se pueden definir los nombres
de los programas de carga y obtención de context en el archivo de configuración.

8.5 Objeto Home

91
Dentro del pattern se puede configurar la generación de un objeto home, que lo que hace
es generar una especie de menú donde en cada opción llama al trabajar con de cada uno
de las instancias. La generación de este objeto se configura en el archivo de
configuración, nodo Template/GenerateHome.

8.6 Objetos básicos

El Pattern K2BEntityServices la primera vez que se aplica sobre una base de

conocimiento, consolida un conjunto de objetos, los cuales se llaman objetos básicos.
Estos objetos se encuentran bajo la carpeta K2BEntityServicesBasicObjects.

Bajo el directorio Components, se encuentra el K2BHeader y las distintas Master Pages.

GridStateSaveAndRestore se encuentran los objetos básicos que se encargan de salvar y
mantener el estado de los filtros.
En Security se encuentra el proc genérico de seguridad PIsAuthorized , y el web panel
NotAuthorized al que al usuario es redireccionado cuando no tiene permisos.
En Session se encuentran los procedimientos genéricos para el seteo de sesión y del
context. En el folder Stack se encuentran todos los objetos relacioneados con el
mantenimiento del stack de ejecución del programa.
En Theme se encuentra el tema de k2b, y en TrnContext se encuentran los
procedimientos para el manejo y salvado del contexto de la transacción.

8.6.1 Customización de objetos básicos

Algunos de estos objetos pueden ser customizados por el desarrollador del pattern, de
forma de adaptarlo a sus necesidades.

92
Dentro de Components, se pueden adaptar las master page y los headers, para colocar el
header que requiera la aplicación.
En Security se puede modificar el procedimiento IsAuthorized para que chequee la
seguridad. Por defecto siempre devuelve K2BBoolen.True.
En Session se pueden modificar los programas PK2BSessionSet y PK2BSessionGet para
que modifiquen la forma en que se guardan los datos de contexto. Por defecto se usa la
web session, pero esto se puede modificar para que se usen cookies o directamente
almacenarla en la base de datos.
En Theme se puede modificar el tema, adaptar el look & feel que viene por defecto en
patterns para que se adapte a la interfaz del cliente.

8.6.2 Recursos

En el directorio correspondiente a patterns se cuenta con una carpeta de nombre

k2bimages. Ahí se almacenan las imágenes del pattern K2BEntityServices. La primera
vez que se aplica el pattern estas imágenes son copiadas al baseimagepath de diseño
(patterns setea el base image path) y si está configurado el modelo de ejecución, lo copia
a ese directorio.

8.6.3 Consolidación objetos básicos

El Pattern la primera vez que se aplica sobre una base de conocimiento consolida los
diferentes objetos básicos, en la KB. Las export de estos objetos básicos se encuentran en
la carpeta K2BEntityServices/Import.
Cada vez que se actualiza una versión del pattern K2BEntityServices algún objeto básico
puede cambiar, y entonces se actualiza su export en ese directorio. Los objetos básicos se
encuentran distribuidos en diferentes xml, dentro del directorio imports, para en caso de
actualización, solo actualizar los xml que se cambiaron. El tema, headar y proc is
Authorized no se consolidarán automáticamente, para que no pise un objeto creado por
un usuario.
En el archivo imports.xml se guarda información sobre los objetos básicos que se van a
consolidar.

93
94
FileName: es el nombre del xml dentro del directorio impots.
Version: Número de versión del objeto.
ObjCheck: Objeto a chequear en caso de que la versión sea 1.

Patterns luego de consolidar los objetos básicos, copia la carpeta imports.xml al

directorio templates de la KB.
Si no existe el imports.xml por cada objeto que va a consolidar verifica la existencia del
objcheck, en caso de no existir consolida el xml, sino no consolida nada.
Si existe el imports.xml lo que hace es compara las versiones, si la versión del import que
está en el directorio de patterns es mayor que el de la KB vuelve a consolidar ese xml.

95
Consolidación forzada de objetos básicos

En la raíz del archivo de configuración, se encuentra con la propiedad

ForceBaseObjectsConsolidation. Seteada esta propiedad en true se fuerza la
consolidación de estos objetos.

8.6.4 Avanzado, crear objetos básicos propios para ser consolidados

Es posible seleccionar otros objetos para que estos se consoliden automáticamente Estos
objetos son desarrollados por el usuario del pattern. Para esto en el archivo de
configuración se puede setear en el nodo OtherImpots,

Donde se puede setear el folder en el que se van a consolidar los objetos y en FileName el
nombre del archivo donde va a estar el xml que hace de Impots.xml.
En dicho folder van a estar ubicados los otros xml que se desea consolidar.

8.7 Organización de objetos en folders.

Posibilidad de dar una organización estructurada a los objetos generados por patterns.
En la forma tradicional, los objetos generados por patterns se guardan en una carpeta (por
defecto generated) indicada en la instancia.
Esta forma se puede modificar yendo al archivo de configuración y modificando el nodo
Object Organization la propiedad Type de Standard a Fólder Organization.
Así se puede establecer una jerarquía de carpetas y el lugar donde van a ser guardados los
objetos. Sobre este nodo es posible agregar :
Fólder, (para continuar con la jerarquía) y Object lugar donde se va a guardar el objeto.
El Type permite seleccionar entre distintos tipos de objetos:

96
Para definir los nombres de los fólders se pueden utilizar los siguientes tags <TrnName>
o <TrnFolder> para referirse al nombre de la transacción o el folder en el que se
encuentra la transacción respectivamente.
Si el fólder que comienza la jearquía no existe, este será creado en la raíz de la kb.
En la siguiente imagen los objetos serán creados en un fólder <TrnName>Generated
ubicado en la carpeta donde se encuentra la transacción.

8.8 Nomeclatura de objetos

Un punto importante es como el pattern determina cuál es el nombre de los objetos que
va a generar. Para esto, se debe ir en el archivo de configuración al nodo Prefix.

Ahí aparece un conjunto de objetos y como se va a generar. El Naming convention

sugerimos utilizar siempre FormatString.

97
Para los objetos View, Selection, Tabular, SubordinatedGrid, Prompt, Report,
ExcelReport, el nombre se toma sustituyendo el tag <Object> por la propiedad name del
nodo level de la instancia.
Para el objeto SubordinatedGrid, <ParentLevelName> es sustituído por el nombre del
nivel padre y <TrnName> por el nombre de la transacción de abajo.

Ej: Tab ciudades de un país. En level name se tiene la propiedad Name (Pais). TrnName
se tiene el nombre de la transacción = Ciudad. El nombre del objeto será PaisCiudadWC
En el subordinated grid es el único caso cuyo nombre aplica a la generación de la
instancia por defecto ya que el nombre se genera en la instancia bajo la propiedad
componetn name del tab. En el resto de los objetos el nombre es calculado a la hora de
aplicar la instancia.

98
9 Propiedades avanzadas de la grilla
Aquí se listará con más detalle el funcionamiento de los objetos con grilla, así como
propiedades avanzadas. El objetivo de estas propiedades avanzadas fue siempre aumentar
la cantidad de objetos que se pueden generar con el Pattern K2BEntityServices para
poder mantener la mayor cantidad de objetos con formato grilla desde el Pattern.

9.1 Manejo de parámetros

El Pattern K2BEntityServices genera en todos los objetos su regla parm basado en el

nodo parameters. La regla parm la genera con variables y para instanciar el atributo de
esa variable agrega una condition att = &att.
Ej:

Conditions:

El selection también puede recibir parámetros. En caso que se quiera recibir una variable
basada en un atributo pero que no se genere la condition, se puede pasar en parámetros la
variable &att, y así el pattern no genera la condición automática.

En los tabs si no se encuentra el nodo parameters se toma como parámetros los

parameters del view.

9.2 Fixed data en el selection

En el pattern K2BEntityServices es posible definir Fixed Data en el selection. La

ubicación de la fixed data es similar que dentro del view. Si el primer atributo tiene
noskip en true este y los de la misma fila son colocados en el cabezal del selection, luego
los atributos hijos son colocados abajo.

Ej: Se tiene un trabajar con facturas que recibe el proveedor como parámetro como se
muestra en la instancia.

99
Coloco la siguiente fixed data para mostrar con los siguientes valores correspondientes a
la propiedad noskip.

Atributo Descripción NoSkip

ProveedorNombre True
ProveedorEstado Estado False
PaisNombre Pais False

El resultado que se obtiene es el mostrado abajo-

En el view se muestra un único registro por lo tanto ya hay registros instanciados, en

cambio en el selection se muestra un conjunto de registros. En tal caso los atributos que
se muestran en la fixed data deben estar en la extendida del conjunto de registros que se
muestran en el selection.
El pattern internamente genera variables por cada atributo y en el evento start genera un
for each donde le setea a cada variable su valor. Se genera una sentencia where en el for
each según los parámetros del selection. Por las dudas que haya más de un registro en el
for each se agrega un exit para quedarse solo con el primer registro.
En este caso el for each que genera el pattern es el siguiente:

100
9.3 Componentes

Es posible dentro de los objetos con grilla la inclusión de determinados componentes.

Estos componentes pueden ser un conjunto de atributos, un web component, o un grid
Freestyle, etc. Las ubicaciones son con respecto a la grilla son encima del grid o debajo
del grid, según se muestra en la siguiente imagen.

Para agregar un componente se para en patterns y se selecciona

101
Allí se pueden asingnar las siguientes propiedades

Layout indica si el componente va a estar ubicado arriba del grid o debajo. Las valores
posibles son top y bottom.
Align indica la alineación del componente esto puede ser center, Left o right. Al valor
<defalult> se le asigna Right para bottom y center para top.

Veremos a continuación las propiedades según el tipo de componente.

9.3.1 Web Component

GXObject indica el nombre del objeto. Hay que poner el nombre completo. En caso del
objeto recibir parámetros es posible parado en el nodo; seleccionar add parameters y ahí
se pueden especificar los parámetros con los que se ve a crear el web component.

102
Patterns le asigna el objeto al componente solo cuando no posee parámetros sino utiliza la
sentencia create en el evento refresh.

9.3.2 Attributes/Variables:

Si se coloca como Type Attributes o FreeStyleGrid es posible agregar atributos o

variables.

Para identificar las variables se coloca un & adelante.

Si se pone type Freestyle grid para que el Freestyle tenga tabla base es importante que se
seleccione un atributo.

Las propiedades que se pueden setear son las mismas que en cualquier vista tabular,
nombre, descripción, visible , no skip y theme class. Para las variables la forma de
definición es la de siempre.
También se puede agregar código que será colcoado a la derecha del símbolo de igual de
la variable. Este código puede ser asignado en el evento start , en el evento refresh o en el
evento load. Esto por ejemplo puede servir para sumar totales de algún valor de una
grilla.

103
Acá por ejemplo se muestra un componente con el total facturado por un proveedor.

9.4 Eventos

Muchas veces existe cierto comportamiento que no es posible lograr utilizando las
propiedades que aparecen en el xml del pattern. En muchos casos se desea traer
información desde un SDT para mostrar en la grilla, definir algún nuevo evento o
subrutina, etc. Para esto el pattern cuenta con la posibilidad que desde el pattern, se pueda
definir código a ser ejecutado en el evento o subrutina que el usuario seleccione.
Esto es realizado usando el nodo events. Para esto parado en cualquier objeto es posible
seleccionar add events

104
Estas son las propiedades que poseen los eventos.
En Type se configura si lo que se va a definir es un evento o una subrutina. Para esto solo
alcanza con modificar el valor de la propiedad type. En name se selecciona en qué evento
se desea agregar el código.
El código puede ser ingresado en algunos de los eventos ya creados por el pattern, esto es
en el Start, Refresh, Load, o [MainGrid.Load] que representa el evento load asociado a la
grilla. El código es agregado al principio y al final según el código se coloque en
BeginCode o EndCode.
En caso de querer definir un evento o subrutina nueva, simplemente alcanza con poner en
Name, el nombre del evento nuevo y en Begin Code o End Code la subrutina.

105
9.5 Reglas

En los objetos con grilla es posible también agregar reglas. Para esto se cuenta con el
nodo rules.

En dicho nodo simplemente se especifican las reglas y listo.

Ahí se pueden agregar todas las reglas que uno desee.

9.6 Variables

Las variables que se visualizan en pantalla son por lo general definidas por el usuario, en
el nodo correspondiente a su visualización. Sin embargo, existen variables que no se

106
encuentran en el web form, pero sí se encuentran por ejemplo en el código de usuario.
Para definir este tipo de variables se cuenta con el nodo variables.

Allí en este nodo se debe colocar el nombre de la variable sin &.

La forma de definir las variables es similar al resto de los nodos donde se definen
variables. La única diferencia es que aquí es posible definir una vaiable de tipo sdt. En la
propiedad SDT se debe colocar el nombre del SDT en el que va a estar definido la
variable.
El value puede ser cualquier expresión a la derecha del igual de la variable que será
ejecutada en el evento start.

9.7 Tabs en los filtros

Esta funcionalidad permite organizar los filtros en grupos, permitiendo de esta manera
ahorrar espacio en pantalla y/o organizarlos de la forma que se quieran utilizar. Dichos
grupos se corresponden a un tab en la página web.

107
Es importante notar que tener los filtros en grupo no implica filtrar solo por los filtros del
tab seleccionado sino que se filtra por todos los filtros en todos los tabs.
Como hijo de los filtros (filter) se tiene los filterAttributes y las conditions. Ahora se
puede agregar un nodo filterTab dentro de filterAttributes, el filterTab mencionado
anteriormente contiene como hijo a los nodos filterAttribute.

En el K2BEntityservices.config se agrega al atributo defaultTabCaption en el nodo Grid,

el valor de dicho atributo se utiliza para el caso en que se tienen tabs y a la vez
filterAtributes que no esten asignados a ningún tab, en ese caso se generara un tab para
dichos atributos con el caption especificado en "defaultTabCaption".

Es bueno notar que cada vez que se selecciona un tab no se va al servidor sino que se
hace en el cliente el pasaje de un tab a otro.
Acá tenemos una captura de pantalla de los tabs.

108
109
9.8 Trucos

9.8.1 Creación de grilla sin tabla base.

1) Poner en el nodo attributes en lugar de atributos variables. Esto se hace en

patterns colocando un & antes del atributo.

2) Escritura del for each de carga de la tabla base: Para esto en el nodo
correspondiente al obejto se debe hacer add events , add event y ahí seleccionar
como evento el [MainGrid].Load. Ahí en EndCode colocar el código de carga de
la grilla. Como sugerencia, escribir primero el código de carga en ese objeto
GeneXus luego copiarlo y pegarlo en patterns en la Evento.

3) Acciones Ingrid: Patterns genera el código link de las acciones con Grid dentro
del evento load. Debido a que es sin tabla base, este código deberá generarse
dentro del foreach. Para esto el último paso es copiar dentro del código generado
por patterns el código correspondiente a la función link de las acciones en el
evento grid.load y colocarlo en la loadCode dentro del for each

9.8.2 Acción que invoca a un evento de usuario.

Dentro del código de los eventos, es posible colocar eventos nuevos definidos por el
usuario. Este evento es asignado a un control de la siguiente manera.
Si se agrega una acción de usuario sin setear el valor de GXobject, se puede hacer que al
cliquear en la imagen asociada a la acción se invoque al evento creando el evento
&actionName.click.

9.8.3 Cambiar acción standard por acción de usuario

Se indica como hacer en patterns para que las acciones update, delete, display, insert, etc
apunten a otros objeto y no a la transacción que es como va por defecto en patterns.

En patterns las acciones standard se definen a través del nodo modes. Estando esta
propiedad en true Patterns por defecto genera código para la invocación de la transacción
en los distintos modos para update, insert y delete, y el llamado al view para el modo
display.
Para hacer que estas acciones apunten a otros objetos se debe hacer lo siguiente:

• Poner en false, el modo que se desea personalizar

110
 • Crear una action, cuya imágen sea igual a la imágen correspondiente al ícono de
la acción.
o En caso de querer personalizar las acciones de Update, Delete, Display,
colocarle a la action Layout InGrid?.
o En caso de querer personalizar la acción de Insert crear una action de
Layout Top(Rigth)
• En GXObject poner el objeto que se desea invocar y en parameters especificarle
los parámetros.

También se puede especificar la acción de Print, para esto a la acción de print generada
por defecto por patterns hay que cambiarle el nombre y en GXObject colocarle el objeto
al que va a invocar y en parameters los parámetros con los que se va invocar.

111
10 Propiedades avanzadas de otros objetos

10.1 Propiedades avanzadas en los views

Dentro de los view es posible definir variables, agregar código dentro de los eventos y
agregar componentes a la izquierda del view.
Una muestra de estos componentes es dada a continuación

10.2 Propiedades avanzadas de los tabs tabulares

Dentro del tab general es posible definir variables de la misma manera que se encuentra
con el nodo variables en los objetos con girlla. En los atributos que se definen en la vista
tabular es posible también agregar variables que serán identificadas mediante un &
adelante.
También es posible agregar eventos y subrutinas.

Conditions
En una vista tabular es posible agregar condiciones. Estas condiciones no están asociadas
a ningún filtro y pueden servir para que por ejemplo se muestre la primera línea de una
factura, orden de compra, etc.. Para esto hay que agregar el nodo filtres para luego
agregar las conditions, pero lo que se coloque en filters no será tenido en cuenta.

112
Componentes:

De la misma manera que en los objetos con grilla es posible especificar componentes
bottom y top dentro de los tabs tabulares. Aquí se muestra un ejemplo de un tab tabular
con componentes top y bottom.

Los únicos componentes permitidos son aquellos que tienen como valor de la propiedad
type =webcomponent.

10.3 Propiedades avanzandas para la generación de la instancia

por defecto
10.3.1 Hidden Attributes

En algunos casos existen atributos en la base de conocimiento que no se desea que el

pattern los coloque en los grids, vista tabulares, etc. Esto puede ser debido a atributos de
auditoría, u otro tipo de atributos. En base a esto patterns permite a la hora de generar la
instancia por defecto, no mostrar atributos que cumplen determinada nomeclatura. En
particular estos atributos los va a generar con la propiedad visible en false.

Esto se realiza a nivel del archivo de configuración. Se debe agregar el Nodo Hidden
Attributes parado en la raíz. Ahí se puede ingresa un nombre, es posible utilizar el tag
<trnName> que será sustituído por el nombre de la transacción a la que se le va a aplicar
el pattern. En NamingConvention se debe utilizar de nomeclatura que debe tener el
atributo que será ocultado por el pattern.

113
En el siguiente caso, se le indica al pattern que en la generación de instancia por defecto
se oculten todos los atributos que comiencen con <TrnName>audit., aquellos que
contengan la palabra User, Last y finalicen con update.

114
11 Integración con WorkFlow
La idea general se basa en reutilizar la misma transacción, sin modificar los parámetros
para que pueda ser invocada independientemente tanto desde workflow como desde
algún otro objeto GeneXus.

Para indicar que una transacción participa en un proceso de WorkFlow?, se debe ir a la

instancia correspondiente a la transacción y dar de alta el WFNode, nodo de WorkFlow?.

Por defecto el nodo aparecerá así:

Las propiedades:

A partir de esta información Patterns generará los stubs de entrada, los stubs de salida, y
un slot en la transacción que en el before complete invoca al slot de salida.

En el WFNode se puede configurar lo siguiente:

Nombre del Stub de entrada , por <default> = <trnName>StubIn

Nombre del Stub de salida , por <default> = <trnName>StubOut?

Los stubs serán generados la primera vez, y no volverán a ser generados por patterns a no
ser que el usuario lo indique a través de las propiedades ForceStubInGeneration,
ForceStubOutGeneration.

11.1 Relevant Data:

En el stub de entrada, se obtiene la forma en que se va a invocar a la transacción. Por

default patterns va a tomar como relevant data el nombre de cada uno de los parámetros
del nodo transaction (sin contar el Mode).

En el stub de entrada patterns genera el siguiente código:

115
En el nodo transaction se tiene en los parámetros SolicitudCmpId?.

Es posible darle otro valor a la relevant data, pudiendo agregar nodos Relevant Data hijos
de WFNode. Allí patterns mapeará uno a uno el nodo relevant data con el nodo
parameters hijo de transaction.

De esta forma invocará el método

&WFProcessInstance.GetApplicationDataByName(“<relevantDataName>“,
&WFAppDataSolicitudCmpId, &WFError)
Notar que patterns agrega las "".

11.2 Slot en la transacción:

Tanto si se tiene generateSlots en true o en false, patterns generará el código que invoca
al Stub de salida. Lo generará la primera vez, luego quedará del lado del usuario, a no ser
que el modo update transaction sea <create default>.

116
11.3 Stub de salida:
Finalmente patterns generará el stub de salida. Tomará como parámetros los atributos que
se encuentran en el nodo transaction y será invocado desde la transacción con esos
parámetros.
El stub de salida a diferencia del de entrada será un proc.

El código generado es el siguiente:

11.4 Importante:
Para que Patterns pueda consolidar automáticamente los stubs se debe setear la propiedad
AllowNonStandardFunctionsOnSaving? en el modelo de diseño.

11.5 Objetos básicos:

Los objetos básicos de WorkFlow? no se consolidan automáticamente, sino que el
usuario deberá consolidarlos a mano.
Para esto, queda un xpz en el directorio Import del Pattern K2BEntityServices
WorkFlowBasicObjects?.xpz.
Es importante primero consolidar los objetos básicos de patterns y luego los objetos de
WorkFlow?. Ya que WorkFlow? agrega un enumerado más al dominio K2BSesItem.

117
12 Seguridad
Existen dos maneras de trabajar con seguridad, dentro del pattern K2BEntityServices.
Una es mediante la invocación a un proc genérico isAuthorized que recibe como
parámetro los nombres de los objetos y otra es utilizar un mecanismo de seguridad
basado en actividades. Explicaremos cada uno de ellos en las siguientes secciones.

12.1 Método IsAuthorized

IsAuthorized es un proc genérico que devuelve true o false según si el usuario está
autorizado a acceder a determinado objeto o realizar determinada acción.
La invocación de este proc a nivel de objeto es realizado dentro de la Master Page
mientras que la invocación a este proc a nivel de acción es realizado en el objeto mismo a
la hora de crear la acción. Si el usuario no le está permitido acceder a determinado objeto,
se redirecciona a un panel HNotAuthorized. Si el usuario no tiene permiso para visualizar
determinada acción la acción será seteada como invisible.
La idea aquí es que el pattern provee la invocación al proc IsAuthorized y el usuario de la
aplicación deberá con esto implementar su propia lógica.
Estudiaremos aquí con qué parámetros es invocado el procedimiento IsAuthorized.

Parámetros IsAuthorized

GxObject:En caso de ser seguridad a nivel de objeto GXObject representa el nombre del
objeto. En caso de ser seguridad a nivel de acción es el objeto al que va a invocar la
acción.
GxSubObjectType y GxSubObj: GXSubObjectType está basado en un dominio. Los
valores que puede tomar son los siguientes:

118
Identifica que valor se pasará en el parámetro GXSubObj.
• Undefined: No hay contexto. Es seguridad a nivel de objeto. El siguiente
parámetro no debe ser tomado en cuenta.
• Tab: Se encuentra dentro de un View. Y se invoca para ver si el tab está
autorizado o no. El siguiente parámetro es el código del tab.
• Action: El contexto es el chequeo de seguridad de una acción. El siguiente
parámetro será el nombre de la acción. Como primer parámetro se pasa el nombre
del objeto que es invocado por la acción.
• Mode: Indica que se está invocando a una acción standard. El siguiente parámetro
va a ser el modo con el que se va a invocar a la transacción.

De esta forma las invocaciones al proc IsAuthorized serán las siguientes:

• Por objeto:
o PIsAuthorized.Call(ContentHolder.Pgmname,
GxSubObjectType.UnDefined, "", &IsAuthorized)
• Por acción
o PIsAuthorized.Call("PMultiRowAction", GxSubObjectType.Action,
"MultiRowButton", &IsAuthorized)
• Por cada uno de los tabs del view
o PIsAuthorized.Call(&Pgmname, GxSubObjectType.Tab,
&Tabs.Item(&Index).Code, &IsAuthorized)
• Por modos en los que se invocan a la transacción dentro del objeto
o PIsAuthorized.Call("TPais", GxSubObjectType.Mode, TrnMode.Insert,
&IsAuthorized)

119
12.2 Seguridad basada en actividades:

La siguiente forma de configurar la seguridad, es mediante la seguridad basada en

actividades. Esta filosofía es obtenida de GXportal y apronta la KB para que la seguridad
sea completamente mantenida por el lado de GXPortal, pero de todas formas siempre el
usuario está en la posibilidad de implementar su propia lógica ya que el pattern lo único
que hace es realizar las invocaciones.

Para poder configurar esta lógica en la raíz de la instancia se cuenta con la propiedad,
AccessControlType. El valor GXPortal, permite configurar la seguridad basada en
actividades. Su valor <default> es tomado del nodo GXPortal/AccessControlType.

El Pattern K2BEntityServices se encarga de manejar el acceso a actividades relacionadas

con operaciones en la transacción base. Estas son:
• Posibilidad de dar de alta un registro. (Insert)
• Posibilidad de actualizar un regitro. (Update)
• Posibilidad de eliminar un regitro.(Delete)
• Posibilidad de visualizar un registro.(Display)
• Posibilidad de visualizar los registros relacionados.
• Posibilidad de ver un conjunto de registros en forma de listado. (List)

El Pattern K2BEntityServices maneja el acceso y la implementación de estas actividades.

De esta forma podría chequear en forma conjunta todas estas actividades.
Para cada actividad, que no está habilitada se inhabilitaría no solo el objeto que
implementa esa actividad sino que también se inhabilita el control que desea acceder a
ese objeto.

120
Dentro de las actividades es posible distinguir entre dos tipos de actividades.
Actividades de mantenimiento y actividades de visualización.
Las actividades de mantenimiento (Maintenance) están compuestas por:
• Insert
• Update
• Delete

Las actividades de visualización (Visualization) estarán compuestas por:

• Display
• List

Para esto el pattern automáticamente define una jerarquía de actividades, donde agrupa
las actividades según si son de Visualization o Maintenance.

Se define que, se tiene permisos para acceder a una actividad si:

• Se tiene permisos para acceder a la actividad padre o a esa actividad.
En caso de no tener permisos:
• En el objeto que representa la actividad se redirecciona a un objeto que informa
sobre el error.
• En los llamadores se inhabilitan los controles que intentan acceder a esa actividad.

121
12.2.1 Nombramiento de actividades

Cada actividad que se realiza en el pattern, tiene su nombre que es generado

automáticamente por el pattern K2BEntityServices. Generalmente el nombre es generado
mediante <TrnName><tipoactividad>. Siendo tipo actividad el tipo que puede ser:
Insert
Update
Delete
Maintenance
Display
List
Visualization

De esta manera el Pattern K2BEntityServices realiza las invocaciones.

Muchas veces se desea poder agrupar un conjunto de actividades en una sola. Por
ejemplo a uno le gustaría tener un permiso solo para poder actualizar estructuras
geogríaficas. O sea si uno puede dar de alta Paises, también podría dar de alta
Departamentos, Ciudades, etc. Lo mismo puede pasar con el alta de Productos. Si uno
pude dar de alta Productos, pueda dar de alta también tipos de productos, clases de
productos, unidades de ese producto, etc.

Para esto es necesario que a la hora de generar el nombre de la actividad no dependa del
nombre de la transacción sino de algo más global que abarque un conjunto de
transacciones.

Para esto surgió dentro del Pattern K2BEntityServices el concepto de Entidad o Business
Entity (entidad de negocios). Y en realidad el nombramiento de una actividad es el
siguiente: <EntityName><tipoActividad>.
Para poder incluir una transacción dentro de una entidad se puede agregar a la instancia el
nodo Businee Entity y poner el nombre de la entidad.

122
De esta manera las actividades se van a crear en función de ese nombre de entidad.
Determinación de nombre de la entidad:
• Si la instancia no tiene Business Entity el nombre de la entidad es el nombre de la
transacción base de la instancia.
• Si tiene Business entity el nombre de la entidad es el nombre del Business Entity.

Nombramiento de actividades: En realidad el nombramiento de actividad no es fijo.

Esto puede ser configurado en el archivo de configuración. En el nodo
GXPortal/ActivitiesNaming se pone el nombre de las actividades.

<TrnName> será sustituido por el nombre de la entidad.

123
12.2.2 Invocación a programas de seguridad

El programa de seguridad que debe ser implementado y que tiene la lógica de integración
con GXPortal, es el IsAuthorizedGXPortalSDT. Este recibe como parámetro un sdt que
representa una lista de actividades y devuelve por cada una, si se está autorizada o no.
El nombre del sdt es K2BGXPortalActivityList y estos son sus campos.

ActivityName es el nombre de la actividad.

FatherActivityName es el nombre de la actividad Padre.
Si el usuario está autorizado a realizar la actividad o la padre el campo IsAuthorized
asociado al item de la colección deberá ser colocado en K2BBoolean.True.
En ProgramName se puede colocar el nombre de un objeto GeneXus que representa esa
actividad, pero en el caso de control de seguridad es a modo informativo y no es
utilizado.

El otro programa que es invocado desde Patterns es el programa

IsAuthorizeGXPortalSingle en lugar de recibir un sdt, recibe dos actividades la hija y la
padre, y retorna verdadero o falso si el usuario está autorizado a realizar alguna de esas
actividades.
El procedimiento simplemente lo que hace es cargar el sdt con un elemento e invocar al
IsAuthorizedGXPortalSDT.

La invocación a estos programas es realiza desde el Pattern de la siguiente forma:

En la transacción seguridad a nivel de objeto:

124
En los trabajar con:

125
12.2.3 Seguridad en los tabs subordinados

La seguridad dentro de los tabs subordinados es completamente diferente al del resto de

los objetos de la instancia, dado que las operaciones sobre los tabs subordinados
pertenecen a otra entidad. De esta forma, Patterns a la hora de generar la seguridad en
estos tabs, a partir del nodo transaction, obtiene el nombre de la transacción y busca una
instancia con ese nombre. Si la encuentra y está configurada con seguridad en GXPortal,
entonces obtiene el nombre de la entidad asociada a esa transacción y chequea la
seguridad con los nombres de actividades obtenidos; si no invoca al proc IsAuthorized.

12.2.4 Alta de actividades

Dado que el Pattern K2BEntityServices genera el nombre de las actividades, este debería
encargarse también de darlas de alta. Para este caso el pattern crea un procedimiento
genérico que da de altas las actividades. Por defecto se comunica con las APIs de
GXPortal y da de alta todas las actividades en el backend para que luego el usuario pueda
asignarles permisos.
Este procedimiento genérico se llama gxportalloadactivitylist y es invocado por el web
panel hgxportalloadactivitylist.

126
Este procedimiento recorre todas las instancias y da de alta las actividades generadas en
ellas. La generación de este procedimiento es configurable

Si se coloca GenerateLoadActiviesListProc en true, el pattern genera este procedimiento.

Este programa es configurable para que de de alta solo las actividades hijas, solo las
padres o ambas. Esto se configura en LoadActivitiesConfiguration.

12.2.5 Otra Configuración

En el nodo GXPortal se cuenta también con la propiedad CheckSecurityForBC.

Esto es si la lógica de seguridad en GXPortal será chequeada cuando el objeto es
invocado como busiesscomponent. En caso de estar en true se genera un slot en las
transacciones que se fija que el usuario este autorizado a la hora de hacer alguna
operación con el bc.

GXPortal/ControlAccess/EntityList es un booleano. Indica si se va a chequear la

seguridad para la actividad de listado, en false solo se chequea la seguridad para las
operaciones de mantenimiento de la transacción y acceso al view. No se chequea la
seguridad a nivel de objeto para los trabajar con, los reportes y tabs subordinados

12.2.6 Integración con GXPortal

Como se menciono anteriormente toda esta lógica es completamente integrable con

GXPortal.

127
Para esto es imprescindible tener:
• Versión de GXPortal 4.2.1.4 o superior
• Tener en la KB consolidados los objetos de integración de aplicaciones con
GXPortal.
• Tener en la KB los objetos de integración K2BEntityServices GXPortal.

Los objetos básicos de integración de K2BEntiytServices con GXPortal son provistos por
el Pattern K2BEntityServices.

Los procedimientos para el alta de actividades se encuentra con el web panel

GXPortalLoadActivityListTest, este proc es el que se encarga de dar de alta las
actividades bajo el botón add activities.
Para ejecutar este proc se debe estar logueado en el frontend de gxportal en la aplicación
que se deben dar de alta las actividades.
En las versiones anteriores el usuario debía poner a mano el nombre del GAmRepId, y
GamProId, actualmente esto se calcula de forma automática.
Dado que este web panel es nuevo, se cuenta con un test, que retorna el GamProId, y
GamRepId, y da de alta las actividades.
Ante cualquier problema se cuenta con el web panel de la versión anterior,
hgxportalloadactivitylist que básicamente lo que hace es dar de alta estas actividades
pidiendo que el usuario ingrese el GAmRepId, y GamProId.

Importante: El procedimiento que da de altas las actividades si la actividad ya existe

simplemente hace un update de la misma.

Sobre este punto, como obtener estos datos y como configurar esta seguridad en
versiones anteriores de GXPortal, ver la siguiente sección.

12.2.7 Obtención de GAMPRoEnvId, GamProId

Es importante que todos los módulos que forman parte de la aplicación (módulo es menú
de aplicación en el portal) esten bajo el mismo directorio virtual. En las últimas versiones
de GXPortal esto ya es así. Sino, se deberá modificar en la tabla GamProEnv los
directorios virtuales de esos módulos y hacerlos que apunten al mismo dir virtual. Sobre
este tema consultar con el equipo de GXPortal para mejores instrucciones.
Para obtener el GAmProEnvId y GamProId esto se calcula obteniendo el menor
GAmProId, dentro de la aplicación, esto se obtiene ejecutando en el MySQL la sentencia
SELECT g.gamproenvid, g.gamproid FROM gamproenv g where
g.GAMProEnvSrvVirDir = "<virtualdir>" order by g.gamproid;
El primer registro que cumple esta condición es el que se tiene que dar de alta.

128
12.2.8 Permisos backend GXPortal
Para esto se debe ir al backend y para cada rol asignarle los permisos sobre las
actividades que se desee que el rol tenga permisos.

129
130
131
Cualquier consutla sobre este último punto sugerimos consultar al equipo de GXPortal.

132