Implementere bruk av manifest-fil for Overgangsløsning i Formidling

[RagnarFatland-Avanade]

Bakgrunn

I sammenheng med møter med Kartverket og systemleverandører som benytter tjenestene Tinglysning og AFPant, så er det avdekket at bruk av Manifest-fil i zip-arkivet som utveksles er nødvendig for overgangsløsning, da det utveksles viktige metadata som ellers ikke er tilgjengelig for mottakerne.
Avsenderene hadde blandet forhold til om de eksplisitt opprettet manifest i filen i tillegg til å sette verdiene i Initialize; uansett ville Altinn 2-implementasjonen lage en manifest-xml og overskrive evt. eksisterende manifest i zip-arkivet.

Det ble derimot bekreftet at informasjonen som blir lagt i feks. PropertyList er viktig og prosessdrivende, og det er derfor et krav at manifest videreføres for overgangsløsning skal kunne brukes.
Det er også enighet om at Manifest-fil er unødvendig for de som går via Altinn 3 API, da nye API tilgjengeliggjør alle metadata i GetFileTransferOverview.

Vi må derfor reprodusere Altinn 2 logikk for manifest.xml.

Eksempel på manifest-fil:

<?xml version="1.0" encoding="utf-16"?>
<BrokerServiceManifest xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://schema.altinn.no/services/ServiceEngine/Broker/2015/06">
  <ExternalServiceCode>4752</ExternalServiceCode>
  <ExternalServiceEditionCode>1</ExternalServiceEditionCode>
  <SendersReference>ref:1245</SendersReference>
  <Reportee>837884942</Reportee>
  <SentDate>2024-10-18T08:43:48.453</SentDate>
  <FileList>
    <File>
      <FileName>coverletter_123456.xml</FileName>
    </File>
    <File>
      <FileName>signedmortgagedeed_123456.sdo</FileName>
    </File>
  </FileList>
  <PropertyList>
    <Property>
      <PropertyKey>senderPhone</PropertyKey>
      <PropertyValue>12345678</PropertyValue>
    </Property>
    <Property>
      <PropertyKey>senderName</PropertyKey>
      <PropertyValue>Ola Normann</PropertyValue>
    </Property>
    <Property>
      <PropertyKey>messageType</PropertyKey>
      <PropertyValue>SignedMortgageDeed</PropertyValue>
    </Property>
    <Property>
      <PropertyKey>notificationMode</PropertyKey>
      <PropertyValue>AltinnNotification</PropertyValue>
    </Property>
    <Property>
      <PropertyKey>senderEmail</PropertyKey>
      <PropertyValue>ola.normann@norge.no</PropertyValue>
    </Property>
    <Property>
      <PropertyKey>coverLetter</PropertyKey>
      <PropertyValue>XmlAttached</PropertyValue>
    </Property>
  </PropertyList>
</BrokerServiceManifest>

Overordnet endring

Overgangsløsningen AS-IS før denne endringen:

• Rører ikke innholdet i filen, som er et zip-arkiv med flere filer.
• Dersom avsender har opprettet en manifest-fil i arkivert, blir det ikke endret.

Endringen medfører ny oppførsel:

• Åpne zip-arkiv
  • Slette evt. eksisterende Recipients.xml
  • Slette evt. eksisterende Manifest.xml
  • Oppretter en Manifest.xml fil og lagrer den i arkivet
    • Basert på metadata om FileTransfer som ble satt i Initialize + FileList basert på hva som ligger i zip-arkivet. (FileList er deprecated i A3).
• Lagre arkiv
• Oppdater FileTransfer.CheckSum ??

Gjenbruk
Man kan kopiere/gjenbruke kode fra Altinn 2 kodebasen (krever tilgang til Altinn 2 Azure Devops repo), men med justeringer for Altinn 3 stack.

• Altinn 2 BrokerServiceManifest
• Altinn 2 BrokerSI.UploadFileStreamed
• Altinn 2 BrokerSI.CreateManifestXML
• Altinn 2 BrokerSI.UpdateMetadataFilesInZipArchive

Teknisk avklaring internt

Siden manifest-fil kun er nødvendig for de konsumentene som benytter seg av LegacyFileTransferController.DownloadFile, men avsendere kan laste opp filen via både LegacyFileTransferController og vanlig FileTransferController så er det litt forskjellige steder man kan vurdere å legge logikken.

• Hvis vi skal opprettholde at filen skal være mest mulig immutable så bør nok endringen skje etter UploadFile har lagret strømmen til storage, men før Publish for både legacy og "ikke-legacy".
  • Dette vil kreve kjennskap til om Ressursen er tilknyttet overgangsløsningen, noe som ikke er en property i løsningen i dag, da det ligger på Altinn 2 siden.
    • Vil kunne løses med en "IsLegacy"-property i ResourceController, som TE kan endre med PUT-kallet for å skru det av ved dekomisjonering.
• Dersom man utfører endringen ved LegacyController.DownloadFile isoleres til endringen til der den behøves:
  • Men man brekker strømmen og innfører noe ustabilitet ved det som ellers er en enkel operasjon i dag.

Beslutning: Gå for implementering i DownloadFile, evt. retrett til UploadProcessing dersom ytelse/stabilitet ikke er god nok men legg til feature-toggle på Resource-nivå:

• bool UseManifestInLegacy, default = false

Dokumentasjon:

Man bør også oppdatere relevant dokumentasjon til å henvise til bruk av feature-toggle.

• https://docs.altinn.studio/nb/broker/broker-transition/technical-overview/
• UpdateResource-eksempel i Postman?

[leogasnier]

settes på kartverkets tjenester, IKKE politiet (enn så lenge) :)

[RagnarFatland-Avanade]

@leogasnier

settes på kartverkets tjenester, IKKE politiet (enn så lenge) :)

Funksjonaliteten er kun relevant for overgangsløsning (og kun ved Download-kallet) slik som den er skissert per nå.

• Har Politiet tenkt å bruke overgangsløsningen, og hvis tilfelle, har man avklart om de har behov for manifest eller ikke?

@Ceredron stilte spørsmål om hvor mye vi bør fremheve denne funksjonaliteten i dokumentasjon, gitt at det gir ekstra ressursbruk i løsningen når den slås på.

Hva tenker du @leogasnier