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. For nedstrøms systemer som leser fra et lokalt Windows-filsystem finnes et alternativt leveringsmål med samme navnekonvensjon og metadata: levering til filshare.

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 filshare som synkroniseres til deres servere), har den videre transporten sin egen synkroniseringstakt, 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.

Metadata ved siden av binær

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

{
  "organizationNumber": "926113127",
  "sender": "tad",
  "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.

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.

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.