México y la automatización de los flujos de trabajo
En México, desde el año 2011 se implementó un sistema de gestión de información que permite la automatización de los flujos de trabajo entre los funcionario, haciendo más eficiente la gestión de la información administrativa en la institución. A partir del uso de este sistema se vieron sus limitaciones así como la necesidad de incorporar nuevas funcionalidades para ayudar a los directivos en la toma de decisiones.
La aplicación desarrollada utilizó el paradigma multi-capa, con la base de datos en la capa inferior. Partiendo de esta arquitectura se realiza un nuevo diseño donde se establece una arquitectura orientada a servicios, con una arquitectura multi capa, similar a la del sistema de gestión de información, pero en esta ocasión preparada para implementarse de forma distribuida.
Aunque éste es el diseño y la implementación del sistema se realizará en un futuro (aunque sea inmediato), se utilizará en este documento el tiempo presente con vistas a hacer más sencilla su comprensión. Por último, se quiere destacar que este diseño incluye lo más reciente del estado actual de la tecnología, y es posible que no se pueda implementar todo lo que se plantea aquí, pero se tratará de acercarse lo más posible a este diseño, como el caso ideal al que se quiere llegar.
En este sistema, el acceso a las entidades se realiza a través de un servicio web que implementa las acciones de Crear, Obtener, Actualizar y Eliminar (en inglés: CRUD, Create, Retrieve, Update, Delete). Uno de los primeros pasos en el diseño de la arquitectura de un sistema es el diseño de la base de datos. Pero, dado que éste sistema se utilizará para gestionar salidas generadas por el sistema anterior, lo más importante es el diseño de las interfaces de entrada y salida.
Los primeros servicios web utilizaron el estándar XML para el intercambio de información, pero la tendencia actual en muchas ocasiones es utilizar formatos más sencillos, que requieren menor complejidad para su interpretación, tales como el JSON (JavaScript Object Notation) o YAML (Yet Another Markup Language). Aunque el formato de intercambio de información es un detalle de la implementación, se recomienda que se utilice JSON porque este formato es interpretable directamente por el lenguaje JavaScript utilizado en las páginas web.
Otra tendencia actual es la utilización de servicios web que utilizan los verbos especificados por el estándar del protocolo HTTP [5] para implementar las diferentes acciones que corresponden al modelo CRUD descrito anteriormente. Se les llama a estos servicios “RESTful”, donde la primera parte de la abreviatura viene de la frase en inglés “Representational State Transfer”. Este modelo fue especificado por primera vez en Como se describe en el trabajo anterior [4], cada tipo de documento se refiere a una entidad específica.
Y las operaciones sobre una o varias instancias de una clase de entidad se efectúan mediante un servicio web. Como un detalle de implementación, se puede utilizar un mismo servicio web que atienda las operaciones con cualquier entidad y recibir como parámetro la clase de entidad sobre la cual se desea operar, o se puede implementar un servicio web para cada una de las clases de entidad a implementar. Se recomienda utilizar un mismo servicio web para todas las clases de entidad y especificar la clase específica mediante un parámetro destinado al efecto.
En cuanto al motor de base de datos, puede ser cualquiera que implemente el lenguaje SQL, inclusive, no es imprescindible utilizar un servidor, si se utiliza SQLite, que es un motor de base de datos empotrado dentro del programa que lo utiliza. La interfaz se implementa mediante páginas web. Sin embargo, se recomienda separar la presentación de los datos propiamente dichos. O sea, se implementa un servicio web que ofrece las funciones para realizar las operaciones típicas sobre los datos, y otro servicio web es el encargado de entregar la interfaz de usuario necesaria para utilizar esos datos.
De esta manera, la interfaz para la creación de una instancia específica de un tipo de documento, puede ser diferente de la interfaz para la edición de un documento ya existente. Con vistas a que cada usuario interactúe con cada una de las partes de los documentos que le corresponde, y solamente de las maneras en que le corresponde, a cada campo de cada tipo de documento se le asigna un rol para cada acción. Y para facilitar la implementación y la configuración del sistema, esto se puede hacer no solamente a nivel de campo aislado, sino también a grupos de campos.
A modo de ejemplo, el rol que permite crear una entidad de tipo trabajador, es diferente al rol que permite editar el campo de salario que corresponde a dicho trabajador. El primero corresponderá a una persona que trabaja en el departamento de Recursos Humanos y el segundo corresponderá a una persona que trabaja en el departamento de Economía o de Contabilidad. Y otro ejemplo a partir de este caso puede ser que el rol que permite crear y editar una entidad de tipo trabajador, pudiera no tener permiso para ver el contenido del campo “salario”, que sólo puede ser visualizado por las personas con el rol correspondiente al que confecciona la nómina, o por el propio trabajador.
