PXTools para Web Principales funcionalidades

Presentación del tema: "PXTools para Web Principales funcionalidades"— Transcripción de la presentación:

1 PXTools para Web Principales funcionalidades
Ing. Juan Marcelo Bustamante PuntoExe Consultores Buenos días, mi nombre es Ing. Juan Marcelo Bustamante. Soy director de la empresa PuntoExe Consultores.

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

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

4 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.

5 Patrón PXWorkWith Características Destacadas:
Manejo de RecentLink similar a aplicación Win. Form en transacciones. Tabs en transacciones y en Filtros. Scroll en Grilla o uso de GXUI.GridExtension Load sin Tabla Base. Force Grid Load. Acciones Confirms Auditoría de Transacciones y de registros. Transaction as Business Component Selección múltiple de registros Two pane dialog 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.

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

7 PXWorkWith Demo Funcionamiento de un WorkWith, View y Sections.
Form en transacciones. Tabs en transacciones y en Filtros. Manejo de RecentLink similar a aplicación Win. Transaction as Business Component Acciones Confirms Selección múltiple de registros Force Grid Load. Two pane dialog 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.

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

9 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.

10 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.

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

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

13 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

14 Patrón PXComposer Características Destacadas: Armado de Secciones
Soporte de invocación como Componentes Soporte de invocación como Embedded Pages Soporte de Secciones repetidas por Free Style Grid Soporte de control GXUI Layout Misma potencia que en Acciones del PXWorkWith Estas fueron los requerimientos básicos para impementar este pattern.

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

16 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.

17 PXFlowController T T T T P T T T T WP WP WP WP WP WP
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

18 PXFlowController T T T P T WP WP
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

19 PXFlowController ¿Cómo resolvemos esta lógica en Web?
Reingeniería de la aplicación. Implementar el diálogo Modal en Web. 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.

20 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.

21 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.

22 PXFlowController Características:
Programación orientada al desarrollo de Bloques 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.

23 Patrón PXOAV 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 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. Generación de Encuestas Interdependencias de Preguntas Inteacción con otra entidad del sistema.

25 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.

26 Ejemplo IdRetail - SalesForce
Patrón PXOAV Ejemplo IdRetail - SalesForce El resultado lo podemos ver con éstas imágenes.

27 Patrón PXSynchronization
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.

28 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.

29 PXSynchronization Características:
Permite personalizar los procesos de exportación para realizar una correcta segmentación. Permite personalizar los procesos de importación. Condicionar la importación Ejecutar procesos post 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.

30 ¿Preguntas?