Eliminar Styles de KB en GeneXus X.

En versiones anteriores de GeneXus, existian los objetos Styles que servían para uniformizar workpanels, webpanes y transacciones. Se definia la estetica en un solo objeto y la misma se replicaba en los objetos que los usaban. Eran útiles pero a partir de la version X los mismos no existen mas.

Si realizamos una migración de GeneXus 9.0 (o anteriores) a la X, los objetos convertidos mantienen una referencia a los Styles, pero como no existen como objetos, dicha referencia queda apuntando a objetos que  se almacenan en la "carpeta" TO BE DEFINED.

En general, joroban bastante poco, pero cuando se quieren subir objetos con dichas referencias al GXServer, dan problemas, pues el GeneXus Server no maneja los objetos Styles.

Si se quiere eliminar dicha referencia, se debe hacer:

1) Distribuir todos los objetos que usen Styles en la GeneXus X.
2) Descomprimir el xpz generado en 1) y salvar el xml.
3) En dicho XML, eliminar el texto:

<Property><Name>ObjStyle</Name><Value>497c0353-2904-4b7e-8711-d0ca41ac4460-ObjectsStyles_TTrnSEliminar</Value></Property>

donde el texto en rojo depende del nombre del style, y el identificador interno.
4) Volver a consolidar los objetos.

De esta forma, se eliminan todos los rastros de los styles en la KB.

Crónica de un poblema "divertido"

Tenemos funcionando varios wikis (www.gxwiki.com) todos con configuraciones/versiones parecidas. C#/SQL server y C#/Oracle.

En la DNA , tenemos un Wiki Interno y otro Wiki Externo. Cuando se da por aprobado un procedimiento en el wiki interno, el mismo se publica en el wiki externo a traves de web services.

Los mismos venian funcionando sin problemas, desde hace varios meses,  pero los usuarios nos plantearon que se habia empezado a "quedar congelado" en varias oportunidades.

Hicimos un TRACE para ver donde se estaba poniendo lento y en el mismo vimos, al querer visualizar una pagina

16:50:54,187 [12] DEBUG GxConnectionCache - SetAvailableCommand stmt:

  SELECT PageUsageDay, PageUsageCount, PageId FROM wikiproc.PageUsage

  WHERE PageId = :PageId AND PageUsageDay = :PageUsageDay ,c.opened:0=0

16:50:54,187 [12] DEBUG GxConnection - DecOpenHandles, OpenHandles after '1'

16:50:54,187 [12] DEBUG GxConnectionManager - GxConnectionManager.DecOpenHandles

   handle '783', datasource 'Default', openhandles 1

16:50:54,187 [12] DEBUG GxConnection - Start Monitor.Exit 59118305

16:50:54,187 [12] DEBUG GxConnection - End Monitor.Exit 59118305    executingCursors:1

16:50:54,187 [12] DEBUG Indexer - Indexer Enqueue waiting...

16:51:10,745 [12] DEBUG GxCommand - Start GxCommand.Close idatareader

16:51:10,745 [12] DEBUG GxDataReader - Close GxDataReader, open:True

16:51:10,745 [12] DEBUG GxConnectionCache - SetAvailableCommand stmt:

   SELECT PageUsageDay, PageUsageCount, PageId FROM wikiproc.PageUsage

   WHERE PageId = :PageId AND PageUsageDay = :PageUsageDay

   FOR UPDATE OF PageUsageCount NOWAIT,c.opened:0=0

16:51:10,745 [12] DEBUG GxConnection - DecOpenHandles, OpenHandles after '0'

16:51:10,745 [12] DEBUG GxConnectionManager - GxConnectionManager.DecOpenHandles

    handle '783', datasource 'Default', openhandles 0

16:51:10,745 [12] DEBUG GxConnection - Start Monitor.Exit 59118305

Estaba demorando 16 segundos en indexar algo. Lo raro es que no se estaba salvando la pagina y lo único que estaba haciendo es registrar el acceso a la pagina, para poder tener luego estadísticas de cuales son las paginas mas leídas.

Revisando con mas detalle, vimos que la actualización se hacia con un Business Component, pero que no hacia referencia al indice o al Full Text Search para nada.

Seguimos revisando y encontramos que la propiedad SEARCHEABLE, que habilita el Full Text Search en la aplicacion estaba en TRUE.  Esto hace que todos los BC graben en el indice de Lucene, cuando se salva.

Revisando un poco la historia del problema, vimos que habíamos cambiado dicha propiedad, solamente para poder identificar en el web.config cual era la linea que hacia referencia a la posición del Lucene Index, pues la empresa que administra los Web server nos había pedido que los cambiáramos de lugar.

Teniamos que cambiar esto y ponerle (cambiar el .. por .)
 <add key="LUCENE_INDEX_DIRECTORY" value="..\LuceneIndex" />

Luego, de hacer el cambio, el mismo no se deshizo (ahí estuvo la causa del problema).

Haciendo un resumen

1) Nos piden que cambiemos el directorio LuceneIndex de lugar.
2) Se cambia la propiedad de Seacheable a nivel del Ambiente, para generar el web.config con la entrada
3) Cambiar el la ubicacion del indice Lucene
4) NO VOLVER LA PROPIEDAD SEARCHEABLE a FALSE (acá esta el problema).
5) Regenerar algunas transacciones  (que no cambiaron)
6) Instalar dichos objetos (se hace varios días después, pues como nada habia cambiado, no se instalaron enseguida).
7) Se empieza a tener problema con el wiki, cuando mas de una persona trabaja en el mismo.

Que conclusión sacamos de esto?
La mas obvia es que las propiedades a nivel de ambiente, muchas veces pueden generar grandes cambios de comportamiento, aunque no se cambie nada a nivel de objetos. Hay que tener mucho cuidado con ellas.
Seria importante poder tener la historia de las mismas y también quien las cambia de forma de poder auditarla al igual que cualquier otro objeto de la KB.
La programacion basada en modelos (como los usados con GeneXus) tiene la potencia de adaptarse a diversos ambientes cambiando propiedades, pero como toda cosa con mucha potencia, debe ser usada con mucho cuidado.  Como dice Spider Manel hombre araña:
"With great power comes great responsibility."

Funcionalidades que me gustaría agregar al KBDoctor (continuación)

Search&Replace

Poder poner un texto a buscar y otro a sustituir y cambiarlo en todos los objetos.
El cambio puede ser en el código, en las pantallas, en las propiedades.
Seria opcional buscar con el Indice que GeneXus ya posee, o que recorra todos los objetos, los distribuya y si el texto esta en dicho objeto, lo modifique y vuelva a consolidarlo.

Seria muy util, para muchas situaciones, por ejemplo para eliminar el &Planilla.UseAutomation, que no se porque motivo el Search de Genexus no lo encuentra.

Funcionalidades que me gustaría agregarle al KBDoctor.

Hay un conjunto de funcionalidades que me gustaría agregarle al KBdoctor y dado el ritmo de trabajo que preveo para este año no voy a poder encarar.

TRNCleaner.

Toma una transacción que no esta siendo usada (solo se usa para crear la tabla) y le saca todas las reglas, pantalla, documentación. Opcionalmente puede eliminar también formulas no redundantes o atributos que no pertenezcan a las tablas básicas de la transacción. También debería marcarla como no generable, para que no jorobe mas por un tiempo.

ThemeCleaner.

Dado un tema, borrar todas las clases no referenciadas por ningún objeto de la KB, tomando en cuenta la jerarquía lógica.

ThemeFixer.

Recorrer todos los objetos WEB y corregir todos aquellos controles que tengan clases que no existan en el tema asignado, poniéndole la clase por defecto para dicho control.

SDTFixer.

Dado un SDT, generar un proc que define una variable basado en dicho SDT, y lo genera forzado para todos los ambientes del modelo. Luego borra el procedimiento.

ObjectState.

Al especificar cada objeto, si el mismo tiene errores o warnings, almacenarlos en listas con los codigos de errores, de forma que sea facil saber cuantos objetos tienen un warning determinado y poder corrergirlo, sin tener que hacer un build all.

ObjectNavigation.

Es importante poder ver la navegación de un objeto, de forma rápida. Para esto, se podría agregar una parte a todos los objetos especificables y guardar en ella, la ultima navegación (o navegaciones si esta en mas de un ambiente).

BuildEnvironment.

Muchas veces nos interesa regenerar todo un ambiente pero no hacer un build all que demora horas. Poder largar una regeneración de todos los objetos que perteneces a un determinado ambiente.

ForceAttDelete.

Tengo un atributo y quiero borrarlo, porque no se debe usar mas. Si el atributo esta siendo usado en mas de un lugar, es bastante engorroso. Me gustaría poder cambiar todos los objetos que tengan variables basadas en dicho atributo y que la cambie por variables basadas en el tipo de datos del atributo.
Si hay índices con dicho atributo, debería eliminarlo del mismo.
Si esta en la estructura de alguna transacción y en los formularios, también debería eliminarlo. En el código y en las reglas, es un poco mas difícil, pues no tenemos un parser del código que permita su manipulación en forma fácil y se podría dejar para hacerlo manualmente.
Por otro lado hay que hacerle muchas mejoras, pues con el paso del tiempo algunas funcionalidades han dejado de funcionar correctamente y por otro lado se han implementando funcionalidades adicionales que podrian aprovecharse mejor desde el KBDoctor.
Como dije antes, no creo que vaya a dedicarle muchas energias a esto, y comento mis ideas por si alguien quiere tomarlas e implementar alguna.

ForceTheme. 

Recuperar el Force Theme que habia en el Genexus 9.0, que recorre todos los controles de las pantallas web, y les asigna la clase por defecto a cada uno. Es util, para cuando traemos objetos desarrollados en otros sitemas con otros temas.

PiensoPienso: Cómo implementar semáforos en GeneXus?

Se tiene una aplicación que se ejecuta en muchas computadoras diferentes sobre la misma base de datos y comparten el file system.

Hay un determinado proceso que por su consumo no puedo permitir mas que tres ejecuciones simultaneas del mismo pues la performance de  toda la aplicación se degrada hasta niveles no aceptables. 

Dicho proceso, puede tener cortes o caídas que hagan que no termine en forma correcta. 

Cuales son las posibles implementaciones con GeneXus para lograr un máximo de tres ejecuciones simultaneas?

Se valorarán las que maximicen la concurrencia y no provoquen bloqueos.

Para los que quieran les dejo el link de wikipedia sobre el tema y otro sobre mutex.