Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 7 Next »

Status

IN PROGRESS

Impact

HIGH

Driver

Edwin Molina (Unlicensed)

Approver

Per Persson 

Contributors

Jari Koponen (Unlicensed) Jenny Stenman (Unlicensed)

Informed

Due date

Outcome

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

Alternativ 1: “On demand” 1

Alternativ 2: “On demand” 2

Alternativ 3: pollning 1

Alternativ 4: pollning 2

Alternativ 5: eventdriven arkitektur

Pros and cons

(plus)

(minus)

(plus)

(minus)

(plus)

(minus)

(plus)

(minus)

(plus)

(minus)

Estimated cost

LARGE

MEDIUM

Action items

Outcome

  • No labels