EksternKommunikation.AbonnementService (2024-4)
- Mads Krøll Didriksen
- 1 Forretningsbeskrivelse
- 1.1 Beskedtyper
- 1.2 Afsendelsesstrategier
- 1.3 Afsendelsesregler
- 1.4 Abonnement
- 1.5 Link til snitfladebeskrivelser
- 1.5.1 Confluence
- 1.5.2 Swagger:
- 1.6 Link til forretningsbeskrivelser
- 2 Metoder
Denne service indeholder webservicekald til at registrere og hente oplysninger vedrørende administration af webservicebeskeder herunder vedligeholdelse af beskedtyper, afsendelsesregler og abonnementer.
Forretningsbeskrivelse
For at styre afsendelse af webservicebeskeder til serviceaftagere anvendes disse metoder til at administrere afsendelsesregler og abonnementer. for en detaljeret beskrivelse af abonnement mm., se Beskrivelse af Webservicebeskeder
Beskedtyper
Beskedtyper håndteres i separat BeskedtypeService - se EksternKommunikation.BeskedtypeService (2023-3)
Afsendelsesstrategier
De generiske afsendelsesstrategier webservicebeskeder kan afsendes efter. f.eks. til borgers eget jobcenter, til borgers bopælskommune, til borgers a-kasse, til borgers a-kasse hvis borger er i kontaktgruppe dagpengemodtager. Disse er foruddefineret og en oversigt kan findes på Afsendelsesstrategier webservicebeskeder pr modtagertype
Afsendelsesregler
Regler for hvilke beskedtype en myndighed må modtager til et specifikt system f.eks. hvad Fasit eller Momentum må modtage i et givent jobcenter. Disse opsættes af STAR og Systemforvalter.
XXXXX Vi skal lige have snakket om et system selv må bestille hvad de må få eller det skal registreres af SF (idag sender de et ark ind)
med andre ord skal systemer ligge på reglen eller abonnementet.
Abonnement
Det abonnement der sikre at en givent system vil modtage den ønskede beskedtype. Det er systemejer der selv sætte abonnementet op.
Link til snitfladebeskrivelser
Confluence
Swagger:
T11: https://eksternkommunikationt11.startest.dk/swagger/index.html?urls.primaryName=Abonnement%20V1
Link til forretningsbeskrivelser
Found 6 search result(s) for Webservicebeskeder.
Metoder
CreateAbonnement (POST /v1/abonnement) - udgår 2023-4
Denne metode anvendes til at oprette et abonnement for en given beskedtype.
Forretningsregler
Slutdato skal være dagsdato eller i fremtiden.
Startdato må ikke være større en slutdato
Webhook url skal være en gyldig url
Abonnement på beskedtypen skal være tilladt
SyncAbonnementer (POST /v1/XXXXXX)
Metoden formål er at kalderen skal eje kendskabet til hvilke abonnementer et givent system skal have. Dermed har STAR ikke ansvar for oprettelsen og nedlæggelsen af abonnementer. STARs serviceaftagere varetager selv hvilke abonnementer og timing for hvornår disse skal træde i kraft. Dette er gældende på alle miljøer - fra Tx til PROD.
Forretningsregler
Alt eller intet:
Ovenstående eksempel viser at de abonnementer som requestet indeholde bliver resultatet efter metodern har returneret. Overflødige abonnementer slettes. Nye abonnementer oprettes.
Denne operation kan kaldes flere gange med samme resultat (Idempotent)
For alle nedenstående regler gælder at hele kaldet udføres som en transaktion. Dvs. at enten bliver alle abonnementer opsat - eller ingen. Dermed kan kalderen ikke stå i en situation hvor kaldet delvist er succesfuldt.
Der kan kun oprettes abonnementer som er gyldige i forhold til de af STAR kontrollerede regler (såsom tilladte abonnementer).
Der kan kun oprettes abonnementer til de systemer som det kaldende systemcertifikat har adgang til.
Håndtering af ikke-modtagede beskeder ved sletning af abonnement (50x eller 40x)
Hvis kalderen sletter et abonnement, hvorpå der identificeres ikke-modtagede beskeder på køen, vil disse beskeder blive slettet uden yderligere forsøg på gensendelse til modtager.
Fejlhåndtering
Ved fejl på kalderens side returneres en fejlstruktur med en komplet liste over de fundne fejl.
Fejlkoder
200: Hvis alle abonnementer er oprettet korrekt returneres OK.
500: Hvis der sker en intern fejl på STARs side returneres HTTP STATUS CODE 500 med den sædvanlige fejlstruktur. Der bliver ikke foretaget nogen ændringer i abonnement opsætningen.
400: Hvis der sker fejl som skyldes et problem i requestet returneres følgende struktur. Der bliver ikke foretaget nogen ændringer i abonnement opsætningen.
Eksempel output (response) ved fejlkode 400
Alle værdier er i eksemplet tilfældige.
{
"errors": [
{
"orgtype": 123,
"orgcode": 456,
"entitytype": 789,
"errorCode": 1001,
"message": "Slutdato er før startdato"
},
{
"orgtype": 321,
"orgcode": 654,
"entitytype": 987,
"errorCode": 1002,
"message": "Denne orgtype har ikke adgang til at abonnere på entity type 987. Tjek webservice metoder xyz for at se hvilke entiteter du må abonnere på"
}
]
}UpdateAbonnement (PUT /v1/abonnement/{abonnementIdentifier})
Denne metode anvendes til at opdatere et eksisterende abonnement.
Forretningsregler
Slutdato skal være dagsdato eller i fremtidigen.
Startdato må ikke være større en slutdato
Webhook url skal være en gyldig url
Abonnementet der opdateres skal eksistere
Abonnementet kan kun opdateres, af samme organisation der har oprettet det
GetAbonnementer (GET /v1/abonnement)
Denne metode anvendes til at hente en liste over eksisterende abonnementer