Der er lavet en version 2 af REST API’et, der er mere i overensstemmelse med god praksis for api design. Som altid kan beskrivelsen findes her. Der er ikke nogen udfasningsdato for version 1, men nye metoder vil blive udviklet i version 2.
1. Annullering af bestilling
2. Tilføjelse af produkt
3. Fjernelse af produkt
Det er dermed nu muligt at holde bestillinger ajour med sin reelle udvikling. Ved brug af metoderne informeres mægler på mail om ændringen. Vi vil særligt opfordre til at tage annulleringsmetoden i brug, da det vil holde sagernes tilstand i Boligdok retvisende over for både bygningssagkyndige selv men også forsikringsselskaberne. Det samme kan siges for tilføjelse/fjernelse, men de er nok lidt mere tidskrævende at implementere. I portalen er det gjort mulig at skifte eget password. Det har været en åbenlys mangel, at brugerne ikke kan skifte password, og den er nu endelig udbedret.
I portalen er det gjort mulig at skifte eget password. Det har været en åbenlys mangel at brugerne ikke kan skifte password, og den er nu endelig udbedret.
Parsningen af tilstandsrapporten er udvidet til også at omfatte undtagne bygninger og BBR afvigelser. Tidligere kom disse informationer kun med i XML-en, hvis bygningssagkyndige også leverede json-filen. Dette har også betydet, at beregningen af ejBeboeligtAreal under ejendom i bestilling fra api’et generelt er blevet mere korrekt, idet undtagne bygninger ikke længere medregnes.
Herunder lidt om hvilke større opgaver vi arbejder på i øjeblikket. Temaerne er bedre muligheder for system til system integration og bedre sagshygiejne. Dette kan sammenfattes til disse punkter:
1. Eventbaserede meddelelser
2. Udvidet api til mæglersystemerne for meddelelse om annullering og salg. 3. Bedre compliance håndtering baseret på salgsstatus
I øjeblikket hentes bestillinger mm. fra api’et gennem et indbakke-princip, og der hentes ved at spørge med en fast frekvens. Dette er simpelt men også primitivt i den forstand at der ikke kan meddeles begivenheder, som f.eks. annullering, produktændring mm. Vi arbejder derfor på at introducere en kø-baseret meddelelsesstruktur. Herved kan vi signalere flere typer information, og modtager kan lytte på køen i stedet for at spørge med fast frekvens. Vi er godt i gang med etablering i testmiljøet, og forventer at sætte det trinvist i produktion i løbet af efteråret.
Det er efterspurgt fra forsikringsselskaberne og bygningssagkyndige, at mægler kan annullere en bestilling, derfor udvider vi api’et med denne mulighed for mæglersystemerne. For meddelelse om salg se næste punkt.
Regler for sletning af sagsoplysninger og dokumenter er i dag styret af nogle faste tidsbaserede forældelsesregler. Dette har den ulempe at dokumenter kan risikere at blive fjernet på sager, hvor salg endnu ikke er foretaget, og sagsinformationer derfor stadig burde bevares. For at vi kan skifte til en salgsbaseret compliancepolitik kræves at vi ved om salg har fundet sted, eller om sagen er taget af. Den bedste kilde til den information er mæglersystemet, derfor vil vi udstille en metode til afgivelsen af denne information. Et alternativ er at indhente informationer fra tingbogen, men den kan kun fortælle om et salg er sket, og ofte med en vis forsinkelse, idet det er skødedato, der i dette tilfælde skal bruges. Ved ændring af compliance-regler skal databehandleraftalerne reguleres.
