Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
# Sviluppo di connettori per dati in serie temporali AWS IoT TwinMaker
Questa sezione spiega come sviluppare un connettore dati per serie temporali in un step-by-step processo. Inoltre, presentiamo un esempio di connettore dati per serie temporali basato sull'intero esempio di Cookie Factory, che include modelli 3D, entità, componenti, allarmi e connettori. La fonte di esempio di cookie factory è disponibile nell'archivio degli [AWS IoT TwinMaker esempi GitHub ]( https://github.com/aws-samples/aws-iot-twinmaker-samples).
**Topics**
+ [AWS IoT TwinMaker prerequisiti del connettore dati per serie temporali](#time-series-data-connectors-prereqs)
+ [Sfondo del connettore dati delle serie temporali](#time-series-data-connectors-background)
+ [Sviluppo di un connettore dati per serie temporali](#time-series-data-connectors-develop)
+ [Miglioramento del connettore dati](#time-series-data-connectors-improve)
+ [Test del connettore](#time-series-data-connectors-test)
+ [Sicurezza](#time-series-data-connectors-security)
+ [Creazione di risorse AWS IoT TwinMaker](#time-series-data-connectors-resources)
+ [Cosa c'è dopo](#time-series-data-connectors-wn)
+ [AWS IoT TwinMaker esempio di connettore per serie temporali di cookie factory](time-series-data-connectors-example.md)
## AWS IoT TwinMaker prerequisiti del connettore dati per serie temporali
Prima di sviluppare il connettore dati per serie temporali, ti consigliamo di completare le seguenti attività:
+ Crea uno spazio di [AWS IoT TwinMaker lavoro](twinmaker-gs-workspace.md).
+ Crea [tipi di AWS IoT TwinMaker componenti](https://docs.aws.amazon.com//iot-twinmaker/latest/guide/twinmaker-component-types.html).
+ Creare [AWS IoT TwinMaker entità](https://docs.aws.amazon.com//iot-twinmaker/latest/guide/twinmaker-gs-entity.html).
+ (Facoltativo) Leggi [Utilizzo e creazione dei tipi di componenti](https://docs.aws.amazon.com//iot-twinmaker/latest/guide/twinmaker-component-types.htm).
+ (Facoltativo) Leggi l'[interfaccia del connettore AWS IoT TwinMaker dati](https://docs.aws.amazon.com//iot-twinmaker/latest/guide/data-connector-interface.html) per ottenere una comprensione generale dei connettori AWS IoT TwinMaker dati.
**Nota**
Per un esempio di connettore completamente implementato, consulta il nostro esempio di implementazione di cookie factory.
## Sfondo del connettore dati delle serie temporali
Immagina di lavorare in una fabbrica che ha un set di frullatori per biscotti e un serbatoio d'acqua. Vorresti creare gemelli AWS IoT TwinMaker digitali di queste entità fisiche in modo da poterne monitorare gli stati operativi controllando varie metriche di serie temporali.
Hai configurato i sensori in loco e stai già trasmettendo i dati di misurazione in un database Timestream. Volete essere in grado di visualizzare e organizzare i dati di misurazione AWS IoT TwinMaker con un sovraccarico minimo. È possibile eseguire questa operazione utilizzando un connettore dati per serie temporali. L'immagine seguente mostra un esempio di tabella di telemetria, che viene popolata mediante l'uso di un connettore di serie temporali.
![\[Un esempio di dati di tabella di telemetria che include l'ID, il tipo, la misura, l'ora e i valori dell'asset.\]](http://docs.aws.amazon.com/it_it/iot-twinmaker/latest/guide/images/image(1).png)
[I set di dati e la tabella Timestream utilizzati in questa schermata sono disponibili nell'archivio degli esempi.AWS IoT TwinMaker GitHub ](https://github.com/aws-samples/aws-iot-twinmaker-samples) Vedi anche il [connettore di esempio cookie factory](time-series-data-connectors-example.md) per l'implementazione, che produce il risultato mostrato nella schermata precedente.
### Flusso di dati del connettore di serie temporali
Per le interrogazioni sul piano dati, AWS IoT TwinMaker recupera le proprietà corrispondenti dei componenti e dei tipi di componenti dalle definizioni dei componenti e dei tipi di componenti. AWS IoT TwinMaker inoltra le proprietà alle AWS Lambda funzioni insieme a tutti i parametri di query API nella query.
AWS IoT TwinMaker utilizza le funzioni Lambda per accedere e risolvere le interrogazioni provenienti da fonti di dati e restituire i risultati di tali interrogazioni. Le funzioni Lambda utilizzano le proprietà del componente e del tipo di componente dal piano dati per risolvere la richiesta iniziale.
I risultati della query Lambda vengono mappati su una risposta API e restituiti all'utente.
AWS IoT TwinMaker definisce l'interfaccia del connettore dati e la utilizza per interagire con le funzioni Lambda. Utilizzando i connettori dati, puoi interrogare la tua fonte di dati dall' AWS IoT TwinMaker API senza alcuna operazione di migrazione dei dati. L'immagine seguente illustra il flusso di dati di base descritto nei paragrafi precedenti.
![\[Le richieste e le risposte API utilizzano le richieste e le risposte di 3P Connector che accedono a un'origine dati.\]](http://docs.aws.amazon.com/it_it/iot-twinmaker/latest/guide/images/data_flow.drawio.png)
## Sviluppo di un connettore dati per serie temporali
La procedura seguente delinea un modello di sviluppo che si sviluppa in modo incrementale fino a diventare un connettore dati funzionale per serie temporali. I passaggi di base sono i seguenti:
1. **Crea un tipo di componente di base valido**
In un tipo di componente, si definiscono proprietà comuni condivise tra i componenti. Per ulteriori informazioni sulla definizione dei tipi di componenti, consulta [Utilizzo e creazione di tipi di componenti](https://docs.aws.amazon.com//iot-twinmaker/latest/guide/twinmaker-component-types.html).
AWS IoT TwinMaker utilizza un [modello di modellazione entità-componente](https://en.wikipedia.org/wiki/Entity_component_system) in modo che ogni componente sia collegato a un'entità. Si consiglia di modellare ogni elemento fisico come un'entità e di modellare diverse fonti di dati con i propri tipi di componenti.
L'esempio seguente mostra un tipo di componente del modello Timestream con una proprietà:
```
{"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
}
}
}
```
Gli elementi chiave del tipo di componente sono i seguenti:
+ La `telemetryId` proprietà identifica la chiave univoca dell'elemento fisico nella fonte di dati corrispondente. Il connettore dati utilizza questa proprietà come condizione di filtro per interrogare solo i valori associati all'elemento specificato. Inoltre, se includi il valore della `telemetryId` proprietà nella risposta dell'API del piano dati, il lato client acquisisce l'ID e può eseguire una ricerca inversa, se necessario.
+ Il `lambdaArn` campo identifica la funzione Lambda con cui interagisce il tipo di componente.
+ Il `isRequiredInEntity` flag impone la creazione dell'ID. Questo flag è necessario in modo che quando viene creato il componente, venga istanziato anche l'ID dell'elemento.
+ `TelemetryId`Viene aggiunto al tipo di componente come ID esterno in modo che l'elemento possa essere identificato nella tabella Timestream.
1. **Crea un componente con il tipo di componente**
Per utilizzare il tipo di componente creato, è necessario creare un componente e collegarlo all'entità da cui si desidera recuperare i dati. I passaggi seguenti descrivono in dettaglio il processo di creazione di quel componente:
1. Passare alla [console AWS IoT TwinMaker](https://console.aws.amazon.com/iottwinmaker/).
1. Selezionate e aprite lo stesso spazio di lavoro in cui avete creato i tipi di componenti.
1. Vai alla pagina dell'entità.
1. Crea una nuova entità o seleziona un'entità esistente dalla tabella.
1. Dopo aver selezionato l'entità che desideri utilizzare, scegli **Aggiungi componente** per aprire la pagina **Aggiungi componente**.
1. Assegna un nome al componente e, per il **Tipo**, scegli il tipo di componente che hai creato con il modello in **1. Crea un tipo di componente di base valido**.
1. **Fai in modo che il tipo di componente chiami un connettore Lambda**
Il connettore Lambda deve accedere all'origine dati e generare l'istruzione di query in base all'input e inoltrarla all'origine dati. L'esempio seguente mostra un modello di richiesta JSON che esegue questa operazione.
```
{
"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
}
}
}
}
```
Gli elementi chiave della richiesta:
+ `selectedProperties`È un elenco che compili con le proprietà per le quali desideri le misurazioni Timestream.
+ I `endTime` campi`startDateTime`, `startTime``EndDateTime`, e specificano un intervallo di tempo per la richiesta. Ciò determina l'intervallo di campionamento per le misurazioni restituite.
+ `entityId`è il nome dell'entità da cui si stanno interrogando i dati.
+ `componentName`è il nome del componente da cui si stanno interrogando i dati.
+ Utilizzate il `orderByTime` campo per organizzare l'ordine in cui vengono visualizzati i risultati.
Nella richiesta di esempio precedente, ci aspetteremmo di ottenere una serie di esempi per le proprietà selezionate durante la finestra temporale specificata per il dato elemento, con l'ordine temporale selezionato. La dichiarazione di risposta può essere riassunta come segue:
```
{
"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. **Aggiorna il tipo di componente in modo che abbia due proprietà**
Il seguente modello JSON mostra un tipo di componente valido con due proprietà:
```
{
"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. **Aggiorna il connettore Lambda per gestire la seconda proprietà**
L'API del piano AWS IoT TwinMaker dati supporta l'interrogazione di più proprietà in un'unica richiesta e AWS IoT TwinMaker segue una singola richiesta a un connettore fornendo un elenco di. `selectedProperties`
La seguente richiesta JSON mostra un modello modificato che ora supporta una richiesta per due proprietà.
```
{
"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
}
}
}
}
```
Analogamente, viene aggiornata anche la risposta corrispondente, come illustrato nell'esempio seguente:
```
{
"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**
In termini di impaginazione, in questo caso, la dimensione della pagina nella richiesta si applica a tutte le proprietà. Ciò significa che con cinque proprietà nella query e una dimensione di pagina pari a 100, se ci sono abbastanza punti dati nell'origine, dovresti aspettarti di vedere 100 punti dati per proprietà, con 500 punti dati in totale.
Per un esempio di implementazione, consulta l'[esempio del connettore 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) su. GitHub
## Miglioramento del connettore dati
### Gestione delle eccezioni
È sicuro che il connettore Lambda generi eccezioni. Nella chiamata all'API del piano dati, il AWS IoT TwinMaker servizio attende che la funzione Lambda restituisca una risposta. Se l'implementazione del connettore genera un'eccezione, AWS IoT TwinMaker traduce il tipo di eccezione in 2`ConnectorFailure`, rendendo il client API consapevole che si è verificato un problema all'interno del connettore.
### Gestione dell'impaginazione
Nell'esempio, Timestream fornisce una [funzione di utilità](https://boto3.amazonaws.com/v1/documentation/api/latest/reference/services/timestream-query.html#TimestreamQuery.Client.query) che può aiutare a supportare l'impaginazione in modo nativo. Tuttavia, per alcune altre interfacce di interrogazione, come SQL, potrebbe essere necessario uno sforzo supplementare per implementare un algoritmo di impaginazione efficiente. Esiste un esempio di connettore [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) che gestisce l'impaginazione in un'interfaccia SQL.
Quando il nuovo token viene restituito AWS IoT TwinMaker tramite l'interfaccia di risposta del connettore, il token viene crittografato prima di essere restituito al client API. Quando il token è incluso in un'altra richiesta, lo AWS IoT TwinMaker decripta prima di inoltrarlo al connettore Lambda. Ti consigliamo di evitare di aggiungere informazioni sensibili al token.
## Test del connettore
Sebbene sia ancora possibile aggiornare l'implementazione dopo aver collegato il connettore al tipo di componente, consigliamo vivamente di verificare il connettore Lambda prima dell'integrazione con. AWS IoT TwinMaker
Esistono diversi modi per testare il connettore Lambda: puoi testare il connettore Lambda nella console Lambda o localmente in. AWS CDK
[Per ulteriori informazioni sul test delle funzioni Lambda, consulta Test delle funzioni Lambda e Test delle [applicazioni Lambda a livello](https://docs.aws.amazon.com//lambda/latest/dg/testing-functions.html) locale. AWS CDK](https://docs.aws.amazon.com//serverless-application-model/latest/developerguide/serverless-cdk-testing.html)
## Sicurezza
[Per la documentazione sulle migliori pratiche di sicurezza con Timestream, consulta Security in Timestream.](https://docs.aws.amazon.com//timestream/latest/developerguide/security.html)
Per un esempio di prevenzione dell'iniezione SQL, vedere il seguente [script Python](https://github.com/aws-samples/aws-iot-twinmaker-samples/blob/main/src/libs/udq_helper_utils/udq_utils/sql_detector.py) in AWS IoT TwinMaker Samples GitHub Repository.
## Creazione di risorse AWS IoT TwinMaker
Dopo aver implementato la funzione Lambda, puoi creare AWS IoT TwinMaker risorse come tipi di componenti, entità e componenti tramite la [AWS IoT TwinMaker console o l'API](https://console.aws.amazon.com/iottwinmaker/).
**Nota**
Se segui le istruzioni di configurazione nell' GitHub esempio, tutte le AWS IoT TwinMaker risorse sono disponibili automaticamente. È possibile controllare le definizioni dei tipi di componenti nell'[AWS IoT TwinMaker GitHub esempio](https://github.com/aws-samples/aws-iot-twinmaker-samples/tree/main/src/workspaces/cookiefactory/component_types). Una volta che il tipo di componente viene utilizzato da qualsiasi componente, le definizioni delle proprietà e le funzioni del tipo di componente non possono essere aggiornate.
### Test di integrazione
Ti consigliamo di utilizzare un test integrato AWS IoT TwinMaker per verificare che la query sul piano dati funzioni end-to-end. È possibile eseguire questa operazione tramite [GetPropertyValueHistory](https://docs.aws.amazon.com//iot-twinmaker/latest/apireference/API_GetPropertyValueHistory.html)l'API o facilmente [AWS IoT TwinMaker dalla console](https://console.aws.amazon.com/iottwinmaker/).
![\[Una pagina della console informativa sui TwinMaker componenti mostra il nome, il tipo, lo stato del componente e così via.\]](http://docs.aws.amazon.com/it_it/iot-twinmaker/latest/guide/images/image(3).png)
Nella AWS IoT TwinMaker console, vai ai **dettagli del componente**, quindi nella sezione **Test**, vedrai che tutte le proprietà del componente sono elencate lì. L'area **Test** della console consente di testare sia le proprietà delle serie temporali che le non-time-series proprietà. Per le proprietà delle serie temporali è inoltre possibile utilizzare l'[ GetPropertyValueHistory](https://docs.aws.amazon.com//iot-twinmaker/latest/apireference/API_GetPropertyValueHistory.html)API e per non-time-series le proprietà utilizzare l'[ GetPropertyValue](https://docs.aws.amazon.com//iot-twinmaker/latest/apireference/API_GetPropertyValue.html)API. Se il connettore Lambda supporta l'interrogazione di più proprietà, puoi scegliere più di una proprietà.
![\[Una parte di una pagina della console informativa sui TwinMaker componenti che mostra il test di un componente.\]](http://docs.aws.amazon.com/it_it/iot-twinmaker/latest/guide/images/image(4).png)
## Cosa c'è dopo
Ora puoi configurare una [dashboard AWS IoT TwinMaker Grafana per visualizzare le metriche](https://docs.aws.amazon.com//iot-twinmaker/latest/guide/grafana-integration.html). Puoi anche esplorare altri esempi di connettori dati nel [ GitHub repository degli AWS IoT TwinMaker esempi](https://github.com/aws-samples/aws-iot-twinmaker-samples/tree/main/src/modules/s3) per vedere se sono adatti al tuo caso d'uso.
# AWS IoT TwinMaker esempio di connettore per serie temporali di cookie factory
Il [codice completo della funzione Lambda di cookie factory](https://github.com/aws-samples/aws-iot-twinmaker-samples/blob/main/src/modules/timestream_telemetry/lambda_function/udq_data_reader.py) è disponibile su. GitHub Sebbene sia ancora possibile aggiornare l'implementazione dopo aver collegato il connettore al tipo di componente, consigliamo vivamente di verificare il connettore Lambda prima dell'integrazione con. AWS IoT TwinMaker Puoi testare la tua funzione Lambda nella console Lambda o localmente in. AWS CDK[Per ulteriori informazioni sul test delle funzioni Lambda, consulta Test delle funzioni [Lambda e Test locale](https://docs.aws.amazon.com//lambda/latest/dg/testing-functions.html) delle applicazioni. AWS CDK](https://docs.aws.amazon.com//serverless-application-model/latest/developerguide/serverless-cdk-testing.html)
## Esempi di tipi di componenti di cookie factory
In un tipo di componente, definiamo proprietà comuni condivise tra i componenti. Per l'esempio di cookie factory, i componenti fisici dello stesso tipo condividono le stesse misurazioni, quindi possiamo definire lo schema di misurazione nel tipo di componente. Ad esempio, il tipo di mixer è definito nell'esempio seguente.
```
{
"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
}
}
}
```
Ad esempio, un componente fisico potrebbe contenere misurazioni in un database Timestream, registri di manutenzione in un database SQL o dati di allarme in sistemi di allarme. La creazione di più componenti e la loro associazione a un'entità collega diverse fonti di dati all'entità e compila il grafico entità-componente. In questo contesto, ogni componente necessita di una `telemetryId` proprietà per identificare la chiave univoca del componente nella fonte di dati corrispondente. La specificazione della `telemetryId` proprietà presenta due vantaggi: la proprietà può essere utilizzata nel connettore dati come condizione di filtro per interrogare solo i valori del componente specificato e, se si include il valore della `telemetryId` proprietà nella risposta dell'API del piano dati, il lato client acquisisce l'ID e può eseguire una ricerca inversa, se necessario.
Se aggiungi `TelemetryId` al tipo di componente come ID esterno, identifica il componente nella tabella. `TimeStream`
```
{
"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
}
}
}
```
Allo stesso modo abbiamo il tipo di componente per`WaterTank`, come mostrato nel seguente esempio 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
}
}
}
```
La `TelemetryType` è una proprietà opzionale nel tipo di componente se è finalizzata all'interrogazione dei valori delle proprietà nell'ambito dell'entità. Per un esempio, vedete i tipi di componenti definiti nel [ GitHub repository degli AWS IoT TwinMaker esempi](https://github.com/aws-samples/aws-iot-twinmaker-samples/tree/main/src/workspaces/cookiefactory/component_types). Nella stessa tabella sono incorporati anche tipi di allarme, quindi vengono definiti e si estraggono proprietà comuni come il `TelemetryId` tipo di componente principale `TelemetryType` da condividere con altri tipi secondari. `TelemetryType`
## Esempio: Lambda
Il connettore Lambda deve accedere all'origine dati e generare l'istruzione di query in base all'input e inoltrarla all'origine dati. Un esempio di richiesta inviata alla Lambda è illustrato nel seguente esempio JSON.
```
{
'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'
}
```
L'obiettivo della funzione Lambda è interrogare i dati di misurazione storici per una determinata entità. AWS IoT TwinMaker fornisce una mappa delle proprietà dei componenti ed è necessario specificare un valore istanziato per l'ID del componente. Ad esempio, per gestire la query a livello di tipo di componente (che è comune nei casi d'uso degli allarmi) e restituire lo stato di allarme di tutti i componenti nell'area di lavoro, la mappa delle proprietà contiene le definizioni delle proprietà dei tipi di componente.
Nel caso più semplice, come nella richiesta precedente, vogliamo una serie di campioni di temperatura durante la finestra temporale specificata per il componente specificato, in ordine temporale crescente. L'istruzione di interrogazione può essere riassunta come segue:
```
...
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}
...
```