Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
# Desarrollo de conectores de datos de series temporales AWS IoT TwinMaker
En esta sección se explica cómo desarrollar un conector de datos de series temporales en un step-by-step proceso. Además, presentamos un ejemplo de conector de datos de series temporales basado en toda la muestra de una fábrica de galletas, que incluye modelos 3D, entidades, componentes, alarmas y conectores. La fuente de muestras de Cookie Factory está disponible en el [ GitHub repositorio de AWS IoT TwinMaker muestras]( https://github.com/aws-samples/aws-iot-twinmaker-samples).
**Topics**
+ [AWS IoT TwinMaker requisitos previos del conector de datos de series temporales](#time-series-data-connectors-prereqs)
+ [Antecedentes del conector de datos de series temporales](#time-series-data-connectors-background)
+ [Desarrollo de un conector de datos de series temporales](#time-series-data-connectors-develop)
+ [Mejora de su conector de datos](#time-series-data-connectors-improve)
+ [Prueba del conector](#time-series-data-connectors-test)
+ [Seguridad](#time-series-data-connectors-security)
+ [Creación de AWS IoT TwinMaker recursos](#time-series-data-connectors-resources)
+ [Siguientes pasos](#time-series-data-connectors-wn)
+ [Conector de series temporales de ejemplo de fábrica de galletas de AWS IoT TwinMaker](time-series-data-connectors-example.md)
## AWS IoT TwinMaker requisitos previos del conector de datos de series temporales
Antes de desarrollar el conector de datos de series temporales, le recomendamos que realice las siguientes tareas:
+ Cree un [espacio de trabajo de AWS IoT TwinMaker](twinmaker-gs-workspace.md).
+ Cree [tipos de componentes de AWS IoT TwinMaker](https://docs.aws.amazon.com//iot-twinmaker/latest/guide/twinmaker-component-types.html).
+ Cree [entidades de AWS IoT TwinMaker](https://docs.aws.amazon.com//iot-twinmaker/latest/guide/twinmaker-gs-entity.html).
+ (Opcional) Lea [Uso y creación de tipos de componentes](https://docs.aws.amazon.com//iot-twinmaker/latest/guide/twinmaker-component-types.htm).
+ (Opcional) Lea [Interfaz del conector de datos de AWS IoT TwinMaker](https://docs.aws.amazon.com//iot-twinmaker/latest/guide/data-connector-interface.html) para obtener una comprensión general de los conectores de datos de AWS IoT TwinMaker .
**nota**
Para ver un ejemplo de un conector completamente implementado, consulte nuestro ejemplo de implementación de una fábrica de cookies.
## Antecedentes del conector de datos de series temporales
Imagine que trabaja con una fábrica que tiene un conjunto de mezcladoras de galletas y un depósito de agua. Le gustaría crear gemelos AWS IoT TwinMaker digitales de estas entidades físicas para poder monitorear sus estados operativos comprobando varias métricas de series temporales.
Ha configurado los sensores in situ y ya está transmitiendo los datos de medición a una base de datos de Timestream. Desea poder ver y organizar los datos de medición de AWS IoT TwinMaker con una sobrecarga mínima. Puede realizar esta tarea mediante un conector de datos de series temporales. La siguiente imagen muestra un ejemplo de tabla de telemetría, que se completa mediante el uso de un conector de series temporales.
![\[Un ejemplo de datos de una tabla de telemetría que incluye el identificador del activo, el tipo, la medida, el tiempo y los valores.\]](http://docs.aws.amazon.com/es_es/iot-twinmaker/latest/guide/images/image(1).png)
[Los conjuntos de datos y la tabla Timestream utilizados en esta captura de pantalla están disponibles en el repositorio de muestras.AWS IoT TwinMaker GitHub ](https://github.com/aws-samples/aws-iot-twinmaker-samples) Consulte también el [ejemplo de conector de fábrica de cookies](time-series-data-connectors-example.md) para la implementación, que produce el resultado que se muestra en la captura de pantalla anterior.
### Flujo de datos de conector de datos de series temporales
Para las consultas del plano de datos, AWS IoT TwinMaker busca las propiedades correspondientes de los componentes y los tipos de componentes a partir de las definiciones de componentes y tipos de componentes. AWS IoT TwinMaker reenvía las propiedades de las AWS Lambda funciones junto con cualquier parámetro de consulta de API de la consulta.
AWS IoT TwinMaker usa funciones Lambda para acceder y resolver consultas de fuentes de datos y devolver los resultados de esas consultas. Las funciones de Lambda utilizan las propiedades del componente y del tipo de componente del plano de datos para resolver la solicitud inicial.
Los resultados de la consulta de Lambda se asignan a una respuesta de API y se le devuelven.
AWS IoT TwinMaker define la interfaz del conector de datos y la utiliza para interactuar con las funciones de Lambda. Con los conectores de datos, puede consultar su fuente de datos desde la API de AWS IoT TwinMaker sin necesidad de realizar ninguna migración de datos. La siguiente imagen describe el flujo de datos básico descrito en los párrafos anteriores.
![\[Las solicitudes y respuestas de la API utilizan las solicitudes y respuestas del conector 3P que acceden a una fuente de datos.\]](http://docs.aws.amazon.com/es_es/iot-twinmaker/latest/guide/images/data_flow.drawio.png)
## Desarrollo de un conector de datos de series temporales
El siguiente procedimiento describe un modelo de desarrollo que se convierte gradualmente en un conector de datos de series temporales funcional. Los pasos básicos son los siguientes:
1. **Cree un tipo de componente básico válido**
En un tipo de componente, se definen propiedades comunes que se comparten entre los componentes. Para obtener más información sobre la definición de tipos de componentes, consulte [Uso y creación de tipos de componentes](https://docs.aws.amazon.com//iot-twinmaker/latest/guide/twinmaker-component-types.html).
AWS IoT TwinMaker utiliza un [patrón de modelado de componentes de entidad](https://en.wikipedia.org/wiki/Entity_component_system) para que cada componente esté asociado a una entidad. Se recomienda modelar cada elemento físico como una entidad y modelar diferentes fuentes de datos con sus propios tipos de componentes.
El siguiente ejemplo muestra un tipo de componente de plantilla Timestream con una propiedad:
```
{"componentTypeId": "com.example.timestream-telemetry",
"workspaceId": "MyWorkspace",
"functions": {
"dataReader": {
"implementedBy": {
"lambda": {
"arn": "lambdaArn"
}
}
}
},
"propertyDefinitions": {
"telemetryType": {
"dataType": { "type": "STRING" },
"isExternalId": false,
"isStoredExternally": false,
"isTimeSeries": false,
"isRequiredInEntity": true
},
"telemetryId": {
"dataType": { "type": "STRING" },
"isExternalId": true,
"isStoredExternally": false,
"isTimeSeries": false,
"isRequiredInEntity": true
},
"Temperature": {
"dataType": { "type": "DOUBLE" },
"isExternalId": false,
"isTimeSeries": true,
"isStoredExternally": true,
"isRequiredInEntity": false
}
}
}
```
Los elementos clave del tipo de componente son los siguientes:
+ La `telemetryId` propiedad identifica la clave única del elemento físico en la fuente de datos correspondiente. El conector de datos utiliza esta propiedad como condición de filtro para consultar únicamente los valores asociados al elemento en cuestión. Además, si incluye el valor de la propiedad `telemetryId` en la respuesta de la API del plano de datos, el cliente toma el ID y puede realizar una búsqueda inversa si es necesario.
+ El campo `lambdaArn` identifica la función de Lambda con la que interactúa el tipo de componente.
+ El indicador `isRequiredInEntity` impone la creación de la ID. Esta marca es necesaria para que, cuando se cree el componente, también se cree una instancia del ID del elemento.
+ `TelemetryId`Se agrega al tipo de componente como un identificador externo para que el elemento pueda identificarse en la tabla Timestream.
1. **Cree un componente con el tipo de componente**
Para usar el tipo de componente que creó, debe crear un componente y adjuntarlo a la entidad de la que desea recuperar los datos. Los siguientes pasos detallan el proceso de creación de ese componente:
1. Vaya a la [consola de AWS IoT TwinMaker](https://console.aws.amazon.com/iottwinmaker/).
1. Seleccione y abra el mismo espacio de trabajo en el que creó los tipos de componentes.
1. Vaya a la página de la entidad.
1. Cree una entidad nueva o seleccione una entidad existente de la tabla.
1. Una vez que haya seleccionado la entidad que desea usar, elija **Agregar componente** para abrir la página **Agregar componente**.
1. Asigne un nombre al componente y, para el **Tipo**, elija el tipo de componente que creó con la plantilla en el punto **1. Cree un tipo de componente básico válido**
1. **Haga que su tipo de componente se llame conector Lambda**
El conector Lambda debe acceder al origen de datos y generar la declaración de consulta en función de la entrada y reenviarla al origen de datos. El siguiente ejemplo muestra una plantilla de solicitud JSON que hace esto.
```
{
"workspaceId": "MyWorkspace",
"entityId": "MyEntity",
"componentName": "TelemetryData",
"selectedProperties": ["Temperature"],
"startTime": "2022-08-25T00:00:00Z",
"endTime": "2022-08-25T00:00:05Z",
"maxResults": 3,
"orderByTime": "ASCENDING",
"properties": {
"telemetryType": {
"definition": {
"dataType": { "type": "STRING" },
"isExternalId": false,
"isFinal": false,
"isImported": false,
"isInherited": false,
"isRequiredInEntity": false,
"isStoredExternally": false,
"isTimeSeries": false
},
"value": {
"stringValue": "Mixer"
}
},
"telemetryId": {
"definition": {
"dataType": { "type": "STRING" },
"isExternalId": true,
"isFinal": true,
"isImported": false,
"isInherited": false,
"isRequiredInEntity": true,
"isStoredExternally": false,
"isTimeSeries": false
},
"value": {
"stringValue": "item_A001"
}
},
"Temperature": {
"definition": {
"dataType": { "type": "DOUBLE", },
"isExternalId": false,
"isFinal": false,
"isImported": true,
"isInherited": false,
"isRequiredInEntity": false,
"isStoredExternally": false,
"isTimeSeries": true
}
}
}
}
```
Los elementos clave de la solicitud:
+ `selectedProperties` es una lista que debe rellenar con las propiedades para las que desea obtener mediciones de Timestream.
+ Los campos `startDateTime`, `startTime`, `EndDateTime`, y `endTime` especifican un intervalo de tiempo para la solicitud. Esto determina el rango de muestra para las mediciones devueltas.
+ `entityId` es el nombre de la entidad desde la que se consultan los datos.
+ `componentName` es el nombre del componente desde el que se consultan los datos.
+ Utilice el campo `orderByTime` para organizar el orden en el que se muestran los resultados.
En la solicitud de ejemplo anterior, esperaríamos obtener una serie de muestras de las propiedades seleccionadas durante el intervalo de tiempo determinado para el elemento en cuestión, con el orden temporal seleccionado. La declaración de respuesta se puede resumir de la siguiente manera:
```
{
"propertyValues": [
{
"entityPropertyReference": {
"entityId": "MyEntity",
"componentName": "TelemetryData",
"propertyName": "Temperature"
},
"values": [
{
"time": "2022-08-25T00:00:00Z",
"value": {
"doubleValue": 588.168
}
},
{
"time": "2022-08-25T00:00:01Z",
"value": {
"doubleValue": 592.4224
}
},
{
"time": "2022-08-25T00:00:02Z",
"value": {
"doubleValue": 594.9383
}
}
]
}
],
"nextToken": "..."
}
```
1. **Actualice el tipo de componente para que tenga dos propiedades**
La siguiente plantilla JSON muestra un tipo de componente válido con dos propiedades:
```
{
"componentTypeId": "com.example.timestream-telemetry",
"workspaceId": "MyWorkspace",
"functions": {
"dataReader": {
"implementedBy": {
"lambda": {
"arn": "lambdaArn"
}
}
}
},
"propertyDefinitions": {
"telemetryType": {
"dataType": { "type": "STRING" },
"isExternalId": false,
"isStoredExternally": false,
"isTimeSeries": false,
"isRequiredInEntity": true
},
"telemetryId": {
"dataType": { "type": "STRING" },
"isExternalId": true,
"isStoredExternally": false,
"isTimeSeries": false,
"isRequiredInEntity": true
},
"Temperature": {
"dataType": { "type": "DOUBLE" },
"isExternalId": false,
"isTimeSeries": true,
"isStoredExternally": true,
"isRequiredInEntity": false
},
"RPM": {
"dataType": { "type": "DOUBLE" },
"isExternalId": false,
"isTimeSeries": true,
"isStoredExternally": true,
"isRequiredInEntity": false
}
}
}
```
1. **Actualice el conector Lambda para gestionar la segunda propiedad**
La API del plano de AWS IoT TwinMaker datos permite consultar varias propiedades en una sola solicitud y, al AWS IoT TwinMaker enviar una lista de`selectedProperties`, sigue una única solicitud a un conector.
La siguiente solicitud de JSON muestra una plantilla modificada que ahora admite una solicitud de dos propiedades.
```
{
"workspaceId": "MyWorkspace",
"entityId": "MyEntity",
"componentName": "TelemetryData",
"selectedProperties": ["Temperature", "RPM"],
"startTime": "2022-08-25T00:00:00Z",
"endTime": "2022-08-25T00:00:05Z",
"maxResults": 3,
"orderByTime": "ASCENDING",
"properties": {
"telemetryType": {
"definition": {
"dataType": { "type": "STRING" },
"isExternalId": false,
"isFinal": false,
"isImported": false,
"isInherited": false,
"isRequiredInEntity": false,
"isStoredExternally": false,
"isTimeSeries": false
},
"value": {
"stringValue": "Mixer"
}
},
"telemetryId": {
"definition": {
"dataType": { "type": "STRING" },
"isExternalId": true,
"isFinal": true,
"isImported": false,
"isInherited": false,
"isRequiredInEntity": true,
"isStoredExternally": false,
"isTimeSeries": false
},
"value": {
"stringValue": "item_A001"
}
},
"Temperature": {
"definition": {
"dataType": { "type": "DOUBLE" },
"isExternalId": false,
"isFinal": false,
"isImported": true,
"isInherited": false,
"isRequiredInEntity": false,
"isStoredExternally": false,
"isTimeSeries": true
}
},
"RPM": {
"definition": {
"dataType": { "type": "DOUBLE" },
"isExternalId": false,
"isFinal": false,
"isImported": true,
"isInherited": false,
"isRequiredInEntity": false,
"isStoredExternally": false,
"isTimeSeries": true
}
}
}
}
```
Del mismo modo, la respuesta correspondiente también se actualiza, como se muestra en el siguiente ejemplo:
```
{
"propertyValues": [
{
"entityPropertyReference": {
"entityId": "MyEntity",
"componentName": "TelemetryData",
"propertyName": "Temperature"
},
"values": [
{
"time": "2022-08-25T00:00:00Z",
"value": {
"doubleValue": 588.168
}
},
{
"time": "2022-08-25T00:00:01Z",
"value": {
"doubleValue": 592.4224
}
},
{
"time": "2022-08-25T00:00:02Z",
"value": {
"doubleValue": 594.9383
}
}
]
},
{
"entityPropertyReference": {
"entityId": "MyEntity",
"componentName": "TelemetryData",
"propertyName": "RPM"
},
"values": [
{
"time": "2022-08-25T00:00:00Z",
"value": {
"doubleValue": 59
}
},
{
"time": "2022-08-25T00:00:01Z",
"value": {
"doubleValue": 60
}
},
{
"time": "2022-08-25T00:00:02Z",
"value": {
"doubleValue": 60
}
}
]
}
],
"nextToken": "..."
}
```
**nota**
En cuanto a la paginación, en este caso, el tamaño de página de la solicitud se aplica a todas las propiedades. Esto significa que con cinco propiedades en la consulta y un tamaño de página de 100, si hay suficientes puntos de datos en la fuente, debería esperar ver 100 puntos de datos por propiedad, es decir, 500 puntos de datos en total.
Para ver un ejemplo de implementación, consulte el ejemplo del [conector Snowflake](https://github.com/aws-samples/aws-iot-twinmaker-samples-snowflake/blob/main/src/modules/snowflake/data-connector/lambda_connectors/data_reader_by_entity.py) en. GitHub
## Mejora de su conector de datos
### Tratamiento de excepciones
Es seguro que el conector Lambda genere excepciones. En la llamada a la API del plano de datos, el AWS IoT TwinMaker servicio espera a que la función Lambda devuelva una respuesta. Si la implementación del conector genera una excepción, AWS IoT TwinMaker traduce el tipo de excepción como tal`ConnectorFailure`, lo que hace que el cliente de la API sepa que se ha producido un problema dentro del conector.
### Gestión de la paginación
En el ejemplo, Timestream proporciona una [función de utilidad](https://boto3.amazonaws.com/v1/documentation/api/latest/reference/services/timestream-query.html#TimestreamQuery.Client.query) que puede ayudar a admitir la paginación de forma nativa. Sin embargo, para algunas otras interfaces de consulta, como SQL, puede que sea necesario un esfuerzo adicional implementar un algoritmo de paginación eficiente. Hay un ejemplo de conector [Snowflake](https://github.com/aws-samples/aws-iot-twinmaker-samples-snowflake/blob/main/src/modules/snowflake/data-connector/lambda_connectors/data_reader_by_entity.py) que gestiona la paginación en una interfaz SQL.
Cuando se devuelve el nuevo token a AWS IoT TwinMaker través de la interfaz de respuesta del conector, el token se cifra antes de devolverlo al cliente de la API. Cuando el token se incluye en otra solicitud, lo AWS IoT TwinMaker descifra antes de reenviarlo al conector Lambda. Se recomienda evitar añadir información confidencial al token.
## Prueba del conector
Aunque todavía puede actualizar la implementación después de vincular el conector al tipo de componente, le recomendamos encarecidamente que compruebe el conector Lambda antes de integrarlo con AWS IoT TwinMaker.
Existen varias formas de probar el conector Lambda: puede probar el conector Lambda en la consola Lambda o localmente en la AWS CDK.
[Para obtener más información sobre las pruebas de las funciones Lambda, consulte Probar funciones [Lambda y Probar aplicaciones](https://docs.aws.amazon.com//lambda/latest/dg/testing-functions.html) localmente. AWS CDK](https://docs.aws.amazon.com//serverless-application-model/latest/developerguide/serverless-cdk-testing.html)
## Seguridad
Para obtener documentación sobre las mejores prácticas de seguridad con Timestream, consulte [Seguridad en Timestream](https://docs.aws.amazon.com//timestream/latest/developerguide/security.html).
Para ver un ejemplo de prevención de inyecciones de SQL, consulte el siguiente [script de Python](https://github.com/aws-samples/aws-iot-twinmaker-samples/blob/main/src/libs/udq_helper_utils/udq_utils/sql_detector.py) en el GitHub repositorio de AWS IoT TwinMaker muestras.
## Creación de AWS IoT TwinMaker recursos
Una vez implementada la función Lambda, puede crear AWS IoT TwinMaker recursos como tipos de componentes, entidades y componentes a través de la [AWS IoT TwinMaker consola o la API](https://console.aws.amazon.com/iottwinmaker/).
**nota**
Si sigue las instrucciones de configuración del GitHub ejemplo, todos los AWS IoT TwinMaker recursos estarán disponibles automáticamente. Puede comprobar las definiciones de los tipos de componentes en el [AWS IoT TwinMaker GitHub ejemplo](https://github.com/aws-samples/aws-iot-twinmaker-samples/tree/main/src/workspaces/cookiefactory/component_types). Una vez que algún componente utiliza el tipo de componente, las definiciones de propiedades y las funciones del tipo de componente no se pueden actualizar.
### Prueba de integración
Recomendamos realizar una prueba integrada AWS IoT TwinMaker para comprobar que la consulta del plano de datos funciona end-to-end. Puede realizarla a través de la [GetPropertyValueHistory](https://docs.aws.amazon.com//iot-twinmaker/latest/apireference/API_GetPropertyValueHistory.html)API o fácilmente en [AWS IoT TwinMaker la consola](https://console.aws.amazon.com/iottwinmaker/).
![\[Una TwinMaker página de la consola de información sobre el componente muestra el nombre, el tipo, el estado, etc. del componente.\]](http://docs.aws.amazon.com/es_es/iot-twinmaker/latest/guide/images/image(3).png)
En la AWS IoT TwinMaker consola, vaya a los **detalles del componente** y, a continuación, en la sección **Prueba**, verá que todas las propiedades del componente se muestran allí. El área de **pruebas** de la consola permite probar propiedades y propiedades de series temporales. non-time-series Para las propiedades de series temporales, también puede utilizar la [ GetPropertyValueHistory](https://docs.aws.amazon.com//iot-twinmaker/latest/apireference/API_GetPropertyValueHistory.html)API y, para las non-time-series propiedades, utilizar [ GetPropertyValue](https://docs.aws.amazon.com//iot-twinmaker/latest/apireference/API_GetPropertyValue.html)la API. Si su conector Lambda admite consultas de propiedades múltiples, puede elegir más de una propiedad.
![\[Parte de la página de una consola de información sobre TwinMaker componentes que muestra la prueba de un componente.\]](http://docs.aws.amazon.com/es_es/iot-twinmaker/latest/guide/images/image(4).png)
## Siguientes pasos
Ahora puede configurar un [panel de AWS IoT TwinMaker Grafana](https://docs.aws.amazon.com//iot-twinmaker/latest/guide/grafana-integration.html) para visualizar las métricas. También puede explorar otros ejemplos de conectores de datos en el [ GitHub repositorio de AWS IoT TwinMaker muestras](https://github.com/aws-samples/aws-iot-twinmaker-samples/tree/main/src/modules/s3) para ver si se ajustan a su caso de uso.
# Conector de series temporales de ejemplo de fábrica de galletas de AWS IoT TwinMaker
El [código completo de la función Lambda de la fábrica de cookies](https://github.com/aws-samples/aws-iot-twinmaker-samples/blob/main/src/modules/timestream_telemetry/lambda_function/udq_data_reader.py) está disponible en. GitHub Aunque todavía puede actualizar la implementación después de vincular el conector al tipo de componente, le recomendamos encarecidamente que compruebe el conector Lambda antes de integrarlo con AWS IoT TwinMaker. También puede crear la función de Lambda con la consola de Lambda o localmente en AWS CDK. [Para obtener más información sobre las pruebas de las funciones de Lambda, consulte Prueba de funciones [Lambda y Prueba local](https://docs.aws.amazon.com//lambda/latest/dg/testing-functions.html) de aplicaciones. AWS CDK](https://docs.aws.amazon.com//serverless-application-model/latest/developerguide/serverless-cdk-testing.html)
## Ejemplos de tipos de componentes de fábrica de galletas
En un tipo de componente, se definen propiedades comunes que se comparten entre los componentes. Para el ejemplo de la fábrica de cookies, los componentes físicos del mismo tipo comparten las mismas medidas, por lo que podemos definir el esquema de medidas en el tipo de componente. Como ejemplo, el tipo de mezclador se define en el siguiente ejemplo.
```
{
"componentTypeId": "com.example.cookiefactory.mixer"
"propertyDefinitions": {
"RPM": {
"dataType": { "type": "DOUBLE" },
"isTimeSeries": true,
"isRequiredInEntity": false,
"isExternalId": false,
"isStoredExternally": true
},
"Temperature": {
"dataType": { "type": "DOUBLE" },
"isTimeSeries": true,
"isRequiredInEntity": false,
"isExternalId": false,
"isStoredExternally": true
}
}
}
```
Por ejemplo, un componente físico puede tener mediciones en una base de datos de Timestream, registros de mantenimiento en una base de datos SQL o datos de alarma en sistemas de alarma. Al crear varios componentes y asociarlos a una entidad, se vinculan diferentes orígenes de datos a la entidad y se completa el gráfico entidad-componente. En este contexto, cada componente necesita una `telemetryId` propiedad para identificar la clave única del componente en la fuente de datos correspondiente. Especificar la `telemetryId` propiedad tiene dos ventajas: la propiedad se puede utilizar en el conector de datos como condición de filtro para consultar únicamente los valores del componente en cuestión y, si se incluye el valor de la `telemetryId` propiedad en la respuesta de la API del plano de datos, el cliente toma el ID y puede realizar una búsqueda inversa si es necesario.
Si se añade `TelemetryId` al tipo de componente como identificador externo, se identifica el componente en la `TimeStream` tabla.
```
{
"componentTypeId": "com.example.cookiefactory.mixer"
"propertyDefinitions": {
"telemetryId": {
"dataType": { "type": "STRING" },
"isTimeSeries": false,
"isRequiredInEntity": true,
"isExternalId": true,
"isStoredExternally": false
},
"RPM": {
"dataType": { "type": "DOUBLE" },
"isTimeSeries": true,
"isRequiredInEntity": false,
"isExternalId": false,
"isStoredExternally": true
},
"Temperature": {
"dataType": { "type": "DOUBLE" },
"isTimeSeries": true,
"isRequiredInEntity": false,
"isExternalId": false,
"isStoredExternally": true
}
}
}
```
Del mismo modo, tenemos el tipo de componente para el `WaterTank`, como se muestra en el siguiente ejemplo JSON.
```
{
"componentTypeId": "com.example.cookiefactory.watertank",
"propertyDefinitions": {
"flowRate1": {
"dataType": { "type": "DOUBLE" },
"isTimeSeries": true,
"isRequiredInEntity": false,
"isExternalId": false,
"isStoredExternally": true
},
"flowrate2": {
"dataType": { "type": "DOUBLE" },
"isTimeSeries": true,
"isRequiredInEntity": false,
"isExternalId": false,
"isStoredExternally": true
},
"tankVolume1": {
"dataType": { "type": "DOUBLE" },
"isTimeSeries": true,
"isRequiredInEntity": false,
"isExternalId": false,
"isStoredExternally": true
},
"tankVolume2": {
"dataType": { "type": "DOUBLE" },
"isTimeSeries": true,
"isRequiredInEntity": false,
"isExternalId": false,
"isStoredExternally": true
},
"telemetryId": {
"dataType": { "type": "STRING" },
"isTimeSeries": false,
"isRequiredInEntity": true,
"isExternalId": true,
"isStoredExternally": false
}
}
}
```
`TelemetryType` es una propiedad opcional en el tipo de componente si su objetivo es consultar los valores de las propiedades en el ámbito de la entidad. Para ver un ejemplo, consulte los tipos de componentes definidos en el [ GitHub repositorio de AWS IoT TwinMaker muestras](https://github.com/aws-samples/aws-iot-twinmaker-samples/tree/main/src/workspaces/cookiefactory/component_types). También hay tipos de alarma integrados en la misma tabla, por lo que se define `TelemetryType` y se extraen propiedades comunes, como `TelemetryId` y `TelemetryType` a un tipo de componente principal para que otros tipos secundarios las compartan.
## Ejemplo de Lambda
El conector Lambda debe acceder al origen de datos y generar la declaración de consulta en función de la entrada y reenviarla al origen de datos. En el siguiente ejemplo de JSON se muestra un ejemplo de solicitud enviada a la .
```
{
'workspaceId': 'CookieFactory',
'selectedProperties': ['Temperature'],
'startDateTime': 1648796400,
'startTime': '2022-04-01T07:00:00.000Z',
'endDateTime': 1650610799,
'endTime': '2022-04-22T06:59:59.000Z',
'properties': {
'telemetryId': {
'definition': {
'dataType': { 'type': 'STRING' },
'isTimeSeries': False,
'isRequiredInEntity': True,
'isExternalId': True,
'isStoredExternally': False,
'isImported': False,
'isFinal': False,
'isInherited': True,
},
'value': {
'stringValue': 'Mixer_22_680b5b8e-1afe-4a77-87ab-834fbe5ba01e'
}
}
'Temperature': {
'definition': {
'dataType': { 'type': 'DOUBLE' },
'isTimeSeries': True,
'isRequiredInEntity': False,
'isExternalId': False,
'isStoredExternally': True,
'isImported': False,
'isFinal': False,
'isInherited': False
}
}
'RPM': {
'definition': {
'dataType': { 'type': 'DOUBLE' },
'isTimeSeries': True,
'isRequiredInEntity': False,
'isExternalId': False,
'isStoredExternally': True,
'isImported': False,
'isFinal':False,
'isInherited': False
}
},
'entityId': 'Mixer_22_d133c9d0-472c-48bb-8f14-54f3890bc0fe',
'componentName': 'MixerComponent',
'maxResults': 100,
'orderByTime': 'ASCENDING'
}
```
El objetivo de la función Lambda es consultar los datos de medición históricos de una entidad determinada. AWS IoT TwinMaker proporciona un mapa de propiedades de los componentes y debe especificar un valor instanciado para el ID del componente. Por ejemplo, para gestionar la consulta a nivel de tipo de componente (que es común en los casos de uso de alarmas) y devolver el estado de alarma de todos los componentes del espacio de trabajo, el mapa de propiedades incluye definiciones de propiedades de tipo de componente.
En el caso más sencillo, como en la solicitud anterior, queremos una serie de muestras de temperatura durante un intervalo de tiempo determinado para el componente dado, en orden temporal ascendente. La declaración de consulta se puede resumir de la siguiente manera:
```
...
SELECT measure_name, time, measure_value::double
FROM {database_name}.{table_name}
WHERE time < from_iso8601_timestamp('{request.start_time}')
AND time >= from_iso8601_timestamp('{request.end_time}')
AND TelemetryId = '{telemetry_id}'
AND measure_name = '{selected_property}'
ORDER BY time {request.orderByTime}
...
```