| Table of Contents | ||||
|---|---|---|---|---|
|
...
Forretningsmæssigt indhold
[TBD]
Teknisk indhold
Alle webservicebeskeder fremsendes som JSON i en struktur, der både indeholder forretningsmæssigt, indhold samt det tekniske indhold (f.eks. metadata)
...
Rækkefølgende af webservicebeskeder overholdes dermed i kombinationen af det enkelte forretningsdomæne og den enkelte borger.
Dokumentation
[TBD]
Hvordan dokumenteres Webhooks og webservicebesked (kontrakter).
Hvordan laves der varslinger også til eksempelvis små private operatører? Light version af dokumentation og tilknytningsmuligheder?
Roadmap.
Teknisk dokumentation.
Referenceimplementation?
Drift
Logning
Hændelseslog
Forretningsdomænet Ekstern Kommunikation laver hændelseslogning på al afsendelse- og genfremsendelsesaktivitet, når webservicebeskeder forsøges afleveret til aftagere af webservicebeskeder.
...
den fejlende webservicebesked tilføjes til en genfremsendelseskø, hvor at den forsøges genfremsendt med en passende tidsforskydning, som bliver større gang for gang webservicebeskeden forsøges genfremsendt.
Tidsforskydningen stiger eksponentielt per besked for hver gang beskeden forsøges sendt igen, op til et maksimum af 3 timer mellem hvert forsøg. Tiden mellem hvert forsøg er baseret ud fra mængden af genforsøg, eksempelvis første gang så er næste forsøg om 1 sekund, så 3 sekunder, så 7, 15, 31... Dvs. at mængden af tid før næste forsøg fordobles, indtil at vi når til et punkt hvor at næste forsøg er over 3 timer (hvor at den så sættes til 3 timer hver gang).
tidsforskydningen er det samme for TEST og PROD miljøer på nuværende tidspunkt, dog er det sat op til nemt at kunne gøres konfigurerbart per miljø, hvis dette bliver nødvendigt.
der fremsendes ikke yderligere webservicebeskeder på samme borger fra det forretningsdomæne, som i DFDG var årsagen til, at den fejlende webservicebesked blev sendt. Disse webservicebeskeder ligges på kø til efterfølgende afsendelse.
der fremsendes ikke yderligere webservicebeskeder på samme dataentitet, som webservicebeskeden omhandler (eksempelvis samme stillingsbetegnelse), fra det forretningsdomæne, som i DFDG var årsagen til, at den fejlende webservicebesked blev sendt. Disse webservicebeskeder ligges på kø til efterfølgende afsendelse.
...
Når genfremsendelsespolitikken ligger webservicebeskeder på kø, er det for at sikre, at den forretningsmæssige rækkefølge af webservicebeskeder overholdes, eksempelvis pr. borger inden for et givent forretningsdomæne i DFDG. De webservicebeskeder, der ligger på kø, vil bliver afsendt fra DFDG, når aftager har modtaget og behandlet den oprindelig fejlende webservicebesked.
...
Når aftager skal opsætte abonnementer (se afsnit selvbetjening) kan dette gøres via GUI eller API. APIet sikres ‘udelukkende’ med en JWT Bearer token. Derved vil det ikke være muligt at benytte samme authenticationmodel som i det øvrige DFDG (certifikat).
[TBD]
Kryptering
Selve webservicebeskeder og deres indhold krypteres ikke. Dette begrundes med, at:
...
STAR overvåger driften af webservicebeskeder, men det er aftagernes ansvar at webhooks er kørende og tilgængelige.
Skal vi skrive noget omkring for mange beskeder de skal kunne holde til?
Webservicebeskedaftagerne kan via STARs webservicebesked-selvbetjeningsløsning se status på driften for egne beskeder.
...
En del af at oprette et abonnement mellem en given aftager af webservicebeskeder og en specifik webservicebeskedtype forudsætter en end-to-end test, der beviser, at aftageren af webservicebeskedtypen kan aftage og returnere en HTTP status kode OK, når STAR sender en webservicebesked indeholde fiktive data.
Hvad gør vi med versionering og nye versioner af samme webservicebesked?
Kan man overhovedet oprette et abonnement i PROD, eller skal test være gennemført på T-miljøer inden?
Mock af Webhooks til vores udviklingsmiljøer → så vi ikke ligger at fejler og forsøger at genfremsende endpoints.
Transition
Aftagere kan på pr. webservicebeskedtype vælge om det skal være webhook eller WSRM i en periode
| Info |
|---|
KMD giver udtryk for at de foretrækker at afvente med omlægningen til alle WSRM-beskeder er omlagt |
[TBD]
Migrering af eksisterende WSRM tilslutningsaftaler og abonnementer
...
Hvornår kan jeg begynde af aftage Webservicebeskeder?
Hvornår jeg kan få WSRM og benytte mig af dobbelt drift?
Skal nye beskedtyper være på ny eller gammel model =>