Del via

TripPin del 2 – datakobling for en REST-tjeneste

  • Artikkel

Denne flerdelte opplæringen dekker opprettelsen av en ny datakildeutvidelse for Power Query. Opplæringen er ment å gjøres sekvensielt – hver leksjon bygger på koblingen som er opprettet i tidligere leksjoner, og legger trinnvis til nye funksjoner i koblingen.

I denne leksjonen vil du:

  • Opprett en basisfunksjon som kaller opp en REST-API ved hjelp av Web.Contents
  • Finn ut hvordan du angir forespørselshoder og behandler et JSON-svar
  • Bruk Power BI Desktop til å vri svaret til et brukervennlig format

Denne leksjonen konverterer den OData-baserte koblingen for TripPin-tjenesten (opprettet i forrige leksjon) til en kobling som ligner noe du ville opprettet for alle RESTful API-er. OData er en RESTful API, men en med et fast sett med konvensjoner. Fordelen med OData er at det gir et skjema, datahentingsprotokoll og standard spørringsspråk. Hvis vi tar bort bruken av OData.Feed , må vi bygge disse funksjonene inn i koblingen selv.

Oppsummering av OData-koblingen

Før du fjerner OData-funksjonene fra koblingen, kan vi gjøre en rask gjennomgang av hva den gjør (for det meste bak kulissene) for å hente data fra tjenesten.

Åpne TripPin-utvidelsesprosjektet fra del 1 i Visual Studio Code. Åpne spørringsfilen og lim inn i følgende spørring:

TripPin.Feed("https://services.odata.org/v4/TripPinService/Me")

Åpne Fiddler, og evaluer deretter gjeldende Power Query-fil i Visual Studio Code.

I Fiddler er det tre forespørsler til serveren:

Fiddler OData-forespørsler.

  • /Me– den faktiske URL-adressen du ber om.
  • /$metadata– et anrop som utføres automatisk av OData.Feed funksjonen for å bestemme skjema og skrive inn informasjon om svaret.
  • /Me/BestFriend– ett av feltene som ble (ivrig) trukket da du oppførte /Me singleton. I dette tilfellet resulterte samtalen i en 204 No Content status.

M evaluering er for det meste lat. I de fleste tilfeller hentes bare dataverdier/hentes når de er nødvendige. Det finnes scenarioer (for eksempel /Me/BestFriend-saken) der en verdi trekkes ivrig. Dette har en tendens til å skje når typeinformasjon er nødvendig for et medlem, og motoren har ingen annen måte å bestemme typen på enn å hente verdien og undersøke den. Å gjøre ting lat (det vil eksempelvis unngå ivrige trekk) er en av de viktigste aspektene ved å lage en M-koblingsantrekker.

Legg merke til forespørselshodene som ble sendt sammen med forespørslene og JSON-formatet for svaret på /Me-forespørselen.

{
  "@odata.context": "https://services.odata.org/v4/TripPinService/$metadata#Me",
  "UserName": "aprilcline",
  "FirstName": "April",
  "LastName": "Cline",
  "MiddleName": null,
  "Gender": "Female",
  "Age": null,
  "Emails": [ "April@example.com", "April@contoso.com" ],
  "FavoriteFeature": "Feature1",
  "Features": [ ],
  "AddressInfo": [
    {
      "Address": "P.O. Box 555",
      "City": {
        "Name": "Lander",
        "CountryRegion": "United States",
        "Region": "WY"
      }
    }
  ],
  "HomeAddress": null
}

Når spørringen er ferdig med evalueringen, skal PQTest-resultatvinduet vise postverdien for Me singleton.

OData-resultater.

Hvis du sammenligner feltene i utdatavinduet med feltene som returneres i det rå JSON-svaret, ser du en mismatch. Spørringsresultatet har andre felt (Friends, Trips, GetFriendsTrips) som ikke vises noe sted i JSON-svaret. OData.Feed-funksjonen tilføyde automatisk disse feltene til posten basert på skjemaet som returneres av $metadata. Dette er et godt eksempel på hvordan en kobling kan øke og/eller formatere svaret fra tjenesten på nytt for å gi en bedre brukeropplevelse.

Opprette en grunnleggende REST-kobling

Nå skal du legge til en ny eksportert funksjon i koblingen som kaller Web.Contents.

Hvis du vil kunne foreta vellykkede nettforespørsler til OData-tjenesten, må du imidlertid angi noen standard OData-overskrifter. Du gjør dette ved å definere et felles sett med overskrifter som en ny variabel i koblingen:

DefaultRequestHeaders = [
    #"Accept" = "application/json;odata.metadata=minimal",  // column name and values only
    #"OData-MaxVersion" = "4.0"                             // we only support v4
];

Du endrer implementeringen av TripPin.Feed funksjonen slik at den i stedet for å bruke OData.Feed, bruker Web.Contents til å foreta en nettforespørsel, og analyserer resultatet som et JSON-dokument.

TripPinImpl = (url as text) =>
    let
        source = Web.Contents(url, [ Headers = DefaultRequestHeaders ]),
        json = Json.Document(source)
    in
        json;

Husk å bygge koblingen nå som du har gjort endringer i koblingsfilen. Deretter kan du evaluere spørringsfilen (TripPin.query.pq). Resultatet av /Me-posten ligner nå på den rå JSON-en du så i Fiddler-forespørselen.

Hvis du ser fiddler når du kjører den nye funksjonen, vil du også legge merke til at evalueringen nå gjør én enkelt nettforespørsel, i stedet for tre. Gratulerer – du har oppnådd en ytelsesøkning på 300 %! Du har nå mistet all type- og skjemainformasjon, men det er ikke nødvendig å fokusere på den delen ennå.

Oppdater spørringen for å få tilgang til noen av TripPin-enhetene/-tabellene, for eksempel:

  • https://services.odata.org/v4/TripPinService/Airlines
  • https://services.odata.org/v4/TripPinService/Airports
  • https://services.odata.org/v4/TripPinService/Me/Trips

Du vil legge merke til at banene som brukes til å returnere pent formaterte tabeller, nå returnerer et verdifelt på øverste nivå med en innebygd [Liste]. Du må gjøre noen transformasjoner på resultatet for å gjøre det brukbart for scenarioer for sluttbrukerforbruk.

Listeresultater.

Redigere transformasjoner i Power Query

Selv om det er mulig å redigere M-transformasjonene dine for hånd, foretrekker de fleste å bruke Power Query til å forme dataene sine. Du åpner utvidelsen i Power BI Desktop og bruker den til å utforme spørringer for å gjøre utdataene om til et mer brukervennlig format. Gjenoppbygg løsningen, kopier den nye filtypefilen til katalogen Egendefinerte data Koble til orer, og start Power BI Desktop på nytt.

Start en ny tom spørring, og lim inn følgende i formellinjen:

= TripPin.Feed("https://services.odata.org/v4/TripPinService/Airlines")

Pass på at du inkluderer = -tegnet.

Manipulere utdataene til det ser ut som den opprinnelige OData-feeden – en tabell med to kolonner: AirlineCode og Name.

Formaterte flyselskaper.

Den resulterende spørringen skal se omtrent slik ut:

let
    Source = TripPin.Feed("https://services.odata.org/v4/TripPinService/Airlines"),
    value = Source[value],
    toTable = Table.FromList(value, Splitter.SplitByNothing(), null, null, ExtraValues.Error),
    expand = Table.ExpandRecordColumn(toTable, "Column1", {"AirlineCode", "Name"}, {"AirlineCode", "Name"})
in
    expand

Gi spørringen et navn («Flyselskaper»).

Opprett en ny tom spørring. Denne gangen bruker du TripPin.Feed funksjonen til å få tilgang til /Airports-enheten. Bruk transformeringer til du får noe som ligner på delingen som vises nedenfor. Du finner også den samsvarende spørringen nedenfor– gi denne spørringen et navn («Flyplasser»).

Formaterte flyplasser.

let
    Source = TripPin.Feed("https://services.odata.org/v4/TripPinService/Airports"),
    value = Source[value],
    #"Converted to Table" = Table.FromList(value, Splitter.SplitByNothing(), null, null, ExtraValues.Error),
    #"Expanded Column1" = Table.ExpandRecordColumn(#"Converted to Table", "Column1", {"Name", "IcaoCode", "IataCode", "Location"}, {"Name", "IcaoCode", "IataCode", "Location"}),
    #"Expanded Location" = Table.ExpandRecordColumn(#"Expanded Column1", "Location", {"Address", "Loc", "City"}, {"Address", "Loc", "City"}),
    #"Expanded City" = Table.ExpandRecordColumn(#"Expanded Location", "City", {"Name", "CountryRegion", "Region"}, {"Name.1", "CountryRegion", "Region"}),
    #"Renamed Columns" = Table.RenameColumns(#"Expanded City",{{"Name.1", "City"}}),
    #"Expanded Loc" = Table.ExpandRecordColumn(#"Renamed Columns", "Loc", {"coordinates"}, {"coordinates"}),
    #"Added Custom" = Table.AddColumn(#"Expanded Loc", "Latitude", each [coordinates]{1}),
    #"Added Custom1" = Table.AddColumn(#"Added Custom", "Longitude", each [coordinates]{0}),
    #"Removed Columns" = Table.RemoveColumns(#"Added Custom1",{"coordinates"}),
    #"Changed Type" = Table.TransformColumnTypes(#"Removed Columns",{{"Name", type text}, {"IcaoCode", type text}, {"IataCode", type text}, {"Address", type text}, {"City", type text}, {"CountryRegion", type text}, {"Region", type text}, {"Latitude", type number}, {"Longitude", type number}})
in
    #"Changed Type"

Du kan gjenta denne prosessen for flere baner under tjenesten. Når du er klar, går du videre til neste trinn for å opprette en (mock) navigasjonstabell.

Simulere en navigasjonstabell

Nå skal du bygge en tabell (ved hjelp av M-kode) som presenterer de pent formaterte TripPin-enhetene dine.

Start en ny tom spørring, og få frem avansert redigering.

Lim inn i følgende spørring:

let
    source = #table({"Name", "Data"}, {
        { "Airlines", Airlines },
        { "Airports", Airports }
    })
in
    source

Hvis du ikke har angitt innstillingen for personvernnivåer til «Ignorer alltid innstillinger for personvernnivå» (også kalt «Rask kombinering»), ser du en ledetekst om personvern.

Brannmur.

Personvernmeldinger vises når du kombinerer data fra flere kilder og ennå ikke har angitt et personvernnivå for én eller flere kilder. Velg Fortsett-knappen, og angi personvernnivået for den øverste kilden til Offentlig.

Personvern.

Velg Lagre , og tabellen vises. Selv om dette ikke er en navigasjonstabell ennå, gir den den grunnleggende funksjonaliteten du trenger for å gjøre den om til én i en senere leksjon.

FakeNav.

Datakombinasjonskontroller forekommer ikke når du får tilgang til flere datakilder fra en utvidelse. Siden alle datakildekall fra utvidelsen arver den samme godkjenningskonteksten, antas det at de er «trygge» å kombinere. Utvidelsen vil alltid bli behandlet som én enkelt datakilde når det gjelder datakombinasjonsregler. Brukere vil fortsatt motta vanlige spørsmål om personvern når de kombinerer kilden med andre M-kilder.

Hvis du kjører Fiddler og velger Oppdater forhåndsvisning-knappen i Power Query-redigering, noterer du de separate nettforespørslene for hvert element i navigasjonstabellen. Dette indikerer at en ivrig evaluering skjer, noe som ikke er ideelt når du bygger navigasjonstabeller med mange elementer. Etterfølgende leksjoner viser hvordan du bygger en riktig navigasjonstabell som støtter lat evaluering.

Konklusjon

Denne leksjonen viste deg hvordan du bygger en enkel kobling for en REST-tjeneste. I dette tilfellet har du gjort om en eksisterende OData-utvidelse til en standard REST-utvidelse (ved hjelp av Web.Contents), men de samme konseptene gjelder hvis du opprettet en ny utvidelse fra grunnen av.

I neste leksjon tar du spørringene som er opprettet i denne leksjonen ved hjelp av Power BI Desktop, og gjør dem om til en ekte navigasjonstabell i utvidelsen.

Neste trinn

TripPin Del 3 - Navigasjonstabeller