Utilización del servicio QueryPropertyHistory
El servicio QueryPropertyHistory consulta el flujo de valor para cada valor de propiedad (debe ser una propiedad registrada) de la cosa de origen determinada en un rango de tiempo concreto. El servicio llama a ValueStream.queryValueStreamEntriespara cada propiedad y, a continuación, combina los valores en un conjunto de resultados.
QueryPropertyHistory devuelve un conjunto de datos creado por la consulta de cada propiedad registrada en una cosa y la posterior combinación de los conjuntos de datos individuales en un conjunto de datos de gran tamaño. Se crea una "fila" para cada fecha y hora en los conjuntos de datos individuales. Si hay un valor registrado con esa fecha y hora, se introduce en la fila del conjunto de datos. Si no hay ningún valor registrado, por defecto se utiliza el último valor registrado para esa propiedad. A menos que se seleccione la opción Ninguno en el parámetro fillOption, se devuelve el valor Null. Si no hay ninguna propiedad registrada; la entrada se deja en blanco. Este proceso de combinación elimina los duplicados de una propiedad determinada en función de la fecha y hora.
Para obtener los valores registrados reales de una propiedad determinada, se deben utilizar los servicios QueryPropertyHistory (por ejemplo, QueryIntegerPropertyHistory). Con estos servicios se puede confirmar que los datos realmente se depuran. Para comprender cómo funciona este servicio, se proporcionan varios escenarios de ejemplo a continuación.
Escenarios de ejemplo
Escenario 1: Se especifican tres filas, pero QueryPropertyHistory devuelve nueve
Se utiliza un flujo de valor para registrar tres propiedades. Ya se han realizado tres entradas separadas para cada propiedad. Por consiguiente, el número total de puntos de datos introducidos es nueve.
Si se invoca QueryPropertyHistory en este flujo de valor con el parámetro maxItems definido en tres, se devolverán nueve filas de datos. QueryPropertyHistory ha consultado cada propiedad individual tres veces porque maxItems se ha definido en tres. Puesto que había tres entradas de datos para cada propiedad, era posible la cantidad máxima de elementos devueltos: nueve filas.
Escenario 2: Se sabe que hay datos en esta fecha y hora, pero se recibe una InfoTable vacía
Se puede registrar una fecha y hora personalizadas propias de un dispositivo Edge si no desea utilizar las que ThingWorx genera automáticamente en un valor que se introduce en el flujo de valor, pero se debe tener en cuenta el funcionamiento siguiente.
¿Qué puede suceder si se intenta consultar en esta columna personalizada de fecha y hora en lugar de utilizar setPropertyVTQ?
El servicio QueryPropertyHistory sale del flujo de valor que la cosa utiliza y toma un conjunto de resultados inicial basado en los parámetros startDate, endDate, oldestFirst y maxRows.
Si se deja startDate y endDate en blanco, significa que no se consulta sobre la propiedad de fecha y hora que se genera automáticamente y la consulta tomará maxRows, por ejemplo, 500, de los valores de propiedad añadidos más recientemente o los valores de propiedad más antiguos del flujo de valor. Esto se determina mediante el parámetro booleano oldestFirst. Si oldestFirst se define en falso, el conjunto de resultados que se devuelve contendrá los 500 valores de propiedad introducidos más recientemente para cada propiedad. Por lo tanto, si se registran tres propiedades de más de 500 valores cada una, el conjunto de datos inicial contendrá 1500 filas.
¿Qué se postprocesa?
Hay un parámetro que no se ha utilizado y es el parámetro query. A este parámetro se le aplica postproceso. Esto significa que, después de que la consulta inicial del flujo de valor se haya completado, a ese conjunto de resultados inicial que se devuelve se le aplica el parámetro query para filtrar y devolver solo los datos deseados.
¿Algún problema?
Si se ha decidido consultar sobre la propiedad personalizada de fecha y hora que se ha creado, pero el primer conjunto de resultados que se devuelve no contiene la hora que se busca en la consulta, no se encontrará nada y se devolverá una infotable vacía.
Solución
Para evitar este problema por completo, utilice el servicio setPropertyVTQ para introducir un valor propio de fecha y hora en el flujo de valor. De este modo, se sobrescriben los valores de fecha y hora generados automáticamente que representan la hora exacta a la que se ha introducido un valor en el flujo de valor. Los parámetros startDate y endDate se pueden utilizar para consultar las fechas en lugar del parámetro query, así no se arriesgará a perder datos al consultar sobre una fecha y hora.
¿Fue esto útil?