Open

Bemærk siden er under opdatering i forbindelse med at 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ændringer 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 etableres (nye) 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 forhold eller teknisk gæld justeringer
   Der etableres en af disse to modeller

   1. Forskudt udviklings- og prod-release
      STAR sikrer at der mindst 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 sikrer, 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 at SOAP service kan anvendes i en lidt længere overgangsperiode. Længden på periode fastsættes af STAR og vil fremgå af epic. Dette sikrer, 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 den gamle SOAP service forsvinder.
      I tilfælde af at en service, der har SOAP-REST konverter, efterfølgende blive ramt af ny forretning, f.eks. ved ny lovgivning vil den falde ind under 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 fremrykker moderniseringsopgaver jf. roadmap vil STAR som udgangspunkt og med mindre andet er aftalt 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 https://starwiki.atlassian.net/wiki/spaces/GI/pages/3826581707. Dette vil forsætte i takt med at flere områder modernisere. STAR erstatter https://starwiki.atlassian.net/wiki/spaces/GI/pages/3826581707 med er række statusservices, der er knyttet til de enkelte forretningsområder. Disse domæne statusservices udbygges i takt med forretningsdomænet moderniseres.

Komposit service

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

Kodelister og fejlkoder

Kodelister og fejlkoder 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ørende kodeliste anvendes fra de pågældende forretningsdomæne.

Webservicebeskeder

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

Serviceaftager kan 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