OSO:2017/Algemene Eisen
Overstapservice Onderwijs: 2017/Algemene Eisen
Algemene eisen en randvoorwaarden
Bewaartermijn
Het overstapdossier doet specifiek dienst voor de overstap van een leerling van de huidige naar een nieuwe school. Nadat de overstap is gerealiseerd, en de gegevens van de leerling in het LAS van de nieuwe school zijn ingevoerd en verwerkt, is advies om het overstapdossier (het complete xml bericht inclusief bijlagen) nog twee jaar te bewaren. Daarna dient het dossier te worden vernietigd.
Adressering
In de adressering van OSO berichten worden altijd vier velden toegepast:
- bronBRIN
- bronAPindex
- doelBRIN
- doelAPindex
Hierbij worden twee uitgangspunten toegepast:
- Doel en Bron worden hier absoluut gebruikt, volgens de rol die het desbetreffende systeem uitvoert in de transactie
- De velden worden ingevuld wanneer dit mogelijk is (en zijn anders leeg). (Bijvoorbeeld: In het geval van een overdrachtRequest kunnen alleen de doelBRIn, doelAPindex en bronBRIN ingevuld zijn, omdat het doelsysteem dat dit request verstuurd nog geen idee heeft welke aanleverpunten afgelopen moeten worden).
Overige technische randvoorwaarden
Logging
Een op OSO aangesloten systeem moet gegevens over verzonden en ontvangen berichten en opgetreden fouten opslaan en beschikbaar kunnen maken voor twee doelen:
- het kunnen achterhalen welk dossier wanneer tussen welke systemen is uitgewisseld en welk gebruikersaccount daar opdracht toe gaf (juridische eis)
- zodat ze in geval van calamiteiten door de leverancier op te zoeken zijn. De gelogde informatie moet redelijkerwijs voldoende zijn om technische problemen op te lossen en in speciale gevallen het verloop van de interacties te reconstrueren (operationele toepassing)
Om aan beide eisen te kunnen voldoen gelden de volgende richtlijnen voor de logging binnen doel- en bron- systemen:
- De SessieID en gebruikersaccount (binnen het systeem) worden gelogd
- De informatie in een logregel voor de gebruiker is voldoende zelfbeschrijvend om zonder contextinformatie uit het bronsysteem de actie te kunnen herleiden tot de verantwoordelijke (rechts)persoon.
- Een systeem registreert logregels voorzien van datum en tijd, met een nauwkeurigheid van ten minste 1 seconde.
- Een systeem garandeert een maximale afwijking van de UTC + 01:00 tijd (de tijdzone waarin Nederland valt) van 5 seconden.
- Log regels bevatten altijd het geldige sessie-id (wanneer dit is toegekend).
- Logregels voor de gebruiker kunnen na creatie niet worden aangepast of verwijderd.
- Logregels voor de gebruiker worden duurzaam bewaard en beschermd tegen verlies en verandering tot 2 jaar na het moment van overdracht van het dossier.
Timing
- Initiator van een interactie ontvangt binnen 30 seconden na het versturen van een request een response van het bevraagde systeem. Indien er binnen deze tijd geen response wordt ontvangen, moet de initiator een time-out (fout) afhandelen (en melden aan eindgebruiker en TC).
- Een OSO sessie heeft, indien niet eerder afgemeld, een duur van maximaal 10 minuten.
- Een systeem dat een interactie start, wacht gedurende minimaal de gespecificeerde responstijd op antwoord.
- Een systeem dat een interactie moet beantwoorden, doet dit binnen de gespecificeerde maximale responstijd.
Omvang berichten
Door de invoering van Passend Onderwijs en andere ontwikkelingen is er een behoefte om meer informatie in dossiers en met name bijlagen op te slaan. Anderzijds is het loslaten van een bovengrens aan de dossiergrootte onverstandig uit praktische overwegingen. De volgende bestandsgrootte's zijn daarom afgesproken:
- Bijlage: maximaal 10MB
- Compleet dossier: maximaal 30MB.
'Zippen' van bijlagen
Documenten die als bijlage aan een dossier worden toegevoegd, worden als een in Base64 gecodeerd zip bestand opgenomen in het dossier. In OSO wordt hiervoor de MIME Base64 content-transfer-encoding standaard, zoals beschreven in RFC 2045, toegepast. Deze variant maakt gebruik van dezelfde tekenset als ‘Standaard’ Base64 (zoals beschreven in RFC 4648, hoofdstuk 4 variant 1), maar kapt regels af op 76 tekens of minder, gescheiden door een CRLF(“\r\n”). Daarnaast worden bij het decoderen alle ‘vreemde’ tekens genegeerd. NB: Deze codering wijkt af van die toegepast voor de zoeksleutel(!).