Loading…
Tilbage

FAQ: OIORASP Implementeringen


I denne resource opsamles typiske spørgsmål og svar der drejer sig om referenceimplementationerne af OIORASP profilen.

Hvis ikke andet er angivet gælder det efterfølgende for både RASP .NET og RASP Java.

Opdateret maj 2017.

1: Hvilke dokumenttyper understøttes?
De dokumenttyper OIORASP implementeringen understøtter fastlægges gennem OIORASP konfigurationsfilen RaspConfiguration.xml [1].

Hver dokumenttype beskrives via en sektion i konfigurationsfilen (DocumentTypeConfig). Sektionen indeholder information, der muliggør identifikation af typen på et behandlet dokument, om dokumentet er validt og muliggør udtræk af information fra dokumentet såsom modtageren.

Hvis man bruger den i bibliotekerne medfølgende konfigurationsfil understøttes OIOXML elektronisk regning; faktura og kreditnota samt alle OIOUBL 2.02 dokumenttyper (Application Response, Catalogue, CatalogueRequest, CatalogueItemSpecificationUpdate, CataloguePricingUpdate, CatalogueDeletion, CreditNote, Invoice, Order, OrderCancellation, OrderResponse, OrderChange, OrderResponseSimple, Reminder og Statement).

2: Hvilke typer af afsender og modtageridentifikation understøttes?
RASP bibliotekerne understøtter alle typer af afsender og modtageridentifikation som angivet i RASP Profile FAQ og dermed alle typer inkluderet i OIOUBL kodelisten EndpointID – dog med undtagelse af CPR-nummer. CPR-nummer understøttes kun som afsender, da man ikke kan registrere private personer i NemHandelsRegisteret, da CPR nummer er personhenførbar information. I OIORASP headeren vil afsenderen blive sat til certifikatets CVR-nummer, hvis afsenderen er identificeret ved et CPR-nummer. Dette forventes dog ændret i fremtidige versioner af RASP bibliotekerne, så værdien i stedet sættes til anonymous.
RASP konfigurationsfilen specificerer, hvordan afsender og modtageridentifikation skal hentes ud af dokumentet afhængig af dokumenttypen. Samtidigt sikrer konfigurationsfilen en normalisering af typeangivelsen, så typeangivelsen i OIORASP headeren er i overensstemmelse med typekoderne angivet i RASP Profile FAQ.

Fra RASP version 2.1 er det muligt at benytte andre typer af afsenderidentifikation, således at det fremover at muligt at understøtte udenlandske afsenere (fx. dokumenter modtaget via PEPPOL).

3: Kontrolleres dokumenter ved modtagelse?
Idet en meddelelse modtages, kontrolleres det om dokumenttypen er kendt og selve indholdet af dokumentet schema- og schematron-validereres baseret på dokumenttypen. Denne validering af modtagne dokumenter sker på baggrund af indholdet i RASP konfigurationsfilen. Hvis konfigurationsfilen ikke ændres, vil RASP bibliotekerne dermed modtage alle dokumenttyper nævnt i afsnittet ”Hvilke dokumenttyper understøttes?”.

Men RASP bibliotekerne kontrollerer ikke om OIOUBL profilen, som dokumentet er sendt med, er en profil som modtageren understøtter. Modtageren registrerer i NemHandelsRegisteret, hvilke profiler der understøttes i hvilke roller, men hvis afsenderen f.eks. ved en fejl sender med en anden profil, vil bibliotekerne ikke fange dette.

Hvorvidt denne validering ønskes foretaget og hvorvidt et dokument skal afvises, hvis valideringen fejler som følge af at profilen ikke understøttes, er en forretningsmæssig beslutning hos modtager.

Se også næste afsnit om kontrol af om alle forsendelser indenfor OIOUBL profilen kan gennemføres.

4: Kontrolleres det om dokumenter i profilen kan sendes?
Ved modtagelse af en forsendelse kontrollerer RASP bibliotekerne ikke om afsender og modtager kan gennemføre alle potentielle udvekslinger inden for den OIOUBL profil, der er angivet i det modtagne dokument [2].

Hvis man f.eks. modtager en faktura i profilen Procurement-BilSim-1.0, kontrollerer RASP bibliotekerne ikke, om modtager senere vil kunne sende en Application Response tilbage til afsenderen. Det bliver altså ikke kontrolleret gennem bibliotekerne, at afsender understøtter OIOUBL profilen i de nødvendige roller for at senere udvekslinger kan gennemføres.

Der er således en årsag til, at der ikke kan gennemføres alle udvekslinger i profilen:

  • Afsender understøtter reelt ikke profilen – dvs. afsenderen sender med en profil som han reelt ikke understøtter i NemHandel sammenhæng

Hvorvidt denne validering ønskes foretaget og hvorvidt et dokument skal afvises, hvis valideringen fejler, er en forretningsmæssig beslutning.

Hvis der ønskes validering på modtagelsestidspunktet, kan man vælge at slå op i NemhandelsRegisteret for at kontrollere de OIOUBL profiler og roller, som afsenderens har registreret at kunne understøtte.

5: Er der begrænsninger på størrelsen af forsendelser?
Der ligger ikke nogen begrænsninger på størrelsen af dokumenter i selve OIORASP profilen, men i praksis begrænses størrelsen af forskellige faktorer. De underliggende frameworks, der er anvendt til implementering af henholdsvis RASP .NET og RASP Java er meget ressourcekrævende ved store meddelelser (forsimplet har RASP .NET et højt cpu forbrug, mens RASP Java har et højt memory forbrug).

Desuden spiller tilgængelig båndbredde i sammenhæng med timeout tider ind på muligheden for at sende store meddelelser.

Derfor er der en anbefalet grænse på forsendelser på 10 MB, hvis man vil være sikker på at kunne sende dokumenter.

Ved forsendelse af større dokumenter anbefales det at lave bilaterale aftaler mellem afsender og modtager – dette kunne være en aftale om at anvende en anden transportprotokol som FTP.

6: Har RASP en indbygget genafsendelsesstrategi?

Nej, RASP bibliotekerne implementerer ikke en genafsendelsesstrategi for meddelelser (og det er ikke længere planen at det bliver implementeret som en del af RASP'en).

Hvis en OIORASP forsendelse ikke kan gennemføres, enten fordi modtageren ikke svarer eller fordi selve OIORASP forsendelsen fejlede, kan afsenderen forsøge at genafsende meddelelsen [3].

Hvis det skulle implementeres, ville det kræve, at RASP'en var koblet op til disk, database eller lign. - og det anses ikke for at være RASP'ens ansvar.

Retningslinjer for genafsendelse er generelt:

  • Der skal gå minimum et minut inden en meddelelse forsøges genafsendt, med mindre der er konkrete forretningsmæssige grunde til at forsøge med et kortere interval.
  • Hvis en genafsendelse fejler, skal intervallet for genafsendelse øges til minimum 5 minutter og generelt skal intervallet øges efter hvert forsøg (en såkaldt ”exponential backoff” algoritme). Der bør maksimum forsøges at genafsende den samme meddelelse 5 gange, hvorefter man forretningsmæssigt skal håndtere meddelelsen på anden vis. Igen kan der afviges fra dette krav, hvis der er konkrete forretningsmæssige grunde til dette.
  • Den samme meddelelse skal ikke forsøges genafsendt, hvis OIORASP forsendelsen fejler med en indikation af at det er en permanent fejl, se afsnittet OIO RASP SOAP Faults i OIORASP profilen.

7: Foretager bibliotekerne logning?
Både afsender og modtager skal logge information om OIORASP meddelelser af hensyn til eventuel senere sporing af forsendelser. Da meddelelser ofte skal igennem flere led, herunder behandling i modtagerens forretningssystemer, vil en entydig identifikation af forsendelsen samt fælles logningsregler lette eventuelt sporingsarbejde.

De nuværende RASP biblioteker implementerer ikke denne logning. Det er dog planen at inkludere logning i en senere version, som kan logge svarende til de nedenfor angivne logningsregler på modtage- eller afsendelsestidspunktet.

Modtager skal logge:

  • MessageId fra OIORASP headeren
  • Certifikat subjekt på det certifikat afsenderen anvendte til signering af meddelelsen
  • Tidspunktet for initiering af forsendelsen
  • Status på forsendelsen – hvis forsendelsen fejlede skal SOAP fejlen logges

Desuden bør modtager logge:

  • SenderPartyIdentifier, ReceiverPartyIdentifier, SenderPartyIdentifierType og ReceiverPartyIdentifierType
  • Information der kan identificere selve indholdet (payload) af meddelelsen bør logges. Et eksempel kunne være information om fakturanummer.
  • Information fra transportniveauet, som f.eks. IP adressen på afsenderen.

Afsender skal logge:

  • MessageId fra OIORASP headeren
  • Tidspunktet for initiering af forsendelsen
  • Status på modtagelsen – hvis forsendelsen fejlede skal SOAP fejlen logges
  • URI på modtagerservicen

Desuden bør afsender logge:

  • SenderPartyIdentifier, ReceiverPartyIdentifier, SenderPartyIdentifierType og ReceiverPartyIdentifierType
  • Information der kan identificere selve indholdet (payload) af meddelelsen. Et eksempel kunne være information om fakturanummer.

8: Hvad er et signaturbevis?
De nuværende referenceimplementeringer af OIORASP foretager en validering, der sikrer at modtageren har kvitteret for modtagelsen af en meddelelse med det certifikat, der er registreret i NemhandelsRegisteret. Information om at denne validering er foretaget succesfuldt fremgår af retursvaret på en forsendelse.

Desuden valideres på modtagersiden, at meddelelsen er signeret med en valid signatur.

Egentlige signaturbeviser genereres dog ikke af OIORASP referenceimplementationerne. Det er under overvejelse at inkludere dette i en fremtidig version.

 

[1] Konfigurationsfilen findes i folderen C:\Users\AppData\Roaming\NemHandel\Configuration som standard, hvis man bruger NemHandelsprogrammet under Windows.

[2] Dette er ikke relevant for OIOXML elektronisk regning, da der ikke findes profiler og ikke kan sendes meddelelser som svar på modtagne dokumenter.

[3] Bemærk at der indenfor en OIORASP session kan være flere forsøg på afsendelse. Det er ikke denne genafsendelse der refereres til her, men uafhængige OIORASP sessioner, der forsøger at genafsende den samme (forretningsmæssige) meddelelse, hvis tidligere forsøg er mislykkedes.