Jens arbejde

NgDP MeMO - rige returdata med ReplyData sikrer at svar kommer det rigtige sted hen

Jens Bruntt

15. jun 2020 • 7 min read

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 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 17/4-2020. MeMO er offentligt tilgængelig i version 0.9. 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 :

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.

Hvis jeg vælger at vedhæfte 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 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. Det undrer mig iøvrigt at værdien ikke hedder generatingSystemID.

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#

replyData1 - replyData4 er fire gør hvad du vil-felter. Du kan som afsendersystem eksempelvis vælge at replyData1 altid indeholder dit følsomhedsniveau, hvis det er en vigtig returdata-type.

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.

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?

En vigtig baggrund for at vi interesserer os meget for ReplyData er, at vi med Næste generation Digital Post maksimalt har fem modtage-systemer, for hver myndighed der modtager Digital post. Men vi kan have ubegrænset mange afsender-systemer.

Så et system der kan sende har ikke nødvendigvis mulighed for også at modtage svar direkte fra NgDP-platformen. Der vil ofte stå en teknisk komponent mellem NgDP-platformen og de IT-systemer der ønsker at modtage Digital Post. Convergens lever af at sælge sådan en komponent. Det kan man kalde en Input-manager.

Input-manageren vil nu 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.