Allmänna REST API-principer

Integration i Severa

När du börjar skapa en integration i Severa är det viktigt att ta hänsyn till den tekniska sidan av integrationen, förutom dess funktionalitet: var och hur integrationen kommer att köras, hur den kan testas och hur man får information om vad som händer när integrationen är igång. Du kan bygga integrationen med den teknik du väljer, och Severa ger inte stöd för den teknik du väljer.

Integrationens schemaläggning

Integration i Severa måste byggas så att den inte kontinuerligt frågar Severas REST API om ny information är tillgänglig. Integration bör köras schemalagt, och vid bestämning av schemat bör följande faktorer beaktas:

1. Vilken information överför integrationen?
2. Behöver varje typ av information överföras enligt samma schema, eller kan vissa överföras oftare än andra?
3. Finns det beroenden i informationen som påverkar den information som ska överföras?
4. Vad är det affärsmässiga behovet av integrationen, vilka affärskrav finns det för överföringen? Det är viktigt att integrationen tjänar sitt syfte enligt det schema som företaget behöver informationen. Till exempel: Överföring av frånvaro till lönehanteringssystemet kan göras en gång i veckan, men fakturor som ska skickas bör överföras en gång om dagen.
5. Om integrationens överföringar måste göras flera gånger om dagen, bör integrationen inte köras oftare än en gång i timmen.
6. Bygg inte en integration vars huvudsakliga logik är en loop som upprepas omedelbart efter att den har avslutats utan någon form av schemaläggning.

Integrationens testning

När integrationen utvecklas måste den testas mot Severas secure-test-miljö. När integrationen har bevisats fungera utan problem kan den bytas till att fungera mot produktion. Mer information: Kuinka päästä alkuun REST APIn kanssa?

När ändringar görs i en befintlig integration måste de testas mot secure-test-miljön. Integration får aldrig publiceras direkt till produktion. Detta säkerställer att kundens data inte skadas om det finns problem med integrationen. Inkludera följande i integrationens testning:

1. Kör integrationen med testdata mot secure-test-miljön.
2. Gör manuella ändringar i informationen både i Severa och i andra integrerade programvaror och säkerställ att överföringen är korrekt.
3. Tillräckligt antal testfall för att täcka hela integrationens funktionalitet. Dessutom bör testdata ha variationer för att täcka scenarier på ett mångsidigt sätt.
4. Regressionstestning av hela integrationens funktionalitet varje gång ändringarna är tillräckligt stora för att kräva en fullständig regression.
5. Överväg också att inkludera tidigare problem i testplanen för att säkerställa att de inte återkommer.

Integrationens konfiguration

Vanligtvis behöver integrationer olika parametrar för att fungera utan problem. Vanliga parametrar inkluderar:

• Severa API URL: Anger var API finns. Integration kan behöva köras mot secure-test.severa.com eller secure.severa.com Severa-miljö.
• Kundens uppgifter: Vilka kunduppgifter och lösenord som används i integrationen.
• Olika typer av parametrar som behövs för att få rätt information från API. Till exempel "använd detta fakturastatusnamn för att få fakturor från Severa".
• Olika typer av standardvärden som behövs för att integrationen ska fungera i alla scenarier. Till exempel "använd denna produktkod när produktkod inte är tillgänglig", eller "använd denna person som standardövervakare om ingen annan användare är tillgänglig".
• Tidsstämplar för senaste datahämtning som används vid nästa körning av integrationen. Till exempel vid användning av "GetCasesChangedSince"-metoden, måste tiden för den tidigare körningen sparas någonstans, och konfigurationen bör kunna ändras automatiskt av integrationen och manuellt av användaren.
• Datum för API-version och entitetsschemaversion så att integrationen vid varje körning kan jämföra sparade versioner och API-versioner och se om det finns ändringar.
• Konfigurationer som behövs för loggning, såsom loggplatser, e-postadresser till vilka meddelanden skickas, och så vidare.

När integrationen hanterar data från flera kunder bör varje kund ha separata konfigurationer för att undvika att fel konfiguration läses och problem uppstår i integrationen.

Integrationens konfigurationer bör vara sådana att de kan ändras manuellt, eftersom tidsstämplar som sparats vid fel ibland måste ändras till det förflutna.

Felhantering

Felhantering i integrationen är avgörande eftersom integrationer berör kundens data, och dessa data kan inte enkelt återställas om integrationen har skadat dem. Vid felhantering bör följande hög nivå frågor övervägas och lösas:

1. Vilka typer av fel i integrationen bör stoppa körningen av integrationen?
2. Vilka typer av fel kan inträffa så att integrationen fortsätter att fungera normalt?
3. Var loggas felen?
4. Vem ansvarar för övervakningen av felloggar?
5. Vad görs när ett fel uppstår i integrationen och vem gör det?

Integrationsprogramvaran själv måste kunna hantera olika fel som uppstår i programvaran. Alla fel bör fångas, det bör inte finnas utrymme för ohanterade undantag. Detta innebär att förutom vanlig felhantering måste programvaran också kunna hantera alla typer av fel som kan komma från Severas REST API.

Loggning

Loggning är en av de viktigaste aspekterna av integrationen, eftersom loggen måste kunna läsas vid fel för att se vad integrationen gjorde vid fel tidpunkt. Loggning kan göras till exempel:

• Till händelselogg på servern som kör integrationen
• Till applikationens databas
• Loggning till e-post. Observera att om loggning görs till e-post är den skickade informationen inte säker, eftersom e-post är som ett vykort när det reser över internet. Integration kan också generera mycket loggdata, vilket kan göra e-post oanvändbar.

Loggning bör göras åtminstone på dessa nivåer:

• Integrationens framsteg bör loggas
• Fel bör loggas

Loggningen bör ha tidsstämplar för alla viktiga funktioner. Det är bäst om tidsstämpeln har sekundprecision, eftersom minutprecision ofta är för stor, eftersom överföringar sker snabbt.

Hjälpte det här svaret? Ja Nej