Modernisering af services og webservicebeskeder - Spørgsmål og svar
Spørgsmål og svar
ID | Fra | Dato | Spørgsmål | Svar | Status |
|
|---|---|---|---|---|---|---|
1 | KMD (KSS) | Oct 24, 2022 | Vi har behov for en kontaktliste til Moderniseringsprojektet, så vi har et sted at stille fremtidige spørgsmål. | Der oprettes postkasse til brug for indsendelse af nye spørgsmål. | besvaret |
|
2 | KMD (KSS) | Oct 24, 2022 | Følger releases (for Moderniseringsprojektet) de almindelige STAR releases? | Releases til Moderniseringsprojektet vil som udgangspunkt følge de almindelige STAR releases. | besvaret |
|
3 | KMD (KSS) | Oct 24, 2022 | Hvordan vil større lovændringer påvirke denne plan? | STAR forventer, at der over projektperioden vil komme både større og mindre lovændringer og andre forhold, som vil påvirke den til enhver tid gældende plan. Når dette sker er det vores forventning at gå i dialog for at finde en løsning, der bedst muligt passer de fleste. | besvaret |
|
4 | KMD (KSS) | Oct 24, 2022 | Hvor lang tid før en given release ligger dokumentation klar til eksternt review? | Det følger de sædvanlige tidsfrister for STAR releases. | besvaret |
|
5 | KMD (KSS) | Oct 24, 2022 | Er der en tilsagnsproces? | STAR vil løbende have en dialog med aftagerne og deres leverandører om planen og forsøge at løse de udfordringer der opstår. | besvaret |
|
6 | KMD (KSS) | Oct 24, 2022 | Hvor lang tid (i hverdage) er der mellem at en given dokumentation for en Service/Operationer låst og til at den er færdigkodet og ligger klar på STAR's eksterne testmiljøer (T3 eller T4)? | Det følger de sædvanlige tidsfrister for STAR releases. | besvaret |
|
7 | KMD (KSS) | Oct 24, 2022 | Hvor lang tid før en given release ligger de færdige services klar på STAR's | Det følger for nogle snitflader de sædvanlige tidsfrister for STAR releases, fx hvis der pga. lovændringer skal ske indholdsmæssige ændringer samtidig med ny REST version af en service. For andre snitflader forventes det i nogle tilfælde at være muligt, at snitfladen er klar i testmiljø fx 1 release før den skal ibrugtages i prod. | besvaret |
|
8 | KMD (KSS) | Oct 24, 2022 | Er en service først "klar" til eksterne aftagere når alle planlagte operationer er omlagt? | Efter behov kan de forskellige operationer/metoder klarmeldes efterhånden som de er klar. | besvaret |
|
9 | KMD (KSS) | Oct 24, 2022 | Hvor lang tid (i hverdage) har serviceaftagere til at omlægge en service før den skal indgå i en E2E test. (Klar til ekstern udvikling minus start på E2E test). | Det følger de sædvanlige tidsfrister for STAR releases. Se også svar på spg. 7. | besvaret |
|
10 | KMD (KSS) | Oct 24, 2022 | Hvor meget forsinkelse må der være i en given STAR service omlægning, før at omlægningen flyttes til en senere release? Forsinkelse i forhold til;
| Det beror på størrelsen/kompleksitet af den enkelte service - og på om der der lovgivning, der betinger, at servicen skal tages i brug på et bestemt tidspunkt. | besvaret |
|
11 | KMD (KSS) | Oct 24, 2022 | Omlægning af ”besked-motor” til Push: | Dette vil ske tæt på realtid. I tilfælde af driftsproblemer vil push-beskederne blive sendt hurtigst muligt. | besvaret |
|
12 | KMD (KSS) | Oct 24, 2022 | Omlægning af ”besked-motor” til Push; | Den endelige interne arkitektur er ikke afklaret. Forventningen er dog, at der pr. borger sendes én besked ad gangen indtil serveren har svaret “modtaget“ på den foregående. På tværs af borgere er der ikke tænkt begrænsninger. Såfremt aftagernes server ikke kan følge med vil STAR “bakke tilbage“ og gensende lidt senere - med overholdelse af nødvendig rækkefølge. | besvaret |
|
13 | KMD (KSS) | Oct 24, 2022 | Omlægning af ”besked-motor” til Push; | Se #12 | besvaret |
|
14 | KMD (KSS) | Oct 24, 2022 | Omlægning af ”besked-motor” til Push;
| STAR vil ikke blokere for push til hele jobcenter. Udelukkende for den enkelte borger.
| besvaret |
|
15 | KMD (KSS) | Oct 24, 2022 | Omlægning af ”besked-motor” til Push; |
| Ikke afklaret |
|
16 | FOA | Oct 24, 2022 | Baggrundsmaterialet er svært at overskue – bl.a. pga
|
Ad 1: Forkortelserne på pakke navne er anvendt for internt at have en idé om forretningsindhold i de enkelte pakker. De kunne også have haft et ikke-betydende løbenr. Ad 2: Række 57 er dp.tællere (som a-kasserne indberetter). Række 143 er tæller om 225 timers reglen på kontanthjælpsområdet. Ad 3: Som udgangspunkt er release for både STAR og eksterne (med enkelte undtagelser, jf. fx NUPH-1, hvor der i kommunikationsprojektet vedr. a-kasse kommunikation er aftalt, at ekstern ibrugtagning aftales nærmere). Ad 4: Ligger tentativt i 2023-4. Ad 5: På områder hvor der ikke samtidig er lovgivningsmæssige ændringer forventes at konverteringen indholdsmæssigt sker 1:1 og med dansk navngivning i snitfladerne. Ad 6: De enkelte services og pakker berører fx jobcentersystemer og a-kasse systemer forskelligt afhængigt af, om aftager bruger den enkelte service. Ad 7: Se ad 6. | besvaret |
|
17 | Netcompany | Oct 25, 2022 | … jeg savner 5-10 linjer knyttet til hver service (ikke WSRM type) omkring hvad er jeres tanker mht. arbejdet. Hvis det blot er et SOAP-REST skift, eller om der er planlagt andre (forretningsændringer). Jeg kan se, at der på de services der snart skal kigges på, er forretningsændringer (det er vel også derfor de ligger først?) – men kan man sige lidt mere om hvad planerne er med de fremtidige ændringer. | Se FOA (id 16) ad 5.
Det er korrekt at de services, der kigges på først, er på Plan-området, fordi de (med forbehold for FT-valget og en kommende regering) påvirkes, af aftale om helhedsorienteret indsats. | besvaret |
|
18 | Netcompany | Oct 25, 2022 | På hele WSRM området er det også endnu uklart hvad der kommer til at ske. Tages det nye rammeværk i brug allerede i 2023-1 ? eller er det blot ”jeres” udvikling der starter der? Hvordan bliver overgangene for de enkelte WSRM’er? Bliver nye kun tilgængelige via den måde at transportere dem på? Hvornår skal de gamle skiftes over? Er der ikke problemer i at køre med 2 kanaler for hændelser, i forhold til rækkefølgen vi så får dem ind i? Nogen hændelser skal jo modtages i ”rækkefølge” på tværs af typer – eks cancelBooking og createBooking. | Foreløbigt svar Vores udvikling påbegyndes med 2023-1 - og forventes idriftsat med 2023-1. Hvis der er nye beskedtyper i 2023-2 er målet, at aftagerne tager disse i brug i form af de nye webservicebeskeder i 2023-2. Vi forventer, at på områder der ikke samtidig er omfattet af forretningsmæssige ændringer, at dér kan vi bruge WSRM og de nye webservicebeskeder parallelt.
Der kan køres parallelt for fx “Til- og afmelding” og “indkaldelser”, men dog således, at den enkelte aftager modtager enten WSRM eller nye webservicebeskeder på hvert samhørende område. Dvs. ikke fx WSRM på tilmelding og nye beskeder på afmeldinger. Endelig svar Ikke afklaret
| Foreløbigt |
|
19 | Netcompany | Oct 25, 2022 | … hvad Release kolonnen angiver – er det der hvor I starter jeres udvikling, eller er det der hvor ændringerne rulles ud – ug skal tages i brug af os? Det går rygter om, at det med at køre SOAP og REST services i parallel – ikke kommer til at være en mulighed i fremtiden – måske på baggrund af de erfaringer vi har med IndkaldelseServicen – hvor eksisterende funktionalitet blev på virket af de nye services, fordi de blev anvendt ”inde bagved”. ….. Et hårdt skift stiller dog store krav til jer om at være færdig med jeres udvikling til tiden – i er nødt til at give os noget at arbejde med – så vi kan få integrationerne på plads i god tid. Det med at I leverer kode til ekstern en uge før I forventer at vi starter test op – er ikke ok. Der må som minimum foreligge nogle end points på T3 i god tid inden, at I afleverer alt til ekstern test – så vi også får noget tid til at foretage vores udvikling. Vi er meget afhængige af at få noget fra jer tidligt, så vi kan starte vores udviklingsforløb. | På de fleste områder er det, hvor der rulles ud til aftagerne.
Det er vi klar over, men der ligger allerede nu et større område og et mindre, der kan tages i brug, frem for at opbygge en pukkel.
| besvaret |
|
20 | Netcompany | Oct 25, 2022 | Det vil også være en fordel for os at vide hvornår i har snitflader klar, og hvis i arbejder på flere services hvilken rækkefølge implementeres de så i. I CV forløbet var vi meget i tvivl om hvilke services var færdige hvornår, og vi sad og ventede på en service som I havde besluttet, at den var der nok ikke brug for alligevel. | Ønsket er noteret | besvaret |
|
21 | Netcompany | Oct 25, 2022 | I kolonnen Berør A-kasse står der:
For TEMP adresse står der ”S-M” - hvad betyder det ? (mit umiddelbare gæt har slet ikke noget med webservices at gøre 😊 | Bemærkningen indgår ikke i Excel-arket, men går på at det i anden delaftale om nytænkning af beskæftigelsesindsatsen indgår afsnit om a-kasser og jobordrer. Temp: Der skulle have stået “Ja”. | besvaret |
|
22 | Netcompany | Oct 25, 2022 | Jeg kan se at services som PersonStatus Service og PersonHistory Service ikke optræder på listen – jeg går ud fra, at det er pga. at udfasningen af dem forventes at ske i løbet af perioden. Hvornår forventes det at de lukkes ned ? Og er der andre SOAP services der på samme måde erstattes af andre REST services, der leverer data fra siloerne? | PSS og PHS tømmes i 2023 og 2024 gradvist for indhold efterhånden som registreringsservices på de enkelte områder omlægges fra SOAP til REST. | besvaret |
|
23 | Netcompany | Oct 25, 2022 | Der er en række services vi i dag anvender – som er markeret med ”Nej” i Berør A-kasse det er:
| Ja, det er korrekt, at a-kasserne bruger de 3 services. Opdateret i kildearket.
| besvaret |
|
24 | Netcompany | Oct 25, 2022 | Så er der også en række services der er markeret med at de berører a-kassen – men som vi ikke har implementeret, fordi de ikke er tilgængelige for os:
|
Ad 1-4, 6, 7 og 8: Ja, det er korrekt, at a-kasserne bruger disse services eller WSRM’er. Opdateret i kildearket. Ad 5: Jobcentre modtager WSRM’erne
|
besvaret |
|
25 | Netcompany | Oct 25, 2022 | Endeligt går det rygter om at sikkerhedsmodellen også skal ændres. | Foreløbigt svar Det er korrekt, at vi arbejder en ændring af sikkerhedsmodellen, men vi bestræber os på, at ændringerne laves på en måde så aftagerne ikke berøres - eller berøres mindst muligt. | Foreløbigt |
|
26 | Edora | Oct 26, 2022 | For os hos Edora er det rigtigt vigtigt, at man fortsat har mulighed for at få tilsendt historiske Webservicebeskeder. Det er en vigtig del af både opsætningen, men også den gnidningsfrie overgang til en ny planner løsning. Jeg kunne forstå på mødet i dag, at det ikke havde været i jeres overvejelser, men at det vil være muligt at efterkomme. Vil du ikke vende tilbage med en bekræftelse, at det også vil være muligt fremover. | Foreløbigt svar Så har jeg vist ikke været tydelig nok, for det jeg prøvede at sige var, hvordan det i dag er muligt for vores systemforvalter fra et ”arkiv” at tage kopi af de WSRM-beskeder, der var sendt til et jobcenters afgående planner-leverandør og lægge på kø til et jobcenters kommende planner-leverandør, så planner-systemet kan få kendskab til kommende møder i det pågældende jobcenter. Vi lovede på mødet at undersøge om det er muligt fremover i en kommende beskedløsning. Så det bliver vi nød til at undersøge - og vende tilbage på. Endelig svar Ikke afklaret | Foreløbigt |
|
27 | Schultz | Feb 6, 2023 | Domæneadskillelse (siloer) vs. Forretningsmæssige afhængigheder Vi ønsker at få afdækket tankerne omkring rækkefølgen af webservicebeskeder: "Rækkefølgende af webservicebeskeder overholdes dermed i kombinationen af det enkelte forretningsdomæne og den enkelte borger." Vi forstår det således, at der hos DFDG vil være en kø (internt) pr. domæne (silo), hvor rækkefølgen er garanteret. Men hvilke problemer kan der være, hvis der fx er forsinkelse på en af domænerne, i forhold til afsendelsen og dermed processeringen hos KSS? Er det anderledes end i dag - og kan man risikere at modtage en webservicebesked, som reelt ikke må/kan processeres pga. sammenhængende funktionalitet hos KSS? Er tanken, at man med det nye koncept ikke længere skal opfatte DFDG som ét system, men en række uafhængige systemer? Skal KSS således betragte DFDG som en række selvstændige it-systemer, og garanterer DFDG at disse fungerer uafhængigt af hinanden? Eksempel: Besked ved tilflytning. Kan vi, når vi modtager en besked om tilflytning (i dag PersonNotificationType) regne med, at alle domæner hos DFDG er fuldt opdateret og at vi på det tidspunkt kan hente opdaterede data fra alle disse? Eller kan man risikere at få besked før alle data m.m. er replikeret/commited ned i DFDG’s domæner? Samme spørgsmål gør sig gældende for andre beskeder fx om tilmelding, fravær, kandidatformidling m.m. hvor KSS har forretningslogik der fx opretter sager eller andet, der er afhængig af at borgerens samlede tilstand er opdateret. | STAR har igangssat et spor om at afdække dette samt løsningsmodeller. Endelig svar Ikke afklaret | Foreløbigt |
|
28 | Schultz | Feb 6, 2023 | Sikkerhed på webhooks Vi vil gerne beskyttes mod hul i vores system, der kan benyttes til misbrug, overbelastning (DDoS), fejlkonfiguration og risiko for at beskeder fejlagtigt sendes på tværs af miljøer. Klientcertifikat mTLS er vores foretrukne løsning og ønske at anvende. | STAR vil arbejde videre ud fra dette input da der på mødet Feb 7, 2023 var enighed om fordelen med at benytte klientcertifikat. | besvaret |
|
29 | Schultz | Feb 6, 2023 | Teknisk indhold (json) - Tidspunkter, "angives i dansk tid": Vi vil gerne opfordre til, at der altid er tidszonekomponent. Men ellers rigtig god idé, at tidspunkterne er angivet i Copenhagen timezone. | Det giver god mening og det vil vi indarbejde. | besvaret |
|
30 | Schultz | Feb 6, 2023 | Teknisk indhold (json) - Links: Vi vil gerne høre jeres tanker om dette, men umiddelbart tænker vi ikke at det er et koncept vi kommer til at følge. I dag er det typisk vores PO og ARK, som ud fra nogle forretningsmæssige overvejelser beslutter, hvorfra vi henter data på baggrund af en (wsrm) besked fra DFDG. | På vores møde Feb 7, 2023 var der inden deltagere som så anvendelsen af disse links. Derfor bliver linkes som beskrevet ikke implementeret. | besvaret |
|
31 | AKA-IT | Feb. 20, 2023 | I dokumentet er det beskrevet, at I går væk fra at benytte hovedkø og subkøer, og at webhooks kan sættes op pr. aftagende system. Er det rigtigt forstået, at flere systemer kan abonnere på samme hændelse, f.eks. at et cv er opdateret, sådan at den samme besked bliver sendt til både system A og system B. | Ja, det er korrekt forstået | besvaret |
|
32 | AKA-IT | Feb. 20, 2023 | Under punktet DFDGs kald til aftagers webhook skriver I om en base-url pr. miljø. Kan I bekræfte, at det er en base-url ”pr. system, pr. miljø”? Sådan at Min A-kasses fagsystem Modulus og Min A-kasses andet system ikke skal modtage hændelser på samme base-url’er. Jeg vil bare være sikker på, at ”webservicebeskedaftager”, som der står i teksten, dækker over systemet og ikke over a-kassen, som kan have flere aftagende systemer. | Ja, det er korrekt forstået | besvaret |
|
33 | Netcompany | Mar. 03, 2023 | Venligst præciser hvad der forstås ved at en besked er ”modtaget og behandlet” – Vi forventer at hente beskeden ned i eget system, persistere den, og dermed kvittere for modtagelsen af den. | Jeres forventning er korrekt. I kvitterer alene for at beskeden er korrekt modtaget. STAR retter til i Noter til web-beskeder | besvaret
|
|
34 | Netcompany | Mar. 03, 2023 | Hvad gør vi, hvis vi ikke kan hente data på det udsendte GUID? Eks. ”Det kendes ikke i DFDG…” eller hvad vi nu kan finde på. | Vi anbefaler at der implementeres resilience/modstandsdygtighed (dvs. genkørsler) i aftagerløsningerne uanset hvad. Dog arbejder vi i STAR på om vi kan løse problemet i DFDG. | besvaret |
|
35 | Netcompany | Mar. 03, 2023 | Jeg er ikke sikker på at jeg forstår blokeringen på dataentitet / forretningsdomæne. Hvis vi ikke kan aftage en indkaldelse (booking) vil vi så ikke kunne modtage flere bookinger (på andre personer) før vi kan aftage den der fejler? | Blokeringen vil udelukkende ske på borgerniveau. Dermed vil andre borgere ikke blive påvirket af at én borger er blokeret. | besvaret |
|