Hente filer fra droppsonen

Altinn Downloader leverer brev og vedlegg til droppsonen i deres eget Azure-miljø. Filene ligger der til oppbevaringsperioden løper ut, og det er dere som henter dem derfra. Denne siden beskriver den vanligste rutinen: en planlagt jobb på deres Windows Server som kopierer nye filer ned i en lokal mappe, slik at fagsystemet leser dem fra sitt eget filsystem.

Trenger nedstrøms system i stedet en ekte SMB-fildeling, er levering til filshare alternativet.

Forutsetninger

1. En Windows Server med utgående HTTPS-tilgang på port 443, og diskplass til filene dere henter.
2. En managed identity på serveren, i deres egen Entra-tenant. Kjører serveren som en Azure VM, aktiverer dere system-tildelt managed identity på VM-en, og da er dere ferdige med dette punktet. Står serveren on-premises, gir Azure Arc den samme identiteten gjennom Azure Connected Machine-agenten. Identiteten må høre hjemme i samme tenant som lagringskontoen, altså deres egen. Leverandøren kan ikke bruke sin egen identitet til dette: Lighthouse-delegeringen dekker drift av infrastrukturen, men gir teknisk ikke tilgang til innholdet.
3. Lesetilgang til droppsonen for den identiteten. Dere sender objekt-id-en til leverandøren, som tildeler rollen Storage Blob Data Reader på lagringskontoen. Selve rolletildelingen er en administrativ operasjon leverandøren utfører gjennom delegeringen.
4. AzCopy installert på serveren.

Lagringskontoen har nøkkeltilgang avskrudd. Det finnes ingen lagringsnøkler eller SAS-tokens å legge på serveren, og innloggingen skjer utelukkende med identiteten fra punkt 2.

Slik setter dere det opp

1. Gi serveren en identitet

Aktiver system-tildelt managed identity på VM-en, eller registrer serveren i Azure Arc. Noter objekt-id-en identiteten får, og send den til leverandøren.

2. Verifiser tilgangen manuelt

Når rollen er tildelt, kjør en enkelt kopiering for å bekrefte at både tilgang og nettverk virker:

azcopy sync "https://<lagringskonto>.blob.core.windows.net/altinn" "C:\altinn-post" --recursive=true

Rekkefølgen er azcopy sync <kilde> <mål>. Kilden er droppsonen, målet er den lokale mappen. Snus argumentene, kopierer jobben i stedet den lokale mappen opp i droppsonen, og med sletting slått på fjerner den levert post for å gjøre droppsonen lik den lokale mappen. Kontroller rekkefølgen før første kjøring.

3. Legg jobben på en plan

Legg kommandoen i et skript og opprett en planlagt oppgave som kjører den, for eksempel hver time:

schtasks /CREATE /SC hourly /MO 1 /TN "Altinn Downloader hent" /TR "C:\scripts\hent-altinn.cmd" /RU "NT AUTHORITY\SYSTEM"

AzCopy mellomlagrer innloggingen per Windows-bruker. En oppgave som kjører som NT AUTHORITY\SYSTEM ser derfor ikke en innlogging noen har gjort interaktivt med sin egen konto. Sett miljøvariabelen AZCOPY_AUTO_LOGIN_TYPE=MSI for oppgaven, så autentiserer hver kjøring seg selv med serverens managed identity.

Valg dere bør ta stilling til

Sletting. azcopy sync speiler innholdet. Slår dere på sletting av målet, forsvinner den lokale kopien når filen forsvinner fra droppsonen, og droppsonen sletter automatisk etter den avtalte oppbevaringsperioden. Da kan filer bli borte lokalt før de er behandlet. Vi anbefaler å la sletting være av, og heller flytte filene ut av mappen når fagsystemet har lest dem.

Hvor ofte. Intervallet dere velger legger seg på toppen av pipelinens eget leveringsintervall. Én time er et vanlig utgangspunkt.

Filene er hele når de dukker opp. Et vedlegg blir synlig i droppsonen først når hele filen er skrevet, så en henting kan ikke fange opp en halvskrevet fil. Metadatafilen skrives rett etter selve vedlegget, så en kjøring kan i sjeldne tilfeller hente vedlegget før metadatafilen. Neste kjøring tar den med.

Med nettverksisolasjon

Med tilvalget nettverksisolasjon er lagringskontoens offentlige endepunkt avskrudd. Serveren må da nå droppsonen over en privat nettverkssti, altså VPN eller ExpressRoute med privat DNS, som settes opp som del av onboardingen. Uten tilvalget, som er standard, holder det at serveren har utgående HTTPS.