GeneXus Server

GeneXus Server es un producto diseñado para facilitar el trabajo en equipo.

Permite que el conocimiento del negocio esté centralizado y que el trabajo de los integrantes del equipo de
desarrollo esté constantemente integrado, aún si sus integrantes se encuentran en diferentes puntos
geográficos

Tener una KB central administrada por GeneXus Server permite que cualquier desarrollador autorizado, pueda
enviar y recibir modificaciones desde su propìo lugar de trabajo.

Durante el proceso de desarrollo de software se hace necesaria la interacción entre los desarrolladores.
Pero esta interacción no es permanente. Muchas veces sucede que un desarrollador necesita aislarse para
comprender o corregir cierta funcionalidad. Luego de finalizado ese proceso debe hacer públicos sus cambios y
a la vez debe tomar cuenta de los cambios que realizaron otros desarrolladores. Y entonces el ciclo vuelve a
repetirse.

Es para facilitar la implementación de dicho ciclo que GeneXus Server provee un entorno de desarrollo aislado
y servicios de comunicación.
Cada desarrollador trabaja sobre su propia copia de la KB (aislada), que a su vez está linkeada a una copia
centralizada de la misma KB administrada por GeneXus Server (servicio de comunicación)

405
 Características generales

Definición Es un producto diseñado para centralizar la KB y facilitar

el trabajo en equipo, aún cuando sus integrantes se encuentren en
diferentes puntos geográficos.

• Ambiente de desarrollo aislado

• Servicio de comunicación

Cada desarrollador trabaja sobre su propia copia de la KB, que está

conectada a una copia centralizada de la misma KB administrada por
GXserver.

Usando GXserver cada desarrollador tiene una KB personal y sus ventajas (performance, status de la KB
conocido sin cambios producidos por modificaciones de otros desarrolladores, etc) y a su vez la solución
completa está siendo construida en el servidor.

A su vez se tienen otras ventajas:

Agregar un desarrollador es simplemente "enrolarlo" al servidor, el status de la solución es bien conocido y
fácilmente accesible, existen servicios RSS que permiten que no solo los desarrolladores involucrados en el
proyecto reciban la información del mismo sino cualquiera que tenga acceso a dichos servicios, etc.

406
Cuando comienza un proyecto un desarrollador crea la KB y la envía al server desde la opción Send KB to
server.

El resto del equipo de desarrollo, realiza la operación New Knowledge Base from server para quedar
conectados con el server y poder comenzar a trabajar.

Aquí vemos solamente 2 desarrolladores pero la idea es que sean equipos desde 1 desarrollador, hasta
equipos de 10, 20 o 30 desarrolladores los que lo usen.

407
 Envío de una Knowledge Base
Send Knowledge Base to Server Operación que se utiliza para
publicar en el server una KB local.

• GxTechnical
• Local

Luego de ser “enviada”, la KB queda disponible

para que otro usuario se conecte a ella.

La KB es ahora servida por la instancia del Gxserver seleccionada, y de esta forma otros usuarios podrán
conectarse a ella.

Además, es importante observar que a partir de este momento la KB local estará linkeada a la KB que se
encuentra en el server. Esto significa que el desarrollador podrá formar parte de un ambiente de trabajo en
equipo, actualizando y enviando sus cambios.

408
 Conexión a una Knowledge Base
Knowledge Base from Server Es la primera operación que el
desarrollador debe completar para suscribirse a una KB hosteada en
un servidor GeneXus.

GXserver URL

Seleccionar:
• Knowledge Base
• Versión de desarrollo
en dicha KB
La KB creada será una
copia exacta de la KB en
el server.

La KB creada será una copia fiel de la KB hosteada por el server.

Luego de finalizado este proceso la conexión con el server finaliza, y el desarrollador podrá trabajar off-line (no
conectado).

409
 Knowledge Manager / Team
Development
Provee el mecanismo para interactuar con una instancia de GXserver.

Opciones:
• Commit To Server
• Update From Server
• What’s New?
• Security

A través de este diálogo se puede interactuar con una instancia del GXserver.

Las acciones posibles a realizar son las siguientes:

• Commit To Server: Oeración para modificar la KB hosteada.

• Update From Server: Operación para recibir los cambios que otros desarrolladores realizaron
sobre la KB hosteada.
• What’s New?: Permite visualizar los commits que se realizaron desde la última actualización.
• Security: Permite definir/chequear la conexión con el server, indicando forma de autenticación,
usuario y contraseña.

410
COMMIT

411
411
 Envío de modificaciones
Commit to Server Es la operación utilizada para actualizar la KB
hosteada en el server.

Se debe agregar un
comentario indicando el
significado de los cambios.
Commit parcial
Selección de
objetos a enviar

Para ver el
conjunto de Para enviar al server las
objetos que propiedades de la KB
sufrieron que sufrieron cambios.
cambios.

Cada desarrollador trabaja sobre una copia personal de la KB (no se requiere conexión alguna y no hay
interacción en esa instancia entre los desarrolladores). Cuando el desarrollador decide que alguna
funcionalidad está completa y quiere compartirla (agregarla a la solución completa) hace el correspondiente
"commit" de dichas modificaciones.

Cuando un desarrollador ejecuta una operación de "commit" los cambios hechos a su KB personal (objetos
modificados, removidos o agregados) son enviados al server. En el server este conocimiento es consolidado
con el existente y se le da "feedback" al desarrollador que está ejecutando la operación.

El envío de las modificaciones puede ser parcial. No es necesario enviar siempre todas las modificaciones
realizadas sino que se pueden seleccionar los objetos a enviar (commit parcial).

Cuando se realiza una operación de commit, se debe agregar un comentario. Este comentario pasará a formar
parte del log en el server.

El botón Recent Comments despliega una ventana con los últimos comentarios ingresados.

412
 Envío de modificaciones
Commit to Server Es la operación utilizada para actualizar la KB
hosteada en el server.

Ignored Objects
Muchas veces sucede que un desarrollador tiene en su KB local objetos de prueba o que aún no han sido
finalizados y testeados. En estos casos no es deseable que dichos objetos se visualicen dentro de la lista de
objetos a ser enviados al server (commit), y por lo tanto se deben enviar a la lista de objetos a ser ignorados en
las operaciones de commit.

Para enviar un objetos a la lista de objetos ignorados, alcanza con hacer click con el botón derecho del mouse
sobre el objeto (desde la solapa Ready for Commit), y seleccionar “Add to ignore on Commit list”.

Una vez que el objeto está terminado y listo para ser enviado al server (commit), se debe eliminar de la lista de
objetos ignorados.

Para esto, alcanza con hacer click con el botón derecho del mouse sobre el objeto (desde la solapa Ignored
Objects), y seleccionar “Remove from Ignore on Commit list”.

413
UPDATE

414
 Recepción de modificaciones
Update from Server Es la operación que se debe ejecutar cada vez
que se desea recibir los cambios que otros desarrolladores realizaron
sobre la KB hosteada.

Para actualizar
también las
propiedades que
cambiaron.

Muestra las nuevas Recibe todas las

definiciones modificaciones en
la KB local.

La operación de "update" es de algún modo la contraparte de la operación de "commit". Aplica a la KB personal

del desarrollador que la está ejecutando, todos los cambios realizados por otros desarrolladores en la KB del
servidor, dándole feedback al desarrollador del resultado de dicha operación.

415
 Revert de objetos
Posibilidad de deshacer todas las modificaciones realizadas a un objeto
desde la última sincronización exitosa con el server.

La operación Revert, permite deshacer todos los cambios realizados sobre un objeto desde la última
sincronización exitosa con el server.
En definitiva, es hacer que un objeto que aparece en la lista Ready for Commit, deje de estarlo.

Esta opción aparece disponible haciendo click con el botón derecho del mouse sobre un objeto desde la lista
Ready for Commit.

Se setea como activa (SetAsActive) la versión correspondiente, sin que se pierda nada de la historia del objeto.

416
 Integración de los cambios

Dos desarrolladores trabajando sobre la misma KB, parten del mismo estado, solo con las TRNs de Clientes,
Facturas y Compañia.

Eventualmente pueden estar trabajando desde sus casas y hasta desconectados, ya que no se requiere
conexión, salvo cuando tengan que integrar sus cambios.

Los 2 parten de la KB AjaxSampleDemo, que tiene solamente la TRN de Client, Invoice y Company.

Cada uno comienza a trabajar en sus objetos:

• A Mary le toca la opción de crear paises y ciudades

• A Diego le toca la parte de productos

Una vez que cada uno termina su parte, desde la opción Knowledge manager / Team development, en la
ventana de commit ven los cambios que deben enviar a GXserver para integrar el conocimiento.

De esa forma realizan el commit y envian sus objetos al server.

Luego si quisieran quedar actualizados con lo que el otro desarrollador envió al server, pueden hacer update.
Mary puede hacer update para obtener los cambios de Diego (TRN Productos).

Si vamos al server es posible ver como quedó integrado todo en la misma KB.

417
 Merge

COMMIT

COMMIT

Veamos cómo enviar los cambios al server, y cuál es el comportamiento cuando dos usuarios modifican el
mismo objeto.

Ejemplo:
Ambos usuarios parten de la misma TRN Company:

- Diego le agrega 2 atributos: CompanyAddress y CompanyPhone.

- Mary le agrega CountryId y CountryName
- Diego hace commit, y se envían sus cambios al server
- Mary hace commit, y aparece una advertencia porque no tiene la última versión de la TRN (ya que Diego la
modificó), así que debe sincronizarse primero

418
 Merge

UPDATE
COMMIT

Merge

- Cuando Mary se sincroniza, automáticamente se realiza un Merge con los cambios que vienen del server y
los cambios que ellla había hecho en la TRN.
- Por lo tanto obtiene una versión con todos los cambios integrados.
- Ahora sí puede enviarlos al server para integrar todos los cambios en la KB

En este ejemplo cada usuario modificó la misma TRN, pero diferentes atributos.

¿Cuál sería el comportamiento si se modifica el mismo atributo?

419
 Se puede volver a la anterior…

Por ej, si ambos usuarios modificaron el atributo CompanyAddress, al momento de realizar la operación de
update, Mary recibirá un mensaje indicando que dicho atributo fue modificado y será sobreescrito por el que se
encuentra en el server.

Podrá ver con detalle cuál fue el cambio que se realizó en el atributo, y en caso de decidir mantener sus
propios cambios podrá consultar las revisiones del atributo y volver a la versión que tenía su propio cambio.

Ningún cambio se pierde y en todo momento se puede decidir cuál es la versión correcta de los objetos y qué
es lo que se quiere enviar al server.

420
 ¿Qué hay de nuevo en el Server?
What’s New? Permite visualizar los commits que se han realizado
desde la última actualización.

Se puede recurrir a esta sección cada vez que se desea saber los cambios que han sido enviados al server
(commits) desde la última actualización.

421
 Visualizador de KBs

Una vez realizados los cambios, es posible ver directamente en Gxserver como quedó finalmente la KB con
todos los cambios integrados.

Esto se realiza desde el Visualizador de KBs.

Al tratarse de una aplicación Web, lo único que necesita es un browser para poder ser utilizada, sin la
necesidad de tener licencias GX.
Por ejemplo, la podría usar el jefe del proyecto desde un hotel, o mostrarles a algunos empresarios como se va
avanzando con el proyecto.

Esto permite ver el estado de la KB, todos los objetos, cuáles fueron los últimos cambios, ver la documentación
asociada a la KB, e inclusive modificar la documentación desde ahí mismo.

También se puede ver la actividad de la KB, los últimos cambios.

Es posible extender las funcionalidades de GXserver, a través del mismo mecanismo de extensibilidad de
GeneXus.

422
Desde este Visualizador se podrá, entre otras cosas:

• Tener información general y gráfica de la KB (cantidad de objetos, objetos nos refernciados, etc)

•Tener una visión total de la KB: Podrá consultar todos los objetos (estructura, forms, reglas, eventos, variables),
propiedades, etc.

• Editar la documentación (Main Document): Cuando posteriormente el desarrollador realice una operación de
update, tendrá dicha documentación actualizada en la copia local de su KB.

• Tener un listado con las revisiones.

• Consultar configuraciones: Extensiones, User Controls (inclusive agregar user controls), Patterns, Indexer
Monitor.

• Consultar el status de la licencia de GeneXus Server: Cantidad de días restantes, ingreso de autorización, etc.

• Eliminar una KB.

423
 Ciclo de Vida de la KB

Otra cosa que permite el visualizador de KBs es llevar el ciclo de vida de la KB, definiendo allí las versiones
que se van necesitando.

En esta pantalla se ve la línea principal de desarrollo. Las versiones congeladas representan liberaciones del
producto, y a su vez líneas paralelas de desarrollo (por ejemplo para corregir errores).

De esta forma, al realizar la operación Create KB from server, se van a ver todas las versiones que hay en ella,
y se podrá elegir sobre cuál hacer dicho create.

Cada KB de GeneXus quedará conectada a una versión del server.

424
 Seguridad

GeneXus Server se instala por defecto sin habilitar los seteos de seguridad.
Para habilitarlos se deberá marcar la casilla de verificación “Secure Instance” durante el proceso de instalación.
De esta forma, el server pedirá identificación cada vez que se intente conectar a él.

Cuando se tiene una instancia segura del server, será necesario tener un certificado SSL ya que la
comunicación entre GeneXus y el server se realiza por HTTPS.

Por defecto existen dos métodos de autenticación:

• Local: El usuario por defecto es “admin”, password “admin123”. En el tab Security de GeneXus Server es
posible modificar este usuario, agregar nuevos usuarios y definir roles y permisos.
• Gxtechnical

Luego se puede definir la autorización. Esto se logra definiendo usuarios y autorizándolos sobre las distintas
KBs. Se pueden definir usuarios a nivel de todo Gxserver o a nivel de KB.

Finalmente, desde GX se utilizará la seguridad al realizar las operaciones Send KB to Server, Create KB from
Server, y para todas las acciones: commit, update.

425
 Seguridad: Roles y Permisos

Permisos
Roles:
Permisos a nivel
a nivel del
de la KB
Server
¾ View
¾ ¾ Admin
ManageSecurity
¾ Update
¾ ¾ KB Admin
ManageUserControls
¾ Commit
¾ ¾ KB User
ManageExtensibility
ViewDocumentation
¾ Server Guest
¾ ManagePatterns
¾
¾ EditDocumentation
¾ Publish
¾ ManageSecurity
¾ ManageVersions
¾ Delete

En las instancias de seguridad de GXserver es posible definir usuarios, roles y permisos.

Cada server tiene un rol por defecto. Los usuarios que no tienen ningún rol asignado, toman dicho rol por
defecto.
Algunos roles pueden ser definidos durante el proceso de instalación del server, pero también es posible definir
luego nuevos roles.
Cada usuario puede tener diferentes roles, y a su vez, cada rol puede tener varios permisos. Hay permisos que
aplican a todo el server, y otros que aplican a una KB específica.

Permisos sobre el server:

• ManageSecurity: Permite adinistrar permisos y roles de todos los usuarios.
• ManageUserControls: Permite instalar y desinstalar User Controls.
• ManageExtensibility: Permite instalar y desinstalar Extensiones.
• ManagePatterns: Permite instalar y desinstalar Patterns.
• Publish: Permite enviar una KB al Server. Al usuario que realiza esta operación se le asigna el rol KBAdmin.

Permisos sobre una KB:

• View: Permite visualizar la KB.
• Update: Permite realizar un Checkout (CreateKBfromServer), y obtener actualizaciones de la KB.
• Commit: Permite enviar modificaciones al server (operación Commit).
• ViewDocumentation: Permite ver la documentación de la KB ustilizando la interfaz web.
• EditDocumentation: Permite editar la documentación de la KB utilizando la interfaz web.
• ManageSecurity: Permite administrar roles y permisos de todos los usuarios de la KB.
• ManageVersions: Permite adinistrar versiones de la KB utilizando la interfaz web.
• Delete: Permite eliminar la KB utilizando la interfaz web (no la elimina físicamente sino que la elimina del
catálogo de KBs publicadas).

426
 Seguridad: Roles y Permisos
Por defecto…

Rol Admin: RolRol

KB Server
User: Guest:
Admin:
9 Todos los permisos 9 Server
9 habilitados,
Server Publish
Publish
tanto a nivel del server como de la KB.
9 KB View
9 KB Update
9 KB Commit
9 KB ViewDocumentation
9 KB EditDocumentation
9 KB ManageSecurity
9 KB ManageVersions
9 KB Delete

Por defecto, los cada rol tiene los siguiente permisos habilitados:

• Admin: Todos los permisos habilitados tanto a nivel del server como de la KB.
• KB Admin: Tiene habilitados los permisos Server Publish, KB View, KB Update, KB Commit, KB
ViewDocumentation, KB EditDocumentation, KB ManageSecurity, KB ManageVersions, KB Delete.
• KB User: Tiene habilitados los permisos Server Publish, KB View, KB Update, KB Commit, KB
ViewDocumentation, KB EditDocumentation.
• Server Guest: Tiene habilitado solamente el permiso Server Publish.

427
 Disconnect from Server
Operación para desconectar una KB local del server.

Nuevamente queda habilitada la operación

Send Knowledge Base to Server en el
menú File.

Para desconectar una KB local de un server, se deberá ejecutar la operación Disconnect from Server.

Desde la vista Preferences, al editar las propiedades de la KB, se encontrará la opción Disconnect from Server.
Esto hace que dicho usuario desconecte su KB locar del server y pueda publicarla en otro server.

Al confirmarse el mensaje, automáticamente vuelve a quedar habilitada la operación Send Knowledge Base to
Server desde el menú File. La KB que se desconecta NO se puede volver a reconectar, pero sí se puede
enviar nuevamente al server.

428
 Eliminación de una KB

Se elimina la KB del server.

Para eliminar una KB del server bastará con deslizar el mouse sobre su nombre y aparecerá la opción
Remove.

Esta operación no elimina físicamente la KB sino que solamente la borra del catálogo de KBs publicadas en el
server.

429