...
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.
| 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 inte i OeP.
| Gliffy | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Alternativ 3 - pollning
Vi etablerar ett publicering av statusuppdateringar (en generisk lösning) en lösning som pollar efter statusförändringar och uppdaterar OeP. Status dubbellagras i OeP.
| Gliffy | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Alternativ 4 - 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 1: | Option 2: | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Description | ||||||||||||||
Pros and cons |
|
| ||||||||||||
Estimated cost |
|
|
...