Domenemodellering i SAP CAP

Introduksjon

En domenemodell i SAP CAP er en modell som beskriver de statiske, datarelaterte aspektene ved et problemdomene i form av enhetsrelasjonsmodeller. I denne artikkelen vil vi studere domenemodellering i SAP CAP i detalj.

Domenemodellering

Med enkle ord, en CDS i SAP CAP produserer domenemodell på en slik måte at den definerer forretningsproblemet i form av nøkler, felt og merknader. Koden for å generere en domenemodell er skrevet i et CDS-skjema (db/schema.cds). Disse domenemodellene kan brukes i tjenestedefinisjoner, persistensmodeller, databaser eller til og med gjenbrukes innenfor en annen domenemodell.

Eksempeleksempel:

Navneområde empInfo; bruker {Currency, managed} fra '@sap/cds/common'; enhet Ansatte: administrert { nøkkel-ID: heltall; fornavn: lokalisert streng (111); etternavn: lokalisert streng (1111); leder: Tilknytning til ledere; DateofJoining: Heltall; lønn: Desimal (9,2); valuta: Valuta; }

 

I dette eksemplet har vi laget en fil schema.cds der vi har opprettet en enhet Ansatte som inkluderer grunnleggende detaljer om en ansatt

Hele dette skjemaet har fått et navneområde, dvs. empInfo

Dette skjemaet bruker en standard datatype, dvs. valuta. Å bruke standarddatatypen som dette hjelper oss med å bringe alle forhåndsdefinerte verdihjelpene knyttet til den.

Vi bruker CDS for å lage en modell. I den CDSen bruker vi

  1. Entiteter for å representere sett med unike objekter, f.eks.
    1. Grunnleggende informasjon om ansatte
    2. Kommunikasjonsinformasjon for ansatte
    3. Informasjon om ansattes lønn
  2. Assosiasjoner for å definere relasjoner
    1. Ledertilknytning til en annen enhetsleder som vil ha alle ledere-listen

Navnekonvensjon og anbefalinger

  1. Navnet på enheten skal starte med stor bokstav, og det skal være lesbart og selvforklarende – for eksempel ansatte
  2. Start elementer med en liten bokstav – for eksempel fornavn
  3. Det anbefales å bruke flertallsform av enheter – for eksempel ansatte
  4. Det anbefales å bruke entallsform av typer - for eksempel valuta
  5. ikke gjenta kontekster – for eksempel Employees.name i stedet for Employees.EmployeeName
  6. foretrekker navn på ett ord – for eksempel lønn i stedet for lønnBeløp
  7. bruk ID for tekniske primærnøkler – for eksempel ID for medarbeider-ID
  8. Du kan bruke navneområde for å gjøre enhetene dine unike. Det er som klientkonsept i SAP hvor du kan ha dupliserte skjemaer (cd-filer) med unikt navneområde for å skille dem. Navneområder er valgfrie, bruk navnerom hvis modellene dine kan bli gjenbrukt i andre prosjekter. På slutten av dagen er de bare prefikser, som automatisk brukes på alle relevante navn i en fil. - for eksempel,

navneområde bærbar datamaskin;enhet Dell {}

...tilsvarer:

entity laptop.Dell {}

  1. Du kan bruke kontekster for nestede navneromsseksjoner. - for eksempel,

navneområde bærbar datamaskin;enhet Dell {}           //> bærbar PC.Dellkontekst Apple { enhet MacBookPro {}       //> bærbar PC.Apple.MacBookPro     enhet MacBookAir {} }

 

enheter

Entiteter er som tabeller med primærnøkler. Vi kan utføre CRUD-operasjoner ved å bruke disse enhetene. Hold den så flat som mulig. Ikke overnormaliser det. Ikke bruk ikke-gjenbrukbare typer. Denne delen er kun for modellering, kun merknader relatert til individuelle felt skal legges til og ingen tekniske detaljer (logikk) skal legges til.

Typer

Typer er som domene i SAP ABAP, det pleide å definere type dataelementer.

aspekter

Aspekter er utvidelsene av modellene og brukes hovedsakelig til å utvide eksisterende definisjoner og merknader. Når en modell er definert, kan vi bruke forskjellige cd-filer (Aspect) for å legge til merknader på toppen av dem for en spesifikk oppgave.

For eksempel-

  • cds– din kjernedomenemodell, holdt ren, enkel og forståelig
  • revisjonsmodell.cd-er– legger til flere felt som kreves for revisjon i en fil
  • auth-model.cds– legger til merknader for autorisasjon.

Primære nøkler

I likhet med tabeller og CDS i SAP ABAP vedlikeholder vi primærnøkler for enheten ved å bruke nøkkelord nøkkel.

En primærnøkkel kan gjenbrukes på tvers av modellen ved å bruke metodikken til vanlige definisjoner.

Vi kan lage en common.cds-modell der alle vanlige definisjoner kan lagres.

// vanlige definisjoner

enhet StandardEntity { nøkkel-ID: UUID; } Nå kan disse vanlige definisjonene gjenbrukes som nedenfor: ved å bruke { StandardEntity } fra './common'; enhet Ansatt: StandardEntity { navn: String; ... } entity Manager : StandardEntity { name : String; ... }

 

Den vanlige filen er allerede opprettet som standard med en forhåndsdefinert enhet kalt cuid.

Kartlegging av UUID-er til OData

CDS tilordner UUID-er til Edm.Guid, som standard, i alle OData-modellene. OData-standarden setter imidlertid opp restriktive regler for Edm.Guid-verdier – for eksempel er bare bindestreker tillatt – som kan komme i konflikt med eksisterende data. Derfor tillater vi at standardtilordningen overstyres som følger:

entity Books {

nøkkel-ID : UUID @odata.Type:'Edm.String';

...

}

Om nødvendig kan du også legge til merknaden @odata.MaxLength for å overstyre den tilsvarende egenskapen.

Association

Det brukes til å definere forholdet mellom to enheter. Som ABAP CDS bruker vi også her ordet Assosiasjon. Her er nøkkelordet mange indikerer a 0..* kardinalitet. Begrensningene for kardinalitet kan legges til som en begrensning (hvor betingelse) – for eksempel ved å bruke ikke null.

komposisjoner

I motsetning til Association hvor vi assosierer et enhetsfelt med objektene til en hel enhet, refererer komposisjonene bare til et spesifikt felt til en annen enhet. Den har ekstra fordel med selvstyrte dype operasjoner (Insert/Update) og kaskadedelt sletting (Sletting av multiavhengig tabell).

// Definer bestillinger med inneholdte ordreelementerentity Orders { key ID : UUID; Varer : Sammensetning av mange Order_Items på Items.parent=$self;}entity Order_Items { // skal kun nås via bestillinger  nøkkelforelder : Tilknytning til bestillinger; nøkkelbok : Association to Books; mengde: Heltall;}

Beste praksis

  1. Ikke legg til tekniske detaljer i Modeller, vi bruker aspekterfor det
  2. Bruk korte navn og enkle flate modeller
  3. Ikke overnormaliser enhetene i modeller
  4. Bruk lokale heltallssekvenser hvis du virkelig håndterer høye belastninger og volumer. Ellers, foretrekk UUID-er

Til nå hva vi har lært: Skapelse av modell og aspekter på toppen av det.

Domenemodellering i SAP CAP

Legg igjen en kommentar

Dette nettstedet bruker Akismet for å redusere spam. Lær hvordan kommentaren din behandles.