Transitionsplan for webservicebeskeder

Owned by Kasper Birkelund
Last updated: Nov 27, 2023
2 min read

Nedenstående diagram viser den forventede transitionsplan for webservicebeskeder.

Den konkrete rækkefølge for hvornår en WSRM besked overgår til Webservicebesked aftales løbende med STARs serviceaftagere.

  • Pt. forventes følgende beskeder/områder at bliver omlagt først: “NUPH'er”, “min plan”, “kontaktgrupper/personkategorier”

 

2023-2

2023-3

2023-4

…

2024-4

DEADLINE

 

2023-2

2023-3

2023-4

…

2024-4

DEADLINE

Levetid

  • Alle WSRM beskeder forbliver uændret

  • Etablering af en Webservicebesked til pIilot

 

 

 

  • WSRM beskeder understøttes ikke mere

Nye forretningsmæssige hændelser

  • Nye forretningsmæssige hændelser udvikles som WSRM beskeder

  • Nye forretningsmæssige hændelser udvikles som både WSRM og Webservicebeskeder 

  • Nye forretningsmæssige hændelser udvikles kun som Webservicebeskeder

 

 

Abonnementsopsætning

  • Pilotens forretningsmæssige hændelse udsendes som både WSRM og Websrvicebesked

  • Et antal forretningsmæssige hændelser udsendes som både WSRM og Websrvicebesked

  • Aftagere af kan abonnemere på både WSRM og Webservicebesked for de omlagte forretningsmæssige hændelser, således at aftagere modtager informationen som både WSRM besked og Webservicebesked 

  • Det forventes, at Webservicebeskeder kun benyttes til tekniske tests, mens WSRM beskeder behandles som hidtil

  • Alle forretningsmæssige hændelser udsendes som både WSRM og Websrvicebesked

  • Aftagere kan abonnemere på enten WSRM eller Webservicebesked for de alle forretningsmæssige hændelser, således at aftagere enten modtager informationen som WSRM besked eller Webservicebesked
    De nærmere regler vil fremgå af Epic s 

 

  • Aftagere kan kun abonnemere Webservicebesked for de alle forretningsmæssige hændelser, således at aftagere modtager informationen som Webservicebesked 

Testkrav til aftagere

  • Ingen særlige krav i pilot fasen

  • Nye aftagere af Webservicebeskeder, beviser, at deres webhooks kan modtage beskeder ved at returnere HTTP statuskode 200

  • De Webservicebeskeder, som aftagere modtager, behandles forretningsmæssigt efter kvittering for modtagelse

 

  • End-To-End test gennemført med STAR

Tekniske krav til aftagere

  • Ingen særlige krav i pilot fasen

 

 

 

Tynde vs. semitynde Webserviebesekder

 

 

 

 

Næste workshop omkring webservicebeskeder afventes

 

TVÆRGÅENDE

  • Blokerende WSRM beskeder

Aftagere af WSRM beskeder vil stadig kunne opleve blokerende WSRM beskeder, som stadig vil spærre ens WSRM kø. Dog vil blokerende WSRM beskeder ikke påvirke udsendelse af Webservicebeskeder, hvilket betyder, at man som aftagere af Webservicebeskeder stadig vil modtage disse, uanset om der er blokerende WSRM beskeder på ens WSRM kø.

  • Blokerende Webservicebeskeder

Udsendelse af Webservicebeskeder stoppes/blokeres pr. borger, hvis der opstår fejl ved udsendelse af en Webservicebesked. Dette betyder, at aftagere af Webservicebeskeder vil stadig modtage Webservicebeskeder, der vedrører andre borgere. Blokerede Webservicebeskeder vil ikke påvirke udsendelsen af WSRM beskeder, hvilket betyder, at man som aftager stadig vil kunne hente WSRM beskeder, som vedrører de borgere, der Webservicebeskedmæssigt er blokeret.
For beskeder der ikke er knyttet til en borger stoppes/blokeres pr. beskedtype eller tilsvarende.

  • Forretningsmæssig rækkefølge af Webservicebeskeder

Hverken blokerende WSMR beskeder ej heller blokerende Webservicebeskeder vil påvirker den forretningsmæssige rækkefølge for beskeder, idet de forretningsmæssige hændelser, hvor rækkerfølgen har en betydning, omlægges samtidig og skal aftages fra samme kanal (WSRM beskeder eller Webservicebeskeder).

Tilgængelighed: https://starwiki.atlassian.net/was