Introducción

El protocolo SHIP de Salto Systems proporciona un conjunto de comandos que pueden ser englobados en dos familias, las cuales representan los dos métodos previstos de uso para este sistema.

El integrador por otro lado también puede atacar el problema desde múltiples ángulos en función de cual sea el objetivo de su integración.

Con todas estas posibilidades y la experiencia acumulada durante varios años con Salto, esta pasarela opta por una estrategia basada en el reparto de las responsabilidades.

El sistema Salto será el responsable de gestionar las cerraduras (Online y  Offline), Zonas y Encoders que deberán ser sincronizados en el sistema integrado (a partir de ahora lo llamaremos nuestra aplicación).

Por otro lado nuestra aplicación se encargará de gestionar las llaves y los permisos.

El resto de objetos del sistema Salto como Usuarios, Grupos de usuarios, Calendarios, Horarios o Departamentos, dejan de ser útiles y simplemente no los utilizaremos.

Mediante nuestra pasarela y asumiendo esta estrategia, es posible dotar a su instalación Salto Systems de prácticamente cualquier funcionalidad.

Partes de la estrategia

El reparto de responsabilidades descrito en la introducción, implica que ambas partes, tanto el sistema Salto como nuestra aplicación, dispondrán de su propia información y deben confiar en la información que tiene el lado contrario.

Esto obliga a que la información que fluye entre ambas partes lo haga en un sentido concreto, por lo cual el orden de las siguientes explicaciones es significativo.

Sincronización desde el sistema Salto

Las puertas, zonas, encoders y resto de equipamiento se gestiona en el sistema Salto ya que corresponde a equipamiento fisico que debe ser instalado y configurado por los técnicos.

Después de incorporar o eliminar puertas, zonas o encoders en el sistema Salto, será necesario trasladar estos cambios a nuestra aplicación ya que solo cuando existan estos objetos en nuestra aplicación podrán ser utilizados para asignar permisos (en las puertas y zonas) y para emitir llaves (en los encoders).

La solución típica consiste en implementar un Wizard, que el propio técnico que gestiona el sistema Salto puede ejecutar, y que se encarga de calcular las diferencias y proponer las acciones necesarias para que nuestra aplicación tenga los datos sincronizados con el sistema Salto. Normalmente bastará simplemente con aceptar las acciones de sincronización propuestas, por lo que supondrá una labor mínima para el técnico.

Puede ver los ejemplos de como leer las listas de puertas, zonas y encoders en el sistema Salto mediante el Kit de desarrollo

Emisión/Cancelación de llaves

Como indicamos en el reparto de responsabilidades, nuestra aplicación gestionará una lista de llaves. Estas llaves podrán ser emitidas o canceladas mediante comandos que serán enviados a la pasarela.

En el caso de emitir una llave, habrá que indicar algunos datos extras como los días de caducidad que tendrá la llave y el encoder mediante el cual se realizará la operación.


Puede ver los ejemplos de como emitir o cancelar llaves mediante el Kit de desarrollo

Asignación de autorizaciones

Una autorización consiste simplemente en establecer una relación entre una llave y una puerta o zona.

El hecho de establecer esta relación implica que el portador de esa llave podrá abrir siempre esa puerta o cada una de las puertas que componen la zona.

Opcionalmente se puede incluir en la relación un periodo durante el cual ésta será válida (una fecha y hora de inicio mas una fecha y hora de final).

Opcionalmente para cada una de las autorizaciones podremos indicar uno o varios rangos horarios (una hora de inicio y una hora final).

Opcionalmente para cada uno de estos rangos horarios se podrá indicar el día de la semana en el que éste será válido.

Esto se ve más claramente en Modelo de datos, donde se describe como implementar las tres vistas que serán las utilizadas por el Servidor de la pasarela.

El servidor de la pasarela accederá a estas tres vistas tanto en el momento de emitir una nueva llave como durante la confección de la lista de autorizaciones que será utilizada para las renovaciones de las llaves solicitadas por el sistema Salto.

Como extender las funcionalidades

Con lo visto hasta ahora puede parecer que simplemente hemos reducido las posibilidades del sistema Salto ya que hemos dejado de utilizar algunos objetos que su software sí gestiona (grupos de usuarios, usuarios, departamentos, calendarios, rangos horarios, etc).

Sin embargo, lo que en realidad hemos hecho es trasladar a nuestro propio sistema de información los objetos primitivos y realmente importantes del sistema (puertas, zonas, llaves y encoders).

En este momento estamos en disposición de implantar nuestro propio modelo sin estar encorsetados en el diseño de propósito general que proporciona Salto Systems.

Veamos un ejemplo de como podemos desarrollar estos objetos primarios para poder cubrir cualquier necesidad que tengamos:


Si tenemos interés en realizar una integración del sistema de Salto Systems con nuestra propia aplicación, el motivo principal normalmente será el hecho de que ya tenemos información disponible y como se muestra en el ejemplo relacionaremos nuestro modelo de datos con los objetos primitivos que interactúan con Salto System.

Con nuestro modelo de datos correctamente enlazado con los objetos que interactuan con Salto Systems ya podemos plantearnos nuestro propio modelo de seguridad.

Siguiendo con el ejemplo:

Cualquier modelo de seguridad que se implementa, deberá finalmente descomponerse en las tres vistas descritas en el Modelo de datos, lo cual normalmente se hace uniendo el resultado de distintas consultas sobre los distintos tipos de autorizaciones que hayamos previsto en nuestra aplicación.

Como ya se ha comentado, cada autorización puede tener asignado un periodo de validez, así como varias zonas horarias. Esto permitiría con un diseño adecuado implantar un sistema de control de reservas de cualquier tipo (aulas, instalaciones deportivas, hospedaje, etc).

El objetivo de este documento es demostrar como puede plantearse una personalización de un sistema de control de accesos mediante esta pasarela, de forma que el desarrollador centre su esfuerzo en obtener el modelo de seguridad deseado y no en las complicaciones técnicas relacionadas con la integración del sistema Salto Systems.