01 Administración del sistema©cnico.doc · Web view2020. 8. 31. · PLER SALUD. Manual...
139
SISTEMAS PLER PLER SALUD Manual Técnico Versión MT.01.09 1
Transcript of 01 Administración del sistema©cnico.doc · Web view2020. 8. 31. · PLER SALUD. Manual...
SISTEMAS PLER
PLER SALUD
Manual TécnicoVersión MT.01.09
1
SISTEMAS PLER
Índice de contenido01. Introducción.................................................................................................................6
01.01. Usuarios y roles................................................................................................6
01.02. Módulos............................................................................................................6
01.03. Establecimientos...............................................................................................7
01.04. Auditoría...........................................................................................................7
01.05. Licencias...........................................................................................................8
02. Instalación y actualización........................................................................................10
02.01. Requerimientos...............................................................................................10
02.02. Framework Pler..............................................................................................10
02.03. Instalación sin framework..............................................................................11
02.04. IDE integrado.................................................................................................11
02.05. Bases de datos.................................................................................................12
02.06. Instalación en Windows Server......................................................................13
JDK de Java 8......................................................................................................13
Apache Tomcat....................................................................................................14
SQL Server..........................................................................................................15
Framework Pler...................................................................................................17
Módulos...............................................................................................................19
Memoria de Tomcat............................................................................................20
02.07. Configuración de parámetros generales.........................................................20
03. Conceptos generales..................................................................................................22
03.01. Administración de usuarios............................................................................22
03.02. Habilitación de módulos.................................................................................23
03.03. Indicadores de rendimiento............................................................................24
03.04. Operaciones de bases de datos.......................................................................25
03.05. Personalización estética del sistema...............................................................26
03.06. Ayudas en línea..............................................................................................26
04. Herramientas de administración................................................................................28
04.01. Ajustar tamaños de bases................................................................................28
04.02. Copias de seguridad........................................................................................29
04.03. Pool de conexiones.........................................................................................29
04.04. Trazado de consultas......................................................................................30
2
SISTEMAS PLER
04.05. Mantenimiento de índices...............................................................................31
04.06. Archivo de auditoría.......................................................................................31
04.07. Prueba de rendimiento....................................................................................32
04.08. Registro de auditoría.......................................................................................33
05. IDE Integrado............................................................................................................35
05.01. Listado de módulos.........................................................................................35
Indicadores por módulo.......................................................................................35
Opciones generales..............................................................................................36
Accesos simultáneos............................................................................................39
05.02. Edición de módulos........................................................................................40
Configuración......................................................................................................42
Consultas SQL (back end)...................................................................................44
Editor de consultas..............................................................................................46
Objeto interfaceJS...............................................................................................47
HTML, JS y CSS (front end)...............................................................................48
Vista previa..........................................................................................................49
Informes...............................................................................................................50
Log de consultas..................................................................................................50
Adjuntos..............................................................................................................51
06. Ejemplos de desarrollo..............................................................................................52
06.01. Módulo de listado de artículos.......................................................................54
06.02. Módulo de edición de un artículo...................................................................59
06.03. Listado editable estilo grilla...........................................................................61
06.04. Informes..........................................................................................................64
07. Instalación de escritorio.............................................................................................66
07.01. Instalación de SQL Server Express................................................................66
07.02. Instalación de Pler en versión de escritorio....................................................67
07.03. Inicio de la aplicación.....................................................................................67
Anexo I – Manual de desarrollo......................................................................................69
Editor de módulos (IDE integrado)...........................................................................69
Editor de querys...................................................................................................69
Configuración de módulos..................................................................................70
Edición de módulos.............................................................................................71
3
SISTEMAS PLER
Diseño de módulos..............................................................................................72
Diseño de informes..............................................................................................73
Back-end (interfaceJS)..............................................................................................73
Datos del módulo.................................................................................................73
Métodos del módulo............................................................................................74
Eventos del módulo.............................................................................................75
Objetos de datos (RS, RQ)........................................................................................76
Propiedades de RS...............................................................................................76
Métodos básicos de RS........................................................................................77
Métodos avanzados de RS...................................................................................77
Front-end (JavaScript)...............................................................................................78
Variables globales...............................................................................................79
Funciones y métodos de clases globales.............................................................79
Funciones de conversión de fechas.....................................................................80
Funciones de validación......................................................................................80
Funciones de Date / Time Picker.........................................................................80
Funciones generales de interface (UI).................................................................81
Funciones adicionales..........................................................................................81
JavaScript avanzado de Pler................................................................................82
Reportes.....................................................................................................................82
Funciones de reportes..........................................................................................82
Expresiones de reportes.......................................................................................83
Base de datos.............................................................................................................83
Diseño de tablas...................................................................................................84
Procedimientos SQL............................................................................................84
Funciones SQL....................................................................................................86
Ejemplos SQL.....................................................................................................87
Bases y tablas del sistema................................................................................................89
Bases de datos del sistema.........................................................................................89
Tablas de módulos.....................................................................................................89
Tablas de usuarios y permisos...................................................................................90
Tablas de archivos adjuntos.......................................................................................90
Tablas de manuales....................................................................................................91
4
SISTEMAS PLER
Auditoría reciente y archivada...................................................................................92
Anexo II – Informe sobre la validez de la historia clínica electrónica............................93
Informe 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.......................................93
Diferencia entre la firma electrónica y la firma digital.............................................99
Exclusiones a la documentación electrónica: El consentimiento informado..........101
Problemas a resolver................................................................................................101
Conclusiones............................................................................................................102
5
SISTEMAS PLER
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.
6
SISTEMAS PLER
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
7
SISTEMAS PLER
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 ta-blas 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 inser-ció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
8
SISTEMAS PLER
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.
9
SISTEMAS PLER
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
10
SISTEMAS PLER
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,
11
SISTEMAS PLER
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”.
12
SISTEMAS PLER
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.
13
SISTEMAS PLER
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.
14
SISTEMAS PLER
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.
<Connectorport="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.
<tomcat-users><user
username="admin"password="aaaaaaaaaa"roles="admin-gui,manager-gui"
/></tomcat-users>
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.
15
SISTEMAS 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.
16
SISTEMAS PLER
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.
17
SISTEMAS PLER
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.
18
SISTEMAS PLER
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.
19
SISTEMAS PLER
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
20
SISTEMAS PLER
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
21
SISTEMAS PLER
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.
22
SISTEMAS PLER
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
23
SISTEMAS PLER
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
24
SISTEMAS PLER
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
25
SISTEMAS PLER
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.
26
SISTEMAS PLER
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.
27
SISTEMAS PLER
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
28
SISTEMAS PLER
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.
29
SISTEMAS PLER
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,
30
SISTEMAS PLER
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
31
SISTEMAS PLER
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.
32
SISTEMAS PLER
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
33
SISTEMAS PLER
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.
34
SISTEMAS PLER
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.
35
SISTEMAS PLER
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.
36
SISTEMAS PLER
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
37
SISTEMAS PLER
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.
38
SISTEMAS PLER
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.
39
SISTEMAS PLER
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.
40
SISTEMAS PLER
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.
41
SISTEMAS PLER
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.
42
SISTEMAS PLER
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
43
SISTEMAS PLER
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
44
SISTEMAS PLER
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.
45
SISTEMAS PLER
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
46
SISTEMAS PLER
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.
47
SISTEMAS PLER
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.
48
SISTEMAS PLER
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.
49
SISTEMAS PLER
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.
50
SISTEMAS PLER
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.
51
SISTEMAS PLER
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:
52
SISTEMAS PLER
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.
53
SISTEMAS PLER
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.
54
SISTEMAS PLER
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.observacionesFROM articulo aLEFT JOIN articulotipo at ON at.articulotipoid = a.articulotipoidWHERE ( @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.
55
SISTEMAS PLER
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 )
56
SISTEMAS PLER
SET @buscar = ?
SELECT a.articulotipoid, a.articulotipo tipoFROM articulotipo aWHERE @buscar IS NULLOR 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
57
SISTEMAS PLER
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.
58
SISTEMAS PLER
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,
59
SISTEMAS PLER
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.
60
SISTEMAS PLER
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 ) utilizadoFROM articulo aLEFT JOIN articulotipo at ON at.articulotipoid = a.articulotipoid
61
SISTEMAS PLER
WHERE @buscar IS NULLOR 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 INTDECLARE @articulo VARCHAR ( 256 )DECLARE @articulotipoid INTDECLARE @codigo VARCHAR ( 50 )DECLARE @habilitado BITDECLARE @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 ) ENDEND
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 articuloWHERE 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.
62
SISTEMAS PLER
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 que sobran a justar el funcionamiento a lo esperado.
En el Html, lo que se modificó a mano es el parámetro de búsqueda, reubicado y haciendo que recargar el contenido de la tabla en el evento “onchange”.
Y un poco más abajo, se acomodaron los encabezados de la tabla.
Luego, en los “scripts”, en el evento “onload”, hubo que hacer que la variable “interfaceJS.mostrados” reciba como valor la lista de ids mostrados, que se requieren en la última consulta del evento de guardar.
Más abajo, dentro del bucle que recorre cada uno de los registros de resultados y lo vincula una celda de la tabla en la pantalla, ajustamos la leyenda visible del control
63
SISTEMAS PLER
que guarda el id del tipo de artículo, y hacemos que el icono para eliminar el registro se oculte en los casos en los que el registro no pueda ser eliminado por estar ya en uso, siendo referenciado desde alguna otra tabla del sistema.
Y la modificación final, es retocar el método que arma cada una de las filas de la tabla, para que concuerde con el encabezado y que guarde el id de cada artículo, pero sin mostrarlo, en un input de tipo hidden.
Y con esto ya está funcionando. Lo demás serán pruebas y mejorar la experiencia de usuario.
06.04. Informes
Para este ejemplo partiremos del módulo del primer ejemplo, haciéndole un clon que, tenga exactamente los mismos scripts del listado, y sobre lo cual haremos un nuevo front-end.
En principio la única modificación que haremos será regenerar todo el front-end, pero utilizando el botón para informes. Y quitaremos los includes que se habían agregado antes de clonar el módulo.
64
SISTEMAS PLER
Luego desde la vista previa, con un click en “mostrar”, ya podemos ver que la consulta, que devuelve una tabla de datos, se tradujo a una tabla imprimible con un encabezado de parámetros. Esto es el formato básico para cualquier informe.
Los informes, a diferencia del resto de los módulos, tienen una sección específica para el Html del contenido del “reporte”, con una notación especial que permite controlar el flujo de su armado por medio de bucles y condiciones.
El contenido de esta sección especial se refiere únicamente al contenido del reporte, es decir, a lo que se quiere mostrar, sin encabezado, parámetros ni opciones. En caso de querer ajustar estas cosas, usaremos las secciones de Html, Javascript y Css, como lo hacemos con cualquier módulo convencional.
65
SISTEMAS PLER
07. Instalación de escritorio
La instalación de escritorio consiste en una versión simplificada que empaqueta el framework Pler, el SDK de Java 8 y el servidor Apache Tomcat, en una distribución portable, de modo que se pueda iniciar y detener fácilmente, tanto para ambientes de desarrollo como para instalaciones independientes que deban ejecutarse sobre equipos portátiles o de escritorio.
El único componente que debe instalarse por separado es el motor de base de datos de SQL Server. Para esto pueden utilizarse las versiones de distribución gratuita Express o Developer, pero tenga en cuenta que en el primer caso se limita el tamaño máximo de las bases a 10 GB, y que en el segundo la licencia no es válida para ambientes de producción.
07.01. Instalación de SQL Server Express
Para facilitar la instalación de la distribución gratuita Express, podemos utilizar el instalador silencioso, funciona de modo desatendido y establece los parámetros de configuración esperados por la instalación de escritorio.
Dado que es posible que existan otras instancias de SQL Server sobre el equipo en el cual se está realizando la instalación, el instalador silencioso utiliza el nombre de instancia “pler” para diferenciarse de cualquier otra preexistente.
Los parámetros establecidos en la instalación silenciosa también habilitan la autenticación del SQL Server y el nombre de usuario “sa”, con contraseña “PlerPassword88” y privilegios de sysadmin.
Tenga en cuenta que las instancias nombradas requieren tener iniciado el servicio adicional “SQL Server Browser”, que vincula los nombres de instancia con sus respectivos puertos.
66
SISTEMAS PLER
07.02. Instalación de Pler en versión de escritorio
Para instalar una versión de escritorio, luego de tener instalado el motor de base de datos, solo es necesario copiar los archivos portables.
En el caso de que se desee utilizar una instancia de SQL Server diferente de la mencionada en el punto anterior, por ejemplo con un servidor de base de datos remoto o preexistente, será necesario revisar la configuración de la conexión a la base de datos.
El archivo de configuración, de nombre “pler.conf”, se encuentra en la carpeta “web”. Si se desea, este archivo puede reubicarse fuera de la carpeta “web”, dentro de cualquiera de las carpetas de nivel superior y dentro de la misma ruta de acceso.
El parámetro dbServerDB contiene el nombre o dirección ip del servidor de datos, y en los casos en los que se utilice una instancia nombrada, el nombre de instancia se agrega luego de una contrabarra (“\”).
Si el nombre de la base de datos no existe en el servidor, se creará una nueva base vacía con dicho nombre en el primer inicio del sistema.
07.03. Inicio de la aplicación
Para comenzar a utilizar el sistema basta con ejecutar el archivo “pler.exe”. Esto iniciará el servicio de Pler y abrirá el navegador sobre la URL local del sistema.
67
SISTEMAS PLER
Adicionalmente, entre los íconos de la esquina inferior derecha de la barra de inicio de Windows, se mostrará una pequeña consolita con la opción de detener el sistema o reabrir una sesión desde el navegador.
68
SISTEMAS PLER
Anexo I – Manual de desarrollo
La siguiente documentación, tomada de las guías de ayuda en línea del IDE integrado, recorre los diferentes recursos provistos para el desarrollo y mantenimiento de aplicaciones con Pler.
Editor de módulos (IDE integrado)
La creación de un módulo con Pler comienza con la definición de los querys que conforman el back-end, y con la configuración del módulo, desde donde se generará un primer borrador del código fuente para el front-end. Desde el momento de generar este primer borrador, el módulo ya puede ser visible, utilizable y testeable desde el preview del editor de módulos.
En los pasos siguientes la codificación del front-end (en html, css y javascript) será acondicionada para ajustarse con exactitud a los requerimientos funcionales y a la expectativa estética. Este será el principal trabajo con Pler.
El primer borrador generado automáticamente es bastante simple y les da a los datos un tratamiento normal de ABM, y la lógica adicional debe agregarse manualmente con javascript. Sin embargo, este borrador ya es operativo y capaz de trabajar y modificar los datos de la base desde el comienzo, incluso desde el preview, por lo que debe utilizarse con mucho cuidado si se utiliza sobre un ambiente de producción. Tenga en cuenta que el editor de Pler permite realizar cambios en caliente (hot-swap) sobre cualquier ambiente.
También tenga presente que Pler no es un nuevo lenguaje, ni una librería específica, ni un paradigma de programación diferente del tradicional desarrollo con HTML+CSS+JS, y que por lo tanto podrá emplear cualquier ejemplo de sitios populares como stackoverflow o w3schools, o su propia experiencia, sin ninguna limitación.
Editor de querys
Cada vez que se agregue, se quite o se modifique un query en el editor de querys de Pler, se actualizará automáticamente la definición del objeto interfaceJS que representa al back-end del módulo.
Para poder reconocer los tipos de datos y asignar un nombre, Pler requiere que
69
SISTEMAS PLER
los parámetros (?) de cada query se reciban por medio de variables locales declaradas dentro del query.
DECLARE @articulotipoid INTSET @articulotipoid = ?SELECT articulotipoid, articulotipo, aud_usuario, aud_fechaFROM articulotipoWHERE articulotipoid = @articulotipoidORDER BY 2
Hay más ejemplos de esto al final de este documento.
Los querys de cada módulo se agrupan en primer lugar según el evento al que correspondan (al inicio, al guardar, al eliminar), y adicionalmente pueden agregarse nombres (nombre/grupo) para agrupar querys que se deban ejecutar juntos, o para vincular entre sí a determinado query de lectura con determinado query de escritura.
Los querys que no sean asignados a alguno de los tres eventos (inicio, guardar, eliminar) podrán llamarse desde interfaceJS por medio del nombre/grupo, pero los querys sin evento ni nombre no podrán llamarse de ninguna forma y mostrarán una alerta en el editor para que sean corregidos o eliminados.
En cuanto a los parámetros de ingreso y los valores de retorno, los querys se clasifican como valores simples, que reciben o entregan variables independientes para cada campo, o como set de datos (RS), que reciben o retornan un objeto de datos conteniendo una tabla. Por ejemplo, los listados o los querys para alimentar reportes deben indicar que devuelven un RS en su definición mientras que los datos de encabezado de un formulario deben definirse como valores simples.
Configuración de módulos
Código del módulo: Este es el código de identificador único del módulo. Para los módulos nuevos se genera un código numérico que deberá ser cambiado manualmente a un código alfanumérico. Los módulos con códigos numéricos no podrán ser exportados.
Nombre del módulo: Este es el nombre del módulo, tal y como se mostrará en el escritorio y en el título de la pestaña contenedora.
Ubicación (carpeta o módulo padre): La ubicación del módulo organizada en carpetas. Tenga en cuenta que las carpetas son módulos sin definición de querys ni front-end, pero que requieren un código alfanumérico al igual que el resto de los módulos. Los módulos ejecutables ubicados directamente en la raíz del árbol de carpetas no se mostrarán en el escritorio y deberán ser reacomodados dentro de alguna carpeta.
Punto de inicio (escritorio): Indica que el módulo se mostrará en el escritorio. Un módulo que no se muestra en el escritorio puede ser llamado, con o sin parámetros, desde otros módulos.
Aplica permisos: Indica que el módulo está sometido a definición de permisos por perfiles de usuario. Un módulo que no aplica permisos, hereda los permisos de la
70
SISTEMAS PLER
carpeta o módulo padre.
Es un informe: Indica que el módulo es un informe.
Timeout extendido: El tiempo de timeout normal para las acciones de base de datos es de 1 minuto. El timeout extendido es de 1 hora. Esto hay que usarlo solamente en casos excepcionales cuando sea realmente necesario.
Múltiples instancias: Indica si el módulo puede instanciarse múltiples veces al mismo tiempo, al llamarse con diferentes parámetros, en una misma sesión de usuario.
Generación de código: La generación automática de código crea el primer borrador para el front-end del módulo o del informe. El código se genera a partir del objeto de back-end (interfaceJS) y reemplaza, si existiera, al código fuente previo del front-end. Esta es una de las principales características de Pler, que le entrega el módulo bastante bien encarado en el inicio y le evita tener que ponerse a hacer todo el código desde cero.
Después de generar el front-end para un módulo estándar, habrá varias cosas que ajustar, como las leyendas de los campos, que inicialmente toman el nombre de las variables a las que representan, o los RS, que por defecto se muestran como grilla editable (RS y RQ) o listado de selección (RS solo). Para un informe estándar en cambio probablemente no sea necesario ningún ajuste posterior. Y por supuesto, si desea algo menos convencional, puede rehacerlo todo a mano y a su gusto.
Includes: Esta es una lista de librerías JS con funcionalidades avanzadas para diferentes tareas. Si no encuentra la librería que necesita, puede agregarla al módulo como un archivo incluido (files) junto con las imágenes, iconos, archivos multimedia, etc.
Edición de módulos
La edición de los módulos normalmente comenzará una vez que haya definido los querys que conforman el back-end, y cuando con esto ya haya logrado una primera vista aceptable (del front-end) en el preview, usando la generación de código automático que aparece entre las opciones de configuración.
El preview del editor de Pler muestra lo mismo que luego se verá en el módulo finalmente desplegado, con la única diferencia de que el preview interpreta el código fuente aún sin minificar.
La minificación de Pler consiste solamente en quitar los espacios redundantes y los saltos de línea innecesarios, causando que los scripts queden "planchados" en una sola línea. Como resultado es posible que en algunos casos la omisión del punto y coma (;) como final de instrucción no muestre ningún error en el preview, pero que si lo haga en el módulo ya desplegado. Esta es la única diferencia que se podría presentar.
El cambio de íconos de escritorio admite cualquier imagen con fondo transparente y que sea (más o menos) cuadrada, no rectangular. En realidad se puede poner cualquier cosa, pero si no es cuadrada o no es transparente, va a quedar medio fea. El buscador de imágenes de Google ayuda mucho en esto. Los ajustes de tamaño y formato se hacen automáticamente.
71
SISTEMAS PLER
Tenga en cuenta que antes de comenzar a modificar un módulo ya existente es conveniente tener una copia exportada como respaldo, por si todo sale mal, para tener un lugar a donde volver.
Diseño de módulos
El diseño de módulos con Pler empleando la (re)generación de código consiste en definir y modificar los querys hasta que el preview muestre una primera versión aceptable, que luego será personalizada.
Para familiarizarse con esto conviene tener presente que las cuatro principales acciones en bases de datos (SELECT, INSERT, UPDATE y DELETE) se corresponden con tres (no cuatro) acciones de usuario en el front-end:
Inicio (o lectura) --> SELECTGuardar --> INSERT y UPDATEEliminar --> DELETE
Para un query que se ejecuta al inicio y entrega algunos campos como valores simples (variables), si existe un query con el mismo nombre de grupo que se ejecuta al guardar y que recibe también valores simples, entonces el módulo tomará a cada uno de esos campos como variables de lectura y escritura, que se leerán al iniciar el módulo, y se guardarán en el evento guardar, con el botón de guardar. En este caso la (re)generación de código creará un control en HTML para cada campo.
Para un query que se ejecuta al inicio y entrega algunos campos como set de datos (no valores simples), si existe un query con el mismo nombre de grupo que se ejecuta al guardar y que recibe también un set de datos (que contenga los mismos nombres de campos, todos o algunos), entonces el módulo tomará al conjunto de campos como una tabla de lectura y escritura (RS y RQ respectivamente), que se leerá al iniciar el módulo, y se guardará en el evento guardar, con el botón de guardar. En este caso la (re)generación de código creará una tabla editable en HTML conteniendo los campos correspondientes.
Para querys que se ejecuten al inicio y no tengan un query correspondiente al guardar, los valores simples o set de datos también generarán controles o tablas en HTML. En el caso de los controles, serán editables aunque sus cambios no se guardarán con el código generado automáticamente. En el caso de las tablas, serán informativas, de solo lectura.
Cuando exista un query sin vinculación a los eventos (inicio, guardar, eliminar) cuyo nombre sea igual al nombre de un valor simple (campo o variable), entonces el control HTML generado será un control de selección que permitirá elegir una o más opciones de entre las ofrecidas por el query. Para generar un control de selección múltiple, el query de opciones debe recibir un parámetro de nombre "selected". Sin este parámetro el control solo podrá recibir un valor único.
Los controles de selección pueden recibir parámetros de filtro, por ejemplo "buscar" para filtrar las opciones mostradas, que se mostrarán en el encabezado de listado de opciones. Estos parámetros se toman de la lista de parámetros de la definición
72
SISTEMAS PLER
de los métodos q_ y r_ (sincrónicos y asincrónicos respectivamente) del objeto interfaceJS, de modo que sobrecargando estas definiciones se puede modificar el resultado de las opciones mostradas.
Diseño de informes
En general, un informe es un módulo convencional, pero que no tiene eventos de guardar ni eliminar, y que agrega facilidades para la impresión y exportación de datos.
El motor de reportes de Pler procesa todos los querys que se ejecuten al inicio y entreguen un set de datos. Con esto, la (re)generación de código, arma un primer borrador del reporte, mostrando los sets de datos como tablas y sus parámetros como opciones de filtro en el encabezado.
El contenido del reporte se modifica desde una sección aparte en el editor de módulos y agrega una lista de tags especiales que se detallan más adelante en este documento.
Back-end (interfaceJS)
Cada módulo de Pler instancia un objeto de back-end llamado interfaceJS, generado automáticamente a partir de los querys, que contiene todos los datos del módulo, los métodos para ejecutar consultas, y una serie de métodos estándar.
El front-end de cada módulo (html, script, style) interactúa con el servidor, con la base de datos y con el framework de Pler por medio de este objeto.
Datos del módulo
Todos los datos de cada módulo, recibidos o devueltos por los querys, se almacenan como propiedades de interfaceJS.
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 los querys como a sus valores de retorno.
interfaceJS.valor1interfaceJS.valor2interfaceJS.etc
Los sets de datos (ResultSet/RecordSet/DataSet) en cambio son almacenados en propiedades con nombres en letras mayúsculas.
interfaceJS.RS = datos()interfaceJS.RS_NOMBRE1 = datos()interfaceJS.RS_NOMBRE2 = datos()
73
SISTEMAS PLER
interfaceJS.RQ = datos()interfaceJS.RQ_NOMBRE1 = datos()interfaceJS.RQ_NOMBRE2 = datos()
En el ejemplo precedente se muestran las propiedades de un módulo con tres grupos de querys que reciben y envían sets de datos (no valores simples).
Los nombres de los grupos de querys se definieron uno como nombre1, otro como nombre2, más un grupo sin nombre, con lo que se obtienen las propiedades RS (valores de retorno del grupo sin nombre definido), RS_NOMBRE1 (valores de retorno del grupo nombre1), y RS_NOMBRE2 (valores de retorno del grupo nombre2).
Los sets de datos recibidos (que se obtienen de la base de datos) se identifican en el nombre porque comienzan siempre con RS. Los sets de datos de envío (que se envían en conjunto a la base de datos) en cambio comienzan por RQ.
Es importante notar que el back-end guarda un espacio de nombres diferentes para los sets de datos que se obtienen y los que se envían a la base de datos (RS y RQ), pero no ocurre lo mismo con los valores simples como un campo de texto, un número o una fecha. Para los valores simples con el mismo nombre, los métodos de lectura y escritura utilizarán (y sobrescribirán) una misma variable.
Adicionalmente cada módulo contiene una propiedad con el código del módulo, otra con el id del módulo, y otra con una referencia al módulo invocador (cuando un módulo fue llamado desde otro, o null si fue llamado directamente desde el escritorio).
interfaceJS._modulo (código alfanumérico del módulo)interfaceJS._pler_moduloid (id del módulo ya instalado, este número se reescribe con cada instalación)interfaceJS._opener (referencia al objeto del módulo padre, o null)
Métodos del módulo
Para cada módulo de Pler los querys de datos se agrupan en tres categorías según si corresponden a las acciones de iniciar (SELECT, obtener datos iniciales), guardar (INSERT/UPDATE), o eliminar (DELETE).
interfaceJS.cargar(): Método de carga con el que se inicia el módulo.
interfaceJS.aplicar(salir): Método para guardar los cambios realizados sin salir del módulo.
interfaceJS.guardar(): Método para guardar los cambios realizados y cerrar el módulo. Equivalente a interfaceJS.aplicar(true);
interfaceJS.eliminar(): Método para eliminar la entidad representada por el módulo.
Los querys o grupos de querys con nombre que no estén agrupados en los eventos de iniciar, guardar y eliminar, son representados por medio de métodos sincrónicos con nombres en minúsculas que comienzan con q_ como en el ejemplo siguiente.
74
SISTEMAS PLER
interfaceJS.q_nombre1(param1, param2, param3)interfaceJS.q_nombre2(param1, param2, param3)
Para llamar a estos mismos querys pero con métodos asincrónicos, los nombres de los métodos comienzan r_ y reciben como primer parámetro la función de retorno (callback) que será llamada al finalizar la ejecución del query.
interfaceJS.r_nombre1(callback, param1, param2, param3)interfaceJS.r_nombre2(callback, param1, param2, param3)
Adicionalmente el back-end provee algunos métodos para interactuar con la gestión de aplicaciones y pestañas. Estos métodos no deben ser sobrecargados desde el front-end.
interfaceJS.recargar(force): Vuelve a cargar el módulo manteniendo los valores de las propiedades. El parámetro (opcional) indica que se forzará la recarga del módulo cuando haya cambios sin guardar.
interfaceJS.cerrar(force): Cierra el módulo. El parámetro (opcional) indica que se forzará el cierre del módulo cuando haya cambios sin guardar.
interfaceJS.throwAlert(message): Lanza una alerta.
interfaceJS.throwError(message): Lanza un error personalizado.
interfaceJS.setTitle(title): Cambia la leyenda de la pestaña del módulo.
interfaceJS.setParam(param): Reescribe el string de parámetros del módulo.
interfaceJS.getTitle(): Obtiene la leyenda de la pestaña del módulo.
interfaceJS.getParam(): Obtiene el string de parámetros del módulo.
interfaceJS.safeEditMode(valor): Activa o desactiva los avisos de cambios sin guardar. Este valor solo puede establecerse en verdadero para módulos con evento de aplicar o guardar. Para todos los módulos restantes el modo de control de cambios se establecerá siempre en falso.
interfaceJS.unsavedChanges(): Indica si hay cambios sin guardar.
Eventos del módulo
La programación de un módulo Pler normalmente consiste en sobrecargar algunos de los siguientes eventos desde el front-end interactuando con las propiedades de interfaceJS.
interfaceJS.onload(): Este es el evento principal. Ocurre una vez al iniciar el módulo, justo después de ejecutar interfaceJS.cargar(), y se repite cada vez que se ejecute interfaceJS.recargar().
interfaceJS.sincronizar(): Ocurre justo antes de ejecutar cualquier método que acceda a la base de datos y realiza la tarea de actualizar los objetos RQ.
Los siguientes eventos son de uso menos frecuente, pero bueno, ahí están, y
75
SISTEMAS PLER
cuando hacen falta, hacen falta.
interfaceJS.validar(): Ocurre justo antes de guardar o eliminar y realiza validaciones de último momento. Si devuelve falso, se interrumpe la acción.
interfaceJS.preload(): Evento previo a interfaceJS.onload().
interfaceJS.preclose(): Ocurre justo antes de ejecutar interfaceJS.cerrar(). Si devuelve falso, se interrumpe la acción, a menos que se trate de un cierre forzado.
interfaceJS.onclose(): Ocurre justo antes de cerrar el módulo y permite alertar sobre datos que no hayan sido guardados.
Objetos de datos (RS, RQ)
Los objetos de datos (RS, RQ) representan al equivalente de un ResultSet de Java, o un DataSet de .NET, o un RecordSet de ADO. En definitiva, una lista de registros que normalmente se obtiene de una instrucción SELECT de SQL y que se puede recorrer para leer o modificar sus datos.
Contienen filas (numeradas) y columnas (nombradas).
Propiedades de RS
RS.error: Descripción del error, cuando hubo algún error, obvio. Si no hubo error es null.
RS.pagesize: Tamaño de la página de resultados (cantidad de registros por página). Si se deja este valor en null, entonces no hay paginación.
RS.pagenum: Número actual de página de resultados o null si no hubo paginación.
RS.pagecount: Cantidad de páginas de resultados. (solo lectura)
RS.orderby: Nombre de la columna por la cual se reordenarán los datos, posterior al orden establecido en el query. Ejemplos: "aaa", "aaa, bbb", "aaa desc".
RS.length: Cantidad de registros.
RS.fields: Array de nombres de campos.
RS.data: Array bidimensional con los datos del objeto en crudo.
RS.position: Posición del registro actual. La primera posición es cero.
RS.firstPosition: Posición del primer registro del RS.
RS.lastPosition: Posición del último registro del RS.
76
SISTEMAS PLER
Métodos básicos de RS
RS.setFields(fields): Inicializa el objeto RS, establece la lista de campos según el parámetro fields y pone la cantidad de registros en cero. Devuelve el objeto RS.
RS.absolute(pos): Posiciona el objeto en el registro indicado. Devuelve true si el registro existe y false si no existe.
RS.next(): Avanza a la posición siguiente. Devuelve true para cualquier registro y false para EOF.
RS.previous(): Retrocede a la posición anterior. Devuelve true para cualquier registro y false para BOF.
RS.beforeFirst(): Posiciona el objeto en BOF.
RS.afterLast(): Posiciona el objeto en EOF.
RS.first(): Posiciona el objeto en el primer registro.
RS.last(): Posiciona el objeto en el último registro.
RS.get(field): Devuelve el valor del campo indicado en field para el registro de la posicion actual.
RS.set(field, value): Establece el valor (value) del campo indicado en field para el registro de la posición actual.
RS.isFirst(): Devuelve true cuando la posición actual es el primer registro y false para los demás.
RS.isLast(): Devuelve true cuando la posición actual es el último registro y false para los demás.
RS.getArray(field): Devuelve un array con los valores de la columna indicada en field.
RS.findFirstPosition(field, value, startPosition): Busca un valor en una columa. Devuelve la posición encontrada o -1 si no hubo coincidencias.
RS.deletePosition(pos): Elimina el registro de la posición indicada en pos o el registro actual si no se ingresó el parámetro pos. Devuelve true si el registro fue eliminado y false cuando el objeto no tiene más registros.
RS.addPosition(pos): Agrega un nuevo registro en la posición indicada en pos o al final si no se ingresó el parámetro pos.
RS.clear(): Borra todos los registros del objeto. Mantiene la definición de campos.
Métodos avanzados de RS
RS.parseText(file, formato, onload, onerror, onabort): Vacía el objeto RS y lo completa interpretando y cargando el contenido del archivo de texto ingresado en el objeto file.
77
SISTEMAS PLER
Ejemplo de formato para archivo de texto sin encabezado. Los nombres de los campos se indican en la definición de formato.
[ { field : "campo1" , pos : 1 , len : 10 } ,{ field : "campo2" , pos : 11 , len : 10 } ,{ field : "campo3" , pos : 21 , len : 10 } ]
Ejemplo de formato para archivo de texto con encabezado. Los nombres de los campos se obtienen de la primera línea del archivo.
[ { pos : 1 , len : 10 } ,{ pos : 11 , len : 10 } ,{ pos : 21 , len : 10 } ]
RS.parseCSV(file, separator, delimiter, fields, onload, onerror, onabort): Vacia el objeto RS y lo completa interpretando y cargando el contenido del archivo CSV (coma separated values) ingresado en el objeto file.
El valor de separator por defecto es punto y coma (;). El valor de delimiter por defecto es la comilla doble (").
El valor de fields por defecto es null, que indica que los nombres de los campos se leerán del encabezado del CSV. Si se indica un array de valores para fields, se interpretará que el archivo no tiene encabezado y la primera línea del registro será leída como datos.
RS.parseExcel(file, onload, onerror, onabort): Vacía el objeto RS y lo completa interpretando y cargando el contenido de la primera planilla del archivo de Excel (XLS, XLSX o CSV) ingresado en el objeto file. La fila 1 se interpretará como el encabezado con los nombres de los campos.
Tanto para parseExcel como para parseCSV y parseText, los eventos onload, onerror y onabort son opcionales, aunque sin el evento onload no se podría saber cuándo termino de parsearse la cosa... así que al menos ese debería estar. Yo personalmente no he visto nunca que se ejecutara el evento onabort, y el evento onerror sale cuando se ingresa un archivo con el formato incorrecto.
RS.saveAs(nombre): Descarga el contenido del objeto RS en el formato CSV de Excel. Funciona como si se descargara un archivo remoto, pero sucede todo en el navegador y es rapidísimo.
Front-end (JavaScript)
A continuación se muestra una lista de recursos disponibles en los módulos Pler.
78
SISTEMAS PLER
Variables globales
window.browser: Devuelve el nombre y número de versión del navegador (Chrome, MSIE, Opera, etc.).
window.mobile: Indica si se está utilizando un dispositivo móvil (true) o una computadora de escritorio (false).
window.versionmajor: Contiene el número de versionado mayor actual según el formato major[.minor[.micro[.build]]].
window.versionminor: Contiene el número de versionado menor actual según el formato major[.minor[.micro[.build]]].
window.versionmicro: Contiene el número de versionado micro actual según el formato major[.minor[.micro[.build]]].
window.buildnumber: Contiene el número de build actual según el formato major[.minor[.micro[.build]]].
Los números major, minor y micro corresponden a la versión del motor de Pler instalado. La numeración build se incrementa automáticamente cada vez que se modifica algún módulo.
window.landscape: Indica si la pantalla está en posición horizontal (cuando es mayor el ancho que la altura).
window.guest: Indica si el usuario es un invitado (usuario guest) que ha entrado anónimamente. El acceso anónimo puede permitirse o denegarse por medio del usuario guest.
Funciones y métodos de clases globales
window.alert(texto): En los módulos de Pler todos los llamados a la función alert() son reemplazados por un mensaje asincrónico que no detiene la ejecución de los scripts. Se pueden usar alertas sincrónicas convencionales, para debugging, con _alert().
Array.prototype.indexOf(obj, start): Devuelve la posición de obj dentro del array. Devuelve -1 cuando no lo encuentra.
String.prototype.trim(): Devuelve el string sin espacios al inicio ni al final.
String.prototype.ltrim(): Devuelve el string sin espacios al inicio.
String.prototype.rtrim(): Devuelve el string sin espacios al final.
String.prototype.replaceAll(token, newToken, ignoreCase): Devuelve el string reemplazado token por newToken.
Date.prototype.toDB(): Devuelve un string con la fecha expresada en el formato de la base de datos.
Date.prototype.toUI(): Devuelve un string con la fecha expresada en el formato la interface de usuario.
79
SISTEMAS PLER
Date.prototype.toH(): Devuelve un string con la hora. (hh:mm:ss)
Funciones de conversión de fechas
function dateParseDB(fecha): Recibe un string con una fecha expresada en el formato de la base de datos, y devuelve una fecha. (Date)
function dateParseUI(fecha): Recibe un string con una fecha expresada en el formato de la interface de usuario, y devuelve una fecha. (Date)
function dateParseUItoDB(fecha): Recibe un string con una fecha expresada en el formato de la interface de usuario, y devuelve un string con una fecha expresada en el formato de la base de datos.
function dateParseDBtoUI(fecha): Recibe un string con una fecha expresada en el formato de la base de datos, y devuelve un string con una fecha expresada en el formato de la interface de usuario.
function dateParseH5toUI(hora): Recibe un string con una hora y devuelve un string con la hora en formato hh:mm.
function dateParseH8toUI(hora): Recibe un string con una hora y devuelve un string con la hora en formato hh:mm:ss.
Funciones de validación
function validarFecha (obj): Devuelve true cuando obj.value contiene una fecha válida expresada en el formato de la interface de usuario.
function validarHora (obj): Devuelve true cuando obj.value contiene una hora válida hh:mm o hh:mm:ss.
function validarNumero (obj, tipo, prec): Devuelve true cuando obj.value contiene un número válido según tipo (tipo de dato) y prec (precisión). Los valores tipo y prec corresponden a los tipos de datos de la base de datos.
Funciones de Date / Time Picker
function seleccionarFecha(obj): Muestra un selector de fechas para cargar en obj.value.
function seleccionarFechaHora(obj): Muestra un selector de fecha y hora para cargar en obj.value.
function seleccionarHora(obj): Muestra un selector de horas para cargar en obj.value.
80
SISTEMAS PLER
Funciones generales de interface (UI)
function moduloPermitido(modulo): Devuelve true cuando el usuario tiene permiso para el módulo indicado. Recibe un string con el código del módulo.
function cargarModulo(modulo, parametros, newTab): Carga el módulo indicado. Los valores “parametros” (ejemplo: "nombre1=valor&nombre1=valor") y “newTab” son opcionales.
function onchangeForButtons(button): Habilita el evento onchange para el objeto button indicado. El objeto button no tiene evento onchange de forma nativa en HTML5. Si se omite el parámetro button, se aplica a todos los objetos button del módulo.
function fileUploaderInit(input): Habilita el upload automático en el objeto input indicado. Si se omite el parámetro input se aplica a todos los inputs con nombre (obj.name) igual a "pler_adjuntoid" o "pler_adjuntoid*". Una vez terminado el upload de un archivo, el valor input.value contendrá el id del archivo subido y almacenado. Si se aplica a un input con type distinto de "file", el input se convertirá a input/file.
function cloneWithEvents(node): Clona un elemento del arbol DOM incluyendo sus eventos. Imita a la función nativa clone(node) que no clona los eventos.
function entidadCargar(button, grupo): Deprecated. Usar loadOptions.
function loadOptions(button, grupo, callback): Muestra las opciones para un objeto button convertido en objeto de selección. El parámetro grupo (requerido) debe ser el nombre de un query o grupo de querys que devuelve las opciones permitidas. Cuando el grupo tiene un parámetro de nombre "seleccion" o "selected", el selector admitirá valores múltiples.
function stopEvent(): Detiene la propagación de eventos en el arbol DOM.
function tecla13(evento): Devuelve true cuando detecta que se presionó la tecla enter. El evento es opcional.
Funciones adicionales
function loadJS(src, callback): Carga dinámica de una librería de JavaScript.
function setCookie(cname, cvalue, exdays): Guarda una cookie.
function getCookie(cname): Lee una cookie.
function activarGeoLocation(activar): Activa el registro de coordenadas de ubicación del usuario en la tabla pler_coords. Recibe true o false.
function iif(condicion, sisi, sino): Equivalente a la expresión condicion ? sisi : sino. Esto lo puse porque soy un retrógrado de mierda.
function passwordHash(value, onload): Devuelve el hash de una cadena de texto por ejemplo un password. Recive el texto y una función de callback (opcional) para respuestas asincrónicas.
81
SISTEMAS PLER
function confirmar(texto, sisi, sino): Pide una confirmación de forma asincrónica mostrando las opciones de aceptar o cancelar. Se utiliza en lugar de confirm() para evitar el congelamiento del navegador. Recibe una cadena de texto con una pregunta o mensaje (texto) y dos funciones de callback (sisi y sino) para los casos de aceptar y cancelar respectivamente.
JavaScript avanzado de Pler
function deferall(): Difiere (des-sincroniza, pospone) la ejecución de eventos de controles que utilicen alguno de los métodos de datos del objeto interfaceJS. IMPORTANTE: Esta función se llama automáticamente al cargar cada módulo (para hacer más agradable la experiencia de usuario y evitar pantallas freezadas sin aviso), por lo que solamente debería emplearse si se agregan dinámicamente nuevos controles con eventos que soliciten datos.
"deferred": La expresión "deferred"; en un evento (así como está, con las comillas y el punto y coma), fuerza a que la función deferall() incluya el evento entre los eventos diferidos.
"nodeferred": La expresión "nodeferred"; en un evento, lo excluye de los eventos diferidos por deferall().
Reportes
Funciones de reportes
function reporteQuery(rs): Recibe un objeto RS (ResultSet/RecordSet) y devuelve un nuevo objeto de datos (q#, por ejemplo q1, q2, etc.) con el resultado del query en formato compatible con las expresiones del motor de reportes. La función reporteRender requiere que los objetos RS se conviertan con esta función.
function reporteRender(imprimir, cerrarpestana, onrendered): Inicia la ejecución del motor de reportes y devuelve el resultado en document.getElementById("viewer") o en document.body. El parámetro imprimir (opcional) indica si el reporte se imprimirá automáticamente. El parámetro cerrarpestana (opcional) indica si el módulo se cerrará automáticamente al terminar de procesarse.
interfaceJS.RS.saveAs(filename): Descarga el contenido del objeto RS en formato Excel. El parámetro de filename (opcional) indica el nombre del archivo de descarga.
function reportePDFtoDisk(filename): Descarga un archivo PDF con el contenido del reporte, tal y como se muestra en la pantalla.
function reportePDFtoMail(filename): Envía por email el reporte en formato
82
SISTEMAS PLER
PDF.
Para imprimir o generar PDFs con la hoja en posición horizontal utilice el siguiente estilo: @page {size: A4 landscape;}
Expresiones de reportes
La codificación de los reportes consiste en código HTML5 convencional más las siguientes expresiones a modo de tags que son interpretadas y procesadas por el motor de reportes de Pler.
<!{header}> <!{footer}>: Entrega encabezado y pie de página, si fueron definidos en los parámetros de la instalación de Pler.
<!{set variable=expresión}>: Guarda la expresión en una variable global del módulo.
<!{get expresión}>: Entrega la expresión.
<!{if condición}> ... <!{else}> ... <!{end}>: Expresión condicional.
<!{for constante}> ... <!{next}>: Expresión de iteración para grupos de datos. La constante identifica al objeto de datos (q#), por ejemplo: 1 para el objeto q1, 2 para el objeto q2, etc.
<!--ignorado-->: Expresión ignorada de HTML convencional.
Base de datos
Todas las tablas de datos, exceptuando las tablas de sistema cuyo nombre comienza por "_" (underscore) o "pler_", están sometidas a triggers de auditoría y seguridad.
Estos triggers invalidan el uso de @@IDENTITY y SCOPE_IDENTITY(), además de que no permiten modificar tablas a usuarios sin identificar ni iniciar sesiones en el sistema si hay tablas o campos que no estén asegurados.
Por eso, cada vez que se modifique la definición de una tabla, inmediatamente después es necesario llamar al procedimiento que reconstruye la auditoría antes de continuar con cualquier otra cosa, de otro modo el sistema no podrá seguir funcionando ni aun en ambientes de desarrollo o de testing.
EXEC sp_pler_armar_full: Reconstruye la seguridad y auditoría de la base de datos. Es necesario correr este procedimiento cada vez que modifique la definición de alguna tabla de usuario. Este procedimiento expulsa a todos los usuarios del sistema, además realiza algunas validaciones, y fundamentalmente asegura que luego de cualquier cambio el sistema no deje de funcionar.
EXEC sp_pler_armar_nokick: Reconstruye la seguridad y auditoría de modo liviano sin expulsar a los usuarios. Se recomienda usar solamente en ambientes de
83
SISTEMAS PLER
desarrollo para hacer lo mismo que sp_pler_armar_full pero de modo más ágil. Tenga en cuenta que este procedimiento efectúa solamente una reconstrucción parcial y que al realizar una instalación nueva o mover una base de lugar, es necesario el armado completo efectuado por sp_pler_armar_full.
EXEC sp_pler_sesion <username>: Le permite simular una sesión de usuario de Pler al conectarse a la base de datos desde una consola como el Management Studio. Si considera que este procedimiento es un riesgo para la seguridad, puede restringirlo o eliminarlo en los ambientes de producción.
Diseño de tablas
El diseño lógico de la base de datos (las tablas y sus relaciones) es la clave de una base de datos relacional optimizada. Un buen diseño lógico de la base de datos permite un rendimiento óptimo en la performance de las aplicaciones. En cambio, un diseño lógico deficiente, aunque pueda no ser muy notorio en ambientes de desarrollo donde las tablas suelen tener muy pocos datos, compromete el rendimiento de todo el sistema e impide la escalabilidad.
Como en toda base de datos, el diseño lógico correcto para bases de Pler corresponde a la tercera forma normal (3FN) o Boyce-Codd (BCFN). Y adicionalmente como sucede con todas las tablas de índices primarios clustered, por razones de performance es conveniente que cada índice primario (primary key) sea un campo numérico auto incremental (identity).
En las bases de datos de Pler es posible (y a veces conveniente) no usar restricciones de tipo foreign key (claves foráneas), y cubrir su falta desde la lógica de los querys utilizando la función dbo.f_pler_deps(tabla,índice) como una condición (where) para consultar si existen dependencias al momento de la eliminación.
El uso de esta característica requiere que los nombres de los campos de clave primaria (primary key) sean únicos y que no se usen en otras tablas más que para hacer referencia a la primary key de la tabla a la que se relacionan. De este modo el motor de Pler y la función f_pler_deps reconocerán que existe una dependencia, aunque en ella no se haya establecido explícitamente una restricción.
Para poner un ejemplo, si tenemos la tabla de nombre articulo, cuya clave primaria es articuloid, Pler interpretará que todas las tablas restantes con campos llamados articuloid, y que tengan el mismo tipo de dato, hacen referencia al registro de la tabla articulo señalado por el valor de articuloid.
En la dirección /der de su instalación de Pler (por ejemplo http://localhost:8080/sistema/der) podrá ver esto funcionando en la graficación del diagrama entidad-relación (DER) de toda la base. Adicionalmente cada módulo provee una vista del DER acotado únicamente a las tablas implicadas en su ejecución.
Procedimientos SQL
Además de los procedimientos sp_pler_armar_full, sp_pler_armar_nokick y
84
SISTEMAS PLER
sp_pler_sesion, ya mencionados más arriba, los siguientes procedimientos le asistirán durante el trabajo de desarrollo e implementación.
EXEC sp_pler_buscar expr1, expr2, expr3, etc: Busca y muestra información sobre los objetos de la base de datos. Es bastante parecido a sp_help de SQL Server, pero aplicado a recursos específicos de Pler.
EXEC sp_pler_kick: Patea (kick=patada) a todos los usuarios conectados a la base de datos para liberar y evitar los bloqueos o la concurrencia durante una actualización. Esta es también una de las acciones que realiza internamente el procedimiento sp_pler_armar_full.
EXEC sp_pler_collation: Cambia (si fuera necesario) el collation de la base de datos y de todas sus tablas para igualarlos al collation del servidor. Este procedimiento es especialmente útil cuando se mueve o se restaura una base de datos proveniente de un servidor instalado con un collation diferente. Esta es también una de las acciones que realiza internamente el procedimiento sp_pler_armar_full. Tenga en cuenta que algunos cambios de collation requieren borrar índices sobre campos de texto y que si fuera necesario deberá eliminarlos manualmente (y luego, si se hacen sentir en falta, volver a crearlos).
EXEC sp_pler_ix_stats: Muestra la fragmentación y estado de actualización de los índices de la base de datos. Solo muestra tablas grandes porque en las chicas no se requiere actualización de índices.
EXEC sp_pler_ix_reindex: Reorganiza los índices y actualiza las estadísticas para toda la base de datos. Lo que hace es muy parecido a una des fragmentación de disco. Solo afecta a tablas grandes y con más de 5% de fragmentación o des actualización.
EXEC sp_pler_ix_missing: Muestra las estadísticas de uso de los índices sugeridos o faltantes según las consultas de base de datos realizadas desde el último reinicio del servidor. Esto muestra muy buenas sugerencias, pero redundantes, de modo que aveces de entre tres o cuatro índices sugeridos solo uno de ellos es realmente útil pudiendo hacer el mismo trabajo que los demás.
EXEC sp_pler_ix_usage: Muestra las estadísticas de uso de los índices existentes en la base de datos, según datos recolectados desde el último reinicio del servidor de base de datos.
EXEC sp_pler_ix_sizes: Muestra el tamaño (en megabytes) de cada índice de la base de datos.
EXEC sp_pler_copiar_tabla <tablename> [, fields]: Genera el script de instrucciones INSERT para copiar todos los datos de una tabla. El parámetro tablename es requerido y fields (lista de nombres de campos separada por comas) es opcional.
Todos los procedimientos restantes (por fuera de los ya mencionados) y de nombre sp_pler_% o pp_pler_%, son de uso exclusivo e interno del motor de Pler, y lo mejor es no alterarlos.
85
SISTEMAS PLER
Funciones SQL
dbo.f_pler_usuario(): Devuelve el nombre del usuario de la sesión actual.
dbo.f_pler_usuarioid(): Devuelve el id del usuario de la sesión actual.
dbo.f_pler_id_insert(tablename): Devuelve una tabla con los ids de los registros insertados (INSERT) durante la transacción actual en la tabla indicada. Esta es la función que debe usarse en los querys de Pler en lugar de @@IDENTITY y SCOPE_IDENTITY(). Aqui dos ejemplos distintos para f_pler_id_insert, pero con el mismo resultado:
DECLARE @tableid INTSELECT TOP 1 @tableid = idFROM dbo.f_pler_id_insert('tablename')ORDER BY 1 DESC
DECLARE @tableid INTSELECT @tableid = MAX(id)FROM dbo.f_pler_id_insert('tablename')
dbo.f_pler_id_update(tablename): Devuelve una tabla con los ids de los registros actualizados (UPDATE) durante la transacción actual en la tabla indicada.
dbo.f_pler_id_delete(tablename): Devuelve una tabla con los ids de los registros eliminados (DELETE) durante la transacción actual en la tabla indicada.
dbo.f_pler_id_insupd(tablename): Devuelve una tabla con los ids de los registros insertados o actualizados (INSERT y UPDATE) durante la transacción actual en la tabla indicada.
dbo.f_pler_deps(tablename,indice): Devuelve los nombres delas tablas (en una lista separada por comas) que tienen dependencias del registro indicado en el valor del índice. Si el parámetro íindice es NULL, entonces f_pler_deps devolverá todas las tablas con posibles dependencias de tablename.
dbo.f_pler_split_int(lista): Recibe una lista de números (enteros) separada por comas, y entrega una tabla con los números y su posición en la lista.
dbo.f_pler_split_lng(lista): Recibe una lista de números (enteros largos, bigint) separada por comas, y entrega una tabla con los números y su posición en la lista.
dbo.f_pler_split_txt(texto,separador): Convierte una cadena de texto en una tabla con valores tomados del texto de entrada cortados según el separador. Esto es el equivalente en bases de datos a un split para obtener un array.
dbo.f_pler_decimal(num,dec): Aplica el formato decimal a un valor numérico.
dbo.f_pler_filesize(tamanio): Aplica el formato de tamaño de archivos a un valor numérico (tamaño en Bytes/KB/MB/GB).
dbo.f_pler_capitalize(texto): Cambia a mayúscula la primera letra de cada palabra.
86
SISTEMAS PLER
Ejemplos SQL
Ejemplo de lectura de datos recibiendo un parámetro.
DECLARE @articulotipoid INTSET @articulotipoid = ?SELECT a.articulotipoid, a.articulotipoFROM articulotipo aWHERE a.articulotipoid = @articulotipoid
Ejemplo de actualización de datos para el evento guardar, combinando las sentencias INSERT y UPDATE.
DECLARE @articulotipoid INTDECLARE @articulotipo VARCHAR(50)SET @articulotipoid = ?SET @articulotipo = ?IF @articulotipo IS NOT NULL BEGIN IF @articulotipoid IS NOT NULL BEGIN UPDATE articulotipo SET articulotipo = @articulotipo WHERE articulotipoid = @articulotipoid END ELSE BEGIN INSERT INTO articulotipo (articulotipo) VALUES (@articulotipo) -- La función dbo.f_pler_id_insert reemplaza a @@IDENTITY o SCOPE_IDENTITY() SELECT TOP 1 @articulotipoid = id FROM dbo.f_pler_id_insert('articulotipo') ORDER BY 1 DESC ENDEND-- El SELECT fonal devuelve al front-end el valor de articulotipoid generado en la instrucción INSERTSELECT @articulotipoid articulotipoid
Ejemplo de eliminación de datos validando dependencias (f_pler_deps) y evitando que se eliminen los registros que se hayan intentado actualizar previamente (f_pler_id_insupd) en la transacción actual.
DECLARE @articulotipoid INTSET @articulotipoid = ?DELETE FROM articulotipoWHERE articulotipoid = @articulotipoidAND articulotipoid NOT IN (SELECT id FROM dbo.f_pler_id_insupd('articulotipo'))AND dbo.f_pler_deps('articulotipo',articulotipoid) IS NULL
Los tres ejemplos anteriores pueden verse aplicados a cada tabla, desde el DER gráfico de Pler, al hacer doble click sobre cualquier entidad. Con esto el armado de querys para un ABM simple podria limitarse a solamente copiar y pegar.
Cursores: El siguiente ejemplo muestra cómo definir un cursor para recorrer dos campos de una tabla.
SET NOCOUNT ONDECLARE @pler_divisionid INTDECLARE @division VARCHAR(256)DECLARE cur CURSOR LOCAL STATIC FOR SELECT pler_divisionid, division FROM pler_division ORDER BY 1
87
SISTEMAS PLER
OPEN curFETCH NEXT FROM cur INTO @pler_divisionid, @divisionWHILE @@fetch_status=0 BEGIN PRINT @pler_divisionid PRINT @division FETCH NEXT FROM cur INTO @pler_divisionid, @divisionEND CLOSE cur DEALLOCATE curSET NOCOUNT OFF
Funciones de Split: El siguiente ejemplo muestra cómo obtener valores individuales a partir de una cadena de texto.
SELECT pos, num FROM dbo.f_pler_split_int('10,20,30,40,41,42,43,44')SELECT pos, num FROM dbo.f_pler_split_lng('100000000000,200000000000')SELECT pos, txt FROM dbo.f_pler_split_txt('aaa|bbb|ccc|11', '|')
88
SISTEMAS PLER
Bases y tablas del sistema
Bases de datos del sistema
El sistema utiliza tres bases de datos diferentes sobre un mismo servidor. En la base principal se almacenan todos los datos, con la excepción de los archivos adjuntos (binarios), y de la auditoría archivada (históricos).
Para la base principal debe privilegiarse la velocidad en los discos, especialmente en el log de transacciones, que es el criterio normal en SQL Server.
Para la base de archivos adjuntos debe privilegiarse el espacio en disco. Y opcionalmente puede habilitarse la opción filestream, que permite optimizar las operaciones con datos binarios al guardarlos directamente sobre el sistema de archivos del disco NTFS.
Para la base de auditoría archivada no se requiere ningún cuidado especial, ya que únicamente se escribe cuando se desplazan los registros de auditoría de la base principal, desde la pantalla de administración del sistema.
Tablas de módulos
Las definiciones de los módulos y su código fuente se almacena dentro de la base de datos, junto con algunos metadatos sobre las tablas y objetos del sistema que cada módulo utilice.
89
SISTEMAS PLER
La tabla pler_modulo contiene el código ejecutable de cada módulo (html, javascript y css) y su configuración general.
Cada una de las consultas de datos de cada módulo se guarda en la tabla pler_query, y por cada consulta también se guardan: la lista de parámetros que recibe (pler_queryparametro), la lista de campos que devuelve (pler_querydevuelve), la lista de tablas que se utilizan (pler_querytabla), la lista de campos que se utilizan (pler_querycampo), y la lista de procedimientos almacenados (pler_queryproc).
Los archivos incluidos en cada módulo como parte de su programación, como por ejemplo imágenes o scripts, se guardan en la tabla pler_moduloarchivo.
La configuración para permitir que un módulo sea buscable por medio de sus datos desde el buscador del sistema, y la configuración para lanzar avisos, se guardan respectivamente en las tablas pler_buscableconfig y pler_avisoconfig.
Tablas de usuarios y permisos
La tabla pler_division contiene la lista de establecimientos utilizados en el sistema. La tabla pler_perfil contiene los diferentes roles que pueden aplicarse a cada usuario, y estos a su vez están relacionados a una lista de módulos mediante la tabla pler_perfilmodulo. La aplicación de permisos vincula a cada usuario (pler_usuario) con uno o más roles por cada uno de los establecimientos, y esto se almacena en la tabla pler_usuariopermiso.
La tabla pler_mensaje guarda los mensajes enviados o recibidos por medio del chat interno del sistema.
Tablas de archivos adjuntos
Los archivos adjuntos se almacenan en una base de datos por separado. Al
90
SISTEMAS PLER
cargar un nuevo archivo adjunto desde cualquier módulo, éste se guarda en la tabla pler_adjunto de la base de archivos y el sistema devuelve el id que lo referencia y que luego será guardado en la base principal como parte de los demás datos transaccionales.
Cuando el archivo adjunto se trata de una imagen, el sistema crea automáticamente algunas miniaturas de diferentes tamaños que se almacenan la tabla pler_thumbnail.
Tanto pler_adjunto como pler_thumbnail, en la base principal, no son realmente tablas, sino vistas que referencian a las tablas correspondientes en la base de archivos adjuntos.
Tablas de manuales
Los manuales en línea se almacenan en la tabla pler_manual, y por medio de la tabla pler_manualmodulo se indica a qué modulo corresponde cada manual.
91
SISTEMAS PLER
Auditoría reciente y archivada
Por cada tabla transaccional del sistema, se crea automáticamente una tabla adicional en la que se almacenan los estados anteriores a cada modificación sobre dicha tabla. Esta es la tabla de auditoría reciente y tiene el mismo nombre que la tabla auditada más el prefijo “_au_”.
Al archivar la auditoria, los registros de ésta tabla de auditoria reciente, se mueven a la base de auditoría archivada. Para consultar la auditoría completa, es decir la reciente más la archivada, el sistema proporciona las vistas con el nombre de cada tabla más el prefijo “v_a_”.
Las tablas cuyo nombre comience por los prefijos “pler_” o “_” (guion bajo) están exceptuadas de la auditoria. El prefijo “pler_” identifica a las tablas internas del sistema, y el prefijo “_” indica que son tablas de datos temporales o redundantes (utilizados por motivos de rendimiento) que no requieren ser auditados.
92
SISTEMAS PLER
Anexo II – Informe sobre la validez de la historia clínica electrónica
Informe 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
La progresiva informatización de la documentación médica ha estado acompañada tradicionalmente por dudas de los profesionales y las autoridades de los establecimientos médicos acerca de su validez en procesos judiciales. Esas dudas han dificultado en parte la expansión de un sistema con innumerables ventajas y han conducido a la adopción de medidas parciales (utilización sólo en determinadas áreas) o bien duplicadas (a pesar de contar con la herramienta electrónica, se imprime y firma todo).
En ámbitos médico-legales, hasta principios de este siglo, siempre se hablaba de un cierto vacío legal con respecto a este tema. Las primeras historias clínicas electrónicas solían presentar el inconveniente de que no garantizaban la inalterabilidad de su contenido ni su autoría. Estos inconvenientes las hacían inadmisibles e ineficaces probatoriamente. Si bien todavía persisten algunas dudas puntuales, la sanción de la Ley 25.506 de Firma Digital en el año 2001 comenzó a llenar gran parte del vacío legal mencionado al brindar un marco normativo a estas nuevas tecnologías, regulando lo concerniente al empleo de la firma digital y la firma electrónica, a las que se les asigna un valor jurídico. La ley modifica sustancialmente el concepto de documento contenido en el Código Civil, asociado a la forma escrita, (art. 978 CC) y realizado en soporte de papel, equiparando a la firma ológrafa con la firma digital y la firma electrónica. Antes de la ley mencionada, cualquier documentación digital no tenía el carácter de documento que ahora sí tiene.
Según la legislación se entiende por documento digital a “la representación digital de actos o hechos, con independencia del soporte utilizado para su fijación, almacenamiento o archivo, Un documento digital también satisface el requerimiento de escritura (art 6). “ Se equiparan entonces al papel soportes tales como discos rígidos, discos compactos, diskettes, etc. en tanto son medios capaces de contener o almacenar información para su posterior reproducción. La Ley de Firma Digital es el elemento jurídico que hace posible que la historia clínica computarizada no sea cuestionable desde el punto de vista legal.
93
SISTEMAS PLER
Los cambios ocurridos en las últimas décadas en el sistema prestacional requieren el acceso y la integración de la información de los pacientes entre los profesionales, los centros diagnósticos, los hospitales y los pagadores. La historia clínica no sólo cumple fines médicos sino también administrativos, estadísticos y legales. Si bien la historia clínica es el documento más importante de la atención médica en condiciones de informatización, no es el único registro. Se consideran Registros Médicos Informatizados (RMI) a todos los archivos informáticos que contengan alguna información relativa al paciente, sus estudios complementarios y su tratamiento, entre ellos: Historia clínica electrónica (HCE) - Registros de admisión y egresos - Archivos de laboratorio de análisis clínicos - Bases de estudios complementarios (radiología, tomografías, ecografías, otros) - Archivos de reserva de turnos - Archivos de facturación y otros. La HCE es el documento que debe estar más protegido. Sin embargo, todos los otros registros deben tener restricciones y reservas, dado que contienen información que puede perjudicar al paciente en caso de difundirse.
Quienes consideren a la historia clínica electrónica como la simple transcripción a la computadora de lo que se escribiría en un papel con el limitado objetivo de ahorrar su uso, despejar los depósitos y hacer las historias más legibles probablemente desaprovechen las ventajas de un sistema bien diseñado. La mera automatización de la forma, el contenido y los procedimientos de documentación actual en papel perpetuará sus deficiencias y será insuficiente para cumplir con las necesidades crecientes.
La historia clínica está conformada por la información provista por distintos actores (médicos, enfermeras, interconsultores, auxiliares, etc). Cada uno debe hacerse responsable de la información que genera y debiera firmar electrónica o digitalmente. A su vez esta información suele estar atomizada en registros de varias tablas, en estructura de datos relacionales. Estos datos pueden ser alterados por distintos procesos, por lo que se impone una metodología que permita recuperar esos datos de distintas tablas y registros y congelarlos en un campo donde permanezcan inalterables al momento de firmarse. Por otro lado debe contemplarse un campo en donde se almacene quién generó la información, en qué fecha y hora, a quién pertenece y quiénes están autorizados a leerla. (Esto último, en términos técnicos, se denomina guardar el “hash” generado por la clave privada.)
Las ventajas médicas, legales, operativas, económicas y aún ecológicas de la historia clínica electrónica sobre la historia clínica en papel son innumerables.
Ventajas Médicas - Mejora el acceso a la información: La recuperación de una pieza específica de la historia es mucho más rápida: una computadora puede entregar un dato en segundos, frente a los minutos u horas que puede requerir localizar, obtener y revisar una historia clínica convencional. Diferentes usuarios autorizados pueden consultar la misma información desde distintos puntos y en forma simultánea. Se facilita de esa forma la comunicación del equipo de salud y se garantiza el acceso en casos de emergencia. - Facilita la historia clínica única: Se evita la actual fragmentación que existe actualmente en muchas instituciones entre las historias de consultorios externos, de guardia y las de internación.
Cada paciente tiene así un solo número de historia y su gestión queda centralizada en un archivo único, garantizando que todos los sucesivos episodios de ese paciente queden conservados juntos. Cada paciente tiene un número de referencia obligatoriamente único, lo cual permite colgar del mismo todos los registros
94
SISTEMAS PLER
asistenciales que se le presten, pudiendo integrar a su vez dicha información con datos de farmacia, de facturación, etc.
Permite la incorporación de imágenes digitales. A su vez, las mismas pueden ser revisadas a distancia por médicos expertos en aquellas situaciones en las que se lo requiera. - Facilita los trabajos estadísticos y científicos: Al estar la historia estructurada en forma de base de datos, es más fácil recuperar la información necesaria que en las historias en papel - Permite incorporar sistemas de apoyo a la decisión clínica (algoritmos y protocolos de estudio y tratamiento), recordatorios de práctica y conexión con cuerpos de conocimiento médico. - Permite incorporar un vademecum institucional, con sistemas de alerta en caso de contraindicaciones, interacciones o sobredosis (las dosis incorrectas no son tomadas por los campos). - El ingreso estandarizado de datos y el uso obligatorio de algunos campos para pasar de pantalla disminuye la posibilidad de olvidos y errores (ej: olvidar chequear alergias)
Ventajas Legales - La historia clínica electrónica contribuye a que la documentación médica sea llevada de acuerdo a los requisitos formales establecidos por las distintas normativas y por la jurisprudencia: - Siempre legible - No permite espacios en blanco ni alteración del orden de los asientos - Siempre firmada - Siempre con fecha y hora - Siempre completa - Se evitan las correcciones, raspaduras, agregados, etc.
Evita las medidas anticipativas, como ser el secuestro judicial, dado que mediante la firma digital se garantiza la identificación de una persona y la autenticidad del documento y la medida resulta entonces innecesaria. - Por las mismas razones, no resulta necesario solicitar judicialmente el reconocimiento de la firma del profesional que hubiere firmado digitalmente en la historia clínica.
Como la historia clínica informatizada tiene el valor de un original, cuando el paciente solicita una copia de ella, como es su derecho, (ya sea durante su internación o su egreso), y a posteriori se llegare a producir la pérdida o extravío de la que se encuentra en poder del establecimiento o profesional, habrá hasta el momento en que se produce el extravío, certeza sobre los datos consignados en la historia clínica digital que el paciente tiene en su poder.
Ventajas operativas, económicas y ecológicas. Son bien conocidos los problemas que traen aparejadas a las instituciones y a los profesionales las historias clínicas en papel. El crecimiento continuo del volumen almacenado llega a crear graves problemas de espacio físico, a lo que se suma el inevitable trasiego de documentos originales, con riesgo de pérdida o deterioro. Son muy ilustrativos algunos ejemplos publicados. Un interesante trabajo de 1998 describe el verdadero caos que representa el manejo de las historias clínicas en un Hospital General de Agudos de la Ciudad de Buenos Aires: 75 m2 de superficie de archivo 504 metros lineales de estantería. 200.000 historias clínicas archivadas por quince años. 100 movimientos de historias de internación 2000 consultas por día 16 empleados administrativos full time. El total de espacio destinado a archivar aprox. 54.000 historias en el Hospital Municipal de Oncología María Curie es de 152 m2 , empleando 6 personas. Considerando que en un disco rígido de 300 GB, de muy bajo costo (menos de $1500) entran tres contenedores de papel que podrían almacenar aproximadamente 450.000 historias clínicas, es evidente que la informatización es la solución más económica y eficiente.
La informatización también evita la redundancia de estudios y de tratamientos.
95
SISTEMAS PLER
Muchas veces, al no contar con estudios realizados en consultorios, los mismos se repiten en forma innecesaria en la internación y viceversa. Por último, no puede dejar de mencionarse el importante impacto ecológico que tiene el ahorro de toneladas de papel disminuyendo la contaminación del medio ambiente (papeleras) y la deforestación.
La historia clínica electrónica debe cumplir con una serie de requisitos para que pueda ser reconocida como una herramienta probatoria válida en los tribunales. La mayoría de las recomendaciones son adaptaciones a nuestro país de normas de los Estados Unidos y de Europa, principalmente las realizadas por el Comité de Ministros del Consejo de Europa a los Estados Miembros sobre la Protección de Datos Médicos. El Código de Ética de la Asociación Médica Argentina (AMA) da entidad a la informatización de la documentación médica, mediante el art. 185 del Capítulo 11 (referido a la historia clínica): “En caso de computarización de la Historia Clínica deberán implementarse sistemas de seguridad suficientes para asegurar la inalterabilidad de los datos y evitar el accionar de violadores de información reservada.” Mediante este artículo, la AMA da por tierra con el arraigado y erróneo concepto de que la historia clínica debe ser indefectiblemente manuscrita, si bien deja en claro que deben cumplirse con ciertos requisitos que son considerados en forma unánime por médicos, especialistas en informática y juristas como indispensables. Estos son:
1. Inviolabilidad: Que la información no pueda ser adulterada. Una vez in-gresados los datos no pueden modificarse (algunos sistemas dan una “ventana” de minutos). Cualquier corrección automáticamente se agrega al final del texto preservando la cita original. Se debe impedir el ingreso no autorizado de datos en el sistema de información. Esto incluye las medidas pertinentes para impedir el ingreso de hackers en el sistema.
2. Autoría: El sistema deberá otorgar garantías acerca de la identidad de quien ingresa los datos (asegurar que un usuario particular es quien dice ser)
3. Confidencialidad: Se debe impedir que los datos sean leídos, copiados o retirados por personas no autorizadas. Esto puede conseguirse con normas de ac-cesibilidad controlada que permiten al acceso o lo restringen de acuerdo a la fun-ción del usuario. Se establece de esa forma un control sobre la utilización de los distintos campos. No todos pueden tener acceso a toda la información (Ej: un empleado administrativo no puede acceder a los antecedentes patológicos de un paciente). Para ello se utilizan diferentes niveles de acceso. Cuando un usuario autorizado necesita acceder a la misma, ingresa su clave y esa historia se repro-cesa volviendo a un formato legible. En nuestro país, la Ley de Hábeas Data y la Constitución Nacional obligan a garantizar una adecuada protección de los datos de las personas y del acceso a la información.
4. Secuencialidad: El sistema debe garantizar que los datos sean ingresados en forma cronológica, siguiendo el orden en que la historia fue escrita e impi-diendo que se altere la secuencia de actualización.
5. Temporalidad: Todo registro en la historia clínica debe automáticamente llevar adosado el día y la hora en que se realizó. Esto se consigue mediante la aplicación de un mecanismo de seguridad informático: el sellado digital de fe-chas (time stamping.)
6. Disponibilidad: Debe garantizarse que la información se encuentre dispo-
96
SISTEMAS PLER
nible en todo momento y lugar cuando se la necesite, aún desde fuera del ámbito institucional (ej: consultorio particular del médico). También debe permitir el acceso, cuando corresponda, de los organismos de control de Salud Pública y de la Justicia.
7. Integridad: El sistema debe alertar si el registro fue adulterado a posterio-ri de la firma. La información volcada en la historia clínica sólo debería poder modificarse de acuerdo a un procedimiento claramente especificado de antema-no y sólo por personal autorizado. A su vez, deberá quedar en el sistema un re-gistro de la introducción de los datos (quién ingresó, desde dónde, con qué clave, fecha y hora, qué cambió, que agregó, etc.). De forma tal que si las historias son modificadas ya sea en forma legítima como fraudulenta, quedará un registro. La integridad de la historia clínica electrónica también depende de adecuados so-ftwares de seguridad informática que protejan a la documentación de posibles virus. Los datos deben salvaguardarse mediante back up regulares y copias de seguridad.
8. Durabilidad: La información generada debe permanecer inalterable en el tiempo. Las instituciones deberían poder prevenir o eventualmente recuperar cualquier pérdida de datos en la eventualidad de incendios, inundaciones, vanda-lismo o fallas del sistema. Se deben establecer normas con respecto a la seguri-dad física de los equipos. También se deberían actualizar los programas obsole-tos según pasan los años a fin de que la documentación archivada pueda mante-nerse accesible y útil durante el tiempo que marca la ley.
9. Transportabilidad e Impresión: El sistema debe permitir que el paciente pueda disponer de una copia de su historia clínica, ya sea en soporte electrónico o en papel. La información transportada vía mail, CD o pen drive debería ser transmitida en clave y con los mismos requisitos descriptos, impidiendo la modi-ficación, la copia y la lectura de personas no autorizadas. Habiendo analizado qué requisitos de seguridad deben garantizarse en la historia clínica electrónica (HCE), la siguiente pregunta que debe responderse es cómo hacerlo. Cuanta ma-yor seguridad tenga el sistema, menos reparos podrán realizarse sobre su valor probatorio en un litigio. Los mecanismos de seguridad informáticos (MSI) se clasifican en:
CLASICOS: Nombre de usuario y clave Tarjetas magnéticas combinadas con clave. Técnicas de back-up.
BIOMÉTRICOS: Huellas dactilares (fingerprint) Estructura de la mano (hand key) Reconocimiento del iris Reconocimiento facial.
CRIPTOGRÁFICOS: Encriptación Firma Digital Sellado digital de fechas (Time Stamping).
MSI Clásicos: La implementación de nombres de usuario y clave de acceso es el mecanismo de seguridad más básico y el más difundido. Para su seguridad depende de pautas culturales que son muchas veces difíciles de cambiar. Si este mecanismo se utiliza mal, no se garantiza la identidad del que genera la información, ya que las claves de acceso pueden pasar de un usuario a otro y no son 100% vinculantes con el usuario si no se respeta su secreto. En algunos centros todavía se comparten claves o bien las mismas son obvias. Puede agregarse a este sistema una tarjeta magnética que deba
97
SISTEMAS PLER
ingresarse junto con la clave, aunque si la misma también es compartida continúa presentando el inconveniente anterior. También se encuentran dentro de este grupo las prácticas de muchas instituciones que realizan el back up regular de su información electrónica (CD/Pendrive) y la entregan a un escribano, de forma tal de brindar una mayor garantía acerca de que la documentación no ha sido alterada. Sin duda los MSI clásicos tienen la ventaja de su fácil implementación y bajo costo. Estos mecanismos pueden ser efectivos si todos los involucrados en el ingreso de datos toman conciencia de la importancia que tiene no compartir su clave y la modifican periódicamente (la mayoría de los sistemas obligan a hacerlo).
MSI Biométricos: Estos mecanismos reconocen los parámetros biométricos propios de cada individuo: huellas dactilares, la estructura de la mano, del iris o de la cara. Se dan así diferentes garantías acerca de la identidad de la persona que ingresa los datos en la historia clínica. Estos mecanismos de seguridad son útiles. Los productos existentes en el mercado son muy variables tanto en el precio (que puede ir desde menos de 100 dólares a varias decenas de miles por dispositivo) como en su sensibilidad y especificidad.
MSI Criptográficos: Una de las formas más efectivas para proteger la información consiste en aplicar técnicas de “encriptamiento” a la información contenida en los archivos. Esta técnica, mediante los denominados “algoritmos”, transforma el texto en símbolos ilegibles, impidiendo de esta forma su lectura y su adulteración. Sin embargo, dicho texto “encriptado” se puede recuperar cada vez que sea necesario mediante técnicas de desencriptamiento, que entran en juego cuando ingresa al sistema un usuario autorizado. La criptografía también debe aplicarse para proteger la información que se envía por correo electrónico. También puede utilizarse para proteger datos almacenados en discos, copias de seguridad, etc. Nombre de usuario y clave Tarjetas magnéticas combinadas con clave. Técnicas de back-up CLÁSICOS BIOMÉTRICOS CRIPTOGRÁFICOS Encriptación Firma Digital Sellado digital de fechas (Time Stamping) Huellas dactilares (fingerprint) Estructura de la mano (hand key) Reconocimiento del iris Reconocimiento facial.
En la firma digital y el sellado digital de fechas está la respuesta a la mayoría de los interrogantes planteados acerca de la validez legal de la historia clínica electrónica.
La Ley vigente 25.506 de Firma Digital es el instrumento jurídico que hace posible que las historias computarizadas no sean cuestionables desde el punto de vista legal. Repasemos algunos artículos:
Art. 1°. Se reconoce el empleo de la firma electrónica y de la firma digital y su eficacia jurídica en las condiciones que establece la presente ley.
Art. 3°. Cuando la ley requiera una firma manuscrita, esa exigencia también queda satisfecha por una firma digital. Este principio es aplicable a los casos en que la ley establece la obligación de firmar o prescribe consecuencias por su ausencia.
Art. 6°. Se entiende por documento digital a la representación digital de actos o hechos, con independencia del soporte utilizado para su fijación, almacenamiento o archivo. Un documento digital también satisface el requerimiento de escritura. La firma digital permite garantizar la autoría de un documento, pero para poder dar valor legal a las evoluciones e indicaciones médicas hace falta probar otro elemento indispensable: la hora y fecha en la que se realizaron. La presunción de autoría no garantiza la
98
SISTEMAS PLER
secuencialidad y la temporalidad que deben tener las evoluciones clínicas. El sellado digital de fecha (time stamping) es el mecanismo de seguridad informático que viene a solucionar este problema, ya que garantiza la determinación del momento exacto en que se generó la información.
Diferencia entre la firma electrónica y la firma digital
La misma Ley 25.506 claramente establece las diferencias entre ambos tipos de firmas:
Firma digital:
Art. 2°. Se entiende por firma digital al resultado de aplicar a un documento digital un procedimiento matemático que requiere información de exclusivo conocimiento del firmante, encontrándose esta bajo su absoluto control. La firma digital debe ser susceptible de verificación por terceras partes, tal que dicha verificación simultáneamente permita identificar al firmante y detectar cualquier alteración del documento digital posterior a su firma.
Art. 7°. Presunción de autoría: Se presume, salvo prueba en contrario, que toda firma digital pertenece al titular del certificado digital que permite la verificación de dicha firma.
Art. 8°. Presunción de integridad: Si el resultado de un procedimiento de verificación de una firma digital aplicado a un documento digital es verdadero, se presume, salvo prueba en contrario, que este documento digital no ha sido modificado desde el momento de su firma.
Art. 9°. Validez: Una firma digital es válida si cumple con los siguientes requisitos:
a) Haber sido creada durante el período de vigencia del certificado digital válido del firmante.
b) Ser debidamente verificada por la referencia a los datos de verificación de firma digital indicados en dicho certificado según el proceso de verificación correspondiente.
c) Que dicho certificado haya sido emitido o reconocido, según el art. 16 de la presente, por un certificador licenciado. Como vemos, la firma digital es mu-cho más que ingresar una clave identificatoria. La firma del profesional debe es-tar certificada por un certificador licenciado. Los certificadores licenciados son por ahora en su mayoría entes públicos (si bien la ley también permite certificar a entes privados) autorizados por la Oficina Nacional de Tecnologías de la Infor-mación (ONTI) para emitir certificados digitales. Un certificado digital no es más que un documento electrónico firmado digitalmente por el certificador li-cenciado donde consta la Clave Pública y los datos del usuario al que hace refe-rencia. El proceso consiste básicamente en la generación de dos claves, una Pú-
99
SISTEMAS PLER
blica y otra Privada, ligada entre sí matemáticamente mediante la aplicación de algoritmos técnicamente confiables. La Clave Pública es de libre distribución y debe estar en disponibilidad de todo aquel que quiera verificar que la firma digi-tal generada con la clave privada se corresponde con dicha clave pública. Se ga-rantiza así que la firma es de quien dice ser y que lo que firmó no ha sido altera-do. La Clave Privada es de conocimiento exclusivo del usuario y debe ser res-guardada con el máximo nivel de seguridad para evitar su uso por personas no autorizadas.
De esta forma, el autor del documento electrónico procede a codificarlo (encriptarlo), luego lo remite a su destinatario quien no podrá transformar el documento en legible si no posee la clave pública del remitente. Sólo si posee dicha clave pública el destinatario podrá “decodificar” el mensaje y hacerlo nuevamente legible, ya que sólo la clave pública del transmisor es capaz de decodificar el documento cifrado con la clave privada. Dicho en otras palabras, la clave privada funciona como una llave que cierra el documento que sólo puede ser abierto por otra llave, la clave pública. Son todavía muy pocos los profesionales de la salud que han certificado su firma de esta forma ya que las entidades que controlan la matrícula (ej: Colegios Médicos) no se han constituido como certificadores licenciados pudiendo hacerlo, según el artículo 18 de la Ley.
Esto por el momento está privando a la comunidad médica del vehículo más fácil y accesible para validar su firma informática. Lo concreto es que todavía los médicos y profesionales de la salud no tienen a quien recurrir para obtener un certificado digital y deben contentarse sólo con la firma electrónica, que también es aceptada por la ley.
Los únicos avances en este sentido provienen de la administración pública, siendo los primeros certificadores licenciados la AFIP y el ANSES (Marzo de 2009). Sin embargo, el proceso de obtención del certificado digital – que no sería demasiado complicado- está limitado a funcionarios y agentes de la administración pública. La misma Autoridad Certificante de la Oficina Nacional de Tecnologías de la Información (ONTI) emite certificados de identificación personal en forma gratuita, si bien los mismos también están limitados a empleados estatales y, en el caso del resto de los ciudadanos a la protección de las comunicaciones por correo electrónico, no validando la identidad de la persona sino tan sólo verificando la existencia y disponibilidad de dicha cuenta. Se puede encontrar mucha información al respecto ingresando en la página oficial de la Autoridad Certificante de ONTI: www.ca.pki.gov.ar
En todos los casos, para obtener un certificado digital se deberá comprobar la identidad, bien directamente o por medio de entidades colaboradoras. Recién ahí el certificador licenciado creará con los dispositivos técnicos adecuados el par de claves pública y privada y generará el certificado digital correspondiente a esas claves, entregándole al profesional el certificado, ya sea en un medio magnético o directamente en formato de archivo.
Firma electrónica:
Si alguno de los requisitos legales descriptos no se cumple (por ejemplo, no se dispone del certificado digital emitido por un certificador), la ley contempla la figura de la firma electrónica, a la que define en su artículo 5° como “al conjunto de datos electrónicos integrados, ligados o asociados de manera lógica a otros datos electrónicos,
100
SISTEMAS PLER
utilizado por el signatario como su medio de identificación, que carezca de algunos de los requisitos legales para ser considerada firma digital. En caso de ser desconocida la firma electrónica corresponde a quien la invoca acreditar su validez.” Se invierte así la carga de la prueba, siendo el profesional de la salud quien debe demostrar su autenticidad en caso de cuestionamientos (a diferencia de la firma digital). Como ejemplos de firma electrónica pueden ser considerados los siguientes: - Una firma hecha con un certificado que no haya sido emitido por una Autoridad Certificante licenciada - Un password o un número de pin utilizados como autenticación - La identificación a través de algún procedimiento biométrico - Un tono o pulso telefónico Habiendo hecho la distinción entre ambos tipos de firmas, queda claro que la inmensa mayoría de los profesionales de la salud en la actualidad están utilizando la firma electrónica y no la digital. Esto seguirá ocurriendo mientras no haya mayores opciones de certificadores privados que faciliten el trámite a los médicos y otros profesionales de la salud.
Exclusiones a la documentación electrónica: El consentimiento informado
El art. 4. de la Ley de Firma Digital establece determinadas exclusiones, entre las cuales se menciona expresamente a los actos personalísimos. Por lo tanto, existen determinados actos que no pueden ser llevados en registros informatizados, tales como la información de riesgos y aceptación del paciente para la realización de estudios y tratamientos (consentimiento informado).
Estos actos entran en la esfera de los derechos personalísimos (el derecho a estar informado posibilita el derecho personalísimo a su integridad psicofísica, el derecho de disponer de su propio cuerpo, de decidir su vida, el derecho a una muerte digna, etc.).
De igual forma se legisla en materia de trasplantes, que por involucrar actos de tanta trascendencia como son la ablación de un órgano o la realización de un trasplante, la Ley 24.193 (De trasplante de órganos y tejidos) ha impuesto requisitos muy concretos en cuanto al contenido de la información, quedando por ende también incluidos dentro de la prohibición del art. 4 de la Ley de firma digital. En todos estos casos (consentimientos informados, directivas anticipadas y trasplantes), la declaración de voluntad del paciente debe seguir siendo registrada en la historia clínica u otros registros con las formalidades que imponen las distintas reglamentaciones y la jurisprudencia: firma manuscrita del profesional, aclaración y número de matrícula y fecha. La inobservancia de tales requisitos torna nulo el acto, acarreando las consecuencias jurídicas propias que de ello se derivan (imposibilidad probatoria y responsabilidad objetiva por falta de información).
Problemas a resolver
Actualmente la mayoría de la información asistencial en las clínicas, sanatorios
101
SISTEMAS PLER
y hospitales no se encuentra computarizada. La informatización del sector salud se encuentra retrasada, particularmente entre los prestadores. Las dudas acerca de la validez legal de documentos informáticos con escasos mecanismos de seguridad y algunas dificultades operativas determinan que en el sector salud, a diferencia de otras industrias donde la nueva tecnología reemplaza a la anterior, la informática conviva con el papel. En la actualidad, los profesionales del equipo de salud escriben más, generan más 8 Exclusiones a la Documentación Electrónica: El Consentimiento Informado Problemas a Resolver Conclusiones órdenes de estudios y deben justificar sus pedidos ante los financiadores en papel, reproduciendo en forma geométrica la producción de documentos en este soporte, que a su vez son fotocopiados y faxeados en numerosas oportunidades, con la amenaza a la confidencialidad que esto significa.
Se requiere entonces no sólo invertir en equipamiento y desarrollo de software sino también producir un cambio de hábito entre los profesionales que permita pasar de la cultura del papel a la cultura informática. Para ello es necesario involucrar a los médicos y auxiliares en el desarrollo de este proceso. Uno de los principales problemas a resolver para que el profesional se sienta más cómodo con la utilización de la historia clínica electrónica es la atomización de la información entre los distintos actores que intervienen en la atención de un paciente. En los sistemas electrónicos actuales, la información sobre la cual el médico toma una decisión se encuentra repartida en diferentes registros computarizados (información del laboratorio, informes de estudios complementarios, registros de enfermería, interconsultas, etc). Es imposible firmar información atomizada de un mismo paciente en distintas tablas, bases de datos y registros, por lo que habría que correr un procedimiento para centralizar en un único registro toda la información que se desea firmar.
Conclusiones
En toda institución médica la historia clínica es el archivo más importante, conteniendo información vital para la gestión médica, administrativa y legal. Las ventajas comparativas de la informática frente al papel son innumerables desde todo punto de vista (operativo, de seguridad, económico y aún ecológico).
No existe ningún imperativo legal que priorice la validez de la firma manuscrita por sobre la firma electrónica o digital, salvo cuando se trata de actos personalísimos como el consentimiento informado, las directivas anticipadas o los trasplantes. - Si bien hay quienes abogan por una nueva ley que regule en forma concreta y específica todo lo referente a la historia clínica electrónica, la legislación vigente (Ley de Firma Digital) y el desarrollo actual de los mecanismos de seguridad informáticos descriptos (principalmente la criptografía, el sellado digital de fechas y el control de la modificación de campos) son suficientes desde el punto de vista legal para que los registros médicos informatizados tengan el mismo valor probatorio que sus homólogos en papel.
Resulta necesario avanzar en el cambio cultural que permita una correcta implementación de la solución. Todo cambio crea dudas e inseguridad ante lo desconocido, por ello es que se debe trabajar en forma conjunta entre profesionales de la
102
SISTEMAS PLER
salud, en informática y en derecho para brindar todas las garantías necesarias a los usuarios del sistema.
Por último, se necesitan certificadores licenciados vinculados al sector salud, para difundir y facilitar la certificación de la firma por parte de los profesionales de la salud. Sólo así se podrá pasar de la firma electrónica (modalidad mayormente utilizada en la actualidad) a la firma digital.
103
