• Vedligeholdes ikke

    • 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