Høne, æg og OIO Sag og Dokument
- Oprettet Fredag, 27 april 2012 08:52
I forbindelse med vores arbejde på vores egen OIO Dokument service er vi løbet ind i en udfordring flere gange.
Når man ser på snitflade-beskrivelsen for f.eks. Dokument så ser man at rigtigt rigtigt mange data er URNer. En URN er jo bare en nøgleværdi.
Et eksempel: Når vi opretter et Dokument så er der plads til at vi i Dokumentet har en fil (f.eks. et officedokument brev22.odt).
Men snitfladen har ikke en plads til at vi f.eks. lægger en base64-udgave af en fil ind som en del af opret-operationen.
Det som der er plads til er at vi lægger en URN ind som unikt identificerer filen. Det betyder at filen skal befinde sig et andet sted.
På samme måde gælder det for mange andre værdier som f.eks. parter (modtager af brevet) eller KL-numre. De menneske-læsbare værdier skal ikke ind gennem snitfladen, det er URNer der skal ind.
Det er pokkers smart arkitektur. Meget løst koblet. Men det bringer os - nu hvor det mere er undtagelsen end regelen at vi har adgang til OIO Sag og Dokument snitflader - ind i en høne-æg situation.
Vi har nu udviklet begyndelsen på en Dokument-webservice. Men de systemer der skal bruge servicen har ikke adgang til andre OIO Sag og Dokument services. Så disse systemer har ikke mulighed for at generere URNer til filer, parter eller KLnumre. Og systemerne skal altså have URNer til at lægge ind i servicekaldet til f.eks. opret Dokument hvis de ønsker at gemme oplysningerne i vores system.
Det er svært at bevæge sig her - vi er låst når vi ikke har alle Sag og Dokument service tilgængelige.
På samme måde ville det være for nogen der skulle udvikle en Sag service.
Vores løsning har været en blanding af to forskellige metoder.
For en del felter har vi vedtaget en URN-konvention. Det betyder at et KL-nummer kan komme ind i vores system ved at man som URN bruger dette format:
URN:OIO:CON:PRIKLASSE:<klnummer> hvor <klnummer> så er KL-nummeret. Så et eksempel kunne være værdien URN:OIO:CON:PRIKLASSE:12.10.
Ved at vedtage en konvention for URNen, som vi så dokumenterer for de systemer der skal bruge servicen har vi løst problemet.
Når det gælder filer så har vi valgt at oprette vores egen FileContainer-webservice. Det er en REST-format service som kan modtage en fil og som leverer en XML-struktur tilbage som blandt andet indeholder en URN. Denne URN kan så efterfølgende bruges i kaldet til vores opret Dokument operation.
Når et dokument-producerende system ønsker at gemme til vores Dokument-service sker det altså ved først at kalde FileContainer-servicen med en fysisk fil som parameter og derefter kaldes Dokuments opret-operation med en SOAP XML-struktur, hvori indgår URNen der matcher den fil der lige er lagt ind i FileContainer.