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.

Metoder

CreateAbonnement (POST /v1/abonnement)

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

SyncWebhookAbonnementer (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