01 Administración del sistema

SISTEMAS PLER

SISTEMAS PLER

PLER SALUD

Manual Técnico

Versión MT.01.09

Índice de contenido

601. Introducción

601.01. Usuarios y roles

601.02. Módulos

701.03. Establecimientos

701.04. Auditoría

801.05. Licencias

1002. Instalación y actualización

1002.01. Requerimientos

1002.02. Framework Pler

1102.03. Instalación sin framework

1102.04. IDE integrado

1202.05. Bases de datos

1302.06. Instalación en Windows Server

13JDK de Java 8

14Apache Tomcat

15SQL Server

17Framework Pler

19Módulos

20Memoria de Tomcat

2002.07. Configuración de parámetros generales

2203. Conceptos generales

2203.01. Administración de usuarios

2303.02. Habilitación de módulos

2403.03. Indicadores de rendimiento

2503.04. Operaciones de bases de datos

2603.05. Personalización estética del sistema

2603.06. Ayudas en línea

2804. Herramientas de administración

2804.01. Ajustar tamaños de bases

2904.02. Copias de seguridad

2904.03. Pool de conexiones

3004.04. Trazado de consultas

3104.05. Mantenimiento de índices

3104.06. Archivo de auditoría

3204.07. Prueba de rendimiento

3304.08. Registro de auditoría

3505. IDE Integrado

3505.01. Listado de módulos

35Indicadores por módulo

36Opciones generales

39Accesos simultáneos

4005.02. Edición de módulos

42Configuración

44Consultas SQL (back end)

46Editor de consultas

47Objeto interfaceJS

48HTML, JS y CSS (front end)

49Vista previa

50Informes

50Log de consultas

51Adjuntos

5206. Ejemplos de desarrollo

5406.01. Módulo de listado de artículos

5906.02. Módulo de edición de un artículo

6106.03. Listado editable estilo grilla

6406.04. Informes

6607. Instalación de escritorio

6607.01. Instalación de SQL Server Express

6707.02. Instalación de Pler en versión de escritorio

6707.03. Inicio de la aplicación

69Anexo I – Manual de desarrollo

69Editor de módulos (IDE integrado)

69Editor de querys

70Configuración de módulos

71Edición de módulos

72Diseño de módulos

73Diseño de informes

73Back-end (interfaceJS)

73Datos del módulo

74Métodos del módulo

75Eventos del módulo

76Objetos de datos (RS, RQ)

76Propiedades de RS

77Métodos básicos de RS

77Métodos avanzados de RS

78Front-end (JavaScript)

79Variables globales

79Funciones y métodos de clases globales

80Funciones de conversión de fechas

80Funciones de validación

80Funciones de Date / Time Picker

81Funciones generales de interface (UI)

81Funciones adicionales

82JavaScript avanzado de Pler

82Reportes

82Funciones de reportes

83Expresiones de reportes

83Base de datos

84Diseño de tablas

84Procedimientos SQL

86Funciones SQL

87Ejemplos SQL

89Bases y tablas del sistema

89Bases de datos del sistema

89Tablas de módulos

90Tablas de usuarios y permisos

90Tablas de archivos adjuntos

91Tablas de manuales

92Auditoría reciente y archivada

93Anexo II – Informe sobre la validez de la historia clínica electrónica

93Informe sobre la validez de la historia clínica electrónica con firma electrónica o digital y las dudas legales de los profesionales de la salud

99Diferencia entre la firma electrónica y la firma digital

101Exclusiones a la documentación electrónica: El consentimiento informado

101Problemas a resolver

102Conclusiones

01. Introducción

Pler Salud es un sistema de gestión hospitalaria que cubre las capas administrativas y médicas de la gestión sanitaria. Se utiliza por medio de un navegador web, como por ejemplo Chrome o Internet Explorer, conectándose a la dirección de Internet del servidor de su organización desde cualquier computadora.

A continuación, y a modo de introducción, se mencionan y describen algunos de los conceptos generales para los sistemas desarrollados por Sistemas Pler.

01.01. Usuarios y roles

La identificación de los usuarios se realiza por medio de nombres de usuario (username) y contraseñas (password). Los nombres de usuario deben ser únicos y, a diferencia de las contraseñas, no distinguen entre mayúsculas y minúsculas.

Los usuarios que cuenten con el privilegio de administración tienen permiso a crear, modificar o eliminar usuarios y roles de usuario en el sistema.

Los roles de usuario agrupan un listado de módulos, sobre los que otorgan el permiso de uso. Cada usuario puede tener un solo rol, o bien tener más de uno, en cuyo caso se le suman los permisos de los diferentes roles.

La vinculación entre roles y usuarios se realiza por cada establecimiento, de modo que un usuario puede tener permisos diferentes para diferentes establecimientos.

01.02. Módulos

Los módulos del sistema son los componentes individuales con los que se realizan las diferentes tareas, y el sistema informático en su conjunto es la suma de sus módulos, más la infraestructura subyacente que lo soporta.

Cada módulo puede consistir en una aplicación, un reporte o una carpeta, y está identificado con un código interno (único), con un nombre legible (visible en la pantalla) y con un ícono para facilitar el reconocimiento visual.

Las aplicaciones son los módulos más convencionales, mediante los cuales se utiliza el sistema, que interactúan con el usuario, con los datos, etc.

Los reportes son módulos simples que únicamente muestran información, sin modificar datos ni requerir acciones importantes por parte del usuario.

Las carpetas son módulos sin funcionalidad, no ejecutables, y que únicamente se utilizan como agrupadores para contener a otros módulos, organizar el escritorio de aplicaciones y el menú del sistema.

Los módulos ejecutables (aplicaciones y reportes) pueden ser llamados desde el escritorio o menú, en cuyo caso se inician sin parámetros, pero también existen módulos que solo pueden ser llamados desde otros módulos, el cual le entrega los parámetros necesarios para su inicialización. Un ejemplo de esto podría ser un módulo de listado de facturas, que se inicia desde el escritorio y sin parámetros, y que llama al módulo que muestra los datos individuales de cada una de las facturas, pasándole como parámetro necesario el número de la factura que se desea mostrar.

01.03. Establecimientos

Los establecimientos son divisiones funcionales para separar diferentes empresas, hospitales, centros, etc. Esto se refiere a lo que se suele llamar “multiempresa”.

El sistema permite identificar diferentes establecimientos para mantener aislada la información de unos y otros, pero a su vez también permite combinar la información como por ejemplo con la historia clínica electrónica única.

Cuando un usuario tiene permisos sobre más de un establecimiento, tendrá la opción de cambiarlo seleccionando el establecimiento deseado desde un menú de opciones desplegable en la esquina superior derecha de la pantalla.

La selección del establecimiento afecta a toda la sesión del usuario, de modo que un usuario solamente puede trabajar sobre los datos de un establecimiento a la vez.

Sin embargo, algunos módulos afectan a todos los establecimientos ya que trabajan sobre toda la información sin discriminar de qué establecimiento se trata. Un ejemplo de esto son los módulos para configuración de aspectos generales, que tendrán el mismo efecto para todo el sistema, independientemente del establecimiento sobre el cual se esté trabajando.

01.04. Auditoría

El sistema guarda registro y respaldo de todas las inserciones, modificaciones y eliminaciones realizadas en las tablas de transacciones de la base de datos. Esto significa que por cada modificación se puede saber en qué fecha y hora ocurrió, quien la realizó, y como estaban los datos antes y después de la modificación.

La auditoría se registra a nivel de cada tabla. Por cada registro se guarda el nombre de usuario y la fecha y hora de actualización. Adicionalmente, en una tabla secundaria, se almacenan los registros reemplazados o eliminados, si existieran, también con usuario, fecha y hora, de forma tal que exista respaldo para todas las operaciones realizadas.

La auditoría puede ser consultada por usuario, por tabla y por registro.

· Por usuario muestra, para un usuario y entre determinadas fechas, la lista de tablas sobre las que se realizó alguna operación.

· Por tablas muestra, para una tabla, la lista de modificaciones realizadas, según varios parámetros de segmentación y filtro.

· Por registros muestra, para un determinado registro, identificado por el nombre de tabla y clave primaria, la lista ordenada de cambios realizados desde su inserción.

Dado que la auditoría registra y guarda toda la información del modo más completo, genera un volumen de datos históricos importante y en constante crecimiento que con el tiempo puede llegar a exceder el tamaño de los datos transaccionales principales. Para reducir el tamaño de los datos en las tablas de auditoria, estos pueden ser desplazados periódicamente a una base de datos auxiliar que funciona a modo de archivo de auditoria.

La auditoría funciona automáticamente por medio de triggers de tipo “instead of” por lo cual resulta transparente al programador, con la única excepción de que este tipo de triggers inhabilita el uso de la función scope_identity y la variable @@identity en las operaciones de inserción.

En lugar de esto, los scripts de bases de datos de Pler utilizan la función dbo.f_pler_id_insert(‘tablename’) para devolver los valores de los IDs generados en las inserciones. Hay más información sobre esto en las guías de ayuda de programación.

01.05. Licencias

La necesidad de licencias afecta únicamente a las instalaciones que utilizan el Framework Pler para desarrollo y mantenimiento. Las distribuciones sin Framework, entregadas como código fuente, no requieren licencia ni tienen restricciones en la cantidad de usuarios ni módulos.

Las instalaciones del Framework Pler que no tengan licencias permiten el ingreso solamente a un único usuario simultáneo, lo que permite su uso para ambientes de desarrollo o de pruebas que no requieran concurrencia de usuarios. También es posible utilizar instalaciones del framework sin licencias para equipos aislados o móviles, de un único usuario concurrente.

Cada licencia de instalación establece un límite máximo de usuarios simultáneos y de módulos habilitados, pudiendo haber muchos más usuarios que los establecidos por la licencia, siempre que estos no utilicen el sistema concurrentemente al mismo tiempo.

Las licencias se aplican a partir de un código generado por la instalación y que identifica al hardware. Si los equipos de producción sufren un cambio de hardware que afecte a la placa base o al disco de la partición de inicio, la licencia debe ser solicitada y suministrada nuevamente de acuerdo al nuevo código de hardware.

02. Instalación y actualización

02.01. Requerimientos

El servidor del sistema funciona sobre la plataforma Java 8 (JDK 8 o posterior) y emplea bases de datos de Microsoft SQL Server versión 2008 R2 o posterior. Para servidor web se emplea el Apache Tomcat 8.

Las versiones Express de SQL Server (versiones gratuitas) limitan el uso de recursos de hardware y el tamaño máximo de las bases de datos a 10 gigabytes, por lo que solo son utilizables en ambientes chicos.

Los requisitos mínimos de hardware para el servidor están fijados por la plataforma Java y la base de datos, siendo en ambos casos muy bajos. Sin embargo, como en todos los productos de software, los ambientes de producción requieren ser dimensionados adecuadamente para no experimentar problemas de rendimiento. El servidor web y el servidor de base de datos pueden funcionar sobre un mismo equipo o en equipos separados.

Los requisitos de Java 8 y Tomcat 8 (servidor web) están disponibles para sistemas operativos Windows, Linux, y otras alternativas. Las bases de datos de SQL Server están disponibles para Windows en todas sus versiones, y para las principales distribuciones de Linux únicamente a partir de la versión 2017.

El uso del sistema se realiza por medio de cualquier navegador web vigente HTML5 compatible (Chrome, IE, FF, etc.), a través de Internet o de una red de área local o VPN. Los requisitos mínimos de hardware y sistemas operativos para los navegadores son los informados por sus respectivos fabricantes y actualizados según la versión vigente.

02.02. Framework Pler

El Framework Pler para el desarrollo y mantenimiento facilita las actividades de desarrollo y devops. Permite la modificación y sustitución de módulos en caliente, sin detener el servicio y con efecto inmediato.

El framework se distribuye como un archivo desplegable WAR, que es la versión web de los archivos JAR de java para funcionar en contenedores de servlets como Tomcat, y cuya estructura interna es igual y compatible con la de los archivos ZIP, por lo que pueden abrirse y explorarse internamente con WinZip, WinRar y herramientas similares.

Dentro del archivo war, en el directorio raíz, se encuentra el archivo pler.conf que debe contener la identificación para conectarse a la base de datos, remota o local, y el nombre de la base de datos.

El usuario suministrado para la conexión debe tener privilegios de administrador del sistema (sysadmin). Si la base de datos nombrada no existe, el framework la creará en el primer inicio, lo que demorará algunos minutos.

El archivo war se despliega en el servidor por medio del Gestor de Aplicaciones Web de Tomcat, normalmente ubicado en la dirección /manager y accesible desde el localhost.

Una vez desplegado, ya puede utilizarse el sistema por medio del navegador web. En instalaciones sobre bases nuevas, recién creadas, utilice el usuario demo y password demo, en el primer inicio de sesión para comenzar a configurar permisos, cargar módulos, etc.

El framework permite crear nuevos módulos y exportarlos en archivos de formato PLER o SQL. Estos archivos contienen todo el código ejecutable del módulo incluyendo sus objetos de base de datos requeridos y definiciones de tablas utilizadas.

02.03. Instalación sin framework

La versión sin framework se distribuye como código fuente, en un proyecto de NetBeans 8, que puede ejecutarse directamente desde el NetBeans, o empaquetarse en un archivo war para desplegar en un contenedor de servlets web.

El archivo pler.conf debe contener los datos para conectarse a una base de datos ya existente. En caso de tratarse de una instalación nueva, el proyecto contiene el script SQL para la creación de la base de datos.

El proyecto de NetBeans contiene un archivo JSP por cada módulo, y este JSP contiene internamente todo el código SQL necesario para su funcionamiento. Sin embargo, también se entregan los objetos de base de datos como scripts independientes para ser utilizados como procedimientos almacenados y aprovechar así las ventajas de rendimiento que ofrece el caché de planes de ejecución.

Para organizar y agrupar los módulos, las instalaciones sin framework utilizan el archivo pler.conf con un segmento de datos en formato XML, no utilizado en las instalaciones con el framework, que establece el orden y ubicación de cada módulo en el escritorio de inicio y en el menú lateral.

02.04. IDE integrado

El Framework Pler incluye un editor de módulos para realizar cualquier cambio, y en cualquier momento, sobre el código ejecutable del sistema. El editor funciona online, por medio del navegador web, y está disponible para los usuarios identificados con el privilegio especial de “programador”.

Cada módulo de Pler se guarda en la base de datos y puede ser exportado a los formatos SQL y PLER, incluyendo todos los componentes necesarios para su funcionamiento.

Los archivos con la extensión “.sql” permiten desplegar módulos directamente sobre la base de datos y contienen todas las instrucciones necesarias para su creación o actualización, incluyendo el código HTML, CSS y JavaScript que conforman las interfaces de usuario.

Los archivos con la extensión “.pler” contienen lo mismo que los archivos SQL, pero codificado en formato base 64 y con algunos datos redundantes de validación para asegurar su integridad. Los archivos pler se despliegan por medio de la pantalla de administración del sistema, y pueden ser aplicados por cualquier usuario con permiso de administración.

El IDE incluye una ayuda en línea más detallada, para programadores, donde se documentan todas las opciones provistas para SQL Server y JavaScript.

02.05. Bases de datos

Cada instalación de Pler emplea tres bases de datos diferentes, ubicadas en una misma instancia del servidor de base de datos y fáciles de identificar como relacionadas de acuerdo a una determinada nomenclatura.

La base de datos principal, donde se guardan los datos transaccionales vigentes, tiene el nombre establecido en el archivo pler.conf, por ejemplo “plerdb”. La base de datos de archivos adjuntos, donde se guardan los binarios utilizados o referenciados por los registros de la base principal, tiene el nombre de la base principal más el sufijo “_files”, por ejemplo “plerdb_files”. Y la base de datos de auditoría archivada, donde se mueven periódicamente los datos históricos de auditoría, tiene el nombre de la base principal más el sufijo “_audit”, por ejemplo “plerdb_audit”.

El motivo de separar estas tres bases es que cada una tiene diferentes condiciones óptimas de configuración. Para la base principal hay que priorizar la velocidad de discos. Para la base de adjuntos hay que priorizar el tamaño de almacenamiento. Y la base de auditoría, podría descartarse periódicamente, o indexarse de forma diferente a sus tablas correspondientes en la base principal. Adicionalmente, el sistema puede realizar muchas operaciones sobre la base de sistema tempdb, por lo que también conviene privilegiarla en velocidad.

El sistema realiza una única conexión a la base de datos, con un único nombre de usuario de base de datos, con autenticación de SQL Server, sobre la que mantiene en simultaneo varias sesiones reciclables en un pool de sesiones. Cada sesión se corresponde con un identificador “spid”.

La identificación de los usuarios se realiza por medio de la variable de contexto context_info, que se establece cada vez que un usuario toma una sesión del pool. Y esta identificación es la que se registra como nombre de usuario en la auditoría en cada actualización. Por este motivo las tablas de transacciones, a diferencia de las tablas de sistema exclusivas de Pler, solo admiten operaciones de insert, update o delete cuando ésta identificación está establecida, y esto funciona del mismo modo para las operaciones provenientes del sistema como para posibles operaciones realizadas desde la consola SSMS.

En consecuencia, para realizar alguna operación de actualización de datos desde fuera del sistema es necesario identificarse previamente por medio del procedimiento almacenado sp_pler_sesion, como se muestra en el siguiente ejemplo:

EXEC dbo.sp_pler_sesion ‘sistema’

De otro modo las operaciones de insert, update o delete realizadas sobre las tablas de las aplicaciones, serán ignoradas y no tendrán ningún efecto. La excepción a esta restricción son las tablas cuyo nombre comience con el sufijo “pler_” o “_” (guion bajo), que están exceptuadas de la auditoría.

El usuario ‘sistema’ está presente en todas las instalaciones de Pler, para uso interno del framework y no debe ser eliminado.

Para más información sobre los objetos de base de datos consulte las guías de ayuda de programación.

02.06. Instalación en Windows Server

Los componentes que deben instalarse en primer lugar son el JDK de Java 8, el motor de base de datos de SQL Server, y el servidor web Apache Tomcat 8. Esta es la infraestructura de software necesaria para desplegar el sistema.

JDK de Java 8

El JDK es el conjunto de herramientas de la plataforma Java, que incluye al entorno de ejecución y al compilador. Su instalación consiste en ejecutar el instalador de la versión de 64 bits, y la descarga puede encontrarse en la siguiente dirección:

https://www.oracle.com/java/technologies/javase-jdk8-downloads.html

La plataforma Java oficial se distribuye bajo licencia libre hasta la versión 8 inclusive. Para versiones posteriores podrá solicitar el soporte de Oracle, o bien utilizar la versión OpenJDK, que es la alternativa de licencia libre, también mantenida por el equipo de Oracle.

Si bien muchas aplicaciones de Java requieren tener establecidas las variables de entorno path, classpath y java_home, para utilizar Tomcat 8 esto no será necesario.

Apache Tomcat

Apache Tomcat es la combinación del servidor de páginas web Apache con el contenedor de servlets Tomcat, que se distribuyen de forma integrada y que juntos permiten la ejecución de aplicaciones java web. La descarga del instalador puede encontrarse en la siguiente dirección:

https://tomcat.apache.org/download-80.cgi

Y para una documentación completa, consulte:

https://tomcat.apache.org/tomcat-8.0-doc

Los componentes necesarios que debe seleccionar durante la instalación son el motor de Tomcat, Manager y Host Manager.

Luego conviene establecer el puerto 80 para el protocolo http, en lugar del 8080 predeterminado, y deberá establecer un nombre de usuario y password para acceder a la consola de administración del servidor web.

Al finalizar la instalación, el servicio del servidor web podrá iniciarse o detenerse desde el administrador de servicios de Windows.

El archivo de configuración server.xml, normalmente ubicado en $CATALINA_HOME/conf/, le permitirá modificar los puertos luego de la instalación, así como habilitar el protocolo HTTPS.

También tenga en cuenta que el límite máximo por defecto para las peticiones POST es de 2 MB (2097152 bytes) y que puede ser conveniente aumentar este límite por medio del parámetro maxPostSize.

port="80"

protocol="HTTP/1.1"

connectionTimeout="20000"

redirectPort="443"

maxPostSize="104857600"

/>

En el archivo tomcat-users.xml verá el nombre de usuario y password establecidos para la administración.

username="admin"

password="aaaaaaaaaa"

roles="admin-gui,manager-gui"

/>

SQL Server

SQL Server es el motor de bases de datos de Microsoft. Si bien se trata de un producto propietario que se distribuye con licencia comercial, para ambientes de desarrollo puede utilizar la edición Developer de distribución gratuita, o para instalaciones cuyas bases no superen los 10 GB de almacenamiento también podrá utilizar una edición gratuita Express. Su documentación completa se encuentra en la siguiente dirección:

https://docs.microsoft.com/es-es/sql/sql-server

El único componente necesario es el servicio del motor de bases de datos. Los restantes son opcionales y no son utilizados por Pler.

Al momento de la instalación puede elegir entre utilizar la instancia predeterminada o utilizar una instancia nombrada.

Las instancias nombradas permiten la existencia de múltiples motores independientes sobre un mismo equipo. Pero tenga en cuenta que esto también requiere habilitar el servicio adicional SQL Server Browser luego de la instalación, y permitir la conexión por el puerto 1434, además del 1433 y los utilizados por cada instancia.

La intercalación, o “collation”, del motor de base de datos es la forma en que se codificarán las cadenas de texto. Si está realizando una instalación para albergar una base de Pler proveniente de otro ambiente, tenga en cuenta indicar en este lugar el mismo tipo de intercalación utilizado por la base. Tener esto en cuenta desde el comienzo le ahorrará mucho tiempo.

El modo de autenticación debe ser cambiado de integrada (de Windows) a modo mixto, que permite utilizar usuarios de SQL Server.

Finalmente, luego de completar la instalación deberá habilitar las conexiones por TCP/IP desde el administrador de configuración de SQL Server. Esto es necesario tanto para admitir conexiones remotas como para conexiones locales provenientes desde aplicaciones desarrolladas en Java.

Framework Pler

La instalación del framework se realiza desplegando el archivo WAR que contiene todos los ejecutables del sistema y el archivo de configuración pler.conf.

El despliegue puede realizarse de dos formas. La primera, que requiere tener el archivo war copiado en el servidor, consiste en indicar la ruta de acceso para la web (trayectoria de contexto) y la ruta de la ubicación del archivo war.

La otra forma consiste en seleccionar el archivo war para subirlo al servidor y desplegarlo en un mismo paso. Tenga en cuenta que esta alternativa no permite indicar una trayectoria de contexto diferente a la del nombre del archivo war.

Luego del despliegue, podrá ver la dirección de la instalación, con sus opciones, junto con las demás aplicaciones desplegadas en el servidor.

Antes del despliegue debe asegurarse de que el archivo pler.conf, contenido dentro del war, contiene los parámetros correctos para la conexión a la base de datos. Los archivos war poseen el mismo formato de los archivos zip, y pueden abrirse con WinZip o herramientas similares.

Luego cuando ingrese al sistema por primera vez, éste se conectará a una base de datos ya existente, o creará una nueva en caso de no existir la base con el nombre indicado en pler.conf.

Tenga en cuenta que, si se conecta a una base existente y extraída de otra instalación, es posible que deba obtener un nuevo código de instalación para activar la licencia del framework y habilitar la concurrencia simultánea de usuarios.

Módulos

Los módulos de Pler se almacenan en la base de datos, y pueden ser cargados o actualizados por medio de scripts de SQL o por medio de los archivos con la extensión “.pler”.

Una exportación completa de módulos de Pler consiste en un archivo zip que contiene un script por cada módulo incluido, más un script adicional, llamado pler_all.sql, que contiene todos los módulos, para ejecutarlo de una sola vez e ingresar todos los módulos al mismo tiempo. Estos scripts pueden ejecutarse desde la consola SSMS, o bien desde la consola de SQL incluida en el IDE integrado.

La habilitación de los módulos, nuevos o actualizados, se realiza desde la pantalla de administración del sistema, en la sección de módulos. El número señalado indica la cantidad de módulos habilitados.

Entrando en la sección señalada, con click en activar todo, y luego en guardar cambios, se habrán habilitado todos los módulos ingresados por scripts.

Esta misma pantalla también permite cargar módulos mediante los archivos de extensión pler, subiéndolos uno a uno.

Luego de activar los módulos y volver a la pantalla principal de administración, veremos que la cantidad de módulos habilitados se ha incrementado. Sin embargo, para poder verlos tanto en el menú como en el escritorio, aun deberemos recargar todo el sistema para tomar las novedades en el navegador con F5.

Memoria de Tomcat

El uso de memoria de Tomcat por defecto es bastante bajo, y tanto para ambientes de producción, como para ambientes de pruebas donde se realicen operaciones con volúmenes de datos muy grandes, esté límite debe establecerse en valores superiores a 1 ó 2 GB.

Esto se realiza con el Ejecutable Tomcat8w.exe, que muestra algunas opciones de configuración, entre ellas los límites de memoria.

02.07. Configuración de parámetros generales

Los parámetros generales del sistema se encuentran almacenados en la tabla pler_parametro, funcionan como pares de clave y valor, y en general son opciones que solo pueden modificarse directamente desde la base. A continuación, se mencionan las claves principales.

sys.timeout.def.secs, sys.timeout.ext.secs y sys.timeout.sys.secs: Indican los tiempos, en segundos, para el timeout de las operaciones de base de datos. El primero es el valor para las conexiones de módulos convencionales. El segundo indica el valor para módulos con timeout extendido. El tercero indica el timeout de las operaciones de sistema.

sys.timeout.ses.mins: Indica el tiempo, en minutos, para el timeout de las sesiones de usuario inactivas.

sys.url.domain: Se utiliza para forzar el redireccionamiento a un dominio específico. También puede usarse para restringir el uso de localhost o 127.0.0.1 como dirección del sistema.

sys.url.https: Indica si se forzará el uso de conexiones seguras https.

sys.usr.fields.apellido: Indica si está permitido que los usuarios completen su apellido en la ficha de su perfil.

sys.usr.fields.nombre: Indica si está permitido que los usuarios completen su nombre en la ficha de su perfil.

sys.usr.fields.telefono: Indica si está permitido que los usuarios completen su número de teléfono en la ficha de su perfil.

sys.logidentity: El sistema guarda todas las claves primarias de todos los registros actualizados en una tabla auxiliar. Esto indica el tipo de tabla auxiliar que se empleará. Por defecto se utiliza una tabla en la base tempdb. Las otras opciones (tabla particionada, local y hekaton) pueden dar mejoras de rendimiento solo bajo condiciones muy específicas.

sys.app.name: Indica el nombre del sistema, mostrado en el título del navegador.

sys.app.welcome: Indica un mensaje de bienvenida, en la pantalla de login.

sys.app.version: Indica el número de versión del motor del framework Pler.

sys.app.version.build: Indica el número de compilación. Este valor se actualiza automáticamente con cada modificación sobre cualquier módulo.

sys.app.maxfilesize: Indica el tamaño máximo permitido para archivos adjunto del sistema.

sys.app.implementador: Es el nombre, link o contacto del implementador del sistema. Se muestra en la parte inferior de la pantalla de login.

sys.app.gzip: Indica si se utilizará la compresión gzip dentro de http. El valor por defecto es true. Deshabilitarlo ofrece una mejora en algunos casos en los que el sistema se utiliza exclusivamente dentro de una red local de alta velocidad.

sys.app.admin.backups: Indica si los administradores tienen habilitada la opción de hacer y descargar copias de seguridad de las bases.

sys.app.admin.licencias: Indica si los administradores tienen habilitada la opción de ingresar licencias.

mail.%: Estos parámetros establecen la configuración para el envío de emails desde el servidor.

Para consultar los valores establecidos puede utilizar la siguiente instrucción:

SELECT parametro,valor FROM pler_parametro ORDER BY parámetro

Los siguientes son scripts de ejemplos de configuración para habilitar los envíos de email, con TLS y SSL respectivamente:

/* Ejemplo de config para gmail via TLS */

DELETE FROM pler_parametro WHERE parametro LIKE 'mail.%'

INSERT INTO pler_parametro (parametro,valor) VALUES

('mail.smtp.auth','true'),

('mail.smtp.starttls.enable','true'),

('mail.smtp.host','smtp.gmail.com'),

('mail.smtp.port','587'),

('mail.address','******@gmail.com'),

('mail.username','******@gmail.com'),

('mail.password','******'),

('mail.retries','5'),

('mail.deletesent','true')

GO

/* Ejemplo de config para gmail via SSL */

DELETE FROM pler_parametro WHERE parametro LIKE 'mail.%'

INSERT INTO pler_parametro (parametro,valor) VALUES

('mail.smtp.host','smtp.gmail.com'),

('mail.smtp.socketFactory.port','465'),

('mail.smtp.socketFactory.class','javax.net.ssl.SSLSocketFactory'),

('mail.smtp.auth','true'),

('mail.smtp.port','465'),

('mail.address','******@gmail.com'),

('mail.username','******@gmail.com'),

('mail.password','******'),

('mail.retries','5'),

('mail.deletesent','true')

GO

03. Conceptos generales

03.01. Administración de usuarios

La administración de usuarios, para crear nuevos usuarios, asignar permisos, etc, se realiza desde el módulo de administración, restringido por el privilegio de administración. A este módulo se accede con el ícono de las herramientas, en el grupo de íconos de la parte superior derecha de la pantalla.

Los permisos se asignan por medio de roles que agrupan listados de módulos habilitados por cada rol. La lista de roles existentes, así como las opciones para crear nuevos, modificarlos o eliminarlos, está en la sección de “roles de usuarios”.

Por cada rol se puede ver un resumen que muestra cuantos módulos agrupa, en cuantos establecimientos fue aplicado, a cuantos usuarios afecta, cuántos de ellos están actualmente conectados, y si el rol otorga permiso para utilizar el chat interno. El rol llamado “admin” es un rol especial, que no puede ser modificado ni eliminado y que siempre otorga permiso sobre todos los módulos del sistema.

La lista de permisos de cada rol se modifica seleccionando o des seleccionando los módulos correspondientes.

Con los roles de usuario ya establecidos, el listado de “usuarios habilitados” en la pantalla de administración muestra las opciones para cada usuario.

El privilegio de administración (“es administrador”) habilita al usuario a ingresar a la administración del sistema, modificar usuarios, deshabilitar módulos, etc.

El privilegio de programador (“es programador”) habilita al usuario a modificar los módulos del sistema, utilizar el editor de módulos, acceder a la base de datos, etc. Se trata de un permiso avanzado que solo se debe otorgar a personal calificado.

La asignación de permisos, por medio de los roles, se realiza por medio de la grilla de establecimientos y roles, de modo que puedan aplicarse diferentes perfiles de permisos en los diferentes establecimientos para un mismo usuario. Si hubiera muchos establecimientos, al pie de la grilla esta la opción de asignar un rol para todos los establecimientos de forma rápida con un solo click.

03.02. Habilitación de módulos

La sección de “módulos” en la administración del sistema muestra todos los módulos existentes, y permite por cada uno activarlo o desactivarlo. El listado se muestra ordenado del mismo modo que se muestra en el escritorio de inicio y en el menú lateral, en cada caso con su respectivo nombre ícono, nombre legible y nombre interno.

Desde esta sección también es posible agregar nuevos módulos al sistema, importando archivos “.pler”, que contienen módulos completos y funcionales.

Los nuevos módulos importados, o actualizados en el caso de que se importe una modificación para un módulo ya existente, quedan desactivados inicialmente y deben ser seleccionados y activados manualmente.

Los usuarios toman los permisos al momento de ingresar en el sistema. Por tal motivo, en el caso de módulos nuevos, los usuarios con sesiones iniciadas previamente deberán recargar el sistema en su navegador para poder ver las novedades, por ejemplo, presionando la tecla F5.

03.03. Indicadores de rendimiento

Los indicadores de rendimiento de la pantalla de administración del sistema muestran en tiempo real el uso de CPU y memoria.

El uso de CPU muestra la carga del servidor web Tomcat, y adicionalmente también la carga total del equipo donde se encuentra alojado. Estos dos valores se grafican más abajo en diferentes tonos de verde.

El uso de memoria también se refiere al servidor web, graficado en amarillo, y al uso total del equipo, en gris.

Adicionalmente en un tercer gráfico se muestra en color anaranjado el uso real de datos dentro de la memoria tomada por parte del servidor web. Este último valor fluctúa de forma normal y es manejado de forma automática por el recolector de residuos de Java.

Para las instalaciones en las que el servidor web y la base de datos funcionen sobre un mismo equipo, la diferencia entre los usos particulares del servidor web y los usos totales de todo el equipo se corresponde con bastante exactitud con el uso de recursos del motor de base de datos, que no es medido de forma más específica por estos indicadores.

03.04. Operaciones de bases de datos

Desde la administración del sistema, se ofrecen algunas funciones para el mantenimiento y supervisión de las bases de datos. Estas funciones están habilitadas para los usuarios con el privilegio de “programador”, y opcionalmente para administradores, según la configuración de la instalación.

Para cada una de las tres bases de datos empleadas por el sistema, es posible reducir el tamaño, hacer copias de seguridad, comprimirlas y descargarlas. La función de backup desde el sistema requiere que el servidor web y el servidor de base de datos estén instalados sobre un mismo equipo.

La función de “ver conexiones” muestra el pool de conexiones a la base de datos, con sus sesiones reciclables que se comparten entre las peticiones de los distintos usuarios. Esto también muestra el estado de cada conexión, libre u ocupado, y la instrucción sql que se está ejecutando en el caso de tratarse de una conexión ocupada.

El “analizador sql” funciona a modo de “traza” de SQL Server, como en la herramienta SQL Server Profiler, y guarda un registro de todas las instrucciones detectadas para su posterior análisis. Esta herramienta tiene un fuerte impacto en el rendimiento y no debe ser utilizada en ambientes de producción.

La función de “reorganizar índices” ajusta la fragmentación y actualización de estadísticas de índices en aquellos índices de un tamaño mayor o igual a mil páginas y cuya desviación de los valores óptimos haya superado el umbral mínimo para afectar al rendimiento de la base. Los índices de menos de mil páginas o con niveles de fragmentación o desactualización de estadísticas muy bajos son ignorados por esta función ya que no tienen impacto en el rendimiento.

La función de “archivar auditoría” mueve los registros de auditoría a una base auxiliar para liberar espacio en la base principal y permitir indexar los registros históricos en una base diferente con criterios más apropiados para este tipo de datos que los empleados en la base principal.

La “prueba de carga” mide el rendimiento del hardware por medio de algunas transacciones simuladas, sin realizar cambios reales, que se asemejan y aproximan bastante a las transacciones reales. El resultado de las mediciones se entrega como cantidad de consultas y transacciones por segundo. Adicionalmente se muestran diferentes valores de configuración de hardware y software que afectan al rendimiento final del sistema.

03.05. Personalización estética del sistema

La administración del sistema permite ajustar la configuración de colores e imagen de fondo de la parte estética del sistema. Esta configuración afecta a toda la instalación y los valores establecidos y confirmados serán visibles por todos los usuarios.

Los valores modificables son el logo del sistema, ubicado en la esquina superior izquierda de la pantalla, los colores de fondo para el panel principal y para las barras de encabezado y menú, y los efectos de transparencia o contraste que compensan la similitud entre algunas combinaciones de colores muy cercanos.

03.06. Ayudas en línea

Las ayudas en línea son un recurso para los administradores del sistema, que les permite publicar instrucciones e indicaciones vinculadas o no a determinados módulos del sistema.

Estas instrucciones se publican por medio de documentos online, similares a los documentos doc o docx de Word, en los que cada uno consta de un nombre, un contenido, y una serie de vinculaciones con los módulos a los que hacen referencia.

El contenido de los documentos se puede copiar y pegar desde documentos de Word, manteniendo sus respectivos formatos e imágenes, o editarse de forma online directamente sobre el sistema.

04. Herramientas de administración

En la pantalla de administración del sistema, por debajo de donde se muestran los indicadores de rendimiento, podemos encontrar algunas herramientas para el trabajo con las bases de datos.

Estas herramientas están disponibles para los usuarios que cuenten con el privilegio de programador, y opcionalmente pueden estar disponibles también para administradores.

04.01. Ajustar tamaños de bases

Para cada base de datos utilizada por Pler tenemos la opción de reducir su tamaño hasta el mínimo posible. Normalmente no es necesario ni conveniente realizar esta acción, dado que las bases tienden a crecer y que tal crecimiento es una de las operaciones más lentas y costosas en uso de recursos.

Con click sobre “ajustar tamaño”, luego de algunos segundos de espera, se mostrarán los tamaños previos y posteriores a la operación de reducción.

Para el caso de la base tempdb, que solamente contiene datos temporales, ésta operación intentará reducirla en un 10% de su tamaño.

04.02. Copias de seguridad

Con click sobre la opción para hacer copias de seguridad, se genera un nuevo archivo de backup completo, y se mostrará su link para la descarga.

La generación del backup puede demorar varios minutos. Luego de obtener el enlace se mostrarán las opciones de eliminarlo, descargarlo, o comprimirlo en formato zip para poder descargarlo más rápido, pero tenga en cuenta que en algunas versiones de SQL Server el backup ya estará comprimido, y una segunda compresión no reducirá aún más el archivo.

En el caso de que la cuenta de usuario de Windows utilizada por SQL Server no tenga permiso sobre la carpeta donde está ubicado el servidor web, los backups se guardarán en la ubicación de backups por defecto y no podrán ser descargados en línea.

04.03. Pool de conexiones

El visor del pool de conexiones muestra el estado y contenido de cada conexión utilizada por el sistema.

Por cada conexión ocupada veremos el tiempo que lleva en ejecución, desde el último llamado, y el nombre del usuario que la ha tomado. Más abajo también se muestra el contenido de la consulta que se está ejecutando.

La opción de matar el proceso (kill), quitará la conexión del pool y terminará el proceso que tenga en ejecución.

04.04. Trazado de consultas

El trazado de consultas coloca un observador que registra y guarda todas las consultas enviadas a la base de datos. Se utiliza para hacer pruebas y detectar errores. Esto es una operación muy costosa en recursos y que ralentiza el funcionamiento de todo el sistema, por tal motivo no debe utilizarse en ambientes de producción.

Al iniciar un nuevo trazado, se puede indicar un parámetro de filtro, que funciona como un operador “contains”, un tiempo máximo de duración, e indicar si se desean incluir o no las operaciones internas del sistema.

Luego de iniciado el trazado, con click en “actualizar” veremos el listado de las consultas interceptadas.

Por cada registro, es posible mostrarlo identado, de forma más legible, haciéndole click. Esto también muestra el usuario, fecha y hora de la petición.

04.05. Mantenimiento de índices

El mantenimiento de índices es un proceso que regenera y actualiza las estadísticas de los índices cuya degradación podría estar teniendo impacto en el rendimiento del sistema.

Los índices reconstruidos serán aquellos que ocupen más de 1000 páginas y su fragmentación sea mayor a 5%. La actualización de estadísticas se aplicará a todos los índices en todas las tablas, del mismo modo que lo realiza el procedimiento sp_updatestats.

04.06. Archivo de auditoría

Los registros de auditoría del sistema guardan todos los estados anteriores de las tablas modificadas, junto con el usuario, fecha y hora de cada ingreso de datos o modificación. Esto genera un gran volumen de datos en la base principal, que periódicamente puede ser desplazado a una base auxiliar para mejorar el rendimiento en las inserciones y en la indexación de datos antiguos.

El desplazamiento de los datos a la base auxiliar puede realizarse en un solo paso, mediante el botón para archivar todo, o seleccionando tablas individuales para realizar la acción en transacciones más pequeñas.

Dado que algunas validaciones internas del sistema utilizan los registros de la auditoría más recientes, estos se vuelven archivables luego de pasadas 24 horas desde su generación.

04.07. Prueba de rendimiento

Es posible medir el rendimiento del sistema, en relación a sus recursos de hardware, mediante un procedimiento que simula ciclos de transacciones. Esto se realiza mediante una prueba de carga.

Esta prueba consta de 5 pasos que miden la velocidad en la que se realizan ciertas operaciones sobre un único hilo de procesamiento.

Los resultados son las cantidades de operaciones por segundo, y al no ser indicadores estándar, sirven únicamente para realizar comparaciones de rendimiento entre diferentes instalaciones de Pler. Adicionalmente, y para comprender mejor los resultados, más abajo también se incluyen varios indicadores más convencionales y datos de la configuración.

Para medir el impacto de la concurrencia, también es posible realizar varias pruebas en paralelo, pero tenga en cuenta que los navegadores web limitan la cantidad de conexiones concurrentes contra un único servidor, generalmente a 6, salvo que se modifique este límite en sus parámetros de configuración.

04.08. Registro de auditoría

Las consultas sobre los registros de auditoria pueden realizarse de tres modos diferentes: por usuario, por tabla, y por registro.

En la auditoría por usuario, se selecciona el nombre del usuario y el rango de fechas, y como resultado se obtiene el listado de tablas que han sido modificadas y la cantidad de registros afectados por cada una. Según el volumen de datos, esta operación puede ser muy lenta y demorar varios minutos.

Con click sobre alguno de los nombres de tablas mostradas como resultado, o ingresando directamente en la auditoría por tablas, podemos identificar las modificaciones individuales realizadas sobre una tabla en concreto.

En este tipo de consulta, es necesario indicar si se desean mostrar las altas, los cambios o las bajas, realizadas en tablas o en campos.

Cuando la consulta se realiza sobre tablas, las altas se corresponden con las instrucciones insert, los cambios con update, y las bajas con delete. Pero al realizar la consulta sobre campos, se consideran altas también a las modificaciones que introduzcan valores en campos que previamente tuvieran un valor nulo.

Para mostrar los resultados, se puede indicar la lista de campos que deben ser incluidos por cada registro, así como la lista de campos que se desean mostrar comparando valores previos y posteriores a cada operación.

Con click sobre cada registro del listado de resultados, o ingresando directamente a la auditoría por registro, podremos ver el historial completo de un registro individual en la base de datos.

En este caso se ingresa únicamente el nombre de la tabla y el valor de la clave primaria de un registro. Como resultado obtenemos el listado de estados que tuvo cada registro, incluyendo todos sus campos, y mostrando destacado en color rosado los campos que hayan tenido alguna modificación.

05. IDE Integrado

El framework de Pler proporciona un entorno de desarrollo integrado dentro del sistema, que permite ver y modificar el código fuente de todos los módulos, así como realizar nuevos desarrollos o exportar las aplicaciones a otros ambientes. Para tener acceso al IDE, es necesario contar con el permiso especial de “programador”, habilitado desde la administración de usuarios.

El ingreso al IDE se realiza por medio del ícono de “programación” ubicado entre las opciones del menú superior. Con un click sobre el ícono se mostrará el listado de módulos y las opciones.

Como un atajo, cuando se tenga abierto un módulo en primer plano, el click sobre el ícono, en lugar de mostrar el listado, nos llevará directamente a su pantalla de edición, con el mismo resultado que si lo hubiéramos buscado en el listado, pero acortando un paso.

05.01. Listado de módulos

El listado muestra todos los módulos existentes, en este caso, los que componen el sistema Pler Salud.

Indicadores por módulo

Por cada módulo mostrado encontraremos el ícono, nombre para mostrar en pantalla y nombre interno, fecha de la última modificación, y una lista de indicadores adicionales.

Los indicadores mostrados son los siguientes:

Act (activado): Indica que el módulo está activado y puede utilizarse. Los módulos no activados solo se podrán ver desde la pantalla de vista previa del editor.

Ini (inicial): Indica que el módulo se muestra en el escritorio y el menú lateral del sistema. Los módulos que no tengan esta propiedad solo pueden ser invocados desde otros módulos, normalmente pasándoles parámetros específicos. Por ejemplo, en un ABM, un listado de artículos se mostrará como una aplicación en el escritorio, pero el módulo de edición de cada artículo individual solo será invocado cuando se llame desde el módulo del listado, pasándole como pará metro el id del artículo seleccionado.

A/P (aplica permisos): Indica que el módulo es susceptible de recibir permisos por medio de los roles de usuarios del sistema.

Inf (informe): Indica que el módulo es un informe. La diferencia entre informes y módulos de aplicaciones es solamente informativa.

T/E: (timeout extendido): Indica que el módulo podría realizar operaciones de base de datos de larga duración.

M/I (múltiples instancias): Indica que el módulo puede estar abierto varias veces al mismo tiempo por un mismo usuario, normalmente bajo diferentes parámetros. Volviendo al ejemplo del ABM, sería normal que el listado de artículos se muestre una vez sola, mientras que los módulos para cada artículo individual puedan abrirse múltiples veces de forma simultánea, una vez por cada artículo seleccionado.

Bus (buscable): Indica que el módulo está integrado con el buscador del sistema, permitiendo encontrar y mostrar datos específicos, como el DNI de una persona, o el nombre de un artículo.

Avs (avisos): Indica que el módulo puede emitir avisos espontáneos para dar notificaciones en tiempo real. Estos avisos se muestran en la franja superior de la pantalla del sistema, entre los íconos fijos ubicados hacia la derecha.

Qrs (querys): Indica la cantidad de consultas de base de datos utilizadas por cada módulo. Este número da una aproximación sobre la complejidad del módulo.

Opciones generales

Además de los indicadores de cada módulo, en la parte superior se muestran las opciones para operaciones generales, como agregar nuevos módulos, realizar validaciones, etc.

Estas ocho opciones son, en su respectivo orden, las siguientes:

Actualizar listado: Vuelve a cargar el listado.

Validar todos los querys: Realiza una comprobación sobre todos los scripts de base de datos, asegurando que sean compilables y que no devuelvan error en la ejecución.

El resultado de la validación consiste en el aviso de que fue completada con éxito, o en el detalle de los módulos y sus errores encontrados.

Exportar todos los módulos: Esta opción permite extraer los archivos de todos los módulos existentes.

El funcionamiento para la extracción requiere de dos pasos. En el primero se genera el archivo zip conteniendo todos los módulos representados cada uno por un archivo de tipo sql. Este paso puede demorar varios minutos.

Luego de la generación, se muestra el enlace de descarga y se permite su eliminación.

Consola SQL: Permite ejecutar cualquier consulta directamente sobre la base de datos.

Los resultados de las consultas se muestran por pantalla, inmediatamente debajo del script ingresado.

Diagrama entidad-relación: Muestra un diagrama completo para todas las tablas del sistema.

El diagrama indica las relaciones entre tablas por medio de sus campos de claves primaria y foránea.

Con doble click sobre cada entidad, también se muestran algunos scripts de ejemplos para su lectura y escritura.

Interacciones entre módulos: Muestra un diagrama de relaciones entre módulos a través de las tablas y campos que utiliza cada uno.

Con click sobre cada módulo, se muestran sus relaciones y los nombres de las tablas leídas, en rojo, o escritas, en azul, por cada uno.

Editor Java/Jsp: Permite ingresar y probar código en lenguaje Java, tal y como si se escribiera dentro del cuerpo de un servlet o un archivo jsp.

El uso de este editor es solamente para realizar pruebas.

La ejecución de código en Java de forma dinámica requiere que el mismo sea devuelto por una consulta de base de datos en un campo especial de nombre “javac”, cuyo contenido será reemplazado por el resultado de la ejecución.

Agregar nuevo módulo: Este ícono agrega nuevos módulos, en blanco y listos para comenzar a desarrollarlos.

Al agregar módulos nuevos, estos se mostrarán desactivados al comienzo de la lista de módulos, junto con la leyenda de aviso.

Accesos simultáneos

Cuando hay varios programadores trabajando sobre un mismo ambiente, es posible que dos o más intenten realizar modificaciones en simultáneo sobre un mismo módulo, pisándose entre ellos y causando pérdidas de tiempo y trabajo.

Para evitar esto, el listado de módulos incluye un aviso con el nombre de usuario del programador que se encuentre trabajando sobre cada módulo en ese preciso momento.

También entrando en la edición de cada módulo se muestra un aviso similar que refuerza las precauciones.

Y en sentido inverso, al programador que ya estuviera trabajando, se le muestra un aviso espontáneo, en la franja superior de la pantalla, avisándole que otro usuario acaba de ingresar a la edición del mismo módulo.

Estos tres tipos de avisos son únicamente informativos, para ayudar en la coordinación de equipos, y no implican restricciones reales, de modo que la edición nunca se encuentra restringida o bloqueada.

05.02. Edición de módulos

Ingresando en la edición de cada módulo, en primer lugar, vemos sus datos de configuración y un menú superior para navegar por las diferentes secciones que componen la programación.

El primer botón del menú, con la leyenda de “Inicio”, se utiliza para salir de la edición y volver al listado de módulos.

El segundo botón, con la leyenda “Config”, muestra la sección con las principales acciones y opciones de configuración.

El botón de “Querys” muestra las consultas de base de datos que componen el back end.

Los botones de Html, Script, Style y Preview, que componen el front end, muestran respectivamente y por separado el código de HTML, de Javascript, de CSS, y la vista previa.

El botón de “Log Sql” muestra el registro de las consultas realizadas a la base de datos por el usuario actual, tanto desde dentro de la vista previa como de los módulos desplegados.

El botón de “Files” tiene la doble función de permitir el cambio del ícono del módulo, como de agregar archivos adicionales. Esto se emplea para incluir y referenciar componentes de Javascript o imágenes.

Finalmente, el botón de ayuda (“?”) muestra la guía de desarrollo, que detalla los diferentes recursos a disposición del programador.

Configuración

Las opciones de configuración definen el comportamiento del módulo, por fuera de lo que es la programación, e incluye las acciones principales como guardar, eliminar o exportar.

El primer grupo de botones contiene las acciones principales para trabajar con cada módulo como archivos independientes.

Los botones de “Aplicar” y “Guardar” guardan permanentemente los cambios realizados.

El botón de “Eliminar” elimina el módulo del sistema.

El botón de “Clonar” crea una copia del módulo, idéntica, pero sin un código alfanumérico (código del módulo) y con el sufijo “(clon)” añadido al final del nombre.

Los botones de “exportar” permiten obtener y descargar el contenido completo de cada módulo. En el primer caso, en formato sql, para ingresarlo en el sistema por consola, y en el segundo caso en formato pler, para ingresarlo por medio de la pantalla de administración del sistema.

Cada módulo se identifica por medio de un código alfanumérico, que es su nombre interno, y por un nombre más legible, que es el que se mostrará a los usuarios.

La ubicación determina cómo se organizarán los módulos en el escritorio y en el menú principal del sistema. Los módulos que no tengan código fuente, o sea módulos en blanco, que únicamente tengan un nombre, actuarán a modo de grupos o de carpetas, conteniendo a los módulos utilizables.

El check de “Módulo activado” indica que el módulo ya está listo para ser utilizado. Sin esta marca solo podrá verse y usarse desde la vista previa de este editor.

El número de orden establece cómo se ordenan los módulos dentro de cada grupo de módulos o carpeta. Si este valor no se completa, el ordenamiento será alfabético, de acuerdo con los nombres.

El enlace para “ver interacciones” muestra el diagrama de relaciones entre módulos, incluyendo únicamente el módulo actual y aquellos que estén relacionados.

Los siguientes checks se corresponden, en su mayoría, con las opciones de configuración que son mostradas en el listado inicial.

Inicia desde escritorio: Indica que el módulo se muestra en el escritorio y el menú lateral del sistema.

Aplica permisos: Indica que el módulo es susceptible de recibir permisos por medio de los roles de usuarios del sistema.

Es un informe: Indica que el módulo es un informe.

Timeout extendido: Indica que el módulo podría realizar operaciones de base de datos de larga duración.

Múltiples instancias: Indica que el módulo puede estar abierto varias veces al mismo tiempo por un mismo usuario, normalmente bajo diferentes parámetros.

Aviso de conflictos: Agrega la validación de conflictos de actualización cuando un usuario esté actualizando datos que, después de haber sido leídos, pudieran haber sido modificados por otra persona.

El sistema genera maquetas iniciales de código fuente a partir de los scripts de base de datos ingresados en el back end, traduciéndolos a pantallas de usuario que representen a todos los datos involucrados y facilitando el comienzo del trabajo sobre el html, css y javascript.

Esta generación de código fuente puede realizarse según dos modelos generales, uno para módulos convencionales utilizando pantallas del estilo de Bootstrap, y otro para reportes.

Finalmente, se muestra la opción de incluir componentes de algunos de los frameworks más utilizados.

Consultas SQL (back end)

El primer paso para crear nuevos módulos con Pler consiste en definir las consultas que se emplearán para la lectura y escritura de datos contra la base. A partir de tales consultas, el sistema genera versiones iniciales del código fuente que facilitan y aceleran el trabajo de desarrollo.

Por tal motivo es fundamental comenzar con una buena comprensión de la configuración de estas consultas y de los objetos de datos que se generarán de forma automática para representarlas.

Cada consulta recibe un conjunto de parámetros y entrega un conjunto de campos. Esto puede verse en las dos columnas finales del listado de consultas.

Para los casos en los que las consultas entreguen un conjunto de registros, o set de datos, la cantidad de campos devueltos se mostrará entre [corchetes], indicando que se devuelven, por ejemplo, 13 campos, en un objeto de datos de múltiples registros.

Pero también se puede establecer que una consulta devuelva valores discretos, es decir como variables independientes, una por cada campo devuelto, sin que se considere que haya múltiples registros, y en tal caso la cantidad de campos devuelta se mostrará sin corchetes.

Lo mismo sucede con los parámetros que recibe cada consulta, teniendo en cuenta que podría haber algunas consultas que reciban como parámetros una lista de variables, pero también consultas que reciban varios registros, en cuyo caso cada consulta se ejecutará una vez por cada registro recibido, convirtiendo cada uno de sus campos en parámetros individuales por cada ejecución.

Hasta aquí tenemos que cada consulta recibe y entrega un grupo de valores, que son sus parámetros y campos respectivamente, y que para ambos casos éstos valores pueden manejarse como variables independientes o como un conjunto de registros.

Luego debemos notar que si bien las operaciones de manipulación de datos son cuatro (select, insert, update y delete), los eventos que las ejecutan en las interfaces de usuarios son tres (al inicio, al guardar y al eliminar). Y esto implica que los scripts para guardar los datos deben incluir las operaciones de insert y update, según si se trate de guardar datos nuevos o modificaciones sobre datos ya existentes.

Así llegamos a que cada consulta de datos puede ser llamada, y ejecutada, de forma individual, directamente por medio de su nombre, o bien en grupos por medio del evento al que correspondan.

Todo esto queda representado en el objeto de nombre interfaceJS, cuya definición se realiza de forma automática y en estricta concordancia con la configuración de las consultas establecidas. La definición de tal objeto se muestra por debajo del listado de consultas.

Para los módulos que permitan ser abiertos desde el buscador del sistema, o los que lancen avisos espontáneos, se deberán ingresar unas consultas adicionales que definan el comportamiento de estas funcionalidades.

A continuación, se muestra el listado de todas las tablas y campos utilizados por el módulo, a modo de diccionario de datos.

Y el enlace para mostrar el DER, limitado únicamente al módulo y las tablas que utilice.

Finalmente, para los módulos que requieran tener cargados algunos datos iniciales, está la opción de incluir un scritp de inicialización. Esto suele usarse para completar las tablas auxiliares, de tipos o de estados.

Editor de consultas

Para modificar una consulta, hacemos click sobre su registro en el listado de consultas.

Esto nos llevará a la pantalla de edición, que consiste en un menú de acciones, en el código sql de la consulta, y en un grupo de opciones d configuración.

Las consultas reciben sus parámetros por medio del signo de interrogación (?), que vinculado a un nombre de variable conforman el nombre y tipo de cada parámetro.

Las principales acciones son validar, identar y guardar. Si bien la validación se realiza automáticamente al hacer click en el botón de guardar, no permitiendo guardar código con errores, la validación y la identación también pueden aplicarse de forma independiente mientras el código se está modificando. Junto a los botones de éste menú, se muestra en color verde, o rojo, el aviso indicando si la validación es correcta.

Las opciones ubicadas por debajo del código sql establecen el comportamiento de la consulta, y cómo será llamada desde la aplicación.

El nombre de la consulta, o nombre de grupo, se utilizará para generar los métodos de llamado, con los prefijos “q_” y “r_” para peticiones sincrónicas y asincrónicas respectivamente.

Luego tenemos los checks para incluir la consulta dentro de alguno de los eventos principales. Cuando existan dos consultas de igual nombre en diferentes eventos, el sistema las relacionará al momento de la generación automática de código fuente, asumiendo que, por cada nombre, los datos obtenidos “al inicio” son los mismos que se guardarán “al guardar”.

El tipo de valores que una consulta “recibe” y “entrega” indica si serán valores simples, es decir variables discretas, una por cada campo, o si serán un set de datos, es decir un objeto representando a una tabla, con varias filas y varios valores por cada columna.

El check de “compilado” convierte el script en un procedimiento almacenado, aprovechando así las ventajas de rendimiento del uso de planes de ejecución. Sin embargo, durante el desarrollo puede ser conveniente dejar este check deshabilitado para ver mejor los logs del contenido de cada consulta realizada.

Luego se muestran, a modo informativo, la lista de nombres y tipos de datos para los datos recibidos y devueltos.

Objeto interfaceJS

El objeto interfaceJS es la representación del back end en el navegador y sus métodos contienen todas las operaciones contra la base de datos.

Todos los datos de cada módulo, recibidos o devueltos por las consultas, se almacenan como sus propiedades. Los valores simples (que no son sets de datos) son almacenados en propiedades con nombres en letras minúsculas. Esto se refiere tanto los parámetros de entrada de las consultas como a sus valores de retorno. Los sets de datos, equivalentes a resultsets, recordsets o datasets, en cambio, son almacenados en propiedades con nombres en letras mayúsculas.

Para cada módulo de Pler, las consultas de datos se agrupan en tres categorías según si corresponden a los eventos de iniciar (select, obtener datos iniciales), guardar (insert y update), o eliminar (delete). Cada uno de estos eventos cuenta con su método correspondiente.

Las consultas o grupos de consultas con nombre y que no estén agrupados en los eventos de iniciar, guardar y eliminar, son representados por medio de métodos sincrónicos, de nombres en minúsculas y que comienzan con el prefijo "q_". Para llamar a estas mismas consultas, pero con métodos asincrónicos, los nombres de los métodos comienzan con "r_" y reciben como primer parámetro la función de retorno (callback).

Al utilizar la generación automática de código, este objeto se complementa con una pantalla, o interface de usuario, que permite mostrar todos sus datos y que permite utilizar sus métodos principales.

HTML, JS y CSS (front end)

Por medio de la generación de código se obtiene un primer esquema del código fuente para cada módulo, que incluye la estructura general y las rutinas para lecturas y escrituras. Y al comenzar con el código generado, nos aseguramos desde el inicio de que la definición y configuración de las consultas de base de datos son correctas, al verlas reflejadas con coherencia en la vista previa.

En la sección de “Script” se encuentra el código ejecutable, en lenguaje Javascript. Aquí es donde se ingresará la mayor parte de la lógica de negocio de cada aplicación.

Por debajo de este editor, se muestran una serie de marcadores de posición para acceder más rápidamente a cada sección del código.

El evento principal, “onload”, se muestra destacado con fondo azul y los eventos restantes se muestran con fondo blanco. Luego están los métodos y funciones, que se diferencian por mostrarse los primeros en negrita y los segundos en letra itálica.

Con alt+espacio se muestran las opciones de autocompletado.

Para los tres editores de código fuente, es posible realizar búsquedas dentro de su contenido con ctrl+f, y reemplazos con ctrl+shit+r.

En cuanto al código en Javascript, tenga en cuenta que los módulos, fuera de la vista previa, se ejecutan minificados para acelerar sus tiempos de carga. Esto significa que se eliminarán espacios sobrantes y saltos de línea, por lo cual debemos ser rigurosamente estrictos colocando el signo de punto y coma (;) al final de cada instrucción.

Vista previa

Como es natural, la vista previa funciona en sincronicidad con los tres editores de código, reflejando cualquier cambio antes de que éste sea guardado y permitiendo el uso del módulo para depuración.

Si ocurren errores en tiempo de ejecución, éstos se muestran indicando el error y número de línea que lo causó.

En este ejemplo podemos ver que se indica una variable no definida en la línea número 45.

Por debajo del panel de vista previa también se muestran los datos del módulo, o más concretamente las propiedades del objeto interfaceJS, diferenciando primero las variables simples y luego los sets de datos.

Por debajo de todo están las opciones de actualizar la vista de propiedades y de eliminar las cookies establecidos para forzar parámetros.

Los parámetros forzados son valores ingresados manualmente desde esta parte de la pantalla para indicarle a la vista previa que muestre los datos para un determinado id, o una determinada fecha, evitando tener que ingresar los valores por pantalla muchas veces durante las pruebas y depuraciones, o simulando parámetros recibidos desde otro módulo.

Informes

Si bien los informes del sistema son módulos, iguales a los demás, éstos cuentan con una sección adicional para introducir específicamente el código html con el que se armarán los reportes.

En este caso el editor de “Html” del módulo se utiliza para definir la pantalla, con sus menús y opciones, mientras el código del “Reporte” representa únicamente la definición del formato con el que se mostrarán los datos.

Los reportes utilizan una serie de tags adicionales, que no son parte del estándar de html, y que sirven para establecer ciclos y condiciones.

Log de consultas

El log de consultas muestra el registro de las instrucciones enviadas a la base de datos por parte del usuario actual, y los mensajes de error si los hubiera.

Cada llamado a la base de datos se registra con el nombre del módulo, el nombre de la consulta y el momento de su ejecución. Si bien las consultas no se muestran de un modo muy legible inicialmente, por medio del botón de identar se acomodan y colorean de una forma estándar.

Finalmente, en la parte inferior de la pantalla encontramos el botón para limpiar el registro.

Adjuntos

La sección de adjuntos se compone de dos partes, donde la primera se utiliza únicamente para establecer el ícono del módulo, y la segunda para agregar los archivos adicionales que puedan ser referenciados y utilizados.

Los íconos ingresados se ajustarán automáticamente al tamaño de 60x60 píxeles, y por motivos de conveniencia estética es conveniente utilizar imágenes cuadradas y con fondo transparente. El buscador de imágenes de Google puede hacer de esto una tarea muy sencilla.

Más abajo, para los adjuntos adicionales, se muestra la ruta de acceso por medio de la cual podrán ser referenciados.

06. Ejemplos de desarrollo

A continuación, explicaremos cómo es el proceso de desarrollo de nuevos módulos con Pler, contemplando mediante algunos ejemplos los casos más comunes y frecuentes. Este capítulo está orientado a programadores con conocimientos básicos de Sql, Html y Javascript.

Para estos ejemplos utilizaremos la siguiente estructura de datos, consistente únicamente en dos tablas llamadas “articulo“ y “articulotipo“ respectivamente.

CREATE TABLE articulo (

articuloid INT IDENTITY NOT NULL,

articulo VARCHAR (256) NOT NULL,

codigo VARCHAR (50) NOT NULL,

habilitado BIT NOT NULL,

pler_adjuntoidimagen INT NULL,

articulotipoid INT NOT NULL,

observaciones VARCHAR (MAX) NULL,

PRIMARY KEY (articuloid)

)

GO

CREATE TABLE articulotipo (

articulotipoid INT IDENTITY NOT NULL,

articulotipo VARCHAR (50) NOT NULL,

PRIMARY KEY (articulotipoid)

)

GO

Inmediatamente después de crear las tablas, o luego de realizar cualquier modificación en la estructura de datos, debemos ejecutar el procedimiento que actualiza los triggers automáticos de auditoría mediante la siguiente instrucción.

EXEC sp_pler_armar_nokick

Luego de esto, veremos que cada una de las tablas tendrán cuatro nuevos campos con datos de auditoría, que contendrán respectivamente:

“ins_usuario”: Nombre del usuario que insertó el registro.

“ins_fecha”: Fecha y hora de la inserción del registro.

“aud_usuario”: Nombre del usuario que realizó la última modificación.

“aud_fecha”: Fecha y hora de la última modificación.

Para insertar algunos datos de prueba antes de comenzar, es necesario identificarse en la base de datos como un usuario de Pler. En caso contrario las operaciones de inserción no tendrán efecto, ya que sin nombre de usuario no podrían ser auditadas. La instrucción para identificarnos como el usuario “sistema” es la siguiente:

EXEC sp_pler_sesion 'sistema'

Luego, estando ya identificados, insertamos algunos valores en las tablas como en el ejemplo que sigue.

INSERT INTO articulotipo (articulotipo)

VALUES ('Tipo A'), ('Tipo B'), ('Tipo C')

INSERT INTO articulo (articulo, codigo, habilitado, articulotipoid, observaciones)

VALUES

('Artículo 1', 'A1', 1, 1, 'Hola mundo!'),

('Artículo 2', 'A2', 1, 1, NULL),

('Artículo 3', 'A3', 1, 2, NULL),

('Artículo 4', 'A4', 1, 3, NULL)

Agregando “/der” en la url del sistema, podremos ver un diagrama con las tablas que hemos creado.

En este diagrama, los nombres de campos destacados en negrita son claves primarias, los campos en color azul son claves foráneas, y los signos de interrogación en color rojo indican que aún no existe ningún módulo en el sistema que esté haciendo uso de tales campos.

A medida que agreguemos módulos nuevos, que hagan uso de estos campos, los signos de interrogación irán desapareciendo.

En cuanto a las claves foráneas, el campo “articulotipoid” se relaciona con la tabla “articulotipo” y su clave primaria de forma automática por medio de la correspondencia de nombres. El campo “pler_adjuntoidimagen”, y cualquier campo cuyo nombre comience por el prefijo “pler_adjuntoid”, se relaciona automáticamente con la tabla de sistema “pler_adjunto”, que se utiliza para almacenar archivos binarios.

Tenga presente que, con doble click sobre cualquier tabla de este diagrama, podrá obtener los scripts de ejemplo para lectura, actualización y eliminación de datos.

Luego de haber preparado y repasado estos preliminares, comencemos con el primer ejemplo.

06.01. Módulo de listado de artículos

En este ejemplo nos proponemos hacer un listado de artículos, con algunos parámetros de filtro, y que nos permita llegar a las pantallas de edición específicas para cada uno.

Comenzaremos por crear un nuevo grupo de módulos, que nos permita ubicar a nuestro módulo en el menú y en el escritorio.

Con el icono de “programación” accedemos al IDE integrado de Pler, y una vez ahí, con el ícono de “agregar nuevo módulo” obtenemos el primer módulo llamado “NUEVO”.

Esto no será realmente un módulo sino el grupo o carpeta que contendrá a nuestro proyecto de ejemplos. Para configurarlo como carpeta, le haremos click para acceder a su configuración, y lo dejaremos únicamente con un código y un nombre.

Al no ingresar ninguna ubicación, estamos indicando que esta carpeta estará ubicada directamente en el escritorio, al nivel raíz, y en el primer nivel más visible del menú. También debemos activar los checks de “módulo activado” y de “aplica permisos”.

Luego, con click en “guardar”, volveremos al listado de módulos donde podremos ver nuestro módulo llamado “Ejemplos”, que usaremos a modo de carpeta, y agregaremos un módulo más.

Esta vez indicaremos como ubicación a la carpeta “ejemplos” creada previamente.

Los pasos mencionados hasta ahora se refieren al procedimiento general de desarrollo y se aplican a la creación de cualquier módulo nuevo. Ahora, para comenzar a desarrollar éste módulo en concreto, haremos click en aplicar, para salvar el nombre y la configuración que ya hemos ingresado, e iremos a la sección de “querys”.

La definición de los “querys”, o en criollo las “consultas”, es lo que nos dará como resultado la primera maqueta del módulo, con código generado automáticamente. Para esto comenzaremos por agregar un nuevo query e ingresar el siguiente script, tomado de los ejemplos del DER, pero modificado para recibir dos parámetros y para relacionarse con la otra tabla que estamos usando.

DECLARE @buscar VARCHAR ( MAX )

DECLARE @articulotipoid INT

SET @buscar = ?

SET @articulotipoid = ?

SELECT

a.articuloid ,

a.articulo ,

at.articulotipo ,

a.codigo ,

a.habilitado ,

a.observaciones

FROM articulo a

LEFT JOIN articulotipo at ON at.articulotipoid = a.articulotipoid

WHERE (

@buscar IS NULL

OR a.articulo LIKE '%' + @buscar + '%'

OR a.observaciones LIKE '%' + @buscar + '%'

)

AND a.articulotipoid = ISNULL ( @articulotipoid , a.articulotipoid )

ORDER BY 2 , 1

En este caso no será necesario ingresar un nombre para la consulta, pero si será necesario indicar que esta consulta se ejecutará “al inicio” y que devuelve, o “entrega” un set de datos, es decir, un objeto con listado de registros.

Con click en “guardar” volveremos al listado de querys del módulo, donde se muestra que nuestra consulta no tiene nombre, que se ejecuta al iniciar el módulo, que recibe dos parámetros, y que entrega un objeto de datos con seis campos.

Volviendo a la sección de “config” también veremos que el módulo ha quedado deshabilitado. Esto sucede toda vez que se modifica alguna consulta de un módulo, y el módulo en cuestión deberá volver a ser habilitado para estar disponible.

Por medio del botón con la leyenda “Bootstrap 3” generaremos la primera maqueta utilizando pantallas al estilo de tal framework, y nos dirigiremos a la sección de “preview”, o vista previa, donde podremos ver un primer resultado.

Como era de esperarse, obtenemos un listado de seis columnas, y un encabezado de filtro, con dos parámetros.

Sin embargo, el parámetro llamado “articulotipoid” está recibiendo números y no opciones legibles. Para solucionar esto, agregaremos un nuevo query, con el mismo nombre del parámetro, y que servirá para mostrar sus opciones.

El query que utilizaremos será este:

DECLARE @buscar VARCHAR ( MAX )

SET @buscar = ?

SELECT a.articulotipoid, a.articulotipo tipo

FROM articulotipo a

WHERE @buscar IS NULL

OR a.articulotipo LIKE '%' + @buscar + '%'

ORDER BY 2 , 1

En este caso si será necesario ingresar un nombre, que sea igual que el nombre del parámetro al que estará relacionado, y de nuevo indicaremos que la consulta entrega un set de datos.

Volviendo a generar el código automático, obtendremos que, ahora sí, el parámetro se ha convertido en un control de selección.

Las opciones presentadas por este control, al hacer click, se corresponden con la definición de su consulta, donde el primer campo devuelto se utiliza para el “id”, o valor interno, y el resto de campos, en este caso solo uno, se muestran como opciones legibles.

Con esto termina la parte automática, al obtener, a partir de las consultas, una vista previa que represente nuestra primera intención. El resto del trabajo sobre el módulo consistirá principalmente en ajustar el Html, el Javascript, y los estilos Css, al comportamiento que esperamos con más exactitud.

Pero antes de continuar, volvamos a activar el módulo, que quedó desactivado al haber agregado la última consulta, y veamos qué es lo que ya hemos obtenido hasta este momento.

En el escritorio encontramos una carpeta, o grupo de módulos, llamada “ejemplos”, que contiene un módulo, llamado “listado de artículos”.

Al abrir nuestro módulo nos encontramos con el listado, tal y como lo teníamos en la vista previa, pero vemos que al hacer click sobre cada registro no tenemos ninguna acción definida, y que al modificar alguno de los valores de los parámetros, estos aún no están teniendo ningún efecto. Para solucionar esto, volveremos al IDE, donde haremos algunos ajustes.

Comenzando por los parámetros, en la sección de “html”, haremos que estos surtan efecto al agregar un llamado al método que recarga el listado, en cada uno de los eventos “onchange” de cada uno de los dos parámetros. Así, al modificar alguno de ellos, se actualizará el listado.

Luego en la sección de “scripts” buscaremos el método que procesa y le da un formato a cada registro de resultados, y modificaremos el evento “onclick”, para que tenga como efecto el llamado a un nuevo módulo, que mostrará cada uno de los artículos y permitirá modificarlo.

Pues bien, llegados a este punto, veremos que el click sobre cada registro nos mostrará un error de acceso. Esto sucede porque aún no existe ningún módulo cuyo código sea “articulo_editar”. Y con esto quedamos a las puertas del ejemplo siguiente, que complementará a este listado.

06.02. Módulo de edición de un artículo

En este ejemplo veremos un módulo que muestra y permite modificar los datos de un artículo, y que, a diferencia del anterior, que se iniciaba desde el escritorio, se iniciará mediante un llamado desde el listado de artículos, recibiendo como parámetro el id del artículo seleccionado.

Para que el módulo funcione de éste modo, deshabilitaremos el check que indica que se puede iniciar desde el escritorio.

En la sección de “querys” utilizaremos los tres ejemplos de scripts tomados del DER para la tabla “articulo”, tomados tal cual, con copiar y pegar, utilizando uno por cada evento de usuario, más la consulta para seleccionar las opciones de tipo de artículo, igual que en el ejemplo anterior.

Y a la primera consulta, vinculada al evento inicial, le pondremos una pequeña modificación, para que se relacione con la tabla de tipos de artículos, y nos entregue su descripción desde el comienzo además del número de id.

En el resultado de generar la primera vista previa podemos observar que en el menú superior obtenemos los botones para aplicar y guardar, y para eliminar, vinculados a los scripts de tales eventos.

Luego, dado que los scripts reciben y entregan variables simples, por cada campo tendremos un control de usuario en la pantalla con algunas diferencias entre ellos según el tipo de dato.

El tipo de artículo, “articulotipoid”, al estar como un nombre de campo simple y como un nombre de consulta, se convierte en un control de selección igual que sucedía en el ejemplo anterior.

El campo cuyo nombre comienza por el prefijo “pler_adjuntoid” se convierte en un control para adjuntar archivos binarios. El binario se almacena en una base auxiliar al momento de seleccionarlo, y luego al guardar los datos lo que se guarda es la referencia al id del binario ya cargado.

Los campos de tipo bit, que solo admiten los valores 0 y 1, se muestran como un check.

Si bien esto ya podría estar funcionando, para completarse requerirá algunos ajustes sobre el código generado de forma automática. Podemos comenzar por ejemplo reacomodando el Html, y eliminando los controles sobrantes.

En el caso particular del control del archivo adjunto, deberemos cambiar el nombre del evento “onchange” por el evento “onload”.

Y en la sección de scripts, en el método “onload”, deberemos eliminar el código que haga referencia a controles eliminados, vincular la descripción del tipo de artículo al control de selección, que combina el id y la descripción, y de paso, también podemos agregar la instrucción para que se modifique la leyenda de la pestaña del módulo según el nombre del artículo mostrado.

Lo siguiente será mejorarlo, dejarlo más lindo y hacer algunas pruebas para mejorar la experiencia del usuario, pero en principio ya tenemos el módulo completo y funcionando.

06.03. Listado editable estilo grilla

En este ejemplo, a diferencia del anterior, donde se usaba un módulo para listar artículos y otro para modificarlos, pondremos todo junto en un listado editable.

Al poner dos consultas con el mismo nombre, una para el evento inicial y otra para el evento de guardar, las cuales entregan y reciben varios registros, la maqueta resultante será una tabla editable que usará esas consultas para obtener y guardar sus datos respectivamente.

De nuevo, los scripts están tomados del ejemplo del DER con algunos ajustes. La primera consulta es la siguiente, que recibe un solo parámetro y entrega varios campos:

DECLARE @buscar VARCHAR ( MAX )

SET @buscar = ?

SELECT

a.articuloid ,

a.articulo ,

at.articulotipoid ,

at.articulotipo ,

a.codigo ,

a.habilitado ,

a.observaciones ,

a.pler_adjuntoidimagen ,

CONVERT ( BIT ,

CASE WHEN dbo.f_pler_deps ( 'articulo' , a.articuloid ) IS NOT NULL THEN 1 ELSE 0 END

) utilizado

FROM articulo a

LEFT JOIN articulotipo at ON at.articulotipoid = a.articulotipoid

WHERE @buscar IS NULL

OR a.codigo LIKE '%' + @buscar + '%'

ORDER BY a.articulo , a.articuloid

La consulta para guardar la tomamos tal cual viene del DER, aprovechando que combina las instrucciones de insert y update:

DECLARE @articuloid INT

DECLARE @articulo VARCHAR ( 256 )

DECLARE @articulotipoid INT

DECLARE @codigo VARCHAR ( 50 )

DECLARE @habilitado BIT

DECLARE @observaciones VARCHAR ( MAX )

DECLARE @pler_adjuntoidimagen INT

SET @articuloid = ?

SET @articulo = ?

SET @articulotipoid = ?

SET @codigo = ?

SET @habilitado = ?

SET @observaciones = ?

SET @pler_adjuntoidimagen = ?

SET @habilitado = ISNULL ( @habilitado , 0 )

IF @articulo IS NOT NULL AND @articulotipoid IS NOT NULL AND @codigo IS NOT NULL BEGIN

IF @articuloid IS NOT NULL BEGIN

UPDATE articulo SET

articulo = @articulo ,

articulotipoid = @articulotipoid ,

codigo = @codigo ,

habilitado = @habilitado ,

observaciones = @observaciones ,

pler_adjuntoidimagen = @pler_adjuntoidimagen

WHERE articuloid = @articuloid

END ELSE BEGIN

INSERT INTO articulo (

articulo , articulotipoid , codigo , habilitado , observaciones , pler_adjuntoidimagen

)

VALUES (

@articulo , @articulotipoid , @codigo , @habilitado , @observaciones , @pler_adjuntoidimagen

)

END

END

Y para eliminar los registros que se quiten de la tabla, agregamos otra consulta en el mismo evento de guardar:

DECLARE @mostrados VARCHAR ( MAX )

SET @mostrados = ?

DELETE FROM articulo

WHERE articuloid IN (

SELECT num

FROM dbo.f_pler_split_int ( @mostrados )

)

AND articuloid NOT IN (

SELECT id

FROM dbo.f_pler_id_insupd ( 'articulo' )

)

AND dbo.f_pler_deps ( 'articulo' , articuloid ) IS NULL

Con esto hecho, generamos el código fuente automático y vemos la primera vista previa.

Como en los ejemplos anteriores, llegados hasta aquí ya tenemos el back-end funcionando, y lo que resta son hacer los ajustes en el front-end para para quitar los controles