Droppsone

Droppsonen er standard leveringsmål og grensesnittet mellom Digital Mailroom og tenantens øvrige systemer. Tjenesten leverer vedlegg hit og gjør ingenting annet. Videre prosessering er tenantens ansvar.

Plassering

Hver kilde har sin egen Azure Blob Storage-beholder i tenantens egne lagringskonto. Altinn Correspondence lander i beholderen altinn (standard, konfigurerbart via Sink:Blob:ContainerName). Fremtidige kilder (SFTP, filshare, …) får sine egne beholdere, slik at kildeisolasjonen ligger på lagringsgrensen og ikke i blobnavnet. Tilgang skjer via managed identity.

Leveringstakt

Leveringen er asynkron og intervallstyrt. Pipelinen oppdager og leverer nye vedlegg på en fast tidsplan, så det kan gå noen minutter fra en melding er tilgjengelig i Altinn til filen ligger i droppsonen. Leveringsloggen registrerer Delivered når filen er skrevet til droppsonen. Dersom dere transporterer filene videre fra droppsonen til egne systemer (for eksempel en planlagt henting til en server hos dere), har den videre transporten sin egen takt, i tillegg til leveringsintervallet.

Navnekonvensjon

Stistrukturen i beholderen konfigureres per tenant via Sink:Blob:PathLayout. Standard er en flat dagskatalog (FlatDay); en katalog per correspondence (PerCorrespondence) kan velges for nedstrøms systemer som heller konsumerer per henvendelse enn per dag.

Flat dagskatalog (FlatDay, standard)

{organisasjonsnummer}/{yyyy}/{MM}/{dd}/{kort-id}-{vedleggsnavn}

Eksempel:

926113127/2022/03/02/e24445019bfd-926113127_20220201_20220228.pdf

Vedleggene ligger flatt i dagskatalogen, uten en egen underkatalog per dialog, slik at en hel dag kan masse-håndteres i ett sveip. Koblingen tilbake til dialog og correspondence skjer via metadatafilen ved siden av hver fil.

Katalog per correspondence (PerCorrespondence)

{organisasjonsnummer}/{yyyy}/{MM}/{dd}/{correspondence-id}/{vedleggsnavn}

Eksempel:

926113127/2022/03/02/0197e746-019a-7039-87fc-c5a6b4e5d712/926113127_20220201_20220228.pdf

Alle vedlegg som hører til samme correspondence samles i én katalog, med det opprinnelige vedleggsnavnet som filnavn. Dette passer for systemer som henter én henvendelse om gangen, men gir ikke samme mulighet som den flate strukturen til å masse-håndtere en hel dag i ett sveip.

Skulle to ulike vedlegg i samme correspondence ha identisk vedleggsnavn, beholder den første filen navnet, og den neste får {kort-id}--prefikset i stedet. Ingen filer overskrives noen gang. Metadatafilen ved siden av hver fil identifiserer alltid vedlegget entydig, uavhengig av filnavnet.

Utpakkede zip-vedlegg

Med utpakking av zip-vedlegg slått på leveres hver fil i arkivet som et eget vedlegg med vedleggets kort-id. En mappestruktur inne i arkivet flates ut til filnavnet, slik at faktura/mars.pdf blir faktura-mars.pdf. Ender to filer i samme arkiv med samme navn, også når navnene bare skiller seg i store og små bokstaver, beholder den første navnet, og de neste får et løpenummer foran filendelsen: faktura-mars (2).pdf. Nummereringen følger rekkefølgen i arkivet, så en ny levering av samme arkiv gir de samme filnavnene.

Metadata ved siden av binær

Hvert vedlegg ledsages av en .metadata.json-fil i samme katalog med kildemetadata:

{
  "organizationNumber": "926113127",
  "sender": "tad",
  "senderName": "Tolletaten",
  "serviceResource": "urn:altinn:resource:tad-eksempel",
  "serviceResourceType": "correspondenceservice",
  "dialogId": "0197e746-019a-7039-87fc-c5a6b4e5d711",
  "correspondenceId": "0197e746-019a-7039-87fc-c5a6b4e5d712",
  "attachmentId": "91201248-3305-4b76-8d6a-57e0d9bf77f7",
  "fileName": "926113127_20220201_20220228.pdf",
  "contentType": "application/pdf",
  "createdAt": "2022-03-02T08:00:00+00:00",
  "blobPath": "926113127/2022/03/02/e24445019bfd-926113127_20220201_20220228.pdf"
}

Avsender-koden (sender) er tjenesteeier-koden fra Dialogporten (f.eks. brg, skd, tad, asf), og forblir kun i metadatafilen, ikke en del av blobstien. Altinn 3 garanterer bare denne koden, så sender er alltid med.

senderName er med når avsendernavnet er kjent, og utelates ellers. Det er avsendernavnet dialogen selv oppgir, for eksempel «Namsmannen» på brev med koden skd. Oppgir dialogen ikke noe navn, brukes tjenesteeierens navn fra Altinns offentlige register.

serviceResource er tjenesteressursens URN i Altinns ressursregister. Det er ressursen — ikke den enkelte dialogen — som bærer kravet om sikkerhetsnivå (f.eks. sikkerhetsnivå høy / LOA-high). Felter serviceResource og serviceResourceType gjør det mulig å koble en levert blob tilbake til ressursregisteret i ettertid og dokumentere hvilket sikkerhetsnivå nedlastingen krevde, uten at sinken er avhengig av et ekstra API-kall ved levering.

Samme JSON-skjema vil bli produsert av fremtidige kilder, slik at nedstrøms konsumenter ser én metadata-flate på tvers av kildekanaler.

Oppbevaring og sletting

Vedlegg slettes automatisk etter oppbevaringsperioden (konfigurert via retentionDays i infrastruktur-utrullingen, f.eks. 7 dager). Dette er en Azure Blob lifecycle-regel, ikke applogikk.

Det er tenantens ansvar å konsumere (hente) filer innen oppbevaringsvinduet. Digital Mailroom registrerer i leveringsloggen at filen ble levert. Leveringslogg-posten overlever blob-slettingen og sikrer at filen ikke lastes ned på nytt.

Tilgangsmodell

Tenantens systemer som skal lese fra droppsonen trenger tilgang til Blob Storage-kontoen. Kontoen godtar kun Entra ID-autentisering: delt nøkkel-tilgang er avskrudd, så storage-nøkler og SAS-tokens signert med kontonøkkelen avvises. Tilgangsmønstrene er:

Managed Service Provider konfigurerer droppsonen; tilgang for tenantens nedstrøms systemer er tenantens ansvar.

Fremgangsmåten, fra rolletildeling til en planlagt henting, står i Hente filene fra droppsonen.

Hva som ikke leveres

Digital Mailroom leverer binære vedlegg pluss en .metadata.json-fil med kildemetadata (filnavn, dialog-id, avsender, dato m.m.). Tjenesten:

• Gjør ikke OCR eller tekstutvinning.
• Gjør ikke klassifisering av innhold.
• Svarer ikke tilbake til Altinn på tenantens vegne.

Disse behovene dekkes av tenantens egne nedstrøms systemer.