Indice
Pack de demostraciones
Esquema cliente-servidor. Para el cliente final
Esquema cliente-servidor. Para el desarrollador
Ejemplos de publicación de un base con interface web
Limitaciones de la conexión a aplicación remota (servidor con TS)
________________________________________
Si va a seguir esta documentación, conviene que descargue un paquete con bases preparadas para trabajar como cliente-servidor en un ordenador local, haciendo las dos funciones en el mismo equipo. De esta forma puede seguir el comportamiento del servidor en la aplicación Windows y al lado, en una ventana del navegador, ver el funcionamiento en el cliente.
Las BD de cada proyecto se encuentran en la misma máquina que la instalación de Ingrid que proporciona los servicios web.
El cliente no requiere ningún tipo de instalación ni permisos especiales de red local, sólo un navegador y acceso a Internet para abrir una web. En los casos de las redes más protegidas que no permiten todo tipo de tráfico hacia el exterior, hay que abrir el firewall de salida hacia una IP y/o DNS y/o puerto concreto, ya que la página redirige habitualmente a ingra.es:5432 ó ingra2.es:5432
El servidor de aplicación web se puede instalar:
1. en un servidor administrado por Ingra, con las ventajas de:
· alta velocidad de salida de un servidor dedicado (100-300Mbps)
· alta disponibilidad de servicio
· backups diarios de las bases
y archivos del proyecto, sin límite de tiempo
· acceso FTP al directorio de datos
· acceso mediante RemoteApp de Windows server 2008 para uso del interface
Windows cuando haga falta, con licencia de Terminal Services para múltiples
usuarios
2. en un servidor del cliente final
(para uso en red local, por ejemplo)
3. también se puede instalar para uso local monousuario
En primer lugar, se puede utilizar el interface web estándar proporcionado por esta versión de Ingrid, mediante los perfiles predefinidos.
Además, al crear un proyecto con una o varias BD, se puede personalizar el interface web de acceso a los datos SIN PROGRAMAR EN JavaScript ni HTML, desde la aplicación Ingrid, se generan los puntos de entrada de los usuarios en cada base, los perfiles de permisos, y la estructura de datos con la que trabajar. Con esto se genera la web de interface que es la que envía y recibe los datos hacia y desde el cliente.
Por último, para desarrolladores, se puede crear un cliente propio completo o completar el estándar de Ingrid con plugins de JQuery programados sobre el API de servicios web que proporciona Ingrid. E incluso conectarse directamente a API de aplicación y datos de Ingrid, utilizando otras librerías JS que no sean JQuery
Para poner el servicio web una BD se debe cumplir:
· Los usuarios de acceso web deben tener todos contraseña, el código de
usuario Ingrid es el nombre de usuario de acceso web
· Para trabajar con imágenes, tienen que estar vinculadas a la base y en
modo web (con las tres versiones vinculadas en BD, no sólo la alta)
· Crear carpetas con el mismo código que los grupos de permisos de
usuarios (como G1, G2), serán los puntos de entrada en web de cada
usuario
· El nombre de base admite espacios en blanco
· Se puede tener un usuario de acceso administrador sin contraseña, para
uso en pre-producción del interface Windows. En BBDD de producción, no
puede haber usuarios sin contraseña, pero TIENE que existir uno 'usuario1',
con contraseña, para el acceso interno del servidor.
· Para generación de licencias es necesario que el servidor web tenga el
módulo Z
Con esto se tiene un acceso en edición automático a las carpetas y elementos de la base, permitiendo visualizar imágenes y posiciones en el geomapa. Los mapas sólo pueden ser cartográficos. La planimetría no puede pasarse a coordenadas geográficas de Google. El campo Geomapa> Cabecera> Datum no puede estar en blanco.
- Abrir la BD en el Ingrid 7 servidor web y activarlo (pulsando Herramientas> Opciones> Servidores> Servidor web> Servidor, teniendo puesto el puerto 80 para red local, o uno cualquiera, como el 5432 para dar servicio en internet, por ejemplo).
- La web que sirve de interface html se encuentra en \macros\web. Esta web puede ir en un servidor remoto, siempre que se cambien los datos del servidor para que apunte a la IP y puerto correctos.
- Si se quieren publicar varias bases, la forma más simple,
es
que estén en el mismo directorio que la base abierta en ventana principal del programa
que actúa de servidor. Para publicar bases en distintas ubicaciones
incluso de red local, abrir el archivo Herramientas> Opciones>
Servidores> Servidor web> Abre webs,.dat y establecer el camino de
acceso a cada nombre de base, como:
B mibase
C:\bases\dir_de_mibase\nombre_archivo_mi_base.ing
También hay una sintaxis para conexiones a BD en SQLserver
- Si el propio Ingrid hace de servidor web, se puede configurar con
una entrada como:
S servidor
C:\ingrid7\macros\web donde se encuentra en archivo index.htm raíz del
interface web
- Servidor web. Puede ser una aplicación nodeJs que sirva archivos http, o bien una aplicación comercial como IIS7 o Apache, por ejemplo. No es imprescindible tener una aplicación porque Ingrid 7 también puede servir el cliente web en el mismo puerto, con algunas limitaciones.
- Adobe Acrobat para creación de vistas en miniatura para archivos PDF (en Windows al hacer ref. externas y en web al subir como imágenes asociadas, por ejemplo).
- Sistema de backup. Ingra lo soporta en sus servidores con aplicaciones nodeJs, alojamientos en la nube y sincronización entre servidores con conexiones P2P.
- Para envío de correo a través de SMTP, hasta la versión 7.4.30 el propio Ingrid tenía código para envío con soporte TLS y SSL. A partir de esa versión, la clase script de Ingrid Csmtp es obsoleta, y el envío se hace mediante un programa nodeJs documentado en los informes comunes> Ejemplos.
Sólo para uso con Aplicación remota (TS):
- Aplicación ofimática asociada a archivos XLS, XLSX, CSV... como Ms-Office u OpenOffice, para abrir los archivos de volcado a hoja de cálculo.
- Navegador de internet (recomendado Google Chrome) para abrir las ventanas html de la aplicación Windows: calendario y mapa web.
Desde la versión de 2014, ya no son necesarios:
- MsOutlook (2003-2010) para recepción de e-mail con MAPI (necesario para el API).
- Cliente de correo Windows live mail, registrado , porque con Outlook se muestra un diálogo de interface al acceder a la cuenta. El cliente web html debe tener instalado un cliente de correo registrado al protocolo MAILTO, para poder subir archivos al servidor.
> los archivos e imágenes se suben ya directamente, sin necesidad de correo electrónico
-MsExcel para generación de archivos o informes XLS
> los informes html ya se exportan directamente a formato PDF y XLS (xml). Sólo sería imprescindible (este u Open Office, o algún otro compatible) para uso desde Aplicación remota, que es un servicio a extinguir.
Utilizando como prototipo la base Bomberos.ing
- Con un script inf.iwebdoc en la BD, se puede gestionar el interface, condicionar la información mostrada para cada usuario, cambiar la distribución de los campos en cada ventana, implementar botones para crear o eliminar registros… Si no existe, las funciones están vacías y la web muestra los campos de defecto que tenga el servicio programado en C++
- Para hacer sensible la información que va amostrar una de una carpeta de búsqueda, al usuario de BD que ha accedido desde web, se pueden usar en el SQL macros que devuelven del grupo de trabajo, el grupo del usuario... como
Recuerde que en una tabla particular 'webusu' y campos con los mismos códigos que la tabla de gestión de usuarios (pwd, raiz y grui) se pueden definir usuarios como conceptos de BD, aunque esta práctica está desaconsejada.
select ide from _tarcor
where trai=<<tra>> order by cod
(correctivas donde el código
de grupo de trabajo coincida con el código de usuario de acceso a
BD)
· Para crear formularios personalizados de búsqueda, se crea un in forme de la tabla INF, con un código que lleve la extensión .ibus (esto indica al cliente web qué debe esperar de ese script: una lista de identificadores resultado de la búsqueda).
Puede ver cómo definir parámetros de distintas clases en al base de ejemplo ClienteWeb, informe INFORMES> prupar.htm
· El concepto formulario de búsqueda debe
contener en el script al menos el código:
incluir ("libcarbus"); return busqueda_carpeta("select")
· Se pueden crear diversos conceptos formulario, por ejemplo, para cada
perfil de permisos, de forma que unos usuarios no vean los datos de
búsqueda de los usuarios de otro nivel
· Para modificar el aspecto de listas y controles, usar directamente la definición del modelo de datos en la ventana Proyecto> Tablas y campos> Campos:
Windows y Web:
o Visible,
En Windows, otra forma de ocultar campos es ignorarlos si se hace un
interface personalizado en la pestaña Ventanas
de la clase). Es el más restrictivo de todos, porque si no se
muestra no se puede editar, y tampoco aparece en las listas que hacen
referencia por este campo (Referenciable).
En web, se puede definir un interface personalizado por tabla, ocultando
los que se desee.
o Editable, editables
o Utilizar el Tipo de dato de cada campo,
para poner formato como: (A)ngulo, (W)eb, (M)ail, (b)ooleano,
(B)yte.
o Virtuales para definir pestañas (persiana/pestaña en web, códigos con prefijo
'__') y rótulos de secciones (códigos con prefijo '_'). Campo
alineación=1 en una pestaña-persiana, significa: cerrada por defecto.
Sólo Web:
o Referenciable, se
muestran listas que hagan referencia por este campo.
o Alineación (web), forzar al estilo habitual de
alineación con modificadores: 1:izquierda 2:centro 3:derecha
· Para ejecutar informes, poner como extensión del código del informe, lo que el informe va a devolver (.pdf si se utiliza el impresor, .htm si se devuelve un texto que es el código HTM de una página web, .xls si es el código XML Spredsheet de una hoja de cálculo... Para ejecutar un script en el servidor, nombrarlo con extensión .js o .json, dependiendo de lo que devuelva como error, confirmación...
ATENCIÓN: para mejorar el rendimiento, sólo se deben definir las funciones que se usen, de forma que ni se evalúen, ni se construyan los parámetros, etc. de las demás, ya que Ingrid las evalúa, si existen. Todas son opcionales.
La documentación completa y actual está en el informe Cabeceras y librerías generales> iwebdocComun de la distribución estándar de informes (comun). Además, en este se definen las variables globales que tenemos disponibles y no hace falta redefinir: el controlador iwebdoc que definamos en cualquier base, es conveniente que lo incluya siempre.
CONTROL DE FLUJO CON BD:
Estas funciones devuelven un json con variables fijas y otras que
ponemos devolver al hacer el graba. Retorna:
acc:<acciones_en_cliente>, dep:<dependencias>, err:<error>,
espera...
· iwebdoc_cabeceraO (o)
Ha habido otras versiones (iwebdoc_cabecera(), iwebdoc_cabecera2() ) con otros parámetros, pero esta es la más completa. El objeto parámetro de entrada se compone de: {tab1, pad1, tab2, pad2, tab, cam}
Define qué campos se muestran en las lista de conceptos por su tipo, o
dependiendo de bajo qué tipo de padres aparezcan. tab1 es la tabla
del concepto padre y tab2 la de los hijos. Por defecto, se debe implementar algo como: return "cod 'Descripción':res '_info";
para formatear todas las listas no específicas con alguna información básica.
· iwebdoc_permisos ()
Permisos de visualización y edición por tablas de conceptos. Restringe la Lectura, Edición, Creación y Destrucción de conceptos en las tablas que se quieran restringir. Por defecto, el grupo G1 de administradores puede editar todo ("*,LECDGM"), y los usuarios a partir del G3, ver todo, pero no editar nada ("*,L").
· iwebdoc_navega (tab, ide, tabpad)
Cada vez que se navega por una página se ejecuta esta función, por lo que aquí se puede diseñar el formato de página para cada tipo de concepto, o para algunos especiales, ver la siguiente sección que documenta el los datos que se pueden utilizar en el parser. Esta función devuelve una cadena multilínea con la construcción de la ventana en cuanto a secciones (pestañas en windows), campos, listas, botones... similar a la que podemos manejar en las ventanas de windows.
· Las funciones iwebdoc_crea, iwebdoc_creado, iwebdoc_graba, iwebdoc_grabado, iwebdo_graba, iwebdoc_grabadom se ejecutan respectivamente antes o después de cada una de esas operaciones (creación de registros, modificación de campos, y eliminación de registros). iwebdoc_grabado se suele usar, por ejemplo, para calcular otros campos en función de los que se han introducido, y refrescar al información en pantalla,
Existen más.
En las BD para demostración de cliente web-servidor, que hay en el directorio Ejemplos de la distribución de Ingrid servidor (como fotovoltaico.ing) se puede ver en la programación del servidor web (informe iwebdoc) que contiene ejemplos de definición de interface, control de campos...
Vea la reducción de funcionalidad de la aplicación Windows servidora a través de Terminal server en: Limitaciones de uso.
Accesible para demostración en: ingrid.ingra.es/d/monumentos.htm
Los tipos de página distinta (aparte de las carpetas de búsqueda):
(MON) Monumento: datos, fotos, mapa situación, datos última
valoración, listas de:
· ascendientes valoraciones y actuaciones (con.padi y superiores)
· espacios (rcc.com) con campos rcc.obs y rcc.num2
· autores (rcc.com)
· bibliografía (rcc.com)
· actuaciones (actdoc.padi)
(ESP) Espacios calle o parque: lista de monumentos con campo rcc.obs y rcc,num2
(AUTBIB) Autor Bibliográfico: datos y lista de ref. bibliográficas (3 clases de bibliografía)
(AUTMON) Autor de monumento: datos y lista de monumentos (10 clases de monum.)
(BIB) Bibliografía: lista de monumentos y de autores bib.
(DCM) Documentación reservada: Informes de valoración y Actuaciones
*Permisos (L) Lectura, (E) Edición, (C) Creación, (D) Destrucción, para cada perfil:
Administrador (coordinador de proyecto)
acceso total y a todas las carpetas, excepto CAR (carpetas)
Edición monumentos (redactores)
visualiza todo, edita todo menos: AUTBIB, BIB, DCMACT, tampoco FAM (familias), ni CAR
Edición bibliografía (documentalista)
visualiza todo, edita AUTBIB, BIB, DCMACT
Consulta (ayuntamiento)
visualiza todo
Consulta restringida (público)
visualiza todo excepto DCM
Accesible para demostración en: ingrid.ingra.es/d/bomberos.htm
Consiste en un sistema de avisos para mantenimiento correctivo en el que hay 5 perfiles de usuarios de acceso web:
1. administrador, gestiona la BD incluso desde interface Windows, gestiona usuarios de acceso web, y sus perfiles de acceso en edición y consulta, y realiza tareas masivas y para las que no hay acceso web.
2. Mando del cada Parque de bomberos, es el editor principal de avisos.
3. Jefe de mantenimiento, distribuye el trabajo para dar respuesta a los avisos, asignando técnicos concretos y fecha programada para cada trabajo.
4. Técnico de mantenimiento, realizan los trabajos asignados por el jefe y cierran el parte, realizado correctamente o sin realizar.
5. Responsable de mantenimiento en cada parque