Espacios. Vol. 35 (Nº 3) Año 2014. Pág. 6

Propuesta de estandarización para la comunicación entre sistemas automatizados de información institucional

Standardization proposal for communication between automated systems institutional information

Tomás Rafael MORENO P. 1; Loly Valentina GÓMEZ F. 2

Recibido: 17/11/13 • Aprobado: 12/02/14

Contenido

RESUMEN:
Toda organización tiene un conjunto de procesos que usualmente pueden o no estar automatizados, pero, ¿Qué pasa cuando un sistema no tiene todos los datos?, muy seguramente en algún momento habrá experimentado los retardos en los procesos “automatizados” porque “aun no llega la data”, procesos vitales como los de nómina, cierre de inventario, cuadres de caja pueden estar paralizados por información que usualmente está en otro sistema de información, pero que por diversas circunstancias debe ser enviado por correo, CD o algún otro medio de almacenamiento que requiere de intervención humana. En ese preciso instante, cuando los datos están en una o más bases de datos, cuando los sistemas pueden procesarlos pero no existe comunicación alguna entre un sistema y otro más que la intervención humana, los sistemas dejan de ser “automatizados”, y comienzan a surgir los problemas. Esta investigación plantea una manera simple de interconexión de Sistemas de Información para logran la interoperabilidad necesaria en el quehacer diario de las institución, el caso de estudio tomado fue el núcleo Nueva Esparta de la Universidad de Oriente
Palabras Claves: Servicios, Automatización, Procesos, Web.

ABSTRACT:
Every organization has a set of processes that can usually be automated or not , but what happens when a system does not have all the data ? Almost certainly at some point have experienced delays in the " automated " process that " has not yet reached the data " vital processes such as payroll , inventory closing , cash tabulated may be paralyzed by information that is usually in another information system , but for various reasons must be mailed , CD or other storage medium that requires human intervention. In that moment , when the data is in one or more databases , when systems can process but there is no communication between one system and another more human intervention , systems cease to be "automated" and begin to problems arise . This investigation presents a simple way to interconnect information systems to achieve interoperability required in the daily work of the institution, the case study was taken from the core Nueva Esparta University East
Keywords: Services , Automation , Process , Web .

1. Introducción

En la década de los 70, hace tal solo unos 40 años atrás, la informática se abría paso en el mundo empresarial, la posibilidad de agilizar el procesamiento de los datos o de tener copias digitales cobró gran importancia, pero… ¿por qué?, ¿qué hacía a los llamados “Cerebros Electrónicos” 3 una herramienta tan importante?, precisión en los cálculos, ahorro de tiempo, posibilidad de acceso rápido a datos históricos, estas y muchas otras ventajas comenzaron a surgir en el mundo empresarial con el uso de los computadores.

En un inicio la incorporación de computadores pudo hacer sentir a muchos “sustituidos”, sin embargo, esta tecnología solo vino a potenciar el rendimiento de un individuo, haciendo más fácil algunos procesos repetitivos y engorrosos en los que el ser humano era propenso a errores.

Progresivamente el uso de la tecnología se hizo cotidiano en el ambiente empresarial, en la actualidad hasta el negocio más pequeño tiene algún tipo de automatización, o al menos digitalización 4 de sus documentos, por ello el reto actual es permitir y potenciar el uso e intercambio de la información existente en una organización, para evitar que un retraso humano afecte el delicado engranaje organizacional.

2. Métodos

De acuerdo a la naturaleza y características del objeto de estudio, esta investigación se enmarca dentro de la investigación aplicada o Proyecto Factible(Hurtado, 1998), por cuanto a través del desarrollo se proponen alternativas en torno a la problemática de la intercomunicación de sistemas institucionales.

3. Planteamiento del Problema.

Toda organización tiene un conjunto de procesos que usualmente pueden o no estar automatizados, pero, ¿Qué pasa cuando un sistema no tiene todos los datos?, muy seguramente en algún momento habrá experimentado los retardos en los procesos “automatizados” porque “aun no llega la data”, procesos vitales como los de nómina, cierre de inventario, cuadres de caja pueden estar paralizados por información que usualmente está en otro sistema de información, pero que por diversas circunstancias debe ser enviado por correo, CD o algún otro medio de almacenamiento que requiere de intervención humana. En ese preciso instante, cuando los datos están en una o más bases de datos, cuando los sistemas pueden procesarlos pero no existe comunicación alguna entre un sistema y otro más que la intervención humana, los sistemas dejan de ser “automatizados”, y comienzan a surgir los problemas.

Es una realidad que los datos en la actualidad son altamente preciados, y por ello, resguardados con el celo correspondiente, y no se dará libre acceso a los datos a cualquiera, pues aunque se forme parte de la misma organización o institución, pueden existir intereses encontrados, es allí cuando se vuelve políticamente correcto un acceso controlado, pero, allí no acaba el problema, pues pese a que se acuerden los datos que se facilitaran, seguramente existirán distintas opciones en los manejadores de base de datos, lo que complicará tanto la comunicación como dos personas hablando idiomas diferentes. En este punto solo existen dos opciones:

  • La construcción de un sistema monolítico con toda la información.
  • Abstraernos de la realidad nativa del conjunto de datos y acordar un lenguaje intermedio.

Aunque parezca un poco extremo el planteamiento no hay más salidas, pues aunque se acuerden estándares para el desarrollo en la organización, lo artesanal del desarrollo de sistemas implica que la abstracción de los datos será realizada desde la visión de cada grupo de desarrolladores, por lo que aunque se tenga todos los datos en un mismo manejador de base de datos, de seguro no existirá homogeneidad en la forma en que son manejados estos datos.

Por ejemplo, en el caso de los datos básicos de una persona un desarrollador “A” puede definir campos como: cédula, nombre, apellido, mientras que un desarrollador “B” podría utilizar: IdPersona, Nombre, Apellido, FechaNacimiento. Esas sutiles diferencias en la definición de los datos puede ser tediosa para cualquiera de los desarrolladores a la hora de utilizar la base de datos del otro, de hecho, el tener que compartir la estructura de su base de datos, puede ser una importante falla a la seguridad. De allí surge la necesidad de buscar un camino intermedio, donde previamente se acuerde lo que necesita el desarrollador “A” de la base de datos del desarrollador “B”, y los términos en que esta información le será suministrada; manteniéndose de esta forma la libertad y autonomía de trabajo en ambas bases de datos y minimizando los riesgos de perder toda la información por un único fallo.

En tal sentido la posibilidad de abstraernos de diseños particulares y permitir la permeabilidad de los datos, abre un abanico de posibilidades para el crecimiento de los sistemas en las organizaciones. De hecho, de no abordar así el crecimiento e intercomunicación de sistemas las posibilidades de comunicación interinstitucionales y el real aprovechamiento de la tecnología se vuelve casi nulo.

¿Qué información es relevante en una organización?, por más que se trate de especificar y priorizar a la larga se llegará a una única conclusión: toda!, los datos que hoy parecen irrelevantes pueden ser prioritarios mañana, y según aumenta la complejidad de los datos estos se acercan más a la realidad del negocio, por ello el desarrollo de sistemas únicos que manejen toda la información de la organización es totalmente viable, pero, para nada es simple.

En cualquier negocio, por simple que parezca existe una complejidad implícita, lo cual implica que el más mínimo sistema que aspire tener la totalidad de los datos de la organización puede llegar a ser considerablemente complejo, sin embargo no es imposible de realizar, pero la cantidad de horas hombre requeridas, así como el resto de recursos utilizados de seguro serán bastante grandes para un solo proyecto, lo cual disminuye la factibilidad del mismo.

En el caso específico de organizaciones cuyo proceso de automatización se encuentra en las etapas iniciales, según las etapas planteadas por Andreau, Ricart, & Valor (1991), es preferible en dichas ocasiones apostar por proyectos de bajos costes de desarrollo y pronta obtención de resultados, que permitan ganar confianza sobre los beneficios de la automatización. En esos delicados momentos iniciales, cuando el sistema manual es lo único conocido, el balance de riesgo beneficio no suele estar a favor de los proyectos arriesgados y se puede afectar en forma considerable la evolución de los sistemas de la organización si se toman alternativas que no garanticen el éxito.

Sin embargo, luego de alcanzada una etapa madura en el desarrollo de sistemas, cuando la organización ha ganado confianza en las soluciones que pueden obtener a través del proceso de automatización, se pueden considerar el desarrollo de proyectos más ambiciosos, no obstante, dado lo compleja de esta etapa, la mayoría de los grandes proyectos suelen ser planteados para la siguiente fase, la coordinación de sistemas, en la cual tanto el negocio como los desarrolladores han tenido el tiempo necesario para explorar los beneficios de la automatización, y hallar las necesidades reales según la dinámica de la empresa.

Visto de esta forma, el abordar un proyecto monolítico en la organización, podría tardarse un tiempo considerable, y aun así ser una apuesta arriesgada, además, en varias ocasiones implicaría desechar gran parte de los desarrollos realizados, en tal sentido, la opción de integrar sistemas disgregados puede resultar mucho más viable y de bajo coste, requiriendo tan solo un mínimo de coordinación.

Por ello el uso de servicios web representa la solución ideal para este tipo de casos, cuando se pueden generar soluciones a través de una sencilla opción de intercambio de información en el software existente.

4. Objetivo General

Diseñar una capa intermedia de servicios para la comunicación entre sistemas institucionales.

5. Objetivos Específicos

  • Analizar las opciones y tecnologías existentes para el desarrollo de servicios basados en web.
  • Codificar los servicios necesarios para la interconexión entre dos sistemas determinados.
  • Prueba de los servicios desarrollados, utilizando casos reales de operatividad.

6. Propuesta para intercambio de información en sistemas académicos de la Universidad de Oriente, Núcleo Nueva Esparta.

6.1. Estructura propuesta para los Servicios XML-Data Packet o HTTP/XML

Los servicios HTTP/XML son accesibles por cualquier lenguaje de programación o programa, que tenga obviamente, la capacidad para acceder a servicios HTTP mediante una conexión estándar TCP/IP. Dichos servicios funcionan de manera idéntica a cómo lo hacen las páginas web, usando un navegador, solo que la información mostrada se expresa en formato XML, solo que las funciones del navegador será un programa escrito en cualquier lenguaje, como por ejemplo: PHP, PERL, PYTHON o DELPHI.

Cuando un lenguaje de programación realiza una petición HTTP, hace exactamente lo mismo que un navegador web cuando solicita una página web. Al fin y al cabo un navegador es solo un programa que se encarga de armar la página web en el lado del cliente, según como lo indica el lenguaje HTTP, la única diferencia entre lo anterior y el funcionamiento de los servicios, es que estos no usan HTML como formato de presentación si no que son presentados en formato XML similar a lo que se presenta a continuación:

FORMATO XML/DATAPACKET

<?xml version="1.0" encoding="UTF-8"?>

<DATAPACKET>

<METADATA>

<FIELDS>

<FIELD attrname="Nombre" fieldtype="string" width="75"/>

<FIELD attrname="Tipo" fieldtype="i2"/>

<FIELD attrname="Descripcion" fieldtype="string" width="255"/>

<FIELD attrname="Version" fieldtype="string" width="255"/>

<FIELD attrname="Desarrollador" fieldtype="string" width="255"/>

</FIELDS>

<PARAMS rowcount="1"/>

</METADATA>

<ROWDATA>

<ROW Nombre="system.planificacion.escuelas.obtener" Tipo="1" Descripcion="Servicio que permite obtener todas las direcciones de escuelas registradas, para un núcleo o extensión." Version="0.1" Desarrollador="Tomás Moreno tomas.moreno@ne.udo.edu.ve">

</ROWDATA>

<ERROR codigo="0" descripcion=""/>

</DATAPACKET>

Donde fieldType=”???” puede ser los siguientes valores para representar los siguientes tipos:

Entero Corto i2 ( 2 Bytes )

Entero i4 ( 4 Bytes )

Cadena string width=Largo

Fecha Date

Hora Time

Fecha y Hora DateTime

Blob "bin.hex\" SUBTYPE=\"Binary\""

Casi todos los servicios son parametrizados según el tipo de información que se desea obtener y según como se programen, para poder acceder a los servicios se debe tener una url, donde se ubica el servicio principal, el cual es único para todos los servicios, además de una usuario y una contraseña un ejemplo del anteriormente mencionado url es el siguiente:

https://thot.ne.udo.edu.ve/servicios/src/services.php

Obsérvese el .php al final del url esto es porque los servicios están implementados en lenguaje script php, sin embargo tanto el cliente como el servidor pueden estar en otros lenguajes de programación como Java, C++, Ruby, Python, Perl y el lenguaje en que se implemente cualquiera de los dos no debe afectar la manera de solicitar mediante una petición HTTP estándar y una respuesta formateada en XML.

En cuanto a los parámetros se deben ser enviados a mediante variable POST o GET según como se implemente el servidor en algunos casos pueden incluso ser cualquiera de los dos.

Tres variables que deben ser enviadas siempre son las siguientes y dependiendo de la implementación del servidor de servicios pueden cambiar de nombre, un ejemplo para la implementación de los servicios de planificación académica es operador_sd, password_sd, servicio_sd, las primeras dos variables implementan la seguridad que le permite al servidor de servicios determinar si tiene o no derecho a acceder a los servicios y a cuáles de ellos, la tercera variable es usada para saber a cuál servicio se desea acceder, recordando que pueden ser un número infinito de servicios, los cuales en uno u otro caso pueden requerir uno o más parámetros adicionales, dichas variables adicionales indicaran al servicio que clase de información desea obtener, un uso clásico es enviar el número de cédula para obtener solo información de una persona especifica.

6.2. Seguridad en el transporte de la información el uso del HTTPS

Como se explicó con anterioridad el acceso a los servicios HTTP/XML tienen un funcionamiento muy similar al acceder a una página web, sin embargo difieren en el formato de presentación de la información el primero usa HTML y los servicios usan XML, en el formato DATAPACKET para darle un formato uniforme y predecible.

Sin embargo por todos es sabido los problemas de seguridad que implican el trasladar información por redes desconocida, situación que es muy común en accesos remotos usando internet como nexo de comunicación, la tecnología de las teleco municiones tuvieron que mejorar la seguridad de manera de garantizar que la información no sea vista o pero que no sea modificada por nadie que esté en el camino entre el servidor y el cliente.

La solución a este problema fue el HTTPS una capa de encriptación que funciona por encima del HTTP, usando certificado digitales y permite establecer un especie de tubo, al cual solo se accede desde los extremos en el cual solo se encuentran el servidor y el cliente, haciendo virtualmente imposible acceder a la información, el éxito de este protocolo ha sido rotundo, al punto de que la banca electrónica, militares de grande potencias y corporaciones eligen este protocolo para proteger sus comunicaciones de ser espiadas por terceros.

La gran ventaja que ofrece el HTTPS es que no es necesario modificar en ningún momento el código que controla las páginas web, evitando engorrosos cambios, este protocolo funciona a nivel de librerías y es transparente para el programador de servicios web.

6.3. Ejemplo de acceso usando el lenguaje script PHP y la librería CURL

<?php

$ch=curl_init("https://thot.ne.udo.edu.ve/servicios/src/services.php");

curl_setopt($ch,CURLOPT_HEADER,0);

curl_exec($ch);
curl_close($ch);
fclose($fp);
?>

7. Conclusiones.

La interoperabilidad entre Sistemas de Información, es quizás un paso vital que se debe dar a nivel de las instituciones públicas para poder garantizar el adecuado flujo de la información, pues, una institución que desconoce su estado actual, no puede tomar decisiones efectivas.

Es uso del XML-Data Packet, es tan solo una de las múltiples opciones que se puede utilizar para lograr la comunicación entre sistemas, pero ha sido altamente efectiva en el caso de la comunicación entre sistemas en el Núcleo de Nueva Esparta, donde no solo ha servido para interconectar los sistemas desarrollados por la Delegación de Computación Académica, sino que también ha servido para la comunicación con los sistemas desarrollados por el Departamento de Administración y Control de Estudios, lo cual demuestra que su implementación puede ser simple y replicable en otros ámbitos. Con lo cual, esta investigación abre una pequeña puerta para lograr ese adecuado flujo de información, pues aunque cueste reconocerlo, en muchas ocasiones la intervención humana en la manipulación y generación de los datos solo genera subjetividades y errores, lo cual, resta fiabilidad a la información y por ende a los sistemas que la generan.

Seguramente la transición a una comunicación plena entre sistema no ocurrirá de un día a otro en las instituciones del país, pero es necesario y propicio que las universidades autónomas inicien y promuevan este proceso.

8. Referencias

Andreau, R., Ricart, E. J., & Valor, J. (1991). Estrategia y sistemas de información. McGraw-Hill.

Hurtado, J. (1998). Metodología para la investigación holistica. Caracas: Fundacite Anzoátegui.

1 Servicios de Computación Académica, Núcleo de Nueva Esparta, Universidad de Oriente, email: tomas.moreno@ne.udo.edu.ve
2 Programa de Licenciatura en Informática, Universidad de Oriente, Núcleo de Nueva Esparta, email: loly.gomez@ne.edu.edu.ve
3 Este término es usado en los relatos de “Historias de un viejo informático”, una serie de relatos vivenciales de la evolución de la informática.
4 Cuando los procesos no son realizados por computadores, pero los soportes o históricos de las transacciones se encuentran en formato digital.
Vol. 35 (Nº 3) Año 2014
[Índice]

[En caso de encontrar algún error en este website favor enviar email a webmaster]