Konfigurasjon av handlingslogger for skrivebordsflyt
Denne siden inneholder konfigurasjonsveiledning for skrivebordsflytlogger, som du finner under funksjonsdelen for miljøet i Power Platform-administrasjonssenteret.
Viktig!
- Denne funksjonen gjelder bare for skrivebordsflyter som startes fra en skyflyt, og som ennå ikke er tilgjengelig for lokalt overvåkede kjøringer fra Power Automate for skrivebordet.
Innstillingen Aktiveringsstatus for kjørehandlingslogger definerer når handlingslogger for skrivebordsflyter skal registreres, og du kan til og med slå dem helt av.
| Aktiveringsstatus | Details |
|---|---|
| Aktivert (standard) | Dette alternativet er standard for både eksisterende og nye miljøer der logger registreres som vanlig. |
| Ved kjørefeil | Dette alternativet registrerer bare handlingslogger for skrivebordsflyter når det oppstår en kjøretidsfeil. Dette betyr at logger ikke er tilgjengelige for hver enkelt kjøring, men bare når det oppstår en feil. Hvis det imidlertid oppstår en feil, er alle logger for den bestemte kjøringen tilgjengelige, inkludert både vellykkede og mislykkede handlinger. |
| Disabled | Med dette alternativet deaktiverer handlingslogger for skrivebordsflytkjøring fullstendig. |
Forsiktig!
Endring av noen av disse innstillingene kan ha betydelig innvirkning på funksjoner som for eksempel feilsøking av kjørefeil og sporing av endringer. Vurder implikasjonene av å endre disse innstillingene før du fortsetter.
Forutsetning
- Premium-lisens på Power Automate og administrative rettigheter for å konfigurere logginnstillinger
- Konfigurasjoner for Power Automate-nettadresse og -IP-adresse
Konfigurer handlingsloggversjon for skrivebordsflyt
Med Handlingsloggversjon kan du velge V1, V2 eller begge deler.
| Loggversjon | Forklaring |
|---|---|
| V1 – lagret i feltet AdditionalContext for enheten FlowSession | Dette er standardalternativet. Logger lagres i feltet AdditionalContext i tabellen Flytøkt, som er et filattributt lagret som en blob i Microsoft Dataverse. Logger av V1 forbruker Dataverse-filkapasitet. |
| V2 – lagret i enheten FlowLogs | Med dette alternativet kan du lagre logger i tabellen Flytlogger, som er lagret i Elastiske tabeller. Logger av V2 forbruker Dataverse-databasekapasitet. |
| Begge | Denne innstillingen tillater at logger lagres både i det tradisjonelle AdditionalContext-feltet i tabellen Flytøkt og tabellen Flytlogger. Denne funksjonen forbruker både Dataverse-fil- og databasekapasitet. Denne innstillingen er beregnet for feilsøking eller testing fordi den forbruker både Dataverse-database- og filkapasitet. |
Verdien Levetid for FlowLogs-enhet i minutter bestemmer hvor lenge handlingslogger skal beholdes i den elastiske tabellen Flytlogger. Dataverse sletter automatisk oppføringer som er eldre enn den angitte tidsrammen. Her er noen eksempler på verdier.
| dager | Minutter |
|---|---|
| Én dag | 1,440 minutter |
| Tre dager | 4,320 minutter |
| Sju dager | 10,080 minutter |
| 14 dager | 20,160 minutter |
| 28 dager | 40,320 minutter |
| 60 dager | 86,400 minutter |
| 90 dager | 129,600 minutter |
| 180 dager | 259,200 minutter |
| 365 dager | 525,600 minutter |
| Alltid | 0 (null) minutter |
Notat
Før du aktiverer logger V2, må du sørge for at du har tilstrekkelig Dataverse-databasekapasitet som støtter innstillingene for dataoppbevaring, og er i samsvar med kapasitetsplanleggingen, rettigheten og justeringen etter behov. Se delen Eksempel på Dataverse-kapasitetsbehov for logger V2 nedenfor for noen størrelseseksempler.
Viktige forskjeller mellom skrivebordsflytlogger V1 og V2
Tabellen nedenfor beskriver forskjellene mellom skrivebordsflytlogger V1 og V2:
| Funksjon | Logger V1 | Logger V2 | Details |
|---|---|---|---|
| Automatisk dataoppbevaring | Ikke tilgjengelig | Tilgjengelig | V2 bruker Elastiske tabeller, som drives av Azure Cosmos DB, og leveres med en innebygd levetidsfunksjon for automatisk dataoppbevaring. |
| Støtte for store logger | Omtrent 50 000 til 80 000 handlingslogger (maksimum) | Omtrent det dobbelte av V1-handlingslogger (opprinnelig) | V2 kan teoretisk sett skalere opptil GB med handlingslogger per kjøring i fremtiden, mens V1 bare kan skaleres til volumet som er angitt i denne tabellen. |
| Støtte for avansert rapportering og styring | Ikke tilgjengelig | Tilgjengelig | I V1 er AdditionalContext-attributtet en filtype, lagret som en blob i Dataverse, noe som gjør det utfordrende å analysere for rapporterings- og styringskontroller. Logger er mye mer tilgjengelige i V2. |
| Støtte for Azure Synapse Link for Dataverse-integrering | Ikke tilgjengelig | Tilgjengelig | I V1 er AdditionalContext-attributtet en filtype, lagret som en blob i Dataverse, som ikke støttes for synkronisering til Azure Synapse. |
| Støtte for Dataverse-revisjon | Ikke tilgjengelig | Tilgjengelig | I V1 er AdditionalContext-attributtet en filtype, lagret som en blob i Dataverse, som ikke støttes i Dataverse-revisjon. |
| Støtte for langsiktig oppbevaring i Dataverse | Ikke tilgjengelig | Planlagt | I V1 er AdditionalContext-attributtet en filtype, lagret som en blob i Dataverse, som ikke støttes i langsiktig oppbevaring i Dataverse. |
| Basert på rollebasert tilgangskontroll (RBAC) i Dataverse | Tilgjengelig | Tilgjengelig | Begge versjonene bruker Dataverse RBAC og arver handlingsloggtillatelser fra oppføringen av den overordnede flytøkten. |
Logger V2 har betydelige forbedringer i forhold til den forrige versjonen, V1. V2 bruker funksjonen for elastiske tabeller, som er utmerket for håndtering av store datavolumer, for eksempel scenarioer med handlingslogger, og som har innebygd dataoppbevaring (TTL). Ideelt for organisasjoner som trenger tilgang til betydelig mengde data for rapportering, styring og integrering med automatisk dataoppbevaringskontroll.
Dataverse-kapasitetsbehovsberegninger for logger V2
Tabellen nedenfor viser eksempler på forbruksestimater for Dataverse-databaselagring per skrivebordsflytkjøring ved bruk av logger V2. Den skisserer det omtrentlige lagringsbehovet for et forskjellig antall handlinger, forutsatt et gjennomsnitt på 3 kB lagringsplass per handling.
| Antall handlinger | Lagringsbehov per handling (kB) | Totalt lagringsforbruk (MB) |
|---|---|---|
| 1,000 | 3 | 2.93 |
| 10,000 | 3 | 29.3 |
| 30,000 | 3 | 87.9 |
| 60,000 | 3 | 175.8 |
| 100,000 | 3 | 293 |
| 160,000 | 3 | 480 |
Viktig!
Tallene som vises i tabellen over, er bare estimater, og det faktiske lagringskonsumet kan variere betydelig. Det nøyaktige lagringsbehovet avhenger av de spesifikke detaljene og kompleksiteten til hver handlingslogg. Disse tallene bør derfor brukes som en omtrentlig veiledning for å forstå det potensielle lagringsbehovet og planlegge lagringskravene i henhold til dette.
Spørre etter data i logger V2
Tilgang til handlingsloggdata for skrivebordsflyter kan oppnås ved å foreta et API-kall til Dataverse-serverdelen, enten ved å bruke den tradisjonelle API-kallsyntaksen eller ved å bruke den nye ExecuteCosmosSqlQuery-metoden. Med denne metoden kan du kjøre en SQL-spørring mot Dataverse, slik at du kan hente og filtrere data.
Datamodellen for logger V2 er basert på en overordnet-underordnet-relasjon mellom tabellene Flytøkt og Flytlogg. Hver oppføring arver tillatelser fra dens overordnede oppføring for flytøkten. Du kan bruke følgende spørringssyntaks for å spørre handlingslogger for en bestemt skrivebordsflyt.
Tradisjonell API-kallsyntaks i Dataverse
API-kallet nedenfor henter en bestemt flytøkt etter sin ID (9d51aa1f-315e-43ab-894f-bc445dfb049b) og får deretter tilgang til de tilknyttede handlingsloggene ved hjelp av flowsession_flowlog_parentobjectid-relasjonen.
[Organization URI]/api/data/v9.0/flowsessions(9d51aa1f-315e-43ab-894f-bc445dfb049b)/flowsession_flowlog_parentobjectid
Ny ExecuteCosmosSqlQuery API-kallsyntaks med FlowLogs-tabell
[Organization URI]/api/data/v9.2/ExecuteCosmosSqlQuery(
QueryText=@p1,EntityLogicalName=@p2,QueryParameters=@p3,PageSize=@p4)?
@p1: 'SELECT c.props.flowlogid as flowlogid, c.props.createdon as createdon, c.props.data as data, c.props.level as level, c.props.type as type, c.ttl as ttlinseconds, c.props.cloudflowid as cloudflowid, c.props.cloudflowrunid as cloudflowrunid, c.props.desktopflowid as desktopflowid, c.props.flowmachineid as flowmachineid, c.props.flowmachinegroupid as flowmachinegroupid, c.props.flowsessionid as flowsessionid, c.props.workqueueid as workqueueid, c.props.workqueueitemid as workqueueitemid FROM c WHERE c.props.type IN (100000001) ORDER BY c.props.data.startTime DESC'
@p2: 'flowlog'
@p3: {"Keys":["@referencingParentId","@referencingParentLogicalName"],"Values":[{"Type":"System.Guid","Value":"40590757-a9c0-4f4c-abfc-e2f389049d90"},{"Type":"System.String","Value":"flowsession"}]}
@p4: 50
Lær mer om spørring av JSON-kolonner i elastiske tabeller.
Oppdeling av kallet i enkeltdeler
- Basis-URL-en (https://[my org].api.crm[my region].dynamics.com/api/data/v9.2/) er endepunktet for Dataverse-nett-API-en.
- ExecuteCosmosSqlQuery er metoden som kalles. Denne metoden tillater kjøring av en SQL-spørring mot Dataverse.
- Parameterne for metoden ExecuteCosmosSqlQuery finnes i parentesen etter metodenavnet:
QueryText=@p1: SQL-spørringen som skal kjøres. I dette tilfellet velger spørringen forskjellige egenskaper fra en tabell der type er 100000001 (handlingsloggtype skrivebordsflyt) og sorterer resultatene etter egenskapen startTime i synkende rekkefølge.EntityLogicalName=@p2: Denne delen er det logiske navnet på tabellen (flowlog) som lagrer handlingsloggene.QueryParameters=@p3: Denne delen er et JSON-objekt som angir parametere for spørringen. I det forrige eksemplet angir det et nøkkelverdipar der nøklene er@referencingParentIdog@referencingParentLogicalNamemed verdieneflowsessionid(GUID) og typen tabellflowsession.PageSize=p4: Denne delen er størrelsen på spørringssiden.
Kjente begrensninger
- Logger V2 er bare tilgjengelige for skrivebordsflytkjøringer som startes fra en skyflyt gjennom koblingshandlingen for skrivebordsflyt.
- Masseslettingsjobber støttes for øyeblikket ikke for tabellen Flytlogg.
- Flytloggoppføringer kan ennå ikke vises i delen Tabell av Maker Portal (make.powerapps.com).
- Endring av versjon av handlingsloggen overfører ikke tidligere handlingslogger for skrivebordsflyter til den nye logglagringstypen.