Ing. Juan Marcelo Bustamante Lamas

Presentación del tema: "Ing. Juan Marcelo Bustamante Lamas"— Transcripción de la presentación:

1 Ing. Juan Marcelo Bustamante Lamas jmbl@puntoexe.com.uy
Casos de Éxito Ing. Juan Marcelo Bustamante Lamas Buenos días, mi nombre es Ing. Juan Marcelo Bustamante. Soy director de la empresa PuntoExe Consultores.

2 Nuestra Empresa Conocemos GeneXus desde su versión 3.3
Comenzamos el trabajo en Web con GeneXus desde 2002 En el 2006 comenzamos a brindar soporte de migraciones de aplicaciones Win a Web y creamos nuestro producto PXTools. Tenemos Presencia en 8 países de America Superamos las 120 licencias otorgadas de PXTools.

3 2003 2006 2007 2008 2009 2010 2011 En esta primera charla recorreremos por orden cronológico algunas de las actividades que nuestra empresa ha tenido y los retos y desafíos que nos hemos encontrado a lo largo de éste período. En particular

4 Epiway 2003 Comenzaremos en el año 2003.
Desde el 2000 nuestra empresa decidió emprender un desarrollo de una herramienta llamada Epiway para el desarrollo de sitios web orientados principalmente al eCommerce. En aquel entonces las comunicaciones con internet no eran tan comunes como en la actualidad. Se utilizaba el teléfono y las conexiones eran lentas. Entonces se decidió que el desarrollo y el mantenimiento del sitio debía desarrollarse en modalidad Off-Line, con procesos de sinchronización al conectarse por internet. En el 2003 las comunicaciones habían mejorado y decidimos darle un cambio para permitir al propietario del sitio poder realizar mantenimiento del sitio web directamente On-Line. Para ello tuvimos que evaluar y desarrollar un Backoffice completamente Web. Esto no era nada mas ni nada menos que una “Aplicación Web”.

5 Backoffice Web Para el desarrollo del Backoffice fue necesario elaborar un conjunto de APIs que nos permitiera aprovechar al máximo lo que se iba desarrollando y por lo tanto desarrollar programación encapsulada. Tuvimos que diseñar cómo queríamos la estética de este Backoffice y fuimos muy pretenciososen cuanto a la calidad de lo que queríamos alcanzar. El resultado fue muy bueno y para la época habíamos alcanzado un nivel de calidad de la aplicación muy alto. Tal es así que aún hoy continuamos teniendo clientes muy conformes con este desarrollo. Ya en aquel entonces estabamos soportando: TreeViewer WorkWith con selector de línea. Paging Status. Tabs en transacciones. Interacción con el FCK Editor (un editor de html WYSIWYG).

6 2003 2006 INSIS – GEOMunicipal En el año 2006 decidimos comenzar a brindar servicios de migración de aplicaciones Win a Web ya que habíamos adquirido mucha experiencia en el desarrollo de aplicaciones Web. En esta búsqueda encontramos a la empresa Insis que tenía necesidad de realizar esta migración. Cuando nos reunimo con la empresa nos encontramos con una determinada situación y necesidad…

7 Situación y Necesidad Cuenta con progrmadores Win.
Poco conocimiento de la nueva plataforma. Intención de que post migración haya autonomía en el mantenimiento de la aplicación. Proceso de migración requerido en breve plazo. La empresa, es conocida en Uruguay y contaba con gran cantidad de programadores con conocimiento Win, pero no contaba con casi ningún programador con conocimientos en el desarrollo Web. Lo que se pretendía es que se hiciera el trabajo colaborativamente para el proceso de migración y luego ellos quedarían a cargo de la aplicación para su posterior mantenimiento. La otra necesidad es que el proceso de migración debía hacerse en un período muy corto de tiempo par el tamaño de la aplicación que se quería migrar.

8 Filosofía de la Migración a Web
Comenzó la tecnología pattern con GXPattern y GeneXus 9. Decidimos utilizar esta tecnología. Teníamos que modificar los generadores porque No era suficiente para lo que debíamos desarrollar. La programación declarativa era fácilmente adaptada por los programadores Win. Si nos manteníamos en la instancia lográbamos una buena productividad. Fue por esta situación y necesidad que debíamos pensar muy bien como íbamos a realizar la migración. En ese entonces comenzaba la versión de GeneXus 9 y Artech había lanzado su nueva herramienta GXPattern. Yo la había estudiado y encontramos que la tecnología ya estaba madura para comenzar a trabajar en ella. Lo que estaba claro era que hera necesario modificar los generadores porque: No era suficiente para lo que debíamos desarrollar. La programación declarativa era fácilmente adaptada por los programadores Win. Si nos manteníamos en la instancia lográbamos una buena productividad.

9 Patrón PXWorkWith El primer patrón que comenzamos a adaptar fue el WorkWith de GeneXus.

10 Patrón PXWorkWith Una de las principales necesidades fue que debíamos permitir diseñar el Form de las Transacciones con características similares al Form Win. Por lo que ya necesitábamos implementar Tabs en Transacciones desde aquella época. No solo eso sino que necesitabamos incorporar todas las funcionalidades que tuviera dicha aplicación con el objetivo de mantener el concepto de dinamismo sin tener que modificar el objeto generado. Esta es una de los grandes paradigmas que implementamos y que lo explicaremos en la próxima charla.

11 Patrón PXWorkWith Características Destacadas:
Manejo de RecentLink similar a aplicación Win. Form en transacciones. Tabs en transacciones. Scroll en Grilla. Tabs en Filtros. Load sin Tabla Base. Force Grid Load. Potenciar Acciones: Soportar todo lo que se puede llegar a programar en un evento. Links a ventanas Popups. Validación de las Acciones. Confirms El desarrollo que hicimos sobre nuestro producto Epiway terminó siendo la base para las adaptaciones iniciales del pattern WorkWith. De las características más destacadas que logramos en ese entonces: Soporte de RecentLink similar al comportamiento de una aplicación Win. Form en transacciones. Tabs en transacciones Scroll en Grilla. Potenciar Acciones.

12 Patrón PXWorkWith El resultado que logramos fue el siguiente.

13 Patrón PXParameterRequest
El segundo patrón que implementamos fue el que llamamos Parameter Request.

14 Patrón PXParameterRequest
Tipicamente resuelve todas aquellas pantallas que solicitan datos en un Form Tabular para luego invocar a un Reporte, Procedumiento o WorkPanel. Es por eso el nombre del patrón.

15 Patrón PXParameterRequest
Características Destacadas: Form Sección para validad condiciones de validación del Form independiente de la acción a ejecutar. Misma potencia que en Acciones del PXWorkWith El desarrollo que hicimos sobre nuestro producto Epiway terminó siendo la base para las adaptaciones iniciales del pattern WorkWith. De las características más destacadas que logramos en ese entonces: Soporte de RecentLink similar al comportamiento de una aplicación Win. Form en transacciones. Tabs en transacciones Scroll en Grilla. Potenciar Acciones.

16 Patrón PXParameterRequest
El resultado lo podemos ver con éstas imágenes.

17 2003 2006 2007 GLM - Seguros La siguiente fecha que generó un impacto trascendentan en nuestro proceso de migración fue en 2007 con el desarrollo de un módulo del sistema de Seguros de la empresa GLM. Ya habíamos realizado previamente desarrollos para la empresa GLM pero este módulo nos implicó mucho trabajo sobre el pattern. El módulo que se requirió migrar fue la parte de consultas de un sistema de Seguros para un Banco de Artentina.

18 Situación y Necesidad Módulo de consulta de Pólizas.
Pantallas muy complejas Existencia de múltiples grillas. Interacción entre las distinas grillas Módulo de ingreso de Pólizas. Proceso muy guiado y variable en función de la información que se iba ingresando. Interacción de multiples interfaces gráficas en una lógica procedural. Este módulo tenía dos grandes áreas: El área de consultas de pólizas. Este módulo contenía gran cantidad de pantallas complejas en donde en muy pocas mantallas debía poder verse información de una Póliza ingresada. Cada una de esas pantallas contenían múltiples grillas o en algunos casos había de interacción entre lo seleeccionado de una grilla con los resultados de otra grilla. La ótra área era el ingreso de pólizas. En este cáso el proceso de alta de póliza era una interacción entre distintas pantallas (WorkPanels y Transacciones) y este era comandado por procedimientos que tomaban acciones de invocación a distinas pantallas en funcion de lo ingresado previamente. Ambos casos resultaron de un reto para poder soportarlo en la platafoma Web sin cambiar dramáticamente la forma de presentar la información.

19 Patrón PXComposer El primer patrón que comenzamos a adaptar fue el WorkWith de GeneXus.

20 Patrón PXComposer Podían existir distintas formas de resolver este problema. Uno era agregar más potencia al pattern PXWorkWith como para soportar todos estos casos pero vimos que no era viable porque complicaría el pattern de tal manera que creemos sería dificil de entender. Por lo tanto decidimos que la forma de resolver esto era componiendo la pantalla

21 Patrón PXComposer Características Destacadas: Armado de Secciones
Soporte de invocación como Componentes Soporte de invocación como Embedded Pages Misma potencia que en Acciones del PXWorkWith Estas fueron los requerimientos básicos para impementar este pattern.

22 Patrón PXComposer El resultado lo podemos ver con éstas imágenes.

23 Preludios del Patrón PXFlowController
El área de edición de pólizas era compleja por dos motivos: Contenía pantallas (principalmente Transacciones) complejas. La interacción entre las pantallas estaban comandadas por procedimientos que hacía la tarea de determinar la interacción de las pantallas en función de lo que se iba ingresando.

24 Preludio del Patrón PXFlowController
WP WP WP WP WP WP T T T T El diagrama de interacción de pantallas era similar a éste. En este proyecto la interacción entre las distinas interfaces gráficas era comandado a través de un procedimiento que nosotros lo llamamos “Controlador”. Este procedimiento es el que comanda las llamadas que son condicionadas en función de la información que se va ingresando en las propias interfaces gráficas. WP

25 Preludio del Patrón PXFlowController
WP T T P WP T Para entender mejor la interacción mostramos acá un caso de ejemplo de invocación. Todo comienza por el procedimiento que comienza llamando a la transacción inicial y de esta se pueden bifurcar a distintas transacciones en función del tipo de póliza ingresada. Luego se puede pasar a un WorkPanel que realizará la tarea de trabajar con los detalles de la pólixa interactuando con una tranzacción para el ingreso de dicho detalle. Finalmente al terminar el ingreso del detalle el controlador invoca a un WorkPanel de Detalle de lo ingresado para confirmar finalmente el ingreso de la Póliza, WP

26 Preludio del Patrón PXFlowController
¿Cómo resolvemos esta lógica en Web? Reingeniería de la aplicación. Implementar el diálogo Modal en Web. ¿Qué se desarrolló? APIs. Plantilla basada en un WebPanel Implementa una máquina de Estados. El estado es la identificación de la línea del controlador. Para resolver este problema hay dos soluciones posibles: Hacer reingeniería del sistema para afrontar las invocaciones a la interfaces de forma distinta. Implementar el diálogo Modal en Web. Nuestra empresa se decidió por esta segunda opción para resolver este problema. La ventaja era que el proceso no cambiaba su lógica original. La desventaja era ver como resolver el problema. En esta fecha lo que se desarrolló fue: Un set de APIs para poder interactuar con el Recent Link y de esa manera saber nombres de los objetos Invocadores e Invocados. Saber si se está en una pantalla por invocación o retorno, etc. Se diseño una plantilla que definía la estructura principal de un Controlador de Flujo. Es una máquina de estados en donde la forma más facil de saber el estado era el número de línea del controlador que se estaba migrando.

27 Ejemplo 1 TClientes.Call(TrnMode.Update ,&CliNro ) 2 Do 'Cargo Nombre Cliente' 3 &CountDirecciones = 0 4 For Each 5 Where CliNro = &CliNro 6 Defined By CDrNro 7 &CountDirecciones += 1 8 EndFor 9 If &CountDirecciones > 0 10 &Msg = "¿Desea Actualizar las Direcciones de " + CliNom.Trim() + "?" 11 Confirm(&Msg) 12 If Confirmed() 13 For Each 14 Where CliNro = &CliNro 15 TCliDir.Call(TrnMode.Update ,&CliNro ,CDrNro ) 16 EndFor 17 EndIf 18 EndIf 19 Do 'Verifico Contactos‘ 20 A modo de ejemplo aquí estamos viendo una lógica procedural en donde se está invocando a una Transacción y luego se define código debajo de la invocación. El proceso de pasaje a la plantilla consistía en determinar las líneas que realizaban invocación a interfaces y eso determinaba la separación de los bloques de código.

28 Ejemplo 1 TClientes.Call(TrnMode.Update ,&CliNro )
2 Do 'Cargo Nombre Cliente' 3 &CountDirecciones = 0 4 For Each 5 Where CliNro = &CliNro 6 Defined By CDrNro 7 &CountDirecciones += 1 8 EndFor 9 If &CountDirecciones > 0 10 &Msg = "¿Desea Actualizar las Direcciones de " + CliNom.Trim() + "?" 11 Confirm(&Msg) 12 If Confirmed() For Each Where CliNro = &CliNro TCliDir.Call(TrnMode.Update ,&CliNro ,CDrNro ) 16 EndFor 17 EndIf 18 EndIf 19 Do 'Verifico Contactos‘ 20 Estos bloques se introducían en la plantilla y las invocaciones a las interfaces se realizaba con cierta metodología. Podemos decir entonces que esta metodología resultó el preludio del desarrollo del pattern de controlador de flujo.

29 2003 2006 2007 2008 INSIS – ERP & VyT En 2008 la empresa Insis decidió pasar el resto de su KB de ERP a Web y en ese momento decidió que este trabajo lo harían internamente con colaboración nuestra como apoyo a dicho proceso.

30 Situación y Necesidad Necesidad de realizar una reingeniería. Objetivo
Migrar el ERP a Web. Adaptar ciertas partes que requerirán mayor flexibilidad para llevar el sistema a otros Mercados. Implementación de OAV potente. En este caso ternían ideas frescas y querían aprovechar el proceso para hacer reingeniería de algunos módulos. Fue en ese entonces que nos llamaron y me pidieron si podíamos desarrollar una versión de OAV más potente de lo que estaba disponible. Nosotros ya habíamos incursionado en la tecnología OAV en Epiway para el armado de Formularios dinámicos y evaluamos con ellos algunas funcionalidades que deseaban tener.

31 PXOAV Características: Soporte de Transacción intermedia.
Flexibilidad en Controles de Edición. Soporte de Integridad Referencial. Definición de Atributos como Entidad Fuerte. Personalización de la validación. Fórmulas (Data Type Expression) Fórmulas Condicionadas.

32 PXOAV Usos del Pattern:
Mayor rapidez para definir atributos en run-time. No requiere impacto en la base de datos. No se definen atributos que no aportan a la funcionalidad del sistema. Utilización como parte del sistema. Los atributos son predominantemente informativos. Tienen influencia minoritariamente en el sistema. Utilización para afectar lógica del sistema. Incorporarlos como parametrización del sistema. Su contenido afecta el comportamiento de la aplicación.

33 Patrón PXOAV Ejemplo El resultado lo podemos ver con éstas imágenes.

34 Swedish Match - SalesPro
2003 2006 2007 2008 2009 2010 Swedish Match - SalesPro Entre 2010 y 2011 se estuvo trabajando para la empresa Swedish Match en un desarrollo para un sistema de gestión de ventas.

35 Situación y Necesidad Análisis de soluciones existentes (Base de Datos) Complejidad en la programación Programación no GeneXus. Personalización Segmentación en Exportación Procesos post Importación Interoperabilidad entre distintas Bases de datos Los puntos de ventas eran notebook con posibilidad de convertirse en tabletas y uno de los problemas que se tenía era la falta de conectividad en algunos puntos de Estados Unidos lo que impedía hacer una aplicación On-Line. La solución que se buscó fue realizar una aplicación Web Local a la tableta pero se necesitaba resolver la forma de enviar y recibir los datos entre la tableta y el servidor central. Para este caso se podían buscar soluciones ya implementadas y en este caso se necesitaba realizar procesos de personalización de la información principalmente en dos sentidos: Segmentación de registros al momento de exportar la información a los dispositivos. Realizar procesamiento local una vez llegada la información de los dispositivos. Además las soluciones por lo general brindan soluciones para una misma plataforma de Base de datos pero no entre distintas plataformas.

36 PXSynchronization Características:
Permite personalizar los procesos de exportación para realizar una correcta segmentación. Permite personalizar los procesos de importación. Genera en forma automática la estructura de datos (SDT) Realiza todos los controles de integridad para importar información consistente. Interacción con Transacciones BusinessComponent. Genera Logs en forma automática de la importación. Brinda en forma preprogramada la visualización del Log para la plataforma Web.

37 Marke & Crédito de la Casa
2003 2006 2007 2008 2009 2010 2011 Marke & Crédito de la Casa En el 2011 se decidió el desarrollo del patrón PXFlowController por necesidad de dos empresas importantes: Marke: empresa mexicana orientada a la venta por catálogo. Crédito de la Casa: financiera uruguaya dedicada al préstamo personal.

38 Situación y Necesidad Funcionalidad de Alta de funcionarios.
Interacción con múltiples intercaces. Control de Cierre de Ventana. Migraciónde KB de Marke Uso abundante del diálogo Modal. Aplicativo. WorkFlow. Complejidad en el Salvado y recuperación de variables del controlador. Uso de invocaciones a interfaces dentro de procesos de iteración. Para la empresa Crédito de la Casa la necesidad que nos habían planteado es tener máximo control del proceso de alta de funcionarios de la empresa. El proceso de alta es grande y debe pasar un unas cuantas transacciones para realizar dicho proceso. La necesidad era que no haya posibilidad de que el usuario pueda cerrar la ventana y adicionalmente realizar ciertos controles para permitir pasar a la siguiente interfaz. Por el otro lado estábamos en pleno proceso de migración del ERP de la empresa Marke con una KB de aproximadamente 4000 objetos y nos encontra con un uso abundante del dialogo modal. Esto claramente requería el uso de la plantilla que ya habíamos desarrollado pero se nos presentaba problemas de control de las variables ya que eso debíamos realizarlo en forma manual y si por alguna razón no salvábamos alguna de las variables generaba comportamientos incorrectos en la ejecución del sistema que era complejo de descubrir. Por otro lado nos encontramos también con muchas invocaciones a interfaces gráficas dentro de procesos de iteración lo cual ya estaba contemplado pero la implementación era compleja.

39 PXFlowController Características:
Programación orientada al desarrollo de Bloqueses de Líneas. Manejo de estado basado en el concepto de número de línea. Soporte de subrutinas con invocación a interfaces gráficas. Control de cierre de ventana. Salvado y recuperación automática de las variables declaradas. Soporte de iteración con invocación a interfaces gráficas. Soporte de invocación a reportes con Output device location en Client. Estas son las características principales de nuestro patrón de control de Flujo.

40 En resumen

41 Patrones Soportados PXWorkWith PXParameterRequest PXComposer PXOAV
PXSynchronization PXFlowController El resultado lo podemos ver con éstas imágenes.

42 User Controls y Extensions
PXTools Password Quality Manager PXTools Scroll Line Extensions Licenser Web Installer C# El resultado lo podemos ver con éstas imágenes.

43 Módulos Predefinidos PXMenus PXAudit PXSecurity PXSendMail
PXSystemParameters PXProcessStatusMonitor PXBatchPrint El resultado lo podemos ver con éstas imágenes.

44 ¿Preguntas? En el 2011 se decidió el desarrollo del patrón PXFlowController por necesidad de dos empresas importantes: Marke: empresa mexicana orientada a la venta por catálogo. Crédito de la Casa: financiera uruguaya dedicada al préstamo personal.