Bakgrund
OeP kommer att integrera mot APIer som i sin tur skickar vidare felanmälningar och ärenden till verksamhetsspecifika system (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.
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 inte i OeP.
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 inte i OeP.
Alternativ 3 - pollning 1
Vi etablerar en robot som pollar efter statusförändringar och uppdaterar OeP. Status dubbellagras i OeP.
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.
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.
Sammanfattning | Option 1: | Option 2: |
|---|---|---|
Description | ||
Pros and cons |
|
|
Estimated cost | LARGE | MEDIUM |
