Audit trail

Förmågan att koordinera och spåra felinformation alternativt ett händelseförlopp när flera API:er varit delaktiga är viktigt för en organisations kontinuitet. Ytterst för att ge ett proaktivt kundbemötande och för att i efterhand kunna spåra vad som gått fel i ett ärende.

För många verksamheter krävs att flera API:er används för att utföra en uppgift såsom att sammanföra en arbetssökande och arbetsgivare utifrån kompetens, registrera ett bolag etc. Mer generellt definieras en e-tjänst vanligen som en digital tjänst som löser ett specifikt behov för en invånare. I sakens natur ligger att en användare ha flera behov där data finns i olika datakällor, och följaktligen nyttjar användaren därmed indirekt flera API:er för att slutföra sitt ärende.

Traditionell lösning

En identifierare (sessions id) nyttjas oftast när ett tillståndslöst protokoll som HTTP används för att utbyta flera meddelanden mellan klient och server för att lagra tillstånd. En anonym användare på en webbsajt som lägger i och plockar ur varor i en varukorg är ett välkänt exempel på behovet att lagra tillstånd kopplat till en session. Denna lösning har sin begränsning i att det är tekniken som skapar id-numret och inte verksamheten.

Rekommendation

Se till att e-tjänsten eller det system som ansvarar för processen skapar ett id-nummer som förmedlas till alla API:er som används, i syfte att anropat API kan använda id-numret för spårning.

Att skicka en identifierare mellan klient och server som kan användas för att spåra transaktioner kan lösas på flera sätt, och tillämpas när det är viktigt att följa transaktioner för verksamheten. Ovan exempel med sessioner bygger på att tekniken sätter en identifierare implicit. Genom att e-tjänsten programmatiskt sätter en identifiera kan verksamheten avgöra var en transaktion börjar. I de flesta fallen så är det med andra ord användaren som initierar en transaktion utifrån mönstret att den vill slutföra en uppgift i en e-tjänst, webbformulär eller dylikt. En uppgifts karaktär är ofta intuitivt och kan beskrivas med enkla termer såsom:

Publicera en platsannons hos Arbetsförmedlingen
Registrera ett nytt bolag hos Bolagsverket
Ansök om sjukförsäkring hos Försäkringskassan

När användaren väljer att starta en transaktion genom att delge myndigheten en informationsmängd kan e-tjänsten skicka med en identifierare som alla efterföljande system kan använda för loggning oberoende av varandra.

Implementering

Ett UUID bör användas.

Def: Universal unique identifier (UUID) – unikt id‑nummer för programfiler och andra filer, bestående av ett 128‑siffrigt binärt tal (motsvarar ungefär ett 38‑siffrigt decimalt tal). UUID har funnits i flera formerÖppnas i ny flik, men är i senaste versionen rena slumptal. En variant av UUID är GUID.

Fördelen men ett UUID är att det kan skapas lokalt i en webbläsare och har låg sannolikhet för att vara upptagen. En konsekvens är att efterföljande system kan använda denna identifierare utan att någon form av informationsutbyte har krävts på förhand.

Går det att förmedla en identifierare i ett API-anrop på ett teknikneutralt sätt?

HTTP header attributet ( x-transaction-id ) är ett sätt att förmedla ett transaktionsid. I en kommande version av REST API-profilen kommer en rekommendation att utfärdas.

Oavsett val av loggsystem krävs en identifierare för att koordinera transaktioner

Ett loggsystem skapar möjlighet att aggregera information från flera källor när det finns en identifierare som korrelerar loggrader.

Nytta för Servidedesk

Genom att användaren av e-tjänster får ta del av en felkod (UUID) så kommer efterföljande hantering underlättas för en kundtjänst eller servicedeskfunktioner. Till exempelvis kan kunden få automatiserade meddelanden som kan förebygga onödig belastning på kundtjänst/servicedesk genom proaktiv information. När användaren väl kontaktar servicedesk kan handläggaren få automatiserade underlag om vad som inträffat om kunden anger sin felkod (UUID).