Beskrivelse af Webservicebeskeder
Samlet her er en beskrivelse af webservicebeskeder og deres abonnementsmodel.
Webservicebeskeder bliver initieret i forretningskoden ved at rejse et RabbitMQ event med en entitetstype (fx. CV opdateret eller Jobordre oprettet). Dette event bliver så behandlet af EksternKommunikation forretningsdomænet som omsætter eventet til en webservicebesked. Webservicebeskeden sendes derefter til aftagernes webhook adresser som det er defineret i abonnementsmodellen.
Webservicebeskeder
De enkelte webservicebeskeder er defineret af STAR/systemforvaltningen i nedestående datastruktur:
MessageType tabellen er den centrale tabel der indeholder selve webservicebesked definitionen. Den har et ExternalMessageTypeId felt som relaterer sig til kodelisten EntityType.
EntityType er en kodeliste med de entiteter der kan rejses webservicebeskeder for i de enkelte forretningsdomæner og kan kun rettes via kodeændringer ligesom andre kodelister. For hver entitet kan der være en webservicebesked. Relationen mellem entitets typen og webservicebesked sættes op når man opretter en ny webservicebesked via EksternKommunikation.BeskedtypeService servicen.
For hver webservicebesked kan der være en eller flere distributionsstrategier. Disse strategier (fx. send til borgers jobcenter, send til borgers a-kasse hvis borger er i kontaktgruppe dagpengemodtager etc.) er defineret i en kodeliste i StrategyType og implementeret i koden. Nye strategier kan derfor kun oprettes via kodeændringer. Angivelsen af hvilke strategier der gælder for en webservicebesked er defineret i relationstabellen DistributionStrategy. Se afsnittet om afsendelsesstrategier længere nede på denne side.
Abonnement på webservicebeskeder
Nedenstående tegning viser datamodellen for abonnementer. Den indeholder en forvaltningsdel som STAR opsætter, der angiver hvilke myndighedstyper der må få de forskellige webservicebeskeder, samt opsætning af systemer med angivelse af hvilke myndigheder de må opsætte abonnement for. Den anden del er aftagerdelen hvor de enkelte aftagere kan oprette abonnement på en webservicebesked og angive hvilken webhook adresse de ønsker at de enkelte beskeder bliver afleveret på.
Abonnementsmodellen indeholder to opsætningstrin - PermittedMessageTypeSubscription og PermittedSystemMessageTypeSubscription. Begge tabeller vedligeholdes af STAR/systemforvaltning. Den første tabel angiver hvilke myndighedstyper der må få hvilke webservicebeskeder, den anden tabel angiver for et specifikt system (fx. Facit) hvilke myndigheder der må aftage en webservicebesked. Så hvor PermittedMessageTypeSubscription fx. angiver at jobcentre må få en CV webservicebesked, angiver PermittedSystemMessageTypeSubscription at Facit må oprette et abonnement af CV webservicebeskeden for jobcenter København. Når en ny webservicebesked oprettes, skal PermittedMessageTypeSubscription opdateres med de myndighedstyper der må få beskedes. Når er nyt system tages i brug, skal det nye system defineres i SubscriberSystem, og i PermittedSystemMessageTypeSubscription skal der angives hvilke myndigheder systemet må oprette abonnementer for.
Den sidste tabel MessageTypeSubscription angiver de enkelte abonnementer, og angiver også hvilken url der skal kaldes på for at aflevere webservicebeskeden. Denne tabel er vedligeholdt af de eksterne systemejere.
Opsætningen af tilladte abonnementer, systemer og egentligt abonnementer sker med servicen EksternKommunikation.AbonnementService
Struktur af en Webservicebesked
Webservicebeskeder er en json struktur der består af to dele: En metadata del og en body del.
De to felter i metadata EntitetId og AendringstypeId udgør tilsammen en identifikation af beskedtypen, og afgøre hvordan body’en ser ud. For det viste eksempel er det en opdatering af et CV, og identifikationen af det opdateret CV’et er givet i feltet EksternIdentifier. Der er således ikke nogen information i body’en og den vil være tom.
Vi vil ikke lave versionering af beskedtypen, men altid serialisere den fulde struktur af metadata og body. Det betyder at aftagere der kun bruger dele af disse, kan deserialisere webservicebeskeden til en klasse der kun indeholder en delmængde af felterne. Fremtidige udvidelser vil være tilføjelser til strukturen og dermed være bagudkompatibel.
Afsendelsesstrategier
Der er identificeret en del modtagere af webservicebeskeder afhængig af hvilken entitet der er tale om, se Afsendelsesstrategier webservicebeskeder pr modtagertype.
En strategi kan være at webservicebeskeden skal sendes til borgeren nuværende jobcenter, en anden at den skal sendes til borgerens a-kasse hvis borgeren er i kontaktgruppe Dagpengemodtagere. En webservicebesked kan have en eller flere strategier knyttet til sig.
De forskellige strategier er defineret i kodelisten StrategyType, og kan opsættes for webservicebeskederne via servicen EksternKommunikation.BeskedtypeService.