RuleNodes

Los RuleNodes son los componentes funcionales de una RuleChain en optiCLOUD. Determinan cómo se filtran, enriquecen, transforman, almacenan o transmiten a otros sistemas los mensajes entrantes.

Esta página sirve como orientación práctica sobre los nodos disponibles y sus ámbitos de uso:

¿Qué nodos existen?
¿Para qué se utilizan?
¿Qué salidas o relaciones tienen?

Visión general por categorías

Nodos de filtro

RuleNode	Finalidad
Message Type Filter	Deja pasar solo determinados tipos de mensaje
Message Type Switch	Distribuye los mensajes por distintas rutas según el tipo de mensaje
File Type Switch	Bifurca los mensajes de archivo según el tipo de archivo
File Names Filter	Filtra los nombres de archivo por prefijos
Device Filter	Limita el procesamiento a determinados dispositivos
Script (Filter)	Ejecuta una lógica de filtrado definida libremente mediante JavaScript
Switch	Dirige los mensajes a salidas dinámicas mediante un script
Check Existence Fields	Comprueba si existen campos en el mensaje o en los metadatos
GPS Geofencing Filter	Deja pasar solo los mensajes dentro de un geofence

Nodos de acción

RuleNode	Finalidad
Save Timeseries	Almacena telemetría como serie temporal
Save Attributes	Almacena atributos en un scope seleccionado
Save Alarms	Almacena estados de alarma a partir de mensajes de alarma
Create Alarm	Crea o actualiza una alarma
Clear Alarm	Finaliza una alarma existente
Alarm Counter	Cuenta alarmas dentro de una ventana de tiempo
Log	Escribe salidas de depuración o de registro
Generator	Genera mensajes periódicamente
Message Count	Cuenta los mensajes entrantes y publica el contador
Delay	Retrasa el reenvío de un mensaje
Aggregate OSF File	Lee archivos OSF y genera telemetría a partir de ellos
Aggregate JSONL File	Lee archivos JSONL y genera telemetría a partir de ellos
Process Raw Data File	Procesa operaciones de archivo en el almacenamiento de blobs
Generate Report	Crea informes para un intervalo de tiempo definido
Device System	Agrega datos de varios dispositivos
GPS Geofencing Events	Genera eventos al entrar o salir de un geofence
RPC Call Request	Envía una llamada RPC a un dispositivo
RPC Call Reply	Responde a una llamada RPC entrante

Nodos de enriquecimiento

RuleNode	Finalidad
Originator Attributes	Carga atributos del elemento de origen en los metadatos
Originator Telemetry	Carga telemetría del elemento de origen en los metadatos
Originator Fields	Añade datos maestros del elemento de origen
Tenant Details	Añade información del tenant

Nodos de transformación

RuleNode	Finalidad
Script (Transform)	Modifica el mensaje, los metadatos o el tipo de mensaje mediante JavaScript
To Email	Construye un objeto de correo electrónico a partir de un mensaje

Nodos externos

RuleNode	Finalidad
REST API Call	Envía datos a una interfaz REST externa
MQTT	Publica mensajes en un broker MQTT
Kafka	Publica mensajes en un topic de Kafka
RabbitMQ	Envía mensajes a RabbitMQ
AWS SQS	Envía mensajes a una cola SQS
AWS SNS	Publica mensajes en un topic de SNS
GCP Pub/Sub	Publica mensajes en Google Pub/Sub
Send Email	Envía un correo electrónico mediante SMTP

Nodos de Scheduler

RuleNode	Finalidad
Create Scheduled Task	Programa una ejecución única con retraso
Clear Scheduled Task	Elimina una tarea programada anteriormente

Nodos de eventos y alarmas

RuleNode	Finalidad
Complex Alarm	Crea alarmas a partir de patrones complejos en tiempo real
Complex Event Processing	Evalúa datos de archivos con reglas de eventos
Enrich Alarm	Completa alarmas existentes con información adicional

Vista general detallada

Nodos de filtro

Message Type Filter

Categoría: Filtro
Salidas: True, False

El nodo comprueba si el tipo de mensaje del mensaje entrante figura en una lista configurada. Si coincide, el mensaje continúa por True; en caso contrario, por False.

Configuración

Label	Campo obligatorio	Descripción
Message Types Filter	Sí	Lista de tipos de mensaje permitidos. Debe haber al menos un tipo introducido.

Entre los valores admitidos se encuentran POST_ATTRIBUTES_REQUEST, POST_TELEMETRY_REQUEST, TO_SERVER_RPC_REQUEST, TO_DEVICE_RPC_REQUEST, ACTIVITY_EVENT, INACTIVITY_EVENT, CONNECT_EVENT, DISCONNECT_EVENT, BLOB_STORE_REQUEST y POST_ALARMS.

Ejemplo

Utilice este nodo cuando, por ejemplo, solo deban seguir procesándose datos de telemetría. En ese caso se configura POST_TELEMETRY_REQUEST y se conecta mediante la salida TRUE con otro nodo, que entonces recibirá con seguridad únicamente mensajes del tipo POST_TELEMETRY_REQUEST.

Message Type Switch

Categoría: Filtro
Salidas: una por tipo de mensaje más Other

El nodo distribuye los mensajes a salidas fijas según su tipo de mensaje. Es adecuado como distribuidor temprano en una RuleChain cuando los distintos tipos de mensaje deben procesarse en ramas separadas.

Configuración

Este nodo no tiene opciones configurables. Las salidas están definidas de forma fija.

Salida	Condición
`POST_ATTRIBUTES`	El tipo de mensaje es `POST_ATTRIBUTES_REQUEST`
`POST_TELEMETRY`	El tipo de mensaje es `POST_TELEMETRY_REQUEST`
`POST_ALARMS`	El tipo de mensaje es `POST_ALARMS`
`BLOB_STORE_REQUEST`	El tipo de mensaje es `BLOB_STORE_REQUEST`
`RPC_REQUEST_FROM_DEVICE`	El tipo de mensaje es `TO_SERVER_RPC_REQUEST`
`RPC_REQUEST_TO_DEVICE`	El tipo de mensaje es `TO_DEVICE_RPC_REQUEST`
`ACTIVITY_EVENT`	El tipo de mensaje es `ACTIVITY_EVENT`
`INACTIVITY_EVENT`	El tipo de mensaje es `INACTIVITY_EVENT`
`CONNECT_EVENT`	El tipo de mensaje es `CONNECT_EVENT`
`DISCONNECT_EVENT`	El tipo de mensaje es `DISCONNECT_EVENT`
`Other`	Todos los demás tipos de mensaje

Ejemplo

En una Root RuleChain, este nodo puede situarse directamente después de la entrada para dividir la telemetría, los atributos, las alarmas, los mensajes RPC y las operaciones de archivo en ramas de procesamiento separadas.

File Type Switch

Categoría: Filtro
Salidas: OSF, JSONL, Other

El nodo bifurca los mensajes de archivo según la extensión del archivo. Se utiliza en pipelines de archivos, una vez que una operación de archivo se ha reconocido como BLOB_STORE_REQUEST.

Configuración

Este nodo no tiene opciones configurables. El reconocimiento se realiza a partir de la extensión del archivo en los metadatos.

Salida	Extensiones de archivo reconocidas
`OSF`	`.osf`, `.osfz`
`JSONL`	`.log`, `.log.gz`
`Other`	Todas las demás extensiones de archivo

Ejemplo

Dirija los archivos .osf, por ejemplo, a Aggregate OSF File.

File Names Filter

Categoría: Filtro
Salidas: True, False

El nodo solo deja que los mensajes de archivo continúen por True si el nombre del archivo comienza con uno de los prefijos configurados.

Configuración

Label	Campo obligatorio	Descripción
File Prefixes	Sí	Lista de prefijos de nombre de archivo. La comprobación distingue entre mayúsculas y minúsculas.

Notas

Una lista de prefijos vacía hace que todos los mensajes salgan por False.
El nombre del archivo se lee de los metadatos del mensaje, normalmente de fileName.

Ejemplo

Si un dispositivo carga archivos con data_ y config_, pueden utilizarse dos File Names Filter para seguir procesando por separado ambos grupos de archivos.

Device Filter

Categoría: Filtro
Salidas: True, False

El nodo limita el procesamiento a determinados dispositivos. Según el ajuste, la lista de dispositivos puede utilizarse como lista de permitidos o como lista de bloqueados.

Configuración

Label	Campo obligatorio	Descripción
Devices	Sí	Selección de dispositivos mediante selección múltiple.
Allow selected devices	Sí	Activado: solo los dispositivos seleccionados salen por `True`. Desactivado: los dispositivos seleccionados se bloquean.

Salidas

Salida	Condición
`True`	El dispositivo está permitido o no está bloqueado
`False`	El dispositivo no está permitido o está bloqueado explícitamente

Ejemplo

Si una regla debe ejecutarse solo para determinados dispositivos, puede colocarse el DeviceFilter antes de la regla, de modo que solo se reenvíe a la regla siguiente una selección de los dispositivos.

Script (Filter)

Categoría: Filtro
Salidas: True, False

El nodo ejecuta una función JavaScript. Si el script devuelve true, el mensaje continúa por True. Con false o en caso de error del script, continúa por False.

Configuración

Label	Campo obligatorio	Descripción
Filter Function	Sí	Función JavaScript con la firma `Filter(msg, metadata, msgType)`.

Contexto del script

Variable	Descripción
`msg`	Cuerpo del mensaje en JSON
`metadata`	Metadatos del mensaje
`msgType`	Tipo de mensaje

Ejemplo

var threshold = parseFloat(metadata.tempThreshold) || 50;
return msg.temperature > threshold;

Switch

Categoría: Filtro
Salidas: dinámicas mediante script

El nodo dirige un mensaje a una o varias salidas con nombre. Los nombres de las salidas los devuelve una función JavaScript como array.

Configuración

Label	Campo obligatorio	Descripción
Switch Function	Sí	Función JavaScript con la firma `Switch(msg, metadata, msgType)`.

El script debe devolver un array de cadenas de texto. Cada cadena corresponde al nombre de una salida.

Notas

Los nombres de salida no conectados se ignoran.
Un array vacío descarta el mensaje.
Para todos los posibles valores devueltos deben crearse conexiones adecuadas en la RuleChain.

Ejemplo

Con la siguiente función se puede, por ejemplo, comprobar el valor de temperatura de un mensaje y reenviar los mensajes de forma distinta según el valor.

La conexión "highTemp" podría dirigirse, por ejemplo, a un nodo de alarma que genere una alarma "High Temperature"
La conexión "lowTemp" podría dirigirse, por ejemplo, a un nodo de alarma que genere una alarma "Low Temperature"
La conexión "normalTemp" podría dirigirse, por ejemplo, a un nodo que establezca un atributo "TempStatus = OK"

function nextRelation(msg) {
    if(msg.temperature > 50){
      return ['highTemp'];
    } else if (msg.temperature < 20){
      return ['lowTemp'];
    } else {
      return ['normalTemp'];
    }
    
}
return nextRelation(msg);

Check Existence Fields

Categoría: Filtro
Salidas: True, False

El nodo comprueba si determinados campos existen en el cuerpo del mensaje y/o en los metadatos. De este modo se puede proteger a los nodos siguientes frente a mensajes incompletos.

Configuración

Label	Campo obligatorio	Descripción
Message Data	No	Nombres de campo que deben existir en el cuerpo del mensaje.
Message Metadata	No	Nombres de campo que deben existir en los metadatos.
Check All Keys Present	Sí	Activado: deben existir todos los campos indicados. Desactivado: debe existir al menos un campo.

Al menos uno de los dos campos messageNames o metadataNames debe contener entradas.

Ejemplo

Antes de un nodo Script se puede comprobar, por ejemplo, si todos los canales utilizados en el script también están presentes en el mensaje. Esto evita que el script falle y reduce la complejidad del script, en el que de lo contrario habría que tomar precauciones mediante condiciones if/else para comprobar si existen los canales. Si este nodo se coloca antes de un nodo Script, en el nodo Script se puede dar por supuesto que los canales están presentes en el mensaje.

GPS Geofencing Filter

Categoría: Filtro
Salidas: True, False

El nodo comprueba si las coordenadas GPS se encuentran dentro de un geofence definido. La comprobación no tiene estado y evalúa en cada caso el mensaje actual.

Configuración

Label	Campo obligatorio	Descripción
Latitude Key Name	Sí	Nombre de campo de la latitud en el cuerpo del mensaje.
Longitude Key Name	Sí	Nombre de campo de la longitud en el cuerpo del mensaje.
Fetch Perimeter Info from Metadata	Sí	Activado: la definición del geofence se lee de los metadatos. Desactivado: el geofence se configura de forma estática en el nodo.
Perimeter Type	Sí, con configuración estática	`Circle` o `Polygon`.
Circle-Felder	Sí, con círculo	Centro, radio y unidad del círculo.
Polygon Definition	Sí, con polígono	Definición del polígono en GeoJSON o WKT.

Nota

Para los eventos de entrada/salida basados en estado se utiliza GPS Geofencing Events.

Ejemplo

Procese, por ejemplo, la telemetría solo cuando un vehículo se encuentre dentro de una zona definida; de lo contrario, la telemetría se descarta.

Nodos de acción

Save Timeseries

Categoría: Acción
Salidas: Success, Failure

El nodo almacena en la base de datos los datos de telemetría del cuerpo del mensaje como valores de series temporales.

Configuración

Label	Campo obligatorio	Descripción
Default TTL	Sí	Vida útil de los puntos de datos almacenados, en segundos. `0` significa que no hay eliminación automática.
Enable Type Cast	Sí	Convierte valores numéricos o booleanos de cadenas de texto a tipos de datos nativos.

Entrada

El tipo de mensaje debe ser POST_TELEMETRY_REQUEST. El cuerpo del mensaje debe ser un objeto JSON o contener un array de objetos JSON con marca de tiempo ts.

Save Attributes

Categoría: Acción
Salidas: Success, Failure

El nodo almacena los pares clave-valor del cuerpo del mensaje como atributos de la entidad de origen.

Configuración

Label	Campo obligatorio	Descripción
Attribute Scope	Sí	Scope de destino de los atributos.
Enable Type Cast	Sí	Convierte valores numéricos o booleanos de cadenas de texto a tipos de datos nativos.

Scope	Significado
`CLIENT_SCOPE`	Atributos notificados por el dispositivo y visibles para el dispositivo.
`SHARED_SCOPE`	Atributos establecidos en el lado del servidor que pueden distribuirse al dispositivo.
`SERVER_SCOPE`	Atributos internos del servidor que no se envían al dispositivo.

Entrada

El cuerpo del mensaje debe ser un objeto JSON. Cada clave se almacena como nombre de atributo.

Save Alarms

Categoría: Acción
Salidas: Activated, Deactivated, Sustained

El nodo procesa mensajes del tipo POST_ALARMS y almacena estados de alarma en la base de datos. Con ello refleja los cambios de estado de las alarmas.

Salidas

Salida	Significado
`Activated`	Se ha abierto una alarma nueva o una alarma eliminada ha vuelto a estar activa.
`Deactivated`	Se ha finalizado una alarma activa.
`Sustained`	Una alarma ya activa sigue activa.

Configuración

Label	Campo obligatorio	Descripción
Propagate	Sí	Indica si las alarmas se propagan a entidades superiores.

Entrada

El mensaje debe ser del tipo POST_ALARMS y contener datos de alarma conforme al modelo de alarmas de la plataforma.

Create Alarm

Categoría: Acción
Salidas: Created, Updated, False

El nodo crea una alarma para el origen del mensaje o actualiza una alarma ya existente del mismo tipo. Los detalles de la alarma se construyen mediante JavaScript a partir del mensaje y de los metadatos.

Salidas

Salida	Significado
`Created`	Se ha creado una alarma nueva.
`Updated`	Se ha actualizado una alarma existente de este tipo.
`False`	El script no ha generado ninguna alarma.

Configuración

Label	Campo obligatorio	Descripción
Alarm Details Builder	Sí	Función JavaScript `Details(msg, metadata, msgType)` para los detalles de la alarma.
Alarm Type	Sí	Tipo de alarma. Admite patrones `${metadata.key}`.
Alarm Severity	Sí	Nivel de gravedad: `CRITICAL`, `MAJOR`, `MINOR`, `WARNING`, `INDETERMINATE`.
Propagate	Sí	Propaga la alarma a entidades superiores.

Metadatos tras el procesamiento

El nodo añade, entre otros, alarmType, alarmIsNew, alarmSeverity y alarmId.

Ejemplo

Un Script Filter anterior comprueba msg.temperature > 80. Con True, este nodo crea una alarma HighTemperature con nivel de gravedad MAJOR. En los detalles podría haber, por ejemplo, una función que registre en los detalles el valor máximo de temperatura mientras una alarma haya estado activa y actualizada

var details = {};
if (metadata.prevAlarmDetails) {
    details = JSON.parse(metadata.prevAlarmDetails);
    if (parseFloat(details.highestTemp) < msg.temperature){
        details.highestTemp = msg.temperature;
    }
}
return details;

Clear Alarm

Categoría: Acción
Salidas: Cleared, False

El nodo finaliza una alarma activa del tipo configurado para el origen del mensaje.

Salidas

Salida	Significado
`Cleared`	Se ha encontrado y finalizado una alarma activa coincidente.
`False`	No se ha encontrado ninguna alarma activa coincidente.

Configuración

Label	Campo obligatorio	Descripción
Alarm Details Builder	Sí	Función JavaScript para los detalles finales de la alarma al finalizar.
Alarm Type	Sí	Tipo de alarma, que debe coincidir exactamente con la alarma generada anteriormente.

Metadatos tras el procesamiento

El nodo añade alarmType y alarmId.

Ejemplo

Si un dispositivo vuelve a notificar temperature < 70, Clear Alarm puede finalizar la alarma HighTemperature creada anteriormente.

información

¡El tipo de alarma distingue entre mayúsculas y minúsculas! Si con un nodo Create Alarm se ha creado una alarma del tipo HighTemperature, ese mismo tipo de alarma HighTemperature debe introducirse también en el nodo Clear Alarm para que pueda cancelarse (cleared).

Alarm Counter

Categoría: Acción
Salidas: Success, Failure

El nodo cuenta alarmas según criterios configurados dentro de una ventana de tiempo y almacena los resultados como atributos de servidor en el origen del mensaje.

Configuración

El nodo contiene una lista de definiciones de contadores.

Label	Campo obligatorio	Descripción
Find by Field Name	Sí	Campo de alarma por el que se filtra, p. ej., `severity` o `type`.
With Field Value	Sí	Valor que debe tener el campo, p. ej., `CRITICAL`.
Save in Server Attribute	Sí	Nombre del atributo de servidor en el que se almacena el contador.
Time Period Alarm Considered	Sí	Ventana de tiempo considerada, en segundos. `0` significa sin restricción temporal.

Ejemplo

Con

fieldName = severity
fieldValue = CRITICAL
attributeName = criticalAlarms24h
periodInSeconds = 86400

se cuenta el número de alarmas críticas de las últimas 24 horas y se almacena en el atributo de servidor criticalAlarms24h.

Log

Categoría: Acción
Salidas: Success, Failure

El nodo escribe en el log del servidor un texto generado mediante JavaScript y reenvía el mensaje original sin modificarlo.

Configuración

Label	Campo obligatorio	Descripción
Log Function	Sí	Función JavaScript `ToString(msg, metadata, msgType)` que devuelve el texto del log.

Notas

El nodo está pensado sobre todo para el desarrollo, el análisis y la corrección de errores.
Debe utilizarse con moderación y, preferiblemente, solo tras consultarlo con Optimeas, ya que un nodo Log en realidad solo tiene sentido si antes se han producido errores que, dado el caso, el propio usuario no puede resolver.

Generator

Categoría: Acción
Salidas: Success, Failure

El nodo genera mensajes periódicamente mediante JavaScript y los introduce en la RuleChain. Puede utilizarse para pruebas, simulaciones o procesos programados en el tiempo.

Configuración

Label	Campo obligatorio	Descripción
Message Count	Sí	Número de mensajes que se deben generar. `0` significa ilimitado.
Period in Seconds	Sí	Intervalo entre los mensajes generados, en segundos.
Originator	Sí	Dispositivo de origen de los mensajes generados.
Generator Function	Sí	Función JavaScript `Generate(prevMsg, prevMetadata, prevMsgType)`.

La función debe devolver msg, metadata y msgType.

Ejemplo

Si, por ejemplo, se quiere crear y probar una RuleChain pero en ese momento no se dispone de un dispositivo real, o de uno que justo en ese momento envíe datos en directo, se pueden generar mensajes artificiales con el nodo Generator. Para una prueba adecuada, estos mensajes generados artificialmente deberían reflejar lo mejor posible los mensajes previstos de un dispositivo real.

El siguiente ejemplo genera mensajes con:

Canales de telemetría: {"temperature": 42} y {"humidity": 77}

Metadatos: {"data": 40}

Tipo: POST_TELEMETRY_REQUEST

var msg = { temperature: 42, humidity: 77 };
var metadata = { data: 40 };
var msgType = "POST_TELEMETRY_REQUEST";

return { msg: msg, metadata: metadata, msgType: msgType };

En el ejemplo anterior se trata de mensajes estáticos con siempre los mismos valores (42, 77, 40). Sin embargo, un Generator también puede generar datos variables, por ejemplo mediante:

var temp = Math.floor(Math.random() * max);
var hum = Math.floor(Math.random() * max);
var meta = Math.floor(Math.random() * max);

var msg = { temperature: temp, humidity: hum };
var metadata = { data: meta };
var msgType = "POST_TELEMETRY_REQUEST";

return { msg: msg, metadata: metadata, msgType: msgType };

Nota

En entornos de producción, el intervalo de tiempo debe elegirse con cuidado para no generar una carga de mensajes innecesariamente alta.

Message Count

Categoría: Acción
Salidas: Success, Failure

El nodo cuenta mensajes dentro de un intervalo de tiempo y publica el valor del contador como telemetría.

Configuración

Label	Campo obligatorio	Descripción
Interval in Seconds	Sí	Duración de la ventana de recuento, en segundos.
Output Timeseries Key Prefix	Sí	Clave de telemetría para el valor del contador.

Salida

Al final de cada intervalo se genera un mensaje POST_TELEMETRY_REQUEST, p. ej.:

{
  "messageCount": 42
}

Los mensajes entrantes se reenvían además sin modificar por Success.

Delay

Categoría: Acción
Salidas: Success, Failure

El nodo retiene los mensajes durante una duración configurada y después los reenvía. El retraso puede determinarse de forma estática o mediante metadatos.

Configuración

Label	Campo obligatorio	Descripción
Use Metadata Period Pattern	Sí	Activa un retraso dinámico mediante metadatos.
Period in Seconds	Sí, si es estático	Retraso estático en segundos.
Period in Seconds Pattern	Sí, si es dinámico	Campo de metadatos o expresión `${...}` para el retraso.
Max Pending Messages	Sí	Número máximo de mensajes almacenados temporalmente.

Notas

En caso de reinicio del servidor, los mensajes en espera se pierden, ya que no se almacenan de forma persistente.
Cuando se alcanza el número máximo de mensajes, los mensajes nuevos salen por Failure.

Aggregate OSF File

Categoría: Acción
Salidas: Success, Failure

El nodo carga un archivo OSF referenciado en un BLOB_STORE_REQUEST y lo procesa.

Entrada y salida

Entrada: BLOB_STORE_REQUEST con el método GET.
Los metadatos deben contener la referencia al archivo almacenado.
Por cada intervalo de tiempo reconocido, el nodo genera un mensaje POST_TELEMETRY_REQUEST con los valores de medición.

Cadena de procesamiento

File Type Switch [OSF]
  -> Aggregate OSF File [Success]
  -> Save Timeseries

Aggregate JSONL File

Categoría: Acción
Salidas: Success, Failure

El nodo carga un archivo JSONL de un BLOB_STORE_REQUEST y lo procesa.

Entrada y salida

Entrada: BLOB_STORE_REQUEST con el método GET.
El archivo debe contener JSONL válido.
Cada línea genera un mensaje POST_TELEMETRY_REQUEST por Success.

Cadena de procesamiento

File Type Switch [JSONL]
  -> Aggregate JSONL File [Success]
  -> Save Timeseries

Process Raw Data File

Categoría: Acción
Salidas: Download, Upload, Delete, Other

El nodo clasifica los mensajes BLOB_STORE_REQUEST según la operación de archivo y los dirige a la salida correspondiente.

Configuración

Label	Campo obligatorio	Descripción
Selected Scopes	Sí	Scopes de atributos que deben procesarse.
Selected Methods	Sí	Métodos HTTP u operaciones de archivo que deben reenviarse.

Método	Salida	Significado
`PUT`	`Upload`	El archivo se ha cargado.
`GET`	`Download`	El archivo debe descargarse.
`DELETE`	`Delete`	El archivo se ha eliminado.
otros	`Other`	Operación desconocida o no configurada.

Ejemplo

Upload puede conectarse a File Type Switch para distinguir además entre archivos OSF y JSONL.

Generate Report

Categoría: Acción
Salidas: Success, Failure

El nodo genera un informe para el origen del mensaje durante una ventana de tiempo configurada.

Configuración

Área	Campos
Tipo de informe	`reportType` con valores como `DEVICE_ACTIVITY`, `TELEMETRY`, `DEVICE_STATISTIC`, `ALARM`, `OSF_DATA`, `JASPER_TEMPLATE`.
Campos condicionales	`alarmSearchStatus`, `templateId`, `keys`, `sources`, según el tipo de informe.
Ventana de tiempo	`useMetadataIntervalPatterns`, `startInterval`, `startIntervalTimeUnit`, `endInterval`, `endIntervalTimeUnit`, `startIntervalPattern`, `endIntervalPattern`.

Ejemplo

Para una exportación diaria de telemetría se puede configurar reportType = TELEMETRY con una ventana de tiempo de un día y las claves de telemetría deseadas.

Device System

Categoría: Acción
Salidas: Success, Failure

El nodo procesa datos procedentes de un Device System. Para ello se agregan o correlacionan datos de varios dispositivos relacionados entre sí.

Configuración

El nodo no tiene opciones de UI configurables. La versión interna la establece la plataforma.

Notas

El origen debe pertenecer a un Device System configurado.
La estructura del Device System se lee de la base de datos.
El nodo solo es relevante si se utiliza la función Device System.

GPS Geofencing Events

Categoría: Acción
Salidas: Entered, Left, Inside, Outside

El nodo realiza el seguimiento del estado de geofence por dispositivo y genera eventos al entrar o salir de una zona. A diferencia del GPS Geofencing Filter, este nodo tiene estado.

Configuración

Los campos de coordenadas y de geofence corresponden a los del GPS Geofencing Filter. Además se configuran duraciones mínimas:

Label	Descripción
Minimal Inside Duration	Duración que un dispositivo debe permanecer dentro de la zona antes de que se genere `Entered`.
Inside Duration Unit	Unidad de tiempo para `minInsideDuration`.
Minimal Outside Duration	Duración fuera de la zona antes de que se genere `Left`.
Outside Duration Unit	Unidad de tiempo para `minOutsideDuration`.

Salidas

Salida	Significado
`Entered`	El dispositivo ha permanecido dentro de la zona el tiempo suficiente y antes estaba fuera.
`Left`	El dispositivo ha permanecido fuera de la zona el tiempo suficiente y antes estaba dentro.
`Inside`	El dispositivo está dentro, pero aún no se ha alcanzado la duración mínima.
`Outside`	El dispositivo está fuera, pero aún no se ha alcanzado la duración mínima.

RPC Call Request

Categoría: Acción
Salidas: Success, Failure, Timeout

El nodo envía una llamada RPC desde el servidor a un dispositivo y espera la respuesta.

Configuración

Label	Campo obligatorio	Descripción
Timeout	Sí	Tiempo de espera en segundos antes de que el mensaje continúe por `Timeout`.

Entrada y salida

El cuerpo del mensaje debe contener method y params. El origen debe ser un dispositivo. Con Success, la respuesta del dispositivo sustituye al cuerpo del mensaje.

Ejemplo

{
  "method": "emergencyShutdown",
  "params": { "reason": "HighTemperature" }
}

información

El dispositivo debe estar configurado de forma adecuada para poder ejecutar también las Remote Procedure Calls concretas.

RPC Call Reply

Categoría: Acción
Salidas: Success, Failure

El nodo devuelve una respuesta a una solicitud RPC procedente del dispositivo. El contenido de la respuesta se forma a partir del cuerpo del mensaje actual.

Configuración

Label	Campo obligatorio	Descripción
Request ID Metadata Attribute	No	Campo de metadatos con el ID de la solicitud RPC.

Entrada

El mensaje debe ser del tipo TO_SERVER_RPC_REQUEST. serviceId, sessionId y requestId normalmente los establece la plataforma.

Nodos de enriquecimiento

Originator Attributes

Categoría: Enriquecimiento
Salidas: Success, Failure

El nodo lee de la base de datos los atributos y los últimos valores de telemetría del origen y los escribe en los metadatos del mensaje.

Prefijos en los metadatos

Origen	Prefijo en los metadatos
Atributos de cliente	`cs_`
Atributos shared	`shared_`
Atributos de servidor	`ss_`
Última telemetría	sin prefijo

Configuración

Label	Campo obligatorio	Descripción
Client Attributes	No	Atributos de cliente que se añaden como `cs_<name>`.
Shared Attributes	No	Atributos shared que se añaden como `shared_<name>`.
Server Attributes	No	Atributos de servidor que se añaden como `ss_<name>`.
Latest Timeseries	No	Últimos valores de telemetría, que se añaden sin prefijo.
Tell Failure	Sí	Activado: los valores que faltan provocan `Failure`. Desactivado: los valores que faltan se omiten.

Debe introducirse al menos una clave de atributo o de telemetría.

Ejemplo

Si, por ejemplo, se quiere definir manualmente un valor de offset para un canal de temperatura, se podría crear un atributo de servidor con la forma offset : 5. Mediante este nodo se podría leer ese valor y enriquecer los metadatos para seguir trabajando con él, seleccionando el canal offset en Server Attributes. En el nodo Script siguiente se puede acceder entonces a este valor mediante:

var offset = metadata.ss_offset;
var correctedTemperature = msg.temperature + offset;
return {
    msg: msg,
    metadata: metadata,
    msgType: msgType
};

Originator Telemetry

Categoría: Enriquecimiento
Salidas: Success, Failure

El nodo lee valores históricos de telemetría del origen dentro de una ventana de tiempo y los añade a los metadatos.

Configuración

Área	Campos
Selección de datos	`latestTsKeyNames`, `fetchMode` con `FIRST`, `LAST` o `ALL`.
Campos adicionales con `ALL`	`aggregation`, `orderBy`, `limit`.
Ventana de tiempo	`useMetadataIntervalPatterns`, `startInterval`, `startIntervalTimeUnit`, `endInterval`, `endIntervalTimeUnit`, `startIntervalPattern`, `endIntervalPattern`.

Notas

Con FIRST o LAST se añade un único valor por clave.
Con ALL los valores se almacenan en los metadatos como un array JSON.

Ejemplo

Para una comparación con el promedio de los últimos cinco minutos, se puede cargar temperature con fetchMode = ALL y evaluarlo a continuación en un script Transform.

*Nodo Script

var temperatureArray = metadata.temperatureArray;
var total = 0;
var avgTemp = 0;

for (var i = 0; i < temperatureArray.length; i++) {
    total += temperatureArray[i];
}

if (temperatureArray.length > 0) {
    avgTemp = total / temperatureArray.length;
}

msg.avgTemp = avgTemp;

return {
    msg: msg,
    metadata: metadata,
    msgType: msgType
};

Originator Fields

Categoría: Enriquecimiento
Salidas: Success, Failure

El nodo lee campos de datos maestros del origen, por ejemplo el nombre o el tipo, y los escribe en los metadatos con nombres configurables.

Configuración

Label	Campo obligatorio	Descripción
Fields Mapping	Sí	Asignación de nombres de campo de la entidad a claves de metadatos.

Campo de origen	Significado
`name`	Nombre visible del dispositivo
`type`	Tipo de entidad, `DEVICE`
`label`	Label de la entidad
`additionalInfo`	Información adicional como JSON
`createdTime`	Fecha de creación en milisegundos de época (epoch)

Ejemplo

Con name -> deviceName, un nodo To Email posterior puede utilizar ${deviceName} en el asunto.

Tenant Details

Categoría: Enriquecimiento
Salidas: Success, Failure

El nodo añade datos de contacto y de dirección del tenant al cuerpo del mensaje o a los metadatos.

Configuración

Label	Campo obligatorio	Descripción
Details	Sí	Campos del tenant seleccionados. Debe seleccionarse al menos un campo.
Add Details to Metadata	Sí	Activado: los valores se escriben en los metadatos. Desactivado: los valores se escriben en el cuerpo del mensaje.

Los campos disponibles son TITLE, EMAIL, PHONE, COUNTRY, CITY, STATE, ZIP, ADDRESS, ADDRESS2 y ADDITIONAL_INFO.

Nodos de transformación

Script (Transform)

Categoría: Transformación
Salidas: Success, Failure

El nodo modifica el cuerpo del mensaje, los metadatos y/o el tipo de mensaje mediante JavaScript. El resultado del script se transmite a los nodos siguientes.

Configuración

Label	Campo obligatorio	Descripción
Transform Function	Sí	Función JavaScript `Transform(msg, metadata, msgType)`.

Valor devuelto

El script debe devolver un objeto con msg, metadata y msgType.

Ejemplo

var newMsg = {};
newMsg.temperatureF = msg.temperature * 9 / 5 + 32;
newMsg.humidity = msg.humidity;

return {
    msg: newMsg,
    metadata: metadata,
    msgType: msgType
};

To Email

Categoría: Transformación
Salidas: Success, Failure

El nodo crea un objeto de correo electrónico a partir del mensaje actual y sus metadatos.

Configuración

Label	Campo obligatorio	Descripción
From	Sí	Dirección del remitente.
To	Sí	Dirección del destinatario o varios destinatarios separados por comas.
CC	No	Destinatarios en CC.
BCC	No	Destinatarios en BCC.
Subject	Sí	Asunto.
Body	Sí	Contenido del correo electrónico.

Todos los campos admiten marcadores de posición con el formato ${metadataKey}.

información

El nodo to Email solo genera el correo electrónico. El correo se envía con el nodo Send Email, que se encarga de la comunicación con el servidor SMTP.

Cadena de procesamiento

Nodos externos

REST API Call

Categoría: Externo
Salidas: Success, Failure

El nodo envía una solicitud HTTP a una interfaz REST externa. El cuerpo del mensaje actual se utiliza como payload de la solicitud.

Configuración

Label	Campo obligatorio	Descripción
Endpoint URL Pattern	Sí	URL de destino. Admite marcadores de posición `${metadata}`.
Request Method	Sí	Método HTTP: `GET`, `POST`, `PUT`, `DELETE`.
Use Simple Client HTTP Factory	No	Utiliza un cliente HTTP sencillo, p. ej., para respuestas grandes.
Headers	No	Encabezados HTTP como lista clave-valor.

Salida

Si tiene éxito, status, statusCode, statusReason y headers se escriben en los metadatos. El Response Body pasa a ser el nuevo cuerpo del mensaje.

MQTT

Categoría: Externo
Salidas: Success, Failure

El nodo publica el cuerpo del mensaje actual en un broker MQTT externo. El topic puede construirse dinámicamente mediante metadatos.

Configuración

Label	Campo obligatorio	Descripción
Topic Pattern	Sí	Topic MQTT con marcadores de posición `${metadata}` opcionales.
Host	Sí	Nombre de host o dirección IP del broker.
Port	Sí	Puerto del broker, p. ej., `1883` u `8883`.
Connection Timeout	Sí	Timeout de conexión en segundos.
Client ID	No	ID de cliente MQTT.
Clean Session	No	Controla si se descartan los datos de sesión del broker.
Enable SSL	No	Activa TLS/SSL.

Credenciales

Se admiten anonymous, basic con nombre de usuario/contraseña y cert.PEM para mTLS con certificados PEM.

Kafka

Categoría: Externo
Salidas: Success, Failure

El nodo publica el cuerpo del mensaje actual como registro en un topic de Kafka.

Configuración

Label	Campo obligatorio	Descripción
Topic Pattern	Sí	Topic de Kafka, opcionalmente con marcadores de posición de metadatos.
Bootstrap Servers	Sí	Lista de brokers separados por comas.
Auto Retry Times	No	Número de reintentos de envío.
Batch Size	No	Tamaño del lote en bytes.
Time to Buffer	No	Tiempo de espera para reunir registros, en milisegundos.
Buffer Max Size	No	Búfer máximo del producer.
Acks	Sí	Comportamiento de confirmación del broker.
Serializer	Sí	Clases de serializer.
Other Properties	No	Propiedades adicionales del producer de Kafka.

Salida

Si tiene éxito, offset, partition y topic se escriben en los metadatos.

RabbitMQ

Categoría: Externo
Salidas: Success, Failure

El nodo publica el cuerpo del mensaje en un exchange de RabbitMQ. El exchange y la routing key pueden formarse a partir de metadatos.

Configuración

Label	Campo obligatorio	Descripción
Exchange Name Pattern	No	Nombre del exchange. Vacío significa exchange predeterminado (Default Exchange).
Routing Key Pattern	No	Routing key.
Message Properties	No	Propiedades del mensaje AMQP.
Host	Sí	Host de RabbitMQ.
Port	Sí	Puerto AMQP.
Virtual Host	No	Virtual Host de RabbitMQ.
Credenciales	No	Autenticación.
Automatic Recovery	No	Reconexión automática.
Timeouts	No	Timeout de conexión y de handshake.
Client Properties	No	Propiedades adicionales del cliente.

AWS SQS

Categoría: Externo
Salidas: Success, Failure

El nodo envía el cuerpo del mensaje actual a una cola AWS SQS. Se admiten colas estándar y FIFO.

Configuración

Label	Campo obligatorio	Descripción
Queue Type	Sí	Cola estándar o FIFO.
Queue URL Pattern	Sí	URL de la cola SQS. Admite marcadores de posición de metadatos.
Delay Seconds	No	Retraso para colas estándar.
Message Attributes	No	Atributos SQS adicionales.
Credenciales de AWS	Sí	Credenciales IAM.
AWS Region	Sí	Región de AWS de la cola.

Salida

Si tiene éxito se añaden, entre otros, messageId, requestId, messageBodyMd5, messageAttributesMd5 y, en las colas FIFO, sequenceNumber.

AWS SNS

Categoría: Externo
Salidas: Success, Failure

El nodo publica el cuerpo del mensaje actual en un topic de AWS SNS.

Configuración

Label	Campo obligatorio	Descripción
Topic ARN Pattern	Sí	ARN del topic de SNS. Admite marcadores de posición de metadatos.
Credenciales de AWS	Sí	Credenciales IAM.
AWS Region	Sí	Región de AWS del topic.

Salida

Si tiene éxito, messageId y requestId se escriben en los metadatos.

GCP Pub/Sub

Categoría: Externo
Salidas: Success, Failure

El nodo publica el cuerpo del mensaje actual en un topic de Google Cloud Pub/Sub.

Configuración

Label	Campo obligatorio	Descripción
GCP Project ID	Sí	ID del proyecto de Google Cloud.
Topic Name	Sí	Nombre del topic de Pub/Sub.
GCP Service Account Key	Sí	Carga de un archivo JSON con las credenciales de la cuenta de servicio.
Message Attributes	No	Atributos adicionales de Pub/Sub.

Nota

La cuenta de servicio necesita el permiso roles/pubsub.publisher para el topic de destino.

Salida

Si tiene éxito, messageId se escribe en los metadatos.

Send Email

Categoría: Externo
Salidas: Success, Failure

El nodo envía un objeto de correo electrónico mediante SMTP. El objeto de correo electrónico debe haberse generado previamente con el nodo To Email.

Configuración

Label	Campo obligatorio	Descripción
Use General SMTP Settings	Sí	Activa los ajustes SMTP de todo el sistema.

Si se desactivan los ajustes SMTP de todo el sistema, se pueden configurar smtpProtocol, smtpHost, smtpPort, username, password, timeout, enableTls, requireTls, checkServerIdentity y sslTrustHost.

Nota

Si el mensaje entrante no es un objeto de correo electrónico válido, sale por Failure.

Nodos de Scheduler

Create Scheduled Task

Categoría: Scheduler
Salidas: Success, Failure

El nodo programa una tarea única para un momento posterior. La tarea puede generar un informe o activar una RuleChain.

Configuración

Label	Campo obligatorio	Descripción
Job Name	Sí	Nombre único de la tarea programada.
Delay Before Start	Sí	Retraso hasta la ejecución.
Type	Sí	`REPORT` o `RULE_CHAIN`.
Rule Chain	Sí, con `RULE_CHAIN`	RuleChain que se debe ejecutar.
Campos del informe	según el tipo de informe	Configuración de los informes programados.

Notas

Una tarea con el mismo jobName para la misma entidad se sobrescribe.

Clear Scheduled Task

Categoría: Scheduler
Salidas: Success, Failure

El nodo elimina una tarea programada anteriormente antes de que se ejecute.

Configuración

Label	Campo obligatorio	Descripción
Job Name	Sí	Nombre exacto de la tarea que se debe eliminar.

Notas

El nombre debe coincidir con el nombre de Create Scheduled Task.
La asignación se realiza por entidad de origen.
Si no existe ninguna tarea coincidente, el mensaje sale por Failure.

Nodos de eventos y alarmas

Complex Alarm

Categoría: Regla de evento
Salidas: Success, Created, Cleared

El nodo genera o finaliza alarmas mediante una regla de evento para telemetría en tiempo real. Es adecuado para patrones que no pueden representarse mediante una simple comprobación de un valor individual.

Configuración

Label	Campo obligatorio	Descripción
Event Rule	Sí	Selección de una regla de evento existente.

Notas

La regla de evento debe haberse creado antes de utilizar el nodo. Véase Event Processing
Created significa que se ha abierto una alarma nueva.
Cleared significa que se ha finalizado una alarma existente.
Success significa que no se ha producido ningún cambio en el estado de la alarma.

Complex Event Processing

Categoría: Regla de evento
Salidas: Success, Created, Cleared

El nodo aplica Complex Event Processing a datos de archivos OSF ya cargados. Es la variante basada en archivos de Complex Alarm.

Configuración

Label	Campo obligatorio	Descripción
Event Rule	Sí	Selección de la regla de evento para la evaluación CEP.

Notas

El nodo se coloca después de Aggregate OSF File.
La regla de evento debe haberse creado previamente en la plataforma. Véase Event Processing

Enrich Alarm

Categoría: Regla de evento
Salidas: Success, Failure

El nodo enriquece una alarma existente con información adicional de una regla de evento basada en Excel.

Configuración

Label	Campo obligatorio	Descripción
Event Rule	Sí	Selección de una regla de evento con el archivo Excel asociado para el enriquecimiento.

Notas

La regla de evento debe haberse creado previamente en la plataforma. Véase Event Processing
La regla de evento debe tener un archivo Excel con asignaciones para tipos de alarma o condiciones.
El nodo se utiliza después de Create Alarm o Complex Alarm.
Los detalles añadidos se escriben de nuevo en el registro de la alarma.

RuleNodes​

Visión general por categorías​

Nodos de filtro​

Nodos de acción​

Nodos de enriquecimiento​

Nodos de transformación​

Nodos externos​

Nodos de Scheduler​

Nodos de eventos y alarmas​

Vista general detallada​

Nodos de filtro​

Message Type Filter​

Configuración​

Ejemplo​

Message Type Switch​

Configuración​

Ejemplo​

File Type Switch​

Configuración​

Ejemplo​

File Names Filter​

Configuración​

Notas​

Ejemplo​

Device Filter​

Configuración​

Salidas​

Ejemplo​

Script (Filter)​

Configuración​

Contexto del script​

Ejemplo​

Switch​

Configuración​

Notas​

Ejemplo​

Check Existence Fields​

Configuración​

Ejemplo​

GPS Geofencing Filter​

Configuración​

Nota​

Ejemplo​

Nodos de acción​

Save Timeseries​

Configuración​

Entrada​

Save Attributes​

Configuración​

Entrada​

Save Alarms​

Salidas​

Configuración​

Entrada​

Create Alarm​

Salidas​

Configuración​

Metadatos tras el procesamiento​

Ejemplo​

Clear Alarm​

Salidas​

Configuración​

Metadatos tras el procesamiento​

Ejemplo​

Alarm Counter​

Configuración​

Ejemplo​

Log​

Configuración​

Notas​

Generator​

Configuración​

Ejemplo​

Nota​

Message Count​

Configuración​

Salida​

Delay​

Configuración​

Notas​

RuleNodes

Visión general por categorías

Nodos de filtro

Nodos de acción

Nodos de enriquecimiento

Nodos de transformación

Nodos externos

Nodos de Scheduler

Nodos de eventos y alarmas

Vista general detallada

Nodos de filtro

Message Type Filter

Configuración

Ejemplo

Message Type Switch

Configuración

Ejemplo

File Type Switch

Configuración

Ejemplo

File Names Filter

Configuración

Notas

Ejemplo

Device Filter

Configuración

Salidas

Ejemplo

Script (Filter)

Configuración

Contexto del script

Ejemplo

Switch

Configuración

Notas

Ejemplo

Check Existence Fields

Configuración

Ejemplo

GPS Geofencing Filter

Configuración

Nota

Ejemplo

Nodos de acción

Save Timeseries

Configuración

Entrada

Save Attributes

Configuración

Entrada

Save Alarms

Salidas

Configuración

Entrada

Create Alarm

Salidas

Configuración

Metadatos tras el procesamiento

Ejemplo

Clear Alarm

Salidas

Configuración

Metadatos tras el procesamiento

Ejemplo

Alarm Counter

Configuración

Ejemplo

Log

Configuración

Notas

Generator

Configuración

Ejemplo

Nota

Message Count

Configuración

Salida

Delay

Configuración

Notas