¿Qué es una puerta de enlace de datos local de Power BI para datos SCADA?

El problema de alcanzabilidad que resuelve la puerta de enlace

La razón de que se necesite una puerta de enlace se reduce a la dirección de la red. Un historiador SCADA o una base de datos de planta vive dentro de una red operativa protegida por un firewall que, con buena razón, no acepta conexiones entrantes no solicitadas desde internet. Power BI, mientras tanto, corre en la nube y necesita leer de ese historiador cuando refresca un conjunto de datos o sirve una consulta en vivo. Si Power BI intentara conectarse hacia adentro al historiador, el firewall lo bloquearía, y abrir un hueco entrante para que el servicio de nube pase por él sería un riesgo de seguridad que la mayoría de las organizaciones no aceptará. Así que hay un genuino empate: la nube necesita los datos locales, pero la red local no dejará que la nube alcance hacia adentro.

La puerta de enlace resuelve esto al invertir la dirección de la conexión. En lugar de que la nube alcance hacia adentro, un servicio de puerta de enlace instalado dentro de la red de la planta alcanza hacia afuera, estableciendo y sosteniendo una conexión saliente a la nube de Power BI. Las conexiones salientes casi siempre las permiten los firewalls porque son como funciona el uso normal de internet, así que no se requiere ninguna regla entrante ni puerto abierto. Una vez que ese canal saliente está arriba, la nube puede enviar una solicitud de consulta por él a la puerta de enlace, la puerta de enlace corre la consulta contra el historiador local en nombre de la nube, y los resultados viajan de vuelta hacia arriba por el mismo canal saliente. Los datos fluyen sin que el firewall tenga que confiar nunca en una conexión entrante.

Este es el valor central de la puerta de enlace: vuelve utilizable por un servicio de nube una fuente local mientras respeta la postura de seguridad de la red. Desde el punto de vista del firewall no ocurre nada inusual, solo un servicio local haciendo una conexión saliente, y sin embargo desde el punto de vista de Power BI el historiador detrás de ese firewall es alcanzable y consultable. Esa reconciliación de la analítica de nube con una fuente de datos local y detrás de firewall es exactamente el problema que la puerta de enlace existe para resolver, y es por qué cualquier equipo que mantiene reportes de Power BI sobre un historiador local termina desplegando una.

Alimentar el refresco programado y DirectQuery

Una vez que la puerta de enlace está en su lugar, soporta las dos formas en que Power BI obtiene datos de una fuente. La primera es el refresco programado, usado cuando un reporte importa sus datos al modelo de Power BI. En el temporizador de refresco, el servicio de nube le pide a la puerta de enlace que jale los datos actuales del historiador local, la puerta de enlace corre la consulta localmente y envía los resultados hacia arriba, y Power BI los carga al modelo. Entre refrescos el reporte corre sobre esa copia importada, así que la puerta de enlace solo está ocupada al momento del refresco. Para el reporte SCADA sobre datos preagregados con un refresco periódico, este es el patrón común, y la puerta de enlace es lo que vuelve capaz al refresco de alcanzar la fuente local en absoluto.

La segunda es DirectQuery, usada cuando un reporte consulta la fuente en vivo en lugar de importar. Aquí cada interacción con el reporte - cada filtro, cada profundización - genera una consulta que el servicio de nube envía por la puerta de enlace al historiador en tiempo real, y la puerta de enlace retransmite la respuesta de vuelta para que el reporte siempre refleje los datos actuales. DirectQuery mantiene los reportes frescos sin importar grandes volúmenes, lo que conviene a datos de series de tiempo de alto volumen que serían poco prácticos de cargar por completo, pero pone carga continua de consultas tanto sobre la puerta de enlace como sobre el historiador, así que la puerta de enlace tiene que dimensionarse y ubicarse para manejar ese tráfico. En ambos modos la puerta de enlace es el conducto; la diferencia es si se usa de forma periódica para un refresco o de forma continua para consultas en vivo.

Como la puerta de enlace se ubica en el camino de cada consulta a la fuente local, su confiabilidad y desempeño moldean directamente los reportes que dependen de ella. Una puerta de enlace en una máquina de poca capacidad, o una que pierde su conexión saliente, hará que los refrescos fallen y los reportes DirectQuery se vuelvan lentos o no disponibles, aunque el historiador mismo esté bien. Por eso la puerta de enlace se trata como infraestructura de producción: necesita un host estable, un camino saliente confiable a la nube y suficiente capacidad para la carga de consultas que carga. Para un entorno de reporte SCADA ocupado, la puerta de enlace no es una ocurrencia tardía sino un componente que tiene que aprovisionarse y mantenerse como cualquier otra parte de la pila de reporte.

Gateway personal vs empresarial, y por qué el SCADA en la nube puede omitirlo

La puerta de enlace viene en dos formas adecuadas a necesidades distintas. El modo personal está diseñado para un solo usuario que refresca sus propios reportes; es simple de instalar y corre bajo el contexto de esa persona, pero no está pensado para compartirse, no soporta DirectQuery para conjuntos de datos compartidos, y deja de funcionar si la máquina de ese usuario está apagada. El modo empresarial es la opción compartida y administrada de forma central: corre como un servicio independiente de cualquier usuario, soporta múltiples usuarios y fuentes de datos, permite DirectQuery, y se administra de forma central con credenciales y permisos gestionados. Para cualquier reporte SCADA serio usado por un equipo, el modo empresarial es la elección correcta, porque el reporte no puede depender del escritorio de una persona estando encendido.

La administración central de la puerta de enlace empresarial es lo que la vuelve viable a escala. Los administradores registran las fuentes de datos locales en la puerta de enlace una vez, almacenan las credenciales ahí de forma segura, y otorgan a los usuarios permiso para construir reportes sobre esas fuentes sin manejar nunca ellos mismos las credenciales subyacentes. Esa separación de la configuración de fuente del diseño de reporte es esencial en un entorno operativo, donde los detalles de conexión del historiador deben ser controlados por unos pocos administradores en lugar de estar dispersos por la máquina de cada analista. La puerta de enlace empresarial provee así no solo alcanzabilidad sino acceso gobernado, compartido y confiable a los datos SCADA locales.

Vale la pena reconocer que la puerta de enlace existe enteramente para sortear el hecho de que la fuente de datos es local, y una plataforma de SCADA nativa de nube elimina esa razón. Si el historiador y su punto de consulta ya están en la nube, como lo están con una plataforma como Merobix, entonces Power BI puede conectarse a ellos directamente por internet, sin problema de firewall entrante que resolver y por lo tanto sin puerta de enlace que instalar, hospedar, dimensionar o mantener. El empate de alcanzabilidad simplemente no surge, porque los datos ya están del mismo lado del firewall que la analítica de nube. Para las operaciones de campo que sopesan cómo llevar sus datos SCADA a Power BI, una plataforma de SCADA en la nube puede convertir un despliegue de puerta de enlace y su mantenimiento continuo en una conexión directa, que es una pieza menos de infraestructura por operar.

Preguntas frecuentes