Desarrollando desde la trinchera.

 Cuando estamos monitoreando aplicaciones distribuidas (en varias webapps o en varios nodos) es util tener centralizado el manejo de los logs de errores, de forma de poder ver en un unico lugar todos los errores que esta dando la aplicación. Esto es particularmente neceario cuando tenemos parte de nuestra aplicacion instalada de forma serverless.  Para hacer mas facil la identificacion de las causas de los problemas, lo que he visto que funciona bien, es mandar los ERRORS (y FATAL) y agregar a los mismos el Call Stack.  Para lograrlo, alcanza con agregar  %stacktrace{level} y cambiar level por el numero de niveles de la pila de llamada que quiero que muestre el log.  Por ejemplo, hay que cambiar el log.config, en la linea         <layout  type="log4net.Layout.PatternLayout">            <conversionPattern  value="%d{ISO8601} [%t] %-5p %c - %m   %stacktrace{10} %n"/>         </layout> De esta forma, cada vez que haga Log.Error('Se produjo un erro

 GeneXus utiliza log4net/log4j para generar el log tanto de las bibliotecas internas de Genexus como para el log de usuario.  Estas bibliotecas de log, son sumamente poderosas y permiten hacer un registro detallado de la actividad realizada en nuestra aplicación.  Para un proyecto especifico, necesitamos el registro del usuario y un identificador de la sesion en el log, de tal forma de poder filtrar luego por la actividad de un usuario especifico.  Vos a mostrar como lo resolví para .NET pero sirve también para java (aunque no lo probé).  Primero hice un procedure para definir una propiedad de log4net, con el código: SetLog4NetProperty //Log4NetPropertyKey and Log4NetPropertyValue son VarChar(100) CSHARP    log4net.ThreadContext.Properties[  [!&Log4NetPropertyKey!]  ] = [!&Log4NetPropertyValue!]; Luego del Login en la aplicación hago: SetLog4NetProperty('GAMUser',&GAMUser.Name) y en los archivos de configuración del log (log.config y log.console.

 Acompañando la tendencia de la industria, en la comunidad GeneXus estamos pasando de tener aplicaciones monolíticas de una sola KB, a aplicaciones de multiplex KB.  No hablo solo de microservicios, que pueden ser uno de los casos aca contemplados (*), sino de algo un poco mas general de tener varias KB que conforme una solución.  Como todo en esta vida, cada cambio trae ventajas y también tiene algunos inconvenientes que es bueno tener en cuenta.  Las ventajas de tener todo en una KB monolítica: Todo en una misma base de datos con integridad transaccional.  Los cambios se reflejan en todos los programas  Es mas facil de instalar La comunicación entre objetos es mas rapida Que cambia cuando se tiene multiples KB?  El deploy es bastante mas complejo y tambien es mas complicada la comunicación entre las diversas KB.  Como GeneXus hoy esta enfocado a aplicaciones mono-kb, se necesitan algunas herramientas que aun no están disponibles entre las standard de GeneXus.  Por ejemplo: Cambiar pr

Quienes tienen aplicaciones GeneXus generadas con .NET Framework, deberán migrarlas a .NET Core. Esta forma de decirlo, es usando la nomenclatura vieja de Microsoft, pues ahora deberia decirse que hay que pasarse a .NET (a secas).  Las nuevas versiones de .NET traen como ventaja la de ser mas liviano su consumo en ejecución y la de poder ejecutar en Linux y en Windows.  Quienes programamos con GeneXus tenemos el camino un poco mas fácil que el resto pero igual hay que hacer un trabajo lindo de migración del generador .NET Framework al generador .NET.  Esto es indispensable, pues entiendo que el generador .NET Framework no va a tener mejoras en el futuro y todos los cambios se realizaran únicamente en el generador .NET.  Como toda migración, va a traer diferentes dolores de cabeza.  Por ejemplo, tengo el siguiente proyecto.  KB Mediana, generada con .NET Framework.  Utilizar PDFTools para concatenar archivos PDF (no funciona aun en .NET Core) Necesita usar Azure Queues para realizar un

GeneXus 17 introdujo el objeto API . Considero que va a tener un rol importante en el desarrollo de aplicaciones de los próximos años.  En un par de charlas brindadas por diferentes empresas, he visto que lo presentan como un objeto que "agrega una capa de servicios REST a nuestra aplicación" . Si bien esta es una de las funcionalidades del objeto API es una simplificación que sirve para que se entienda la utilidad, pero no me parece que sea una buena definición.  El objeto API, lo que hace es definir una interfaz de los métodos para que puedan ser usados por el resto de la aplicación o por aplicaciones externas.  En el objeto API, yo distingo dos partes bien diferenciadas. Por un lado, tenemos la lista de métodos/servicios expuestos, con sus parámetros de entrada, parámetros de salida y todo lo necesario para lograr procesar los parámetros de entrada y devolver la salida esperada.  Esta parte es la que tiene el verdadero conocimiento y es la que va a perdurar mas en el tiemp