Gå til hovedindhold
RA.Om rammearkitekturen

Beskeder

I rammearkitekturen arbejder vi med med to typer beskeder: Hændelsesbeskeder og Meddelelsesbeskeder. Disse typer beskeder er asynkrone integrationsmønstre, der understøttes af Beskedfordeleren, og det er vigtigt at forstå den konkrete forskel på disse 2 mønstre.

Ældre end 12 mdr.

Indhold

    Hændelsesbeskeder

    Hændelsesbeskeder sendes til beskedfordeleren, når der er sket registreringer på et forretningsobjekt,. Eksempelvis udsender CPR hændelsesbeskeder, når der sker ændringer i personobjektet, da det er dem, der registrerer på det. Andre kan opsætte et abonnement, der beskriver, at de gerne vil have besked om ændringer i Personobjektet og kan herudover sætte andre kriterier, som yderligere skal være opfyldt. Eksempelvis at Ansvarlig Aktør skal være Rødovre Kommune. De vil så modtage beskeder, når der sker Personændringer i Rødovre.

    I dette mønster er det vigtigt at pointere:

    • Afsender og modtager kender i princippet ikke hinanden og afsender ved ikke om der findes en modtager.
    • Afsenderen ved ikke (som udgangspunkt) hvem, der abonnerer på sine beskeder.
    • Det er det forretningsobjekt (den nyeste udgave), afsenderen har ændret på, som medsendes i beskeden (det er det objekt, der er ændret).
    • Når beskeder er blevet fordelt af beskedfordeleren, påfører beskedfordeleren ”Abonnement” i beskedkuverten, så modtageren kan se hvilket abonnement, der gav anledning til denne besked.

    Meddelelsesbeskeder

    Meddelelser anvendes, når man vil sende information fra en part til en anden. Meddelelsesformatet er defineret af modtageren. Det svarer til at modtageren har defineret en blanket, som han beder afsenderen om at udfylde, hvis han vil have modtageren til at gøre noget. Et eksempel kunne være, at afsenderen ønsker at sende en udbetalingsanmodning til et udbetalingssystem. Afsenderen kender ikke nødvendigvis det konkrete udbetalingssystem, men véd, at der findes et sådant til at modtage meddelelsen. Dette kan håndteres i beskedfordeleren ved at Afsenderen påfører et kendt abonnement på sin besked. Dette abonnement kunne f.eks. være ”Udbetaling”. Afsenderen ved at denne meddelelse, indeholdende en udbetalingsanmodning, skal til et udbetalingssystem og påfører derfor dette abonnement.

    Udbetalingssystemer abonnerer naturligvis på ”Udbetaling og får dermed denne meddelelse. I abonnementet kan det yderligere kvalificeres at man kun vil have Udbetalingsanmodninger, når Ansvarlig Aktør er Rødovre. Dermed vil Rødovre kommunes Udbetalingssystem modtage Rødovres udbetalingsanmodninger og ikke andres (og omvendt). Man kunne også opsætte et abonnement, der f.eks. hedder ”KMD Udbetaling” og dermed kvalificere det system, som meddelelserne skal modtages af.

    I dette mønster er det vigtigt at pointere:

    • Afsender og modtager kender ikke (nødvendigvis) hinanden fysisk, men véd at der findes en modtager. De kender begge til samme abonnement.
    • Afsenderen ved at der er en, som abonnerer på samme abonnement, som de sender meddelelserne ud under (ellers fungerer den samlede proces ikke)
    • Det er et forretningsobjekt som Modtageren ejer, som afsenderen udfylder og sender til Modtageren. I dette eksempel en Udbetalingsanmodning, som ”ejes” af Udbetaling.
    • Abonnement er allerede udfyldt i beskedkuverten og indgår i filtreringsinformationen på lige fod med andre filteringsattributter.

    Kontakt

    Chefkonsulent

    Peter Thrane

    IT-Arkitektur & Standarder

    Telefon: +45 3370 3553

    E-mail: pth@kl.dk