| Page Properties | ||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||||||||||||||
|
Bakgrund
OeP kommer att integrera mot APIer som i sin tur skickar vidare felanmälningar och ärenden till verksamhetsspecifika system (ISYcase och ByggR t ex), och på sikt mot vårt generiska processtöd.
Det finns behov av att kunna exponera aktuell status på ett sådant ärende via OeP, och vi behöver besluta om hur detta skall implementeras.
Värt att ta i beaktande är att OeP hittills är den enda identifierade klient som inte kan hämta status vid behov från respektive API utan större ingrepp i lösningen (då beroendet till de 150-isch kommuner som använder OeP idag stökar till det) - vi tittar alltså på en lösning specifikt för OeP med låg sannolikhet för återanvändning mot andra klienter (om vi går på något annat alternativ än alternativ 1 nedan).
Alternativ
Alternativ 1 - “on-demand” 1
OeP läser status från respektive API när status efterfrågas av en intressent (“on demand”) - status för dessa ärenden dubbellagras nödvändigtvis inte i OeP.
| Gliffy | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Alternativ 2 - “on-demand” 2
Vi etablerar ett standardiserat status-API för all typ av status, som i sin tur hämtar statusar från respektive API. OeP läser status från detta standardiserade APIet när status efterfrågas av en intressent (“on demand”) - status för dessa ärenden dubbellagras nödvändigtvis inte i OeP.
| Gliffy | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Alternativ 3 - pollning 1
Vi etablerar en robot som pollar efter statusförändringar och uppdaterar OeP. Status dubbellagras i OeP.
| Gliffy | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Alternativ 4 - pollning 2
Vi etablerar något annat, som likt roboten i alternativ 3, pollar efter status och uppdaterar OeP. Status dubbellagras i OeP.
| Gliffy | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Alternativ 5 - eventdriven arkitektur
Vi etablerar en generisk lösning för publicering av statusuppdateringar där OeP får konsumera en kö. Status dubbellagras i OeP.
| Gliffy | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Sammanfattning | Option Alternativ 1: “On demand” 1 | Option Alternativ 2: | Description | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Pros and cons |
|
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Estimated cost“On demand” 2 | Alternativ 3: pollning 1 | Alternativ 4: pollning 2 | Alternativ 5: eventdriven arkitektur | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Pros/cons |
|
|
|
|
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||
Kostnadsestimat | API-teamet: 0 OeP:
| API-teamet:
OeP:
| API-teamet: 0 OeP: 0 RPA-teamet:
| API-teamet:
OeP: 0 | API-teamet: 0 Eventarkitektur-team:
OeP:
|
Action items
...
| |||||
Utvärdering | Mycket utveckling i OeP (som dessutom blir Sundsvalls-specifik) då de inte kan använda standardkomponenter för att hantera hämta status som andra API-källor. Stor insats för OeP. | OeP kan hämta status på samma sätt som andra API-källor då vi lägger en fasad mellan OeP, som levererar status på OeP-format, och våra tjänster. “Enkel” felhantering - antingen går status hämta eller ej. Rimlig insats för båda parter och bör vara möjlig att få på plats under Q2 2021. | Inte lämplig för RPA som långsiktig lösning - går därför bort. | Stor insats för API-teamet, framförallt för att skapa en säker, feltolerant och effektivt förvaltningsbar lösning - finns ingen möjlighet att få detta på plats förrän tidigast Q4 2021. Dessutom mycket svårt att få rättssäkert - hur vet man att den status som presenteras är den status som faktiskt är korrekt?! | Källsystemen saknar nödvändig funktionalitet för att kunna skicka event idag, |
|---|
Actions
- Jari Koponen (Unlicensed) - granska och kommentera
- Mikael Nordlander (Unlicensed) - granska och kommentera
- Jenny Stenman (Unlicensed) - granska och kommentera
Beslut
Alternativ 2 - enkel lösning (vad avser felhantering och hantera rättssäkerhet) som kräver rimlig insats (möjlig att få på plats under Q2 2021) av båda parter.