En WSDL-fil beskriver den aftale der dannes mellem kaldende system og den udstillede service. WSDL-filen indeholder den beskrivelse af webservicens detaljer der er nødvendige for at man kan konstruere et kald til webservicen. WSDL-filen indeholder blandt andet en binding-del, der beskriver hvor endepunktet for en service befinder sig.
Eksempel:
I dette eksempel kan endepunktet for serviceoperationen findes som værdien af location
Listen over tilgængelige WSDL-filer kan findes på siden WSDL katalog.
I nogle tilfælde vil port og binding være udeladt fx hvis servicen kun er i review-fasen.
I SKATs OIO WSDL-filer er typerne defineret ved import af eksterne namespaces og nestede sæt af XML schemas.
Denne metode er gyldig i henhold til W3C-specifikationerne, og er også den eneste praktiske måde at håndtere skema datatyper på, når de skal anvendes på tværs af multiple services. En anden lovlig måde at definere WSDL filer på, er ved at definere datatyperne fuldstændig inlinet i WSDL-filens typesektion. Selvom denne metode er et validt alternativ ifølge W3C, skalerer den dårligt på tværs af services, og SKAT anvender den derfor ikke. En anden grund til ikke at gøre sådan er, at OIOXML er opbygget ved omfattende brug af imports, og derfor vil WSDL-filen blive dekoblet OIOXML.
Ikke desto mindre har visse (ældre) udviklingsmiljøer ikke understøttelse for rekursiv include af eksterne schemas, og det giver problemer ved udvikling af serviceklienter.
Hvis man har dette problem, kan løsningen være at transformere den officielle WSDL-fil om til en inlinet version af samme fil, inden man anvender et kodegenereringsværktøjer. Dette vil naturligvis ikke være en korrekt OIOXML-specifikation, men den vil ikke desto mindre definere et ækvivalent sæt af skemaer, og vil derfor være tilstrækkeligt til at danne en klient.
Se i øvrigt OIOWSDL for udvikling og implementering på forskellige platforme.
SKATs schemafilnavne indeholder aldrig æøå, men schemaer kan indeholde æøå i navne og annotations. Det er fuldt ud i overensstemmelse med standarderne og alle moderne XML-værktøjer og kodegeneratorer bør understøtte unicode og UTF-8. Ved problemer anbefaler vi, at man kontakter leverandøren eller udviklerne bag værktøjet. Det er vores erfaring, at problemet ofte kan løses med en opgradering eller ændring i indstillingerne.
Det forventes at datoperioder repræsenteret som DateInterval som minimum understøtter en periode, som består af to datoer, dvs. StartDate og EndDate. Altså - med mindre andet er dokumenteret, kan klienter ikke forvente at services understøtter offset-periode (dato + duration).
Transaktions-id i hovedoplysningerne bruges til at sammenkæde et antal transaktioner. Pga. begrænsninger i en række underliggende services bør et transaktions-id ikke være længere end 26 tegn, men udover det er der ingen begrænsninger i indholdet
SKAT anvender en delmængde og følgende muligheder i CivilstandSamlivsforholdKode er ikke understøttet, dvs. hvis de anvendes vil servicen fejle:
”deceased” : død
”1”: Samlevende med ægtefælle;
”2”: Samlevende med anden person i ægteskabslignende forhold;
”3”: Samboende med slægtning som jeg ikke kan indgå ægteskab med;
”5”: Gift men samliv ophørt pga. uoverensstemmelse;
”6”: Gift, men samliv ophørt pga. institutionsophold under Kriminalforsorgen;
“7”: Enlig;
”8”: Andet;
”9”: Ugift, samliv ophørt.
De ikke-understøttede koder må indplaceres i ”unmarried” og ”married”. At være død begragter SKAT ikke som en civilstand. Koden „deceased“ skal derfor angives på anden måde.
Der anvendes udelukkende to-tegnskoder ifølge ISO 3166 alpha 2, dvs. kun værdien „iso3166-alpha2“ af attributten „scheme“ på CountryIdentificationCode er understøttet.
WSDL-filen indeholder en reference til digitaliser.dk. Brug dette værktøj til at hente filerne. Det kan danne en zip-fil indeholdende WSDL og alle anvendte schemaer.
Forretningsmæssige fejl returneres vha. særlige strukturer (hovedoplysninger), som er inkluderet i serviceinterfacet.
Læs om OIO-hovedoplysninger her .
Tekniske fejl (fx fejl vedr. autorisation) returneres som SOAP fault.