OSO:2017/Algemene Eisen: verschil tussen versies

Uit Kennisnet Developers Documentatie
Naar navigatie springen Naar zoeken springen
(Nieuwe pagina aangemaakt met '==Algemene eisen en randvoorwaarden== ===Bewaartermijn=== Het overstapdossier doet specifiek dienst voor de overstap van een leerling van de huidige naar een nieuwe...')
 
Regel 1: Regel 1:
 
==Algemene eisen en randvoorwaarden==
 
==Algemene eisen en randvoorwaarden==
  +
====Dossierformaat====
  +
Binnen OSO wordt gewerkt met één gestandaardiseerd formaat voor het Dossier; in OSO'17 wordt de Standaardversie: '''2017.1.0''' gebruikt. Een Bronsysteem moet voorafgaand aan verzending controleren dat het Dossier hieraan voldoet. Deze controle beperkt zich tot de eerste twee digits van de versie (dus 2017.1.0 én 2017.1.1 moeten beiden worden geaccepteerd.)
  +
  +
 
===Bewaartermijn===
 
===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.
 
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.

Versie van 10 feb 2017 12:14

Algemene eisen en randvoorwaarden

Dossierformaat

Binnen OSO wordt gewerkt met één gestandaardiseerd formaat voor het Dossier; in OSO'17 wordt de Standaardversie: 2017.1.0 gebruikt. Een Bronsysteem moet voorafgaand aan verzending controleren dat het Dossier hieraan voldoet. Deze controle beperkt zich tot de eerste twee digits van de versie (dus 2017.1.0 én 2017.1.1 moeten beiden worden geaccepteerd.)


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:

  1. Doel en Bron worden hier absoluut gebruikt, volgens de rol die het desbetreffende systeem uitvoert in de transactie
  2. 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(!).