Delen via


Wat zijn configuratiepatronen in Azure IoT Data Processor Preview?

Belangrijk

Azure IoT Operations Preview: ingeschakeld door Azure Arc is momenteel in PREVIEW. Gebruik deze preview-software niet in productieomgevingen.

Raadpleeg de Aanvullende voorwaarden voor Microsoft Azure-previews voor juridische voorwaarden die van toepassing zijn op Azure-functies die in bèta of preview zijn of die anders nog niet algemeen beschikbaar zijn.

Verschillende typen configuraties zijn gebruikelijk voor meerdere pijplijnfasen. In dit artikel worden de configuratiepatronen voor pad, batch, sjablonen, nieuwe pogingen en duur beschreven.

Pad

In verschillende pijplijnfasen wordt een pad gebruikt om een locatie in het bericht te identificeren waarnaar gegevens moeten worden gelezen of waarnaar ze moeten worden geschreven. Als u deze locaties wilt definiëren, gebruikt u een Path veld dat jq-syntaxis gebruikt:

  • Een pad wordt gedefinieerd als een tekenreeks in de gebruikersinterface en maakt gebruik van de jq-syntaxis .
  • Er wordt een pad gedefinieerd ten opzichte van de hoofdmap van het bericht Gegevensprocessor. Het pad . verwijst naar het hele bericht.
  • Alle paden beginnen met ..
  • Elk padsegment kan het volgende zijn:
    • .<identifier> voor een alfanumerieke objectsleutel zoals .topic.
    • ."<identifier>" voor een willekeurige objectsleutel zoals ."asset-id".
    • ["<identifier>"] voor een willekeurige objectsleutel zoals ["asset-id"].
    • [<index>] voor een matrixindex zoals [2].
  • Segmenten kunnen worden gekoppeld om complexe paden te vormen.

Afzonderlijke padsegmenten moeten voldoen aan de volgende reguliere expressies:

Patroon Reguliere expressie Opmerking
.<identifier> \.[a-zA-Z_][a-zA-Z0-9_]* .topic
."<identifier>" \."(\\"\|[^"])*" ."asset-id"
["<identifier>"] \["(\\"\|[^"])*"\] ["asset-id"]
[<index>] \[-?[0-9]+\] [2]

Zie Paden in de jq-handleiding voor meer informatie.

Padvoorbeelden

De volgende paden zijn voorbeelden op basis van de standaardgegevensprocessorberichtstructuur:

  • .systemProperties Retourneert:

    {
      "partitionKey": "foo",
      "partitionId": 5,
      "timestamp": "2023-01-11T10:02:07Z"
    }
    
  • .payload.humidity Retourneert:

    10
    
  • .userProperties[0] Retourneert:

    {
      "key": "prop1",
      "value": "value1"
    }
    
    
  • .userProperties[0].value Retourneert:

    value1
    

Duur

Voor verschillende fasen is de definitie van een tijdsduur vereist. Vensters in een statistische fase en time-outs in een call-outfase. In deze fasen wordt een Duration veld gebruikt om deze waarde weer te geven.

In verschillende pijplijnfasen wordt een tijdsduur gebruikt. De statistische fase heeft bijvoorbeeld een venstereigenschap en de bijschriftfasen hebben een time-outeigenschap. Als u deze tijdsperioden wilt definiëren, gebruikt u een Duration veld:

Duur is een tekenreekswaarde met de volgende notatie <number><char><number><char> waarbij 'teken' kan zijn:

  • h:Uur
  • m:Minuut
  • s:Tweede
  • ms:Milliseconde
  • us, : µsmicroseconden
  • ns: nanoseconde

Voorbeelden van duur

  • 2h
  • 1h10m30s
  • 3m9ms400ns

Sjablonen

Voor verschillende fasen moet u een tekenreeks definiëren met een combinatie van dynamische en statische waarden. In deze fasen worden sjabloonwaarden gebruikt.

Data Processor-sjablonen gebruiken mustache-syntaxis om dynamische waarden in tekenreeksen te definiëren.

De dynamische systeemwaarden die beschikbaar zijn voor gebruik in sjablonen zijn:

  • instanceId: de exemplaar-id van de gegevensprocessor.
  • pipelineId: De pijplijn-id waarvan de fase deel uitmaakt.
  • YYYY: Het huidige jaar.
  • MM: De huidige maand.
  • DD: De huidige datum.
  • HH: Het huidige uur.
  • mm: De huidige minuut.

Op dit moment kunt u sjablonen gebruiken om bestandspaden in een doelfase te definiëren.

Statische en dynamische velden

Voor sommige fasen is de definitie van waarden vereist die statische tekenreeksen kunnen zijn of een dynamische waarde die is afgeleid van een Path in een bericht. Als u deze waarden wilt definiëren, kunt u statische of dynamische velden gebruiken.

Een statisch of dynamisch veld wordt altijd geschreven als een object met een type veld met een van de twee waarden: static of dynamic. Het schema varieert op typebasis van .

Statische velden

De statische definitie is een vaste waarde voortype.static De werkelijke waarde wordt bewaard in value.

Veld Type Beschrijving Vereist Standaardinstelling Opmerking
type const-tekenreeks Het type veld. Ja - static
waarde willekeurige De statische waarde die moet worden gebruikt voor de configuratie (meestal een tekenreeks). Ja - "static"

In de volgende voorbeelden ziet u enkele statische velddefinities:

{
    "some-field": {
        "type": "static",
        "value": "some-static-value"
    }
}
{
    "some-boolean-field": {
        "type": "static",
        "value": true
    }
}
{
    "some-complex-field": {
        "type": "static",
        "value": {
            "some": [
                "nested",
                "data"
            ]
        }
    }
}

Dynamische velden

De vaste waarde voor type is dynamic. De waarde is een jq-pad.

Veld Type Beschrijving Vereist Standaardinstelling Opmerking
type const-tekenreeks Het type veld Ja - dynamic
waarde Pad Het pad in elk bericht waarin een waarde voor het veld dynamisch kan worden opgehaald. Ja - .systemProperties.partitionKey

In het volgende voorbeeld ziet u een definitie van een dynamisch veld:

{
    "some-field": {
        "type": "dynamic",
        "value": ".systemProperties.topic"
    }
}

Opnieuw proberen

Fasen die externe services aanroepen, kunnen nieuwe pogingen gebruiken om tijdelijke fouten af te handelen en de betrouwbaarheid te verbeteren. U kunt het standaardbeleid voor opnieuw proberen overschrijven wanneer u een fase configureert.

Er zijn vier mogelijke beleidsregels voor opnieuw proberen:

  • default: Het standaardbeleid voor opnieuw proberen is het gebruik van een exponentieel uitstel met drie nieuwe pogingen en een interval van 500 ms voor opnieuw proberen.
  • none: Er worden geen nieuwe pogingen uitgevoerd.
  • fixed: Een vast beleid voor opnieuw proberen probeert een vast aantal keren met een vast interval tussen elke nieuwe poging.
  • exponential: Een beleid voor exponentieel opnieuw proberen probeert een vast aantal keren met een exponentieel toenemend interval tussen elke nieuwe poging.

Als u kiest default of none, hoeft u geen configuratie meer op te geven. Als u kiest fixed of exponential, moet u meer configuratie opgeven:

Vast

Veld Type Description Vereist? Standaardinstelling Opmerking
type tekenreeks De naam van het type nieuwe poging: fixed Ja N.v.t. fixed
interval Duur Initiële periode tussen elke nieuwe poging. Nee 500ms 2s
maxRetries int Het aantal nieuwe pogingen, van 1 naar 20 Nee 3 20

Exponentieel

Veld Type Description Vereist? Standaardinstelling Opmerking
type tekenreeks De naam van het type nieuwe poging: exponential Ja N.v.t. exponential
interval Duur Initiële periode tussen elke nieuwe poging. Nee 500ms 2s
maxRetries int Het aantal nieuwe pogingen, van 1 naar 20 Nee 3 20
maxInterval Duur Maximale periode tussen elke nieuwe poging. Nee Geen 100s

Exponentiële tijden voor opnieuw proberen worden als volgt berekend: als het interval begint met 500ms, zijn randInt(500ms, 500ms * 2^1)de volgende intervallen voor opnieuw proberen , randInt(500ms, 500ms * 2^2)..., randInt(500ms, 500ms * 2^maxRetries).

Batch

Met verschillende bestemmingen in de uitvoerfase kunt u berichten batchgewijs verwerken voordat ze naar de bestemming schrijven. Deze bestemmingen maken gebruik van batch om de batchparameters te definiëren.

Op dit moment kunt u batch definiëren op basis van tijd. Als u batchverwerking wilt definiëren, moet u het tijdsinterval en een pad opgeven. Path definieert welk gedeelte van het binnenkomende bericht moet worden opgenomen in de batchuitvoer.

Veld Type Beschrijving Vereist Standaardinstelling Opmerking
Tijd Duur Hoe lang het duurt om gegevens te batcheren Nee 60s (In bestemmingen waar batchverwerking wordt afgedwongen) 120s
Pad Pad Het pad naar waarde in elk bericht dat moet worden opgenomen in de uitvoer. Nee .payload .payload.output