Bemærk siden er under opdatering i forbindelse med STAR moderniseringsprojekt er igangsat

Bemærk at indholdet på siden udvikler sig løbende i forbindelse med den dialog der er mellem STAR og serviceaftagerne. indholdet er derfor et øjebliksbillede af situation på sidens seneste opdateringstidspunkt

Webservice

STAR har følgende 2 transitionsmønstre

1. Ny forretning eller forretnings med store ikke bagud kompatible ændringer

   • Her etableres den nye forretningsfunktionalitet alene på REST service og webservicebeskeder
     Note: Der pågår en dialog om hvorvidt der kan nøjes med webservicebeskeder eller der også skal etablere WSRM beskeder i en overgangsperiode og i givet fald hvor længe / på hvilke områder dette er nødvendigt for serviceaftager

2. Eksisterende forretning der flyttes uden forretningsændringer, dog kan der forekommer tekniske forholde eller teknisk gæld justeringer
   Der etableres en af disse to modeller

   1. Forskudt udviklings og prod release
      STAR sikre at der mindst er minimum er 3 måneder svarende normalt til 1 release imellem en service er tilgængeligt på testmiljøer og til den skal anvendes i produktion. Dette sikre at serviceaftager har ekstra tid til at foretage egen implementering.
      Denne model forudsætter at alle serviceaftager er klar i prod release og der er ingen mulighed for en overgangsperiode udover de ekstra 3 måneder/ 1 release

   2. Parallel understøttelse med SOAP og REST service
      SOAP-REST konverter der gør SOAP service kan anvendes i en lidt længere overgangsperiode. Længden på periode fastsættes af STAR og vil fremgå af epic. Dette sikre at serviceaftager dels har ekstra tid til at foretage egen implementering og dels at serviceaftager ikke er bundet til en bestemt release men blot skal være klar inden overgangsperioden udløber og gamle SOAP service forsvinde.
      I tilfælde at en service der har SOAP-REST konverter efterfølge blive ramt af ny forretning, f.eks. ved ny lovgivning vil den falde indunder punkt 1 for ny forretning.

STAR vil som udgangspunkt anvende model 2.a, da det er forbundet med ekstra implementeringsomkostninger for STAR at anvende model 2.b. Ønsker serviceaftager model 2.b skal dette aftales med STAR.
Hvis STAR fremrykke moderniseringsopgaver jvf. roadmap vil STAR som udgangspunkt og med mindre andet er aftale tilstræbe af anvende model 2.b således at serviceaftagers planer ikke behøves at ændres. Sådan ændringer vil også fremgå af roadmap

Det fremgår af DFDG moderniserings og forretnings roadmap for serviceaftagere hvilken model der anvendes på de forskellige service.

Statusservice

STAR har over en længer periode reduceret indholdet i /wiki/spaces/GI/pages/3826581707. Dette vil forsætte i takt med at flere områder modernisere. STAR erstatter /wiki/spaces/GI/pages/3826581707 men er række statusservice der er knytte til de enkelte forretningsområder. Disse domæne statusservice udbygges i takt med forretningsdomænet moderniseres.

Komposit service

STAR har etableres et forretningsdomæne hvor hvis der er behov for det kan etablers composit service er operer på tværs af flere forretningsdomæner. Det vil være en individuel vurdering hvornår sådan composit service er relevante at etablerer.

Kodelister og fejlkoder

Kodelister og fejlkode koblet til domæner. Alle kodelister og fejlkoder bevare deres værdisæt men bliver koblet til det forretningsdomæne der ejer data. Samtidig med en snitflade flyttes til REST skal de tilhørede kodeliste anvendes fra de pågældende forretningsdomæne.

Webservicebeskeder

STAT vil løbende etablerer webservicebeskeder fra 2023-4 og frem. Disse etableres parallelt med de eksisterende WSRM beskeder. For ny forretnings etableres kun webservicebeskeder (dette er under dialog med de eksterne i forbindelse med deres impl. strategi).

Serviceaftager kan i vælge en trinvis overgang men skal være opmærksom på følgende

• Aftager må kun modtage en given besked enten som webservicebesked eller WRSM

• Er der en krævet rækkefølge skal de beskeder der er berørt enten aftages som webservicebesked eller WRSM