OData i Dynamics 365 FO: En Komplet Guide

Integration er en afgørende del af moderne forretningssystemer, og Dynamics 365 Finance and Operations (D365FO) er ingen undtagelse. En af de mest almindelige metoder til at interagere med data i D365FO er gennem OData (Open Data Protocol). Denne protokol fungerer som en standardiseret bro mellem dit D365FO-miljø og eksterne applikationer, hvilket muliggør problemfri dataudveksling. Denne artikel giver en dybdegående gennemgang af, hvad OData er, hvordan det fungerer inden for D365FO, dets kernefunktioner, fordele og ulemper, samt hvordan man praktisk anvender det til at bygge robuste integrationer.

Hvad er OData og Data Entities?

For at forstå OData i D365FO er det vigtigt først at definere to centrale begreber: selve OData-protokollen og Data Entities, som protokollen interagerer med.

OData (Open Data Protocol) er en webprotokol baseret på REST (Representational State Transfer), designet til at skabe og forbruge data-API'er. Den standardiserer den måde, data forespørges og manipuleres på over internettet ved hjælp af almindelige HTTP-metoder. OData er bygget til at understøtte såkaldte CRUD-operationer, som står for:

• Create (Opret): Tilføjelse af nye data.
• Read (Læs): Hentning af eksisterende data.
• Update (Opdater): Ændring af eksisterende data.
• Delete (Slet): Fjernelse af data.

Protokollen anvender standard webteknologier som HTTP og JSON (JavaScript Object Notation), hvilket gør den let at integrere med næsten enhver moderne applikation eller platform.

Data Entities i D365FO er en fundamental byggesten for integration. En Data Entity er en abstraktion over den fysiske databasestruktur. I stedet for at skulle arbejde direkte med komplekse, normaliserede databasetabeller, tilbyder en Data Entity en forenklet og de-normaliseret repræsentation af et forretningskoncept. For eksempel kan en 'Vendor' (Kreditor) Data Entity samle information fra flere forskellige tabeller (såsom kreditordetaljer, adresser, kontaktinformation) i én samlet, flad struktur. Dette gør det markant lettere for udviklere at læse og skrive data uden at skulle kende den underliggende, komplekse datamodel. Når en Data Entity i D365FO markeres som 'Public', bliver den automatisk tilgængelig som et OData-endpoint, klar til at blive brugt af eksterne systemer.

Kernefunktioner og Forespørgselsmuligheder i OData

OData's styrke ligger i dets rige sæt af forespørgselsmuligheder, der giver klienter mulighed for at forme og filtrere data direkte i URL'en. Dette minimerer mængden af data, der sendes over netværket, og reducerer behandlingen på klientsiden. D365FO understøtter en række standard OData-query options.

CRUD-operationer via HTTP-verber

OData mapper CRUD-operationer direkte til HTTP-metoder:

• POST: Anvendes til at oprette en ny post (Create).
• GET: Anvendes til at læse data (Read).
• PATCH/PUT: Anvendes til at opdatere en eksisterende post (Update). PATCH opdaterer kun de specificerede felter, mens PUT erstatter hele posten.
• DELETE: Anvendes til at slette en post (Delete).

System Query Options

Disse optioner tilføjes som parametre til URL'en for at manipulere det returnerede datasæt.

Praktisk Anvendelse: Opsætning og Autentificering

For at kunne kommunikere med D365FO's OData-endpoints skal en ekstern applikation først autentificeres. Dette sker via Azure Active Directory (AAD), som fungerer som identitetsudbyder for D365FO.

Trin til Autentificering

1. Registrer en applikation i Azure AD: Først skal du oprette en ny app-registrering i din Azure AD-tenant. Denne registrering vil give dig et 'Application (client) ID' og mulighed for at oprette en 'Client Secret'. Disse to værdier fungerer som applikationens brugernavn og adgangskode.
2. Giv adgang til D365FO: I Azure AD skal du give den registrerede applikation tilladelse til at tilgå Dynamics ERP API'en.
3. Registrer AAD-applikationen i D365FO: Gå til Systemadministration > Opsætning > Azure Active Directory-applikationer i D365FO. Her skal du tilføje dit 'Application ID' fra Azure AD og tildele det en D365FO-bruger. De tilladelser, applikationen har, vil være de samme som den tildelte brugers.

Når opsætningen er fuldført, kan din applikation anmode om et adgangstoken fra Azure AD. Dette gøres ved at sende en POST-forespørgsel til AAD's token-endpoint med dit client ID, client secret og D365FO-miljøets URL som 'resource'. Det returnerede adgangstoken skal derefter inkluderes som et 'Bearer token' i 'Authorization'-headeren på alle efterfølgende OData-kald.

Forespørgsler på tværs af selskaber (Cross-Company)

Som standard returnerer en OData-forespørgsel kun data fra den brugerdefinerede standardvirksomhed. For at hente data fra alle virksomheder, som brugeren har adgang til, skal du tilføje parameteren ?cross-company=true til din URL. Hvis du ønsker at filtrere på en specifik virksomhed, der ikke er din standard, kan du kombinere dette med et $filter på feltet dataAreaId.

Eksempel: https://[baseURI]/data/CustomersV3?$filter=dataAreaId eq 'usmf'&cross-company=true

Fordele og Ulemper ved at bruge OData

Selvom OData er et kraftfuldt værktøj, er det ikke altid den bedste løsning til alle integrationsscenarier. Det er vigtigt at kende både styrkerne og svaghederne.

Fordele

• Standardiseret og åbent: Som en åben protokol er OData bredt understøttet og let at implementere i mange forskellige teknologier.
• Nem at bruge: Den REST-baserede tilgang og de simple query options gør det hurtigt at komme i gang med simple dataoperationer.
• Klar til brug med tredjepartssoftware: Værktøjer som Microsoft Power BI, Excel og mange andre kan direkte forbinde til D365FO's OData-endpoints uden behov for kodning.
• Fleksible forespørgsler: Klienten har fuld kontrol over, hvilke data der hentes, hvilket kan optimere ydeevnen ved at reducere datamængden.

Ulemper

• Ydeevne: OData kan være langsom, især når man arbejder med store mængder data. Hver forespørgsel behandles interaktivt, hvilket kan belaste serveren. Det er ikke designet til bulk-operationer.
• Begrænset til simpel forretningslogik: OData er bedst til simple CRUD-operationer. Kompleks forretningslogik, valideringer eller operationer, der involverer flere trin, er svære at implementere. I sådanne tilfælde skal logikken ofte placeres i klientapplikationen.
• Ikke egnet til store datamængder: Til integration af store datasæt er andre metoder som Data Management Framework (DMF) langt mere effektive. OData har en sidebegrænsning (typisk 1.000 poster pr. kald), hvilket kræver paginering for større resultatsæt.

Alternativer til OData-integration

Afhængigt af dine behov findes der flere andre integrationsmetoder i D365FO:

Ofte Stillede Spørgsmål (OSS)

Hvad er den største begrænsning ved at bruge OData med D365FO?

Den primære begrænsning er ydeevnen. OData er ikke optimeret til store datamængder eller komplekse forespørgsler og kan blive en flaskehals i performance-kritiske scenarier.

Kan jeg bruge OData til at overføre tusindvis af poster på én gang?

Det er ikke anbefalet. OData er bedst til interaktive, mindre forespørgsler. Til bulk-dataoverførsler bør du bruge Data Management Framework (DMF) for at opnå bedre ydeevne og stabilitet.

Er det nødvendigt at være udvikler for at bruge OData?

For simple dataudtræk i værktøjer som Power BI eller Excel kræves der ingen kodning. Men for at bygge en egentlig applikationsintegration, der håndterer autentificering og udfører CRUD-operationer, er programmeringskendskab (f.eks. i C#) nødvendigt.

Hvordan fungerer OData med D365FO's sikkerhedsmodel?

OData respekterer fuldt ud D365FO's sikkerhedsroller og -tilladelser. Den bruger, der er knyttet til AAD-applikationen, bestemmer, hvilke data og operationer applikationen har adgang til. Hvis brugeren ikke har tilladelse til at se en bestemt Data Entity, vil OData-kaldet fejle.

Konklusion

OData er en essentiel og tilgængelig teknologi for integration med Dynamics 365 Finance and Operations. Den tilbyder en standardiseret, REST-baseret metode til at udføre grundlæggende dataoperationer, hvilket gør den ideel til simple integrationer, ad-hoc dataudtræk og forbindelse til OData-klare applikationer. Men det er afgørende at forstå dens begrænsninger, især med hensyn til ydeevne og håndtering af kompleks logik. Ved at vælge det rigtige integrationsværktøj til opgaven – hvad enten det er OData for enkelhedens skyld eller DMF for volumen – kan du sikre, at dine D365FO-integrationer er både effektive og robuste.