Bakgrunn: 4000+ enheter i felt
I løpet av de siste årene har vi designet, bygget og deployert Neptune DXP SAP Edition-applikasjoner som samlet sett kjører på over 4000 enheter i produksjonsmiljøer. Miljøene inkluderer lageroperasjoner med rugget Android-håndterminaler, felttjeneste-operatører med nettbrett, og kontrollroms-personell med stasjonære enheter.
Denne erfaringen har gitt oss et veldig konkret bilde av hva Neptune DXP gjør bra, hva som krever ekstra oppmerksomhet, og hvilke arkitekturbeslutninger som skiller prosjekter som lykkes fra de som ikke gjør det.
## Hva vi alltid gjør fra start
Definer offline-scopet eksplisitt. Den aller viktigste beslutningen i et Neptune offline-prosjekt er: hvilke data skal være tilgjengelige offline? Dette er ikke en teknisk beslutning – det er en forretningsbeslutning som prosesseierne må ta. Data som ikke er inkludert i offline-scopet, er ikke tilgjengelig når nettverket er nede. Brukerne vil forsøke å gjøre operasjoner som mislykkes fordi de mangler data.
Vi bruker alltid et par møter med prosesseierne på å gå gjennom alle scenariene og bestemme explicit hva som er in-scope og out-of-scope for offline-drift.
Design for worst-case nettverk. Test ikke applikasjonen med god WiFi – test den med 2G-mobilnett og sporadisk tilkobling. Applikasjoner som fungerer på kontor-WiFi kan vise seg å ha alvorlige synkroniseringsproblemer i felt der forbindelsen er ustabil.
Delta-synkronisering er ikke opsjonelt. For datasets over noen hundre elementer er full synkronisering ved innlogging for treg. Vi designer alltid delta-synkronisering fra start: ved oppstart synkroniseres kun endringer siden siste synkronisering, ikke hele datasettet.
## De vanligste utfordringene i praksis
Utfordring 1: Konflikter ved gjenoppretting
Scenario: To lageroperatører jobber offline og begge reserverer samme varelager for ulike formål. Når de begge synkroniserer, har du en konflikt.
Vi løser dette ved å definere eksplisitte forretningsregler for konflikthåndtering – typisk "sist registrert vinner" for enkle transaksjoner, eller "flagger for manuell gjennomgang" for kritiske transaksjoner der feil er alvorlig. Disse reglene implementeres i Neptune backend og i SAP ABAP-laget.
### Utfordring 2: Enhetssvikt og tap av usynkronisert data
Scenario: En enhet mister batteri eller krasjer før synkronisering er fullført. Dataen er tapt.
Vi designet alltid applikasjonen slik at den synkroniserer hyppig (ved avslutning av hver transaksjon, ikke bare ved innlogging/utlogging) og gir brukerne klar informasjon om synkroniseringsstatus. For kritiske transaksjoner bruker vi optimistisk synkronisering der de sendes til server umiddelbart, men fortsetter å fungere offline hvis serveren ikke er tilgjengelig.
### Utfordring 3: SAP-ytelse under høy synkroniseringsbelastning
Scenario: 500 enheter prøver alle å synkronisere mot SAP-systemet mellom klokken 06:00 og 07:00 når dagvakten starter.
Vi planlegger alltid synkroniseringsarkitekturen for topp-last og implementerer rate limiting og queue-basert synkronisering der det er nødvendig. SAP-systemet bør konfigureres med dedikerte dialog Work Processes for synkroniserings-API-er slik at heavy synkroniseringslast ikke fortrenger andre brukere.
## Hva Neptune DXP gjør bedre enn alternativene
Native app-pakking via Neptune App Store er ekstremt praktisk for enterprise-deployments. Vi kan konfigurere app-versjoner sentralt og pushe oppdateringer via MDM uten at operatørene trenger å gjøre noe. Sammenlignet med PWA-løsninger er dette langt mer robust for enterprise-skala.
Offline-datasynkronisering ut av boksen er Neptunes sterkeste kort. Alternativer som rene SAPUI5-løsninger krever betydelig tilleggsutvikling for å oppnå tilsvarende offline-funksjonalitet.
Visual designer gjør prototyping rask og gjør det mulig å involvere prosesseierne direkte i designprosessen. Vi bruker aktivt Neptune Designer i workshops med kunder for å validere arbeidsflyter.
## Konklusjon
Neptune DXP er vår foretrukne plattform for offline-kapable mobile SAP-applikasjoner, basert på konkret leveranseerfaring. Men offline SAP-utvikling er ikke enkelt – det krever nøye arkitekturplanlegging, tett samarbeid med prosesseierne om konflikthåndtering og dataomfang, og grundig testing i realistiske nettverksforhold.
De prosjektene som lykkes, starter med god arkitekturplanlegging. De som mislykkes, undervurderer kompleksiteten og forsøker å legge til offline-støtte som ettertanke.
Har du spørsmål til artikkelen?
Ta kontakt