SAP Fiori for S/4HANA: arkitektur og beste praksis

·
SAP FioriSAPUI5Neptune DXPODataCDS ViewsArkitektur

Fiori er en stack, ikke bare et UI

En vanlig misforståelse er at SAP Fiori er et design- og frontend-valg. I virkeligheten er Fiori en fullstendig applikasjonsarkitektur som spenner fra databaselaget i SAP til nettleseren hos sluttbrukeren. For å bygge Fiori-applikasjoner som faktisk fungerer bra i produksjon, må du forstå hele stacken.

Laget 1: Datamodellen – CDS Views

Core Data Services (CDS) er fundamentet for moderne SAP Fiori-utvikling. CDS Views definerer datamodellen som applikasjonen bruker, og de er der du bestemmer hvilke data som eksponeres til frontend.

Gode CDS Views er:

  • Avgrenset til det data-settet applikasjonen faktisk trenger (unngå SELECT *)
  • Godt annotert for OData-generering (Odata.publish: true for V2, eller @OData.entityType for V4)
  • Designet med tilgangskontroll i tankene (@AccessControl.authorizationCheck)
  • Ytelsesoptimalisert med riktige joins og nøkkel-strukturer

En vanlig feil er å bruke én stor CDS View som dekker alle behov – resulterer typisk i dårlig ytelse og tunge OData-kall.

Laget 2: OData-tjenesten

OData er RESTful API-protokollen SAP bruker for Fiori-integrasjon. Det finnes to versjoner i SAP-universet:

OData V2 er den etablerte standarden for eksisterende Fiori-applikasjoner. Genereres direkte fra CDS Views med ABAP MBC (Model Business Context) eller via SEGW-transaksjonen i klassisk utvikling.

OData V4 er den nyere og mer kapable versjonen, brukt i RAP-baserte applikasjoner og for mer komplekse applikasjonsscenarier med batch-operasjoner og binære data.

For nye applikasjoner anbefaler vi OData V4 via RAP. For vedlikehold av eksisterende løsninger holder V2.

Laget 3: ABAP-forretningslogikken

Uansett om du bruker SAPUI5 eller Neptune DXP i frontend, trenger du solid ABAP-backend. I RAP-modellen er forretningslogikken implementert i ABAP-klasser som følger RAP's Behaviour Definition:

  • Validations: Sjekker at data er korrekt
  • Determinations: Beregner avledede verdier automatisk
  • Actions: Eksponerer eksplisitte forretningsoperasjoner
  • Side Effects: Oppdaterer relaterte data ved endring

Denne strukturen er langt mer testbar og maintainable enn klassisk ABAP-kode som blander presentasjonslogikk og forretningslogikk.

Laget 4: Frontend-valget – SAPUI5 eller Neptune DXP?

Dette er valget mange stiller spørsmål om. Her er vår praktiske guide:

Velg SAPUI5 når:

  • Applikasjonen er tett integrert i SAP Fiori Launchpad
  • Du bruker Fiori Elements-templater og vil ha standard SAP-look-and-feel
  • Du har et team med sterk JavaScript og SAPUI5-kompetanse
  • Du trenger maksimal kontroll over Fiori-skjermbilder og -navigasjon

Velg Neptune DXP når:

  • Applikasjonen trenger offline-kapabilitet (feltoperasjoner, logistikk)
  • Du skal rulle ut til mobile enheter som native app
  • Du ønsker raskere utviklingstid med Neptune's visual designer
  • Applikasjonen trenger integrasjon mot flere datakilder (SAP + REST-tjenester)

En tredje vei: Fiori Elements Fiori Elements er SAPs tilnærming til "less-code Fiori" – en samling pre-bygde applikasjonstyper (List Report, Object Page, Worklist etc.) som genererer Fiori-applikasjoner automatisk fra OData-annotasjoner. Fiori Elements er riktig valg for applikasjoner med standard UI-mønstre, da det gir raskest utvikling og best kompatibilitet med SAP-oppdateringer.

Praktisk anbefaling for et norsk SAP-team

Start alltid med å sjekke om det finnes en standard SAP Fiori-app som dekker behovet. SAP leverer over 2000 standard Fiori-apper – mange norske organisasjoner er ikke klar over hvor mye som faktisk finnes. Bruk den standard appen, konfigurer og tilpass via SAP-godkjente utvidelsespunkter, og bygg skreddersydde løsninger kun for de prosessene der standard ikke strekker til.

Artikkelen er skrevet av

Nicolay Aarstad Wildhagen

Daglig leder – SAP-utvikler

LinkedIn-profil

Interessert i å ta SAP-prosjektet Viidre?