Bare lidt løst og fast omkring hvordan vi i Dafolo lige nu nærmer os overgangen til det nye Digital Post (NgDP).

Jeg har lige nu fem åbne sager hos Netcompanys NgDP-support. Nogen er mere alvorlige end andre. Den ene af dem, tror jeg, er rettet (og måske er rettelsen skyld i den som jeg har først på min liste her), så den taler vi ikke om.

Efter de åbne sager kommer der lidt andet løst og fast.

Fejl: Svar der kommer fra borger.dk indeholder ikke korrekte messageUUID i ReplyData - DPET-3069

Her er vi i den meget alvorlige ende af spektret. Det er en vigtig funktionalitet, som ikke virker på NgDP-platformen.

Når man svarer på et MeMo, er der beskrevet nogle forretningsregeler for, hvordan den der svarer skal gøre for at sikre, at tråden bevares. Det er ReplyData vi taler om.

Jeg har skrevet om hvordan det (bør) fungere her: NgDP MeMO - rige returdata med ReplyData sikrer at svar kommer det rigtige sted hen

Og hvad er det så, vi ser?

Når en borger svarer på en Digital Post, så ser vi, at den ReplyData-instans som borger.dk visningsklienten danner ikke følger specifikationen. Jeg har formuleret det, der skal ske sådan:

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.

Men det som vi ser, er at ReplyData-instansen som dannes af borger.dk-visningsklienten ikke har samme UUID stående i ReplyData-instansens MessageUUID, som der står i MessageHeader.messageUUID.

Og hvad er så problemet med det?

Godt eksempel: Når et ESDH-system sender en Digital Post til en borger, og borgeren svarer, så kan vi ikke journalisere svaret på den samme sag, som vi sendte fra. Vi kan ikke automatisere det.

Vi ved, at det har fungeret som det burde, for vi har set hele flowet fungere fra ESDH til borger tilbage til ESDH. Men det fungerer ikke nu.

Fejl: MeMo_Schematron og dermed også MeMoLib har forkert regel for TechnicalDocument - DPET-3095

Dette er i småtingsafdelingen.

Når man sender eller modtager et MeMo, så er det i følge Schematron-definitionen tilladt at sende nogle filtyper, som ikke burde være tilladt i den del af MeMo som hedder TechnicalDocument.

Det er den del af fil-området, som er reserveret til special-filer. Så ikke hoveddokument eller bilag.

Her burde man kun kunne sende XML-filer, men man kan eksempelvis sende et word- eller HTML-dokument.

Netcompany og Digitaliseringsstyrelsen kender til problemet, og er ved at rette det.

Fejl: Afsendersystem på Legacysnifladen: Savner dokumentation for encoding i MeddelelseTitelTekst - DPET-1801

Ikke super-alvorligt, men irriterende.

Når vi sender Digital Post via overgangssnitfladen. Altså den snitflade hvor vi kan sende i det gamle DP1/DP2-format. Så kan vi ikke sende med nogle specialtegn i overskriften.

Det er tegn som disse:

< - mindre end

> - større end

& - og

I vores sende-løsninger (dem der bruger overgangssnitfladen) fjerner vi simpelthen disse tegn fra overskrifter, da vi ikke ved, hvornår der kommer en rettelse.

Fejl: Nyoprettet System kan ikke hente post - DPET-3008

Jeg opfatter den som ret alvorlig.

Hvis man i Administrativ Adgang opretter et System, som er kombineret afsender- og modtage-system, så kan dette system ikke modtage post.

Når vi sætter sådan et system op til at bruge PULL-modtagelse, så får vores system en fejlkode 403.

Vi ved, at der arbejdes på at gøre noget ved dette.

Overvejelser omkring overgang fra e-boks' til NetCompanys sende-snitflader

Vi driftsovervåger ca. 40 kommuner og en regions afsender- og modtagersystemer.

Vi vil sørge for ikke at sende på e-boks' snitflade i god tid inden lukketid. Vi har ikke fastsat tiden endnu.

Vores brugere vil ikke opleve det som nedetid, for udgående Digital Post vil blot ligge i kø.

Men vi har diskuteret, hvornår vi så begynder at sende til NgDP-snitfladen. Vi kan vælge at sende før 21/3-2022. Sender vi på snitfladen før 21/3, så ligger posten og venter på åbningsdagen.

Vi hælder kraftigt til ikke at sende på de nye snitflader, før vi er nået helt frem til den 21/3.

Hvorfor: Så kan andre få lov til at finde eventuelle tidlige problemer. Og vi skal ikke til at rode med at hugge bremsen i, fordi Digitaliseringsstyrelsen beder alle om at holde igen, mens der arbejdes på at fikse tidlige problemer.