Bemærk
Adgang til denne side kræver godkendelse. Du kan prøve at logge på eller ændre mapper.
Adgang til denne side kræver godkendelse. Du kan prøve at ændre mapper.
I Activator ankommer data som begivenheder. Du kan oprette regler direkte på begivenheder for at udløse handlinger, når betingelserne er opfyldt. Valgfrit kan du gruppere begivenheder i objekter efter en unik nøgle og eksponere egenskaber (felter, du vil overvåge over tid), som låser op for mere kraftfulde regeltyper. Begivenheder, objekter, egenskaber og regler er alle repræsenteret i Activator-brugerfladen som entiteter – elementer i explorer-træet, som du kan vælge og konfigurere.
Denne artikel forklarer hvert af disse koncepter og hvordan man bruger dem til at bygge triggere.
Begivenhedsenheden
Alle triggere i Activator starter med en eller flere begivenheder. Disse begivenheder repræsenterer Activators realtidsindtagelse af data fra en af flere kilder. Se oversigt over indtagelse for at forstå, hvordan Activator indlæser data fra forskellige kilder i Activator.
Du kan se information om event-enheden på event-siden. Den indeholder et realtidsbillede af begivenheder, efterhånden som de ankommer, samt en optælling over begivenheder over tid.
Hændelsen har to slags felter: systemfelter (tilføjet af Activator, når data indlæses) og datafelter (de faktiske data om begivenheden, der sendes til Activator).
Systemfelterne er:
| Navn på felt | Forklaring |
|---|---|
Time |
Den logiske begivenhed, tid. Hvordan det beregnes, varierer fra kilde til kilde. Se Oversigt over Indtagelse for en beskrivelse af, hvordan dette felt beregnes af Activator. |
___id |
Begivenhedens unikke ID |
___source |
Et internt ID, der identificerer kilden i Aktivator-systemet |
___type |
Den slags kilde (for eksempel Power BI, eventstream), som begivenheden stammer fra |
System.IngestionTime |
Dette er det faktiske tidspunkt, hvor begivenheden blev indtaget i Activator (i UTC). Se Latency in Activator for en detaljeret diskussion om, hvordan det adskiller sig fra Time feltet, og hvordan dette relaterer sig til dine triggere. |
System.LastUpdateTime |
Dette er sidste gang, begivenhedsdefinitionen blev opdateret. |
Dine datafelter kan variere fra begivenhed til begivenhed, og Activator pålægger ikke et strengt skema ved indtastning.
Bemærkning
I Activator betragtes et datafelt, der indeholder en tom streng (""), som det samme som begivenheden, der ikke indeholder datafeltet.
Regler
Efter at have indført dine data i Activator i form af en evententitet, kan du oprette en regel til at handle på dine data. Der findes tre forskellige slags regelenheder. Denne tabel giver et overordnet overblik over, hvornår man skal vælge hvilken:
| Dimension | Eventregler | Split-Event Regler | Ejendomsregler |
|---|---|---|---|
| Kompleksitet | Laveste | Mellem | Højeste |
| Understøttelse af ændringer i detektering | Kun simple betingelser tilgængelige | Kun simple betingelser tilgængelige | Hele sæt af tilgængelige betingelser |
| Kan spore ændringer på tværs af forskellige objekter | Ikke understøttet | Understøttet | Understøttet |
| Kan oprette regler baseret på flere event-enheder | Ikke understøttet | Ikke understøttet | Understøttet |
Bemærkning
Latenstiden afhænger delvist af kompleksiteten af den oprettede regel, men mange andre faktorer kan påvirke Activator-regellatens. Se Latens in Activator for dokumentation af disse faktorer.
Begivenhedsregelenheden
Den simpleste type regel, du kan lave i Activator, er en event-regel. Denne type regel virker direkte på én begivenhedsenhed og præsenterer et enklere sæt betingelser end split-event-regler og egenskabsregler. Brug det, når du vil advare om en global egenskab for en strøm og ikke vil skelne mellem forskellige objekter. For eksempel, hvis du vil advare, når globale salg overstiger $100.000, skal du bruge en eventregel. Men hvis du i stedet vil overvåge salget i de enkelte lande, så brug en split-event eller ejendomsregel.
Monitortrin
I monitor-trinnet vælger du, hvilken event-enhed du vil overvåge med denne regel.
Betingelsestrin
En begivenhedsregel har en eller flere betingelser, og den aktiveres, når alle betingelser er opfyldt. For eksempel brander ovenstående, når temperaturen er > 10 og trykket 30 < . Hvis dine events ikke har et konsistent skema, kan du vælge en standardværdi. For eksempel mangler nogle af dine begivenheder trykfeltet, og du vil angive et standardtryk på 15.
Handlingstrin
Event-regler understøtter det samme sæt handlinger som alle andre regler. Se Activator-introduktionen for dokumentation af hver enkelt. Du kan vælge felter fra begivenheden for at tilføje ekstra kontekst til aktiveringen.
Objektentiteten, split-event-enheden og egenskabsenhederne
Objekter er en måde logisk at opdele dine indkommende begivenhedsenheder i separate strømme, så objekterne kan overvåges separat. Mange virkelige anvendelsestilfælde passer ind i dette paradigme, for eksempel overvågning af motortryk på tværs af en vognpark.
Objects
Et objekt er baseret på en eller flere begivenhedsenheder. For at omdanne en begivenhed til et objekt, vælg en kolonne fra begivenheden som objekt-ID-nøglen:
Denne kolonnes værdier skal unikt identificere hvert objekt – det er sådan, Activator beslutter, hvilket objekt en indkommende begivenhed hører til. Flere hændelser kan have samme værdi, når de tilhører det samme objekt. For eksempel kan du bruge VehicleId til at overvåge en bilflåde eller PackageId til at overvåge et sæt pakker.
Et objekt kan også bestå af flere begivenhedsenheder. For eksempel kan du have motortryk på én begivenhedsenhed, og temperaturen på en anden, men du vil gerne knytte dem til det samme køretøjsobjekt. Se Kombinering af flere strømme for en detaljeret gennemgang af denne funktion.
Split-event enheder
Hver event-entitet, du tilføjer til objektet, skaber en tilsvarende split-event-entitet, som er en visning af den oprindelige event-entitet, men delt af objekt-ID-nøglen. Du kan oprette en split-event regel ud fra en split-event.
Ejendomsenheder
Du kan tilføje felter fra begivenhederne som egenskaber for objektet. Egenskabsenheder tillader yderligere beregninger på feltet og kan genbruges af en eller flere egenskabsregelentiteter :
Egenskaber tillader simple aggregeringer (gennemsnit, maks, min. og antal). Aggregationerne ser på data over hele vinduesbredden og beregner resultatet ved hver vindueshopstørrelse. Hvis du har brug for mere komplekse transformationer på et hændelsesfelt, kan du overveje at bruge kapaciteterne i systemet, der sender dataene til Activator.
Bemærkning
Egenskaber angives med et enkelt etiketikon, mens objekt-ID'et er mærket med et dobbelt etiketikon. Objekt-ID'et er ikke en egenskab og kan derfor ikke bruges som grundlag for ejendomsregler.
Split-event regelenheden
Split-event regler er en simpel måde at skabe regler, der kan differentiere mellem forskellige logiske objekter. For eksempel, hvis du vil oprette en regel, der advarer, når en given butiks salg overstiger $10.000, så brug en split-event regel. Objekt-ID'et (for eksempel butiksnavnet) tilføjes automatisk til aktiveringen, som en split-event-regel producerer. Ellers fungerer de på en meget lignende måde som event-regler. Split-event-regler deler de samme betingelser og handlingstrin som event-regler.
Ejendomsregelenheden
Ejendomsregler giver dig størst fleksibilitet i at definere komplekse alarmbetingelser. En egenskabsregel skal være forbundet med én "basisegenskab". Basisegenskaben er den eneste egenskab, der kan få reglen til at aktiveres. Andre egenskaber kan bruges som filtre eller til at tilføje ekstra kontekst i aktiveringen.
Der er fire trin i en ejendomsregel:
Monitortrin
Betingelsestrin
Egenskabsfiltertrin
Handlingstrin
Monitortrin
I monitor-trinnet vælger du først, hvilken egenskab der styrer din trigger. Så kan du eventuelt tilføje nogle filtre. Disse filtre fjerner alle ejendomsværdier, der ikke opfylder alle kriterier før næste trin.
Bemærkning
Hvis du ikke ser et felt fra din begivenhed opført, så sørg for, at der findes en egenskab på objektet for det felt.
Betingelsestrin
I dit betingelsestrin vælger du, hvilken ændringsdetektion du vil bruge. Aktivator understøtter ændringer i detektionsbetingelser såsom StigningerMed 10%, eller BliverMindreEnd 30. Disse betingelser sammenligner flere punkter i den indkommende begivenhedsstrøm i stedet for en simpel punkt-for-punkt-sammenligning. Se Detektionsbetingelser for en komplet liste over betingelsesmulighederne og en forklaring af deres adfærd, herunder hvordan man sammenligner med en anden egenskab på det samme objekt i stedet for en fast værdi.
Du kan også vælge en "Forekomst"-mulighed for at ændre tilstanden yderligere. For eksempel kan du ønske at affyre, når temperaturen bliver mindre end 30, og så forbliver sådan i 10 minutter. Forekomstmulighederne er:
Hver gang betingelsen er opfyldt—er denne mulighed standardadfærden.
Når det har været sandt n gange i træk—bemærk at denne mulighed betyder sammenhængende, ikke total. Triggeren udløses, når basisbetingelsen har været sand i n på hinanden følgende evalueringer. For eksempel kan du ønske at affyre, når temperaturen er under 30 grader for 10 på hinanden følgende temperaturmålinger.
Når det har været sandt for—denne mulighed betyder, at udløseren aktiveres, når basisbetingelsen har været sand i x tid.
Ikke alle forekomstmuligheder er tilgængelige for alle tilstande.
Egenskabsfiltertrin
Egenskabsfiltre er en måde at filtrere outputtet af betingelsestrinnet på. De adskiller sig fra filtrene i monitor-trinnet på to måder:
Monitor-trin filtre opstår, før betingelsesresultatet beregnes, mens egenskabsfilter-trinnet anvendes efter betingelsestrinnet er fuldført. Denne forskel kan resultere i, at forskellige aktiveringer produceres.
Egenskabsfiltre kan referere til andre egenskaber end basisegenskaben. For eksempel kan din grundejendom være "temperatur" og din tilstand sat til brand, når temperaturen stiger over 30. Du vil måske tilføje begrænsningen om, at aftrækkeren kun skal affyres, når "trykket" er under 10. Det gør du ved at tilføje et egenskabsfilter ved hjælp af tryk til reglen.
Handlingstrin
Handlingstrinnet er det samme som handlingstrinnet i event og split-event triggere. Du kan vælge andre egenskaber, der vises som ekstra kontekst i din aktivering via "kontekst"-dropdownmenuen. ID'et på objektet, der fik reglen til at affyre, og tidspunktet for affyringen, er inkluderet som standard.
Bemærkning
For at tilføje et hændelsesfelt som ekstra kontekst til din egenskabsregel, skal du først sikre dig, at der findes en egenskab på dit objekt for det felt.
Fejljusterede egenskaber
En egenskabsregel kan referere til flere egenskaber på én gang—for eksempel i egenskabsfiltertrinnet eller som ekstra kontekst i handlingstrinnet. Disse egenskaber bør bedst betragtes som logisk uafhængige strømme, og derfor kan tidspunktet for begivenheder på disse strømme variere.
Hvis disse egenskaber opdateres med forskellige hastigheder, opstår spørgsmålet: hvilken værdi skal bruges, når reglen skal evalueres? Overvej disse eksempler:
- Du laver en regel, der aktiveres, når trykket overstiger 30, og du inkluderer gennemsnitstemperaturen (beregnet hvert femte minut) som ekstra kontekst.
- Du opretter en regel, der aktiveres, når en chauffør bliver utilgængelig, men kun når chaufføren er tildelt en pakke med mindre end en dag tilbage før levering. Chaufførstatus og pakkedeadline kommer fra forskellige eventenheder.
I traditionelle streamingsystemer skal der overvejes omhyggeligt, hvordan flere hændelsesstrømme, hvor begivenheder sker på forskellige tidspunkter, kan kombineres på en ensartet måde. Men i Activator fungerer denne adfærd naturligt ud af boksen. Objekter i Activator er tilstandsfulde, så den sidste begivenhed for en given egenskab bevares altid og er tilgængelig for brug i en fremtidig beregning. Bemærk, at ejendomsværdier kun bevares i 7 dage fra det tidspunkt, hvor den sidste hændelse blev set for det pågældende objekt.