Introduktion til returdata

I denne blog vil jeg forklare hvordan man bruger returdata i Meddelelsesmodellen (MeMo) for Næste generation Digital Post (NgDP).

Det at bruge returdata handler om at afsender og modtager af Digital Post hjælper hinanden med at sikre at Meddelelser der er svar på andre Meddelelser kan komme godt på plads.

Som afsender af en Digital Post kan man vælge at inkludere returdata i den sendte Meddelelses datastruktur. De returdata man sender vil komme uberørte tilbage når den man sendte til svarer tilbage.

Returdata kan være information om hvilket system der oprettede Meddelelsen (for eksempel ESDHsystemets navn), og om hvilken ESDHsystem-sag (for eksempel et sagsløbenummer) Meddelelsen hører til. Disse oplysninger kommer så tilbage når modtageren svarer, og vi kan derfor med ret stor sikkerhed vælge at placere/journalisere dette svar på baggrund af returdata i svaret.

Meddelelsesmodellen tillader, at den der svarer, selv skriver egne returdata på svaret, så der nu er to sæt returdata, og denne liste med returdata kan blive længere og længere, efterhånden som en Digital Post-udveksling om samme emne fortsætter.

Blogserien

Bloggen her er den fjerde i en serie af blogs jeg skriver om NgDP. Nederst på siden er der links til de andre blogs i serien.

Det jeg skriver er baseret på hvad jeg ved om MeMO den 26/5-2021. MeMO er offentligt tilgængelig i version 1.1. Jeg har en forventning om at der kun vil være ganske få ændringer i formatet frem mod den færdige version.

MeMo og returdata

Her ses den fulde MeMO-struktur - klik på figuren for høj opløsning:

I denne blog er det MessageHeaderens ReplyData-område som jeg går i dybden med.

Når et system skal svare på en Digital Post der indeholder ReplyData

Vi starter lige i den anden ende af forsendelsen: Jeg har et IT-system, og i dette vil jeg nu besvare en Digital Post Meddelelse.

Hvis der på den Digital Post Meddelelse jeg vil svare på er en eller flere ReplyData-instanser, så skal jeg, på den MeMO jeg nu danner, vedlægges en uberørt kopi af samtlige de ReplyData-instanser jeg modtog.

Jeg kan så nu, på min besvarelse, vælge også at vedlægge en ny instans af ReplyData. Det er en mulighed, jeg skal ikke gøre det, men jeg bør gøre det.

Hvis jeg vælger at vedlægge min egen ReplyData-instans så er det fordi jeg også selv ønsker at kunne benytte mig af de muligheder det giver mig for at behandle de svar jeg modtager i fremtiden.

Bemærk: Der er (desværre) ikke nogen sikring af at svar-systemet rent faktisk husker at medsende de originale ReplyData. Det er det enkelte aftager-system som skal opføre sig ordentligt. 

Når et system skal sende en ny Digital Post med ReplyData

Tilbage til begyndelsen: Jeg har et system hvorfra jeg ønsker at sende en Digital Post Meddelelse. Og jeg ønsker at medsende ReplyData. Og det er ikke et svar på en modtaget Meddelelse.

Jeg vil nu løbe gennem de felter jeg kan forholde mig til om jeg vil bruge eller ej. Der er et enkelt felt jeg skal udfylde, hvis jeg bruger ReplyData: messageUUID.

messageID skal være den samme messageID som står i MessageHeader på den Meddelelse jeg er ved at generere. Hvis der i MessageHeader ikke er en messageID så bør den udelades i min ReplyData-instans. messageID er - både i MessageHeader og her - en slags supplement til Meddelelsens messageUUID. Ved at inkludere den kan jeg - når jeg får svar - finde frem til min egen registrering af den oprindelige Meddelelse.

messageUUID skal udfyldes hvis vi opretter vores egen ReplyData-instans. Værdien vi skriver i messageUUID skal være den samme som den værdi der står i den messageUUID der findes i vores Meddelelses MessageHeader. Det er denne messageUUID der entydigt binder vores ReplyData-instans sammen med den Meddelelse vi er ved at danne. Når vores Meddelelse i fremtiden bliver besvaret og vi derfor modtager svaret, så kan vi i svaret kigge i de ReplyData-instanser der findes og dén ReplyData-instans som indeholder messageUUIDen som vores oprindelige Meddelelse havde - vil være den ReplyData-instans vi genererede da vi sendte den oprindelige Meddelelse. Når der er blevet svaret frem og tilbage mange gange bliver denne messageUUID helt central i at holde styr på hvad der er svar på hvad. Når jeg får svar kan jeg, med denne værdi, finde frem til min egen registrering af den oprindelige Meddelelse.

replyUUID giver det ikke mening at udfylde når vi er ved at oprette første Meddelelse i en tråd. Den skal derfor være tom.

senderID bør udfyldes med den samme værdi som står i MessageHeader.Sender.senderID på den Meddelelse som vi er ved at generere. Altså et CVRnummer hvis jeg er en myndighed eller en virksomhed. 

recipientID bør udfyldes med den samme værdi som står i MessageHeader.Recipient.recipientID på den Meddelelse som vi er ved at generere. Altså et CVRnummer hvis jeg er ved at sende til en myndighed eller en virksomhed og et CPRnummer hvis jeg er ved at sende til en borger.

caseID kan bruges til at angive en sagsID i det system som genererer Meddelelsen. Hvis man bruger MessageHeader.ContenData.CaseID, så er det sandsynligvis samme caseID der skal bruges begge steder. Hvis det genererende system er et ESDH-system er det oplagt at det er en system-ID der unikt identificerer den sag der sendes fra.

contactPointID. Jeg vil klart mene, at tanken med denne er at man angiver en contactPointID som man også - i samme Meddelelse - angiver i MessageHeader.Sender.ContactPoint.contactPointID. Altså: Det er afsenderens (mit) kontaktpunkt, som jeg har bedt modtageren om at svare tilbage gennem. Ved at angive samme contactPointID her i ReplyData får jeg den jo tilbage uberørt, når der svares.

generatingSystem er stedet hvor man bør angive hvilket system der er ved at generere Meddelelsen. Hvis det er ESDHsystemet SBSYS, så kunne vi her skrive "SBSYS". Samme værdi bør også være at finde i MessageHeader.Sender.AttentionData.GeneratingSystem.generatingSystemID. Det at bruge generatingSystem her vil give os forbedrede muligheder for at lade svar finde tilbage til samme system der blev sendt fra.

comment er ikke beskrevet. Som jeg ser det, kan den bruges til 'hacks': Hvis den returværdi vi ønsker at sende afsted ikke passer ind i andre ReturnData-felter, så kan vi skrive dem her. Man bør øverveje at bruge en model hvor sådan en værdi præfixes/suffikses med noget der gør at man med sikkerhed ved hvilket felt der er tale om. Eksempelvis #følsomhedsniveau#2#følsomhedsniveau#. Men inden man hacker, så skal man hellere se på AdditionalReplyData.

AdditionalReplyData er fire sæt af "gør hvad du vil-felter". Du kan som afsendersystem eksempelvis vælge at sende et følsomhedsniveau med, hvis det er vigtigt at få tilbage.

Når et system skal sende en svar-Digital Post med ReplyData

Lad os sige, at vi har et system der har modtaget en Digital Post Meddelelse, og nu skal vi herfra sende et svar. Og vi ønsker at medsende egne ReplyData. For det skal vi jo.

Det første vi skal gøre er at se på den Meddelelse vi svarer på: Er der nogen ReplyData-instanser på den?

Hvis der er en eller flere ReplyData-instanser, så skal vi kopiere dem alle, uberørte, ind på den Meddelelse vi skal til at sende. De skal slet ikke modificeres, bare gentages som de så ud da vi modtog dem.

Så opretter vi en ekstra ReplyData-instans. Det er 'vores' ReplyData-instans - den vi selv skal skrive data ind i.

I vores ReplyData-instans skal vi sikre at vi i feltet replyUUID skriver UUID på den Meddelelse som vi er ved at svare på. Det er ret vigtigt for at tingene hænger sammen. Denne UUID finder vi i MessageHeader.messageUUID i den Meddelelse som vi er ved at svare på.

Vi skal også sikre os (og dette er et krav) at vi i vores ReplyData-instans udfylder messageUUID. Her skal stå præcist den samme værdi som vi skriver i MessageHeader.messageUUID på den Meddelelse som vi er ved at generere.

De øvrige felter bør bruges som beskrevet i det foregående afsnit.

Hvad er det vi kan når vi har udfyldt ReplyData - hvorfor gøre det?

ReplyData handler om at sikre at når vi modtager et svar, så kan vi lægge svaret ind på rette sted. Typisk tilbage til det Fag- eller ESDH-system som vi oprindeligt sendte Digital Post ud fra.

En Input Manager kan modtage indgående Digital Post som skal sendes videre til en række IT-systemer i modtager-organisationen. Og for at kunne finde ud af hvilket IT-system der skal have en Digital Post har vi brug for metadata. Og hvis vi nu for eksempel har en ReplyData hvori der står et generatingSystem (for eksempel 'SBSYS'), så er vi rigtigt langt. Ved at skrive nogle gode returdata på vores udgående Digital post gør vi at Input-manageren kan placere svar på den rette hylde. Og jo rigere data jo bedre; har vi for eksempel en caseID, så kan Input-manageren journalisere svaret direkte til den relevante sag.

Hvis vi ikke er i en myndighed, men i stedet er i en virksomhed, og hvis vi har flere interne systemer der sender udgående Digital Post, så bliver det endnu mere vigtigt at medsende returdata. En virksomhed kan nemlig kun have et enkelt modtager-system til den indgående Digital Post.

Om returdata uden garanti

Som jeg nævnte tidligere, så er der ikke garanti for at man får sine returdata tilbage.

Når den man sender Digital Post til er en borger, så vil jeg mene at man med sikkerhed kan forvente at returdata kommer tilbage som de skal. For her er det jo borger.dk der implementerer svar-funktionaliteten i en visningsklient.

Eftersom der ikke er noget MeMO-politi, så bør du - desværre - sørge for at din input-manager kan klare sig uden returdata.

Convergens' Input-manager har indbygget forskellige faciliteter til at styre Digital Post ind på rette hylde, selv når metadata er meget "tynde".  Det er sådan noget som for eksempel at lede efter stikord i teksten på den Meddelelse der skal placeres, kombineret med at kigge på hvem afsenderen af Meddelelsen er. "Børneattest" i teksten kombineret med "Rigspolitiet" siger eksempelvis en del om hvad indholdet er.

Andre blogs i serien om Næste Generation Digital Post (NgDP)

Denne liste vil blive opdateret efterhånden som der skrives nyt.

Introduktion til Næste generation Digital Post

NgDP MeMO - adressering med AttentionData og ContactPoint

NgDP MeMO - afsenderoplysninger med AttentionData og ContactPoint