FORSLAG TIL MASSEAFSENDELSE Digital Post og Fjernprint 2015-03-11
Dagsorden 1. Velkomst 2. Nuværende OIO-rest 3. Udfordringer 4. Afrunding
Nuværende OIO-REST løsning Digital post De nuværende Digital Post (DP) understøtter to afsendelser: 1. Enkeltforsendelser Leveres en ad gangen til DP. Videresendes normalt til modtagers postkasse med det samme Valideringer foretages synkront, og eventuelle fejl returneres i til afsenderen som svar på afsendelseskaldet 2. Masseforsendelser Leveres som enkeltbeskeder. Afsendelserne opsamles hos DP og eksekveres på et senere tidspunkt (som regel i løbet af natten) Validerer XML synkront, men alle andre valideringer sker asynkront. Afsender skal selv periodisk afhente status for at identificere eventuelle fejl
Nuværende OIO-REST løsning Fjernprint De nuværende Fjernprint (FP) understøtter to afsendelser: 1. Enkeltforsendelser Leveres en ad gangen til FP. Ekspederes til forsendelse med det samme Valideringer foretages både synkront og asynkront. Afsender skal selv periodisk afhente status på asynkron validering/ tracking for at identificere eventuelle fejl 2. Masseforsendelser Leveres som en sekvens af leverancer af forsendelser med fælles konfiguration. Hver leverance kan enten udgøre en enkeltforsendelse eller en samling af enkeltforsendelser der dog maksimalt kan udgøre 10 Mbyte. Afsendelserne opsamles hos FP indtil afsendersystemet indikerer at leverancen af masseforsendelsen er komplet. Validerer XML synkront, men alle andre valideringer sker asynkront. Afsender skal selv afhente status på asynkron validering/ tracking for at identificere eventuelle fejl
Udfordringer Filbaseret overførsel er ikke en del af standarden. (De nuværende løsninger har dog implementeret egen løsning) Den nuværende OIO-REST standard understøtter ikke at mange beskeder kan afsendes i samme kald, da der er en øvre grænse på størrelsen. Den nuværende FP-integration benytter en OIO-REST definition der er væsentlig forskellig fra DP-Standarden
Løsningsbehov Kommunerne ønsker at der defineres en fælles standard for afsendelse af post, uanset hvilken leverandør der måtte tilbyde en løsning, og uanset om der er tale om digital eller fysisk forsendelse Det skal være muligt at afsende en bunke post uden at skulle implementere opdeling i mindre transmissioner Mulighed for at eliminere den resourcekrævende BASE64 transformation af samtlige forsendelser i en bunke
Afsendelse af flere meddelelser i et kald Da web-services har begrænset kapacitet hvad angår mængden af data, foreslås en løsning hvor data i stedet overføres via SFTP Til kontrol af overførslen benyttes et efterfølgende web-service kald. Det er kaldet og ikke filoverførslen der igangsætter validering af modtagelsen i DP. Processen er følgende: 1. Afsendersystemet danner masseafsendelse i en fil 2. Afsender overfører filen til DP/ FP med SFTP. 3. Afsender kalder masseafsendelse på DP/ FP med OIO- REST med Fil reference, DP/ FP tjekker at filen kan læses ud fra referencen og returnerer et OK eller fejlbesked. 4. Hvis filen kan læses, validerer DP/ FP filen og behandler hver enkelt besked som om de var afsendt enkeltvis. 5. Afsender henter kvitteringsliste med OIO-REST, når denne er klar. 6. Afsender tjekker kvitteringsliste.
Forsendelseslayout Header Enkeltforsendelse Bilag 1 Bilag 2... Bilag n Header Masseforsendelse Parametre (XML) Binær fil (FTP) Parametre (XML) Binær fil (FTP) Bilag 1 Bilag 2... Bilag n Modtager detaljer Meddelelse Liste af Modtager detaljer Meddelelse 1 Meddelelse 2... Meddelelse n Det er afsender der beslutter om data skal sendes i separat binær fil. Det er således stadig muligt at inkludere teksten som BASE64 i XML og udelade filtransporten. Hvis man f.eks. skal afsende mindre enkeltforsendelser benyttes den nuværende enkeltforsendelsesmetode.
Binær fil Parameter (XML) Bilag 1: - Offset - Længde - Tjeksum Bilag 2: - Offset - Længde - Tjeksum Header Detaljer Meddelelse1: - Offset - Længde - Tjeksum Meddelelse2: - Offset - Længde - Tjeksum Binær fil (FTP) {... (Bilag 1 data)..... } {... (Bilag 2 data).. } {....... (Meddelelse 1 data)... } {....... (Meddelelse 2 data)...... } De enkelte binære filer pakkes sammen i en ubrudt datastrøm. Offset udgør byteadressen hvor filen starter, og længden er antal bytes i filen. Tjeksum benyttes til at validere at filen er udtrukket korrekt af strømmen Størrelsen af Parameter listen er stadig underlagt de 10 Mbyte, men da detaljer kan reduceres til CPR/ CVR, Offset, Længde, Tjeksum kan der sendes et meget stort antal beskeder ad gangen. Dette mønster muliggør også at størrelsen på den enkelte besked med bilag kan overstige 10 Mbyte
Forsendelse header Forsendelsesheader indeholder fremover følgende information: Forsendelses ID. (UUID) Skal være unik for en forsendelse Relateret fil reference (Kun hvis binær fil overføres via FTP) Afsenderidentifikation Kanalvalg (Digital, Fysisk, Automatisk via tilmelding) Forsendelsestype/ Meddelelsestype Transaktionsparametre Dokumentparametre (Indhold afhænger af kanalvalg) Bilagsamling. Bilag defineres som Filindhold (Base64), Filreference (Offset+Længde+Tjeksum) eller URI
Forsendelse detaljer En forsendelse indeholder fremover følgende information for hver meddelelse i forsendelsen: Afsendelses ID for meddelelsen. Unik indenfor forsendelsen Modtager (CPR/ CVR/ Postadresse + Landekode) Modtager postadresse skal kunne hentes fra CPR/ CVR Filindhold (Base64), Filreference (Offset+Længde+Tjeksum) eller URI Metadata omkring dokumentet Al øvrig information omkring forsendelsen hentes fra den fælles header. Såfremt der er behov for detaljer omkring mange forsendelser, kan størrelsen på den enkelte forsendelse reduceres til blot ID + CPR/ CVR + Filreference. Det muliggør forsendelse af op til ca. 200.000 meddelelser i et 10 Mbyte kald.
Afrunding Spørgsmål?
Kontakt Kommentering af materiale og opfølgende spørgsmål til Nicolai Nørr Korolkiewicz Mail: nko@kombit.dk tlf: 23 27 58 65