Oversikt over koblinger for lerretsapper

Dataene er i kjernen for de fleste apper, inkludert dataene du oppretter i Power Apps. Dataene er lagret i en datakilde, og du importerer disse dataene inn i appen ved å opprette en tilkobling. Tilkoblingen bruker en bestemt tilkobling for å kommunisere med datakilden. Power Apps har koblinger for mange populære tjenester og lokale datakilder, inkludert SharePoint, SQL Server, Office 365, Salesforce og Twitter. Hvis du vil komme i gang med å legge til data i en lerretsapp, kan du se Legg til en datatilkobling i Power Apps.

En kobling kan inneholde tabeller med data eller handlinger. Noen koblinger inneholder bare tabeller, noen inneholder bare handlinger, og noen inneholder begge. Koblingen kan også være enten en standardkobling eller egendefinert kobling.

Tabeller

Hvis koblingen inneholder tabeller, legger du til datakilden, og deretter velger du tabellen i datakilden som du ønsker å administrere. Power Apps henter både tabelldata fra appen og oppdateringsdata fra datakilden automatisk. Du kan for eksempel legge til en datakilde som inneholder en tabell med navn Leksjoner. Deretter angir du Items-egenskapen til en kontroll, som et galleri eller skjema, til denne verdien i formellinjen:

Du kan angi dataene som appen henter ved å tilpasse Items-egenskapen for kontrollen som viser deg dataene. Hvis vi fortsetter fra forrige eksempel, kan du sortere eller filtrere dataene i Leksjoner-tabellen ved bruk av navnet som et argument for Søk- og SortByColumn-funksjonene. I denne grafikken angis formelen som Items-egenskapen er angitt til, og den spesifiserer at dataene sorteres og filtreres basert på teksten i TextSearchBox1.

Hvis du vil ha mer informasjon om hvordan du tilpasser formlene med tabeller, kan du se disse artiklene:

Forstå datakilder i Power Apps
Å generere en app fra Excel-data
Opprett en app fra bunnen
Forstå tabeller og oppføringer i Power Apps

Obs!

Hvis du vil koble til data i en Excel-arbeidsbok, må den være lagret i en skylagringstjeneste som OneDrive. Hvis du vil ha mer informasjon, kan du se Å koble til lagring i skyen fra Power Apps.

Handlinger

Hvis koblingen inneholder handlinger, må du fremdeles velge datakildene som før. I stedet for å velge en tabell som neste trinn kan du heller koble til en kontroll i en handling manuelt, ved å redigere Items-egenskapen til kontrollen som viser dataene. Formelen som du angir Items-egenskapen for, angir handlingen som henter dataene. Appen henter for eksempel ikke data hvis du kobler til Yammer, og deretter angir Items-egenskapen til navnet på datakilden. Hvis du vil fylle ut en kontroll med data, angir du en handling som GetMessagesInGroup(5033622).messages.

Hvis du må håndtere egendefinerte dataoppdateringer for handlingskoblinger, bygger du en formel som inkluderer Patch-funksjonen. Identifiser handlingen og feltene som du skal binde til handlingen, i formelen.

Obs!

For handlingsbaserte koblinger søker ikke gallerier og andre kontroller inn flere data automatisk på samme måte som de gjør for tabellformede koblinger. Hvis du for eksempel binder en datakilde i tabellform til et galleri, vil den hente det første settet eller siden med poster (f.eks. 100 poster). Og så vil den søke inn flere data etter hvert som kontrollen ber om det. For en handlingsbasert kobling vil den imidlertid hente en "side" med data. Hvis de forespurte dataene imidlertid overskrider størrelsen for en side med data, henter ikke kontrollen den neste siden automatisk.

Hvis du vil ha mer informasjon om hvordan du tilpasser formlene for egendefinerte oppdateringer, kan du se disse artiklene:

Patch
Collect
Update

Dynamisk skjema er en vanlig type resultat for handlingsbaserte koblinger. Dynamisk skjema viser til muligheten for at den samme handlingen kan returnere en annen tabell med andre kolonner, alt etter hvordan den kalles. Betingelser som kan føre til at kolonnene i tabellen er forskjellige, er inndataparametere, brukeren eller rollen som utfører handlingen, og gruppen som brukeren arbeider i, blant andre. Lagrede SQL Server-prosedyrer kan for eksempel returnere andre kolonner hvis de kjøres med forskjellige inndata, eller en Azure DevOps-forekomst kan bruke egendefinerte felter som ikke er tilgjengelige som standard. Merk at koblingsdokumentasjonen viser dynamiske skjemaresultater med denne meldingen "Utdataene for denne operasjonen er dynamiske." som returverdi.

For mer informasjon om hvordan du arbeider med dynamisk skjema i Power Apps, se Arbeid med typeløse og dynamiske objekter for en oversikt og Koble til Azure DevOps fra Power Apps for et detaljert eksempel.

Populære koblinger

Denne tabellen inneholder koblinger til mer informasjon om våre mest populære koblinger. Hvis du vil ha en fullstendig liste over koblinger, kan du se Alle koblinger.

Microsoft Dataverse	Skylagring **
Dynamics AX	Excel
Microsoft Translator	Office 365 Outlook
Office 365-brukere	Oracle
Power BI	SharePoint
SQL Server	Twitter

** Gjelder for Azure Blob, Box, Dropbox, Google Drive, OneDrive og OneDrive for Business

Standardkoblinger og egendefinerte koblinger

Power Apps inneholder standard-koblinger for mange vanlige datakilder. Hvis Power Apps har en standard kobling for datakildetypen du ønsker å bruke, må du bruke den koblingen. Hvis du ønsker å koble til andre datakildetyper, for eksempel en tjeneste som du har opprettet, kan du se Registrer og bruk egendefinerte koblinger.

Alle standardkoblinger

Standardkoblinger krever ikke spesiell lisensiering. Hvis du vil ha mer informasjon, se Power Apps-planer.

Du kan stille spørsmål om en bestemt kobling i Power Apps-forumene, og du kan foreslå koblinger som du vil legge til eller andre forbedringer i Power Apps Forslag.

Sikkerhet og godkjenningstyper

Når du redigerer appen og oppretter en tilkobling til en datakilde, ser du kanskje at du kan bruke ulike måter å godkjenne på. SQL Server-koblingen tillater for eksempel at du bruker Microsoft Entra-integrert, SQL-servergodkjenning og Windows-godkjenning. Hver godkjenningstype har forskjellige sikkerhetsnivåer tilknyttet. Det er viktig å forstå hva slags informasjon og hvilke rettigheter du deler med brukere som bruker programmet. Hovedeksemplet i denne artikkelen er SQL Server, men prinsippene gjelder for alle typer tilkoblinger.

Obs!

• Hvis du vil ha detaljert informasjon om sikkerhetshensyn ved bruk av en relasjonsdatabaseserver (for eksempel Microsoft SQL Server eller Oracle) som datakilde for en app, kan du se Bruk Microsoft SQL Server sikkert med Power Apps.
• Power Apps støtter ikke identiteter av typen Eksternt medlem. Hvis du vil ha mer informasjon, kan du se Egenskaper for en Microsoft Entra B2B-samarbeidsbruker.

Microsoft Entra-ID

Dette er en sikker tilkoblingstype. SharePoint bruker for eksempel denne godkjenningstypen. SQL Server tillater også denne godkjenningstypen. Når du kobler til, identifiserer Microsoft Entra-tjenesten deg deg separat for SharePoint på dine vegne. Du trenger ikke å oppgi brukernavn eller passord. Som forfatter kan du opprette og arbeide med datakilden med legitimasjonen din. Når du publiserer programmet, og programbrukeren logger på, vil de gjøre dette med sin legitimasjon. Hvis dataene er sikret i en back-end, kan brukerne bare se hva de har tillatelse til å se, basert på legitimasjonen deres. Denne typen sikkerhet gjør det mulig å endre rettigheter for bestemte programbrukere på serverdel-datakilden etter at programmet er publisert. Du kan for eksempel gi tilgang til, nekte tilgang eller finjustere hva en bruker eller et sett med brukere kan se på serverdel-datakilden.

Åpen standardgodkjenning (OAuth)

Dette er også en sikker tilkoblingstype. Twitter bruker for eksempel denne godkjenningstypen. Når du kobler til, må du angi brukernavn og passord. Som forfatter kan du opprette og arbeide med datakilden med legitimasjonen din. Når du publiserer programmet, og programbrukeren logger på, må de også angi legitimasjonen. Denne tilkoblingstypen er derfor sikker siden brukerne må bruke sin egen legitimasjon for å få tilgang til datakildetjenesten.

Delte tilkoblinger / Sikre implisitte tilkoblinger

I en delt tilkobling oppgis brukernavnet og passordet for tilkoblingen av Power Apps-forfatteren på det tidspunktet datakilden opprettes i applikasjonen. Tilkoblingsgodkjenningen til datakilden er deretter implisitt delt med sluttbrukerne. Så snart appen publiseres, publiseres også tilkoblingen og er tilgjengelig for brukerne.

Før januar 2024 kunne sluttbrukerne dine ta tilkoblingen som deles med dem, og opprette separate nye applikasjoner. Brukerne kan ikke se brukernavnet eller passordet, men tilkoblingen er tilgjengelig for dem. Imidlertid etter januar 2024, er alle nyopprettede delte tilkoblinger sikret. Merk at gamle apper må publiseres på nytt for å være sikre. Dette betyr at tilkoblingen ikke lenger deles med sluttbrukere. Den publiserte Power App snakker med en tilkoblingsproxy. Tilkoblingsproxyen vil kun snakke med den spesifikke Power App-en den er koblet til. Tilkoblingsproxyen begrenser handlingene som sendes til tilkoblingene, til de i Power App {Get, Put/Patch, Delete} for en gitt datakilde. Hvis du har en app som bruker tilkoblingene publisert før januar 2024, bør du publisere applikasjonen på nytt og oppheve deling av tilkoblinger med sluttbrukere som ikke burde ha dem.

I SQL Server er et eksempel på denne tilkoblingstypen SQL Server-godkjenning. Mange andre database-datakilder gir en lignende funksjon. Når du publiserer programmet, trenger ikke brukerne å oppgi et unikt brukernavn og passord.

Varsling om å oppdatere appene dine (sikre implisitte tilkoblinger)

Hvis du har programmer som kan oppgraderes til å bruke denne funksjonen, vises en melding på Apper-siden. Det angir antall apper som krever din oppmerksomhet.

Velg koblingen, og dermed åpnes et sidepanel som viser alle appene som trenger oppmerksomhet.

Velg Åpne-ikonet til høyre for appnavnet for å åpne det og publisere det på nytt. Se instruksjonene nedenfor.

Aktivere sikre implisitte tilkoblinger for en eksisterende app

Åpne en eksisterende app som er åpen for redigering med implisitt delte tilkoblinger som tidligere har blitt publisert:

1. Velg Innstillinger på kommandolinjen, og søk etter "Sikre".
2. Oppdater funksjonsbryteren riktig for å aktivere sikre implisitte tilkoblinger.
3. Lagre og publiser appen.

Oppheving av deling

Når appen er publisert, følger du denne fremgangsmåten for å kontrollere at deling fungerer som det skal:

• Kontroller om tilkoblinger er delt med medeiere. Hvis du ikke vil at sluttbrukere skal få en tilkobling, fjerner du merket for Medeier.

  

• Hvis du vil kontrollere at funksjonen fungerer som den skal, deler du appen med en annen bruker som ikke er eier. Når du har delt appen, kan du se i Tilkoblinger-listen i Dataverse kategorien i Power Apps for den brukeren. Kontroller at brukeren ikke har en tilgjengelig tilkobling.

• Åpne Deling-panelet for å endre sluttbrukerens rettighet til tilkoblingen. Hvis du velger X , fjernes brukerens tilgang til tilkoblingen.

  .

Bruke apper med en ny sikker implisitt tilkobling

Når appen publiseres og deles på nytt, har ikke sluttbrukerne tilgang til tilkoblingen, men den fungerer med den skjulte proxy-tilkoblingen. De kan ikke opprette en ny app basert på den opprinnelige tilkoblingen.

Begrensninger

1. Alle typer implisitt delte koblinger fungerer, for eksempel handling og tabell.
2. Server- og databasenavn skjules i nettverksspor, men vises i dialogboksen for samtykke. Kolonnenavn er ikke skjult.
3. For koblinger i tabellform begrenser vi bare CRUD-handlinger som Get, Post, Put eller Delete Hvis du har tillatelse til Put, har du tilgang til Post.
4. Grense for handlingsbaserte koblinger basert på den bestemte API-en som brukes i programmet.
5. Det er fremdeles aktivert advarsler ved deling. Advarselen om implisitt delte tilkoblinger advarer fremdeles i privat forhåndsvisning. Tilkoblingen til denne funksjonen er imidlertid sikker – til tross for advarselen.
6. Du kan publisere til bestemte grupper eller enkeltpersoner, men ikke til en hel leier.
7. Det er et kjent problem ved import av en implisitt delt sikker tilkobling via en tilkoblingsreferanse. Sikkerheten er ikke riktig angitt i målmiljøet.
8. Det er et kjent problem ved import av en løsning ved hjelp av en tjenestekontohaver, som fører til importfeil. En løsning er å dele tilkoblingen med tjenestekontohaveren.

Windows-godkjenning

Denne tilkoblingstypen er ikke sikker fordi den ikke er avhengig av sluttbrukergodkjenning. Bruk Windows-godkjenning når du har behov for å koble til en datakilde som finnes lokalt. Et eksempel på denne tilkoblingstypen er til en lokal server som har en SQL Server. Tilkoblingen må gå gjennom en gateway. Ettersom den går gjennom en gateway, har koblingen tilgang til alle dataene på datakilden. All informasjon som du har tilgang til med Windows-legitimasjonen du oppgir, er derfor tilgjengelige for koblingen. Så snart appen publiseres, publiseres også tilkoblingen og er tilgjengelig for brukerne. Dette betyr at sluttbrukerne også kan opprette programmer ved hjelp av den samme tilkoblingen og få tilgang til dataene på den maskinen. Tilkoblinger til datakilden blir også implisitt delt med brukere som appen er delt med. Denne tilkoblingstypen kan være gyldig når datakilden bare ligger på en lokal server og dataene på kilden er fritt delt.

Datakilder i løsninger

Løsninger brukes til administrasjon av programlivssyklusen og gir andre funksjoner for administrasjon av livssyklusen for datakilder. Hvis en lerretsapp finnes i en løsning, kan tilkoblingsreferanser og miljøvariabler opprettes for å lagre informasjon om datakildene. Dette sikrer at datakilder kan endres eller opprettes på nytt når løsninger overføres til forskjellige miljøer.

Gi nytt navn til datakilder i apper

Hvis du vil vite hvordan du gir nytt navn til datakilder i en app, og forskjellen mellom tabell- og handlingsbaserte datakilder, kan du gå til Gi nytt navn til Power Apps-handlingsbaserte datakilder.

Dialog for tilkoblingssamtykke

Når brukere åpner en app som bruker koblinger for første gang, vises dialogboksen for tilkoblingssamtykke for følgende formål.

1. Til å informere brukere om datakildene som appen har tilgang til.

2. Til å skissere handlingene en kobling kan utføre i en app eller ikke. Dette kan for eksempel være følgende for apper som bruker Office 365 Users-koblingen:

   • Denne appen kan gjøre følgende:
     • Les den fullstendige brukerprofilen din
     • Les den fullstendige profilen til alle brukere
   • Den kan ikke:
     • Endre eller slette all brukerprofilinformasjon

3. For å fange opp sluttbrukerens samtykke til å koble til datakildene som appen bruker.

4. For å muliggjøre manuell sluttbrukergodkjenning når det er nødvendig.

For noen koblinger kan Power Platform automatisk godkjenne en bruker for å få tilgang til datakilde. Hvis den automatiske påloggingen imidlertid mislykkes, ber denne dialogen brukerne om å rette en tilkobling ved å logge på manuelt. Power Platform kan bare prøve automatisk pålogging for en tilkobling når en datakilde forhåndsautoriserer Microsofts tjenestekontohaver for Azure API-tilkoblinger, og gir den tillatelse til å utføre enkel pålogging for en bruker når en tilkobling opprettes. Hvis du vil ha mer informasjon om enkel pålogging, kan du se Hva er enkel pålogging (SSO)?

Merk at for modelldrevne apper som bruker egendefinerte sider, og når det finnes flere egendefinerte sider i en app, ber samtykkedialogen om datatillatelser for alle koblingene på alle de egendefinerte sidene, selv om de ikke er åpnet ennå.

Bildet nedenfor er et eksempel på dialogen om tilkoblingssamtykke for en app som kobler til et SharePoint-område.

For utvalgte koblinger kan administratorer hindre denne dialogen og samtykke på vegne av sluttbrukere om å koble til en datakilde. Tabellen nedenfor forklarer hvilke koblingstyper som dialogen med samtykke kan bli undertrykt for en app.

Obs!

Hvis en administrator ikke godtar dialogen om samtykke, men plattformen ikke kan utføre enkel pålogging for en sluttbruker, vises dialogen for brukeren når appen startes.

Koblingstype	Er samtykkedialogen undertrykket?	Referanse
Koblinger fra Microsoft som støtter enkel pålogging (for eksempel SharePoint, Office 365-brukere)	Ja	Cmdleten for Power Apps-administrator
Kobling for tilgang til en ikke-Microsoft, tredjepartstjeneste, som SalesForce	Nei	Ikke aktuelt
Egendefinerte koblinger som bruker OAuth med Microsoft Entra ID som identitetsleverandør. Dette er egendefinerte koblinger som er bygd av organisasjoner, og de er bare tilgjengelige for brukere i organisasjonen (for eksempel bygd av Contoso bare for Contoso-brukere)	Ja	Administrere tilkoblinger

Microsoft Power Platform kan bare hindre dialogen med samtykke for tilkoblinger til datakilder der:

1. Brukeren har ikke plikt av datakilden til å vise et grensesnitt for eksplisitt samtykke.
2. Datakilden forhåndsautoriserer Microsofts kontoinnehaver for Azure API-koblinger til å aktivere enkel pålogging.
3. En administrator konfigurerer en app for å hindre samtykke for de foregående tilkoblingene.

Forhåndsgodkjenningen av Microsofts kontohaver for Azure API-tilkoblinger finnes for Microsofts førstepartsdatakilder, og kan konfigureres av egendefinerte programmer som er registrert i en leier som brukes av egendefinerte Microsoft Entra-koblinger. En administrator administrerer samtykkedemping per app-basis (i motsetning til kontaktbasis) slik at undertrykking administreres på det mest detaljerte apperfaringsnivået dette detaljnivået hindrer at samtykkedemping for en organisasjons godkjente apper utilsiktet hindrer samtykke for apper som ikke er godkjent eller gjennomgått.

Obs!

Kan du fortelle oss om språkinnstillingene for dokumentasjonen? Ta en kort undersøkelse. (vær oppmerksom på at denne undersøkelsen er på engelsk)

Undersøkelsen tar rundt sju minutter. Det blir ikke samlet inn noen personopplysninger (personvernerklæring).