Integrasjon til Severa
Når du begynner å lage en integrasjon til Severa, er det viktig å ta hensyn til den tekniske siden i tillegg til integrasjonens funksjonalitet: hvor og hvordan integrasjonen skal kjøres, hvordan den kan testes og hvordan man kan få informasjon om hva som skjer når integrasjonen er i gang. Integrasjonen kan bygges med den teknologien du velger, og Severa gir ikke støtte for den valgte teknologien.
Planlegge integrasjonen
Integrasjonen til Severa må bygges slik at den ikke kontinuerlig spør Severas REST API om det er ny informasjon tilgjengelig. Integrasjonen bør kjøres planlagt, og når du definerer tidsplanen, bør du ta hensyn til følgende:
- Hvilken informasjon overfører integrasjonen?
- Trenger hver type informasjon å overføres med samme tidsplan, eller kan noen overføres oftere enn andre?
- Er det avhengigheter i dataene som påvirker informasjonen som skal overføres?
- Hva er den forretningsmessige behovet for integrasjonen, hvilke forretningskrav er det for overføringen? Det er viktig at integrasjonen tjener sitt formål i henhold til tidsplanen for informasjonen som bedriften trenger. For eksempel: Overføring av fravær til lønnssystemet kan gjøres én gang i uken, men fakturaer som skal sendes bør overføres én gang om dagen.
- Hvis integrasjonens overføringer må gjøres flere ganger om dagen, bør integrasjonen ikke være i gang oftere enn én gang i timen.
- Ikke bygg en integrasjon der hovedlogikken er en løkke som gjentas umiddelbart etter at den er avsluttet uten noen form for tidsplan.
Testing av integrasjonen
Når integrasjonen utvikles, må den testes mot Severas secure-test-miljø. Når integrasjonen har vist seg å fungere uten problemer, kan den byttes til å fungere mot produksjon. Mer informasjon: Hvordan komme i gang med REST API?
Når endringer gjøres i en eksisterende integrasjon, må de testes mot secure-test-miljøet. Integrasjonen må aldri publiseres direkte til produksjon. Dette sikrer at kundens data ikke blir skadet hvis det er problemer med integrasjonen. Inkluder følgende i integrasjonstesten:
- Kjøring av integrasjonen med testdata mot secure-test-miljøet.
- Manuelle endringer i dataene både i Severa og i andre integrerte programmer og sørge for at overføringen er korrekt.
- Tilstrekkelig antall testtilfeller for å dekke hele integrasjonens funksjonalitet. I tillegg bør det være variasjoner i testdataene for å dekke scenariene omfattende.
- Regresjonstesting av hele integrasjonens funksjonalitet hver gang endringene er store nok til å kreve full regresjon.
- Vurder også å inkludere tidligere problemer i testplanen for å sikre at de ikke gjentar seg.
Konfigurering av integrasjonen
Vanligvis trenger integrasjoner forskjellige parametere for å fungere problemfritt. Vanlige parametere inkluderer for eksempel:
- Severa API URL: Forteller hvor API-en befinner seg. Integrasjonen må kanskje kjøres mot secure-test.severa.com eller secure.severa.com Severa-miljøet.
- Klientens legitimasjon: Hvilke klientens legitimasjon og passord som brukes i integrasjonen.
- Ulike parametere som trengs for å få riktig informasjon fra API-en. For eksempel "bruk dette fakturastatusnavnet for å få fakturaer fra Severa".
- Ulike standardverdier som trengs for at integrasjonen skal fungere i alle scenarier. For eksempel "bruk denne produktkoden når produktkoden ikke er tilgjengelig", eller "bruk denne personen som standardveileder hvis ingen annen bruker er tilgjengelig".
- Tidsstempler for siste datainnhenting som brukes ved neste kjøring av integrasjonen. For eksempel ved bruk av "GetCasesChangedSince"-metoden, må tiden for forrige kjøring lagres et sted, og konfigurasjonen bør kunne endres automatisk av integrasjonen og manuelt av brukeren.
- Datoer for API-versjon og entitetsskjema-versjon slik at integrasjonen kan sammenligne lagrede versjoner og API-versjoner ved hver kjøring og se om det er endringer.
- Konfigurasjoner som trengs for logging, som plasseringer av logger, e-postadresser som meldinger sendes til, og så videre.
Når integrasjonen håndterer data fra flere kunder, bør hver kunde ha separate konfigurasjoner for å unngå å lese feil konfigurasjon og forårsake problemer i integrasjonen.
Konfigurasjonene for integrasjonen bør være slik at de kan endres manuelt, fordi noen ganger må tidsstempler som er lagret i en feiltilstand endres til fortiden.
Feilhåndtering
Feilhåndtering i integrasjonen er avgjørende fordi integrasjoner berører kundens data, og disse dataene kan ikke enkelt gjenopprettes hvis integrasjonen har skadet dem. Når du gjør feilhåndtering, bør du vurdere og løse følgende høynivåspørsmål:
- Hvilke typer feil i integrasjonen bør stoppe integrasjonens kjøring?
- Hvilke typer feil kan oppstå slik at integrasjonen fortsetter normal drift?
- Hvor logges feilene?
- Hvem er ansvarlig for overvåking av feillogger?
- Hva gjøres når det oppstår en feil i integrasjonen og hvem gjør det?
Integrasjonsprogramvaren selv må kunne håndtere forskjellige feil som oppstår i programvaren. Alle feil bør fanges, det bør ikke være rom for ubehandlede unntak. Dette betyr at i tillegg til vanlig feilhåndtering, må programvaren også kunne håndtere alle typer feil som kan komme fra Severas REST API.
Logging
Logging er en av de viktigste tingene i integrasjonen, fordi i en feiltilstand må man kunne lese fra loggen hva integrasjonen har gjort på tidspunktet for feilen. Logging kan gjøres for eksempel:
- Til hendelsesloggen på serveren som kjører integrasjonen
- Til applikasjonens database
- Logging til e-post. Vær oppmerksom på at hvis logging gjøres til e-post, er ikke de sendte dataene sikre, da e-post er som et postkort som reiser på internett. Integrasjonen kan også generere mye loggdata, noe som kan gjøre e-post ubrukelig.
Logging bør gjøres minst på disse nivåene:
- Integrasjonens fremdrift må logges
- Feil må logges
Loggingen må ha tidsstempler for alle viktige operasjoner. Det er best hvis tidsstempelet har nøyaktighet på sekundet, fordi nøyaktighet på minuttet ofte er for stor, da overføringer skjer raskt.
Var dette svaret til hjelp? Ja Nei
Send feedback