gemaakt werk met beoordeeld resultaat - hoe terugkoppelen als SIS intussen de association heeft gecanceld?

roelgrif commented 5 months ago

Discussie ontstaan na testdag 21 juni pilot 2. in TAS is afname geweest op een toets die via flow 1 en 2 netjes is uitgewisseld. Voor definitieve vaststelling van het cijfer in TPS (na flow 3/4) vindt er een wijziging in SIS plaats waardoor het component offering association ID vanuit het SIS via flow 1 alsnog op gecanceld wordt gezet. SIS (in dit geval PeopleSoft) verwacht het resultaat terug in flow 5 --> trigger om bij de inschrijving van de student de betreffende planbare toets opnieuw aan te maken (b.v. een 3F toets bij een afstroom van niveau 4 naar niveau 3 waardoor standaard 2F wordt gekoppeld en niet meer 3F). Maar afhandeling zou ook in TPS plaats kunnen vinden (signaal naar de gebruiker: geen terugkoppeling mogelijk wegens gecancelde componentOfferingAssociation) Welke werkwijze gaan we de standaard maken?

rrutte commented 5 months ago

Effectief gaat het om het volgende:

SIS weet niet of/wanneer een toetsinschrijving van de student effectief gepland is en dus ook niet op het moment van cancellation van componentOfferingAssociation in flow 1 of er al een toets gemaakt is door de student.
TPS ontvangt een cancellation van de componentOfferingAssociation op flow 1. Moet dit een beschouwd worden als een cancellation van de inschrijving of van de volledige toetsdeelname. In het eerste geval zullen resultaten gestuurd gaan worden (extra pogingen worden niet meer toegestaan vanuit TPS naar TAS). In het tweede geval moeten resultaten nog steeds afgehandeld worden.

hamrt commented 5 months ago

Stelling: Het resultaat van een examen moet in ieder geval ergens geregistreerd worden. Een behaald resultaat mag niet verdwijnen.

We moeten hierover procesafspraken met elkaar maken. Osiris: Als een association wordt weg gehaald verdwijnt alles (inclusief de associationId) Eduarte: Peoplesoft: Ondanks dat de association verwijderd wordt, blijft de associationId bestaan en kan daar op worden teruggeschreven

rrutte commented 4 months ago

@mcginkel en Huib-jan Standpunten bespreken vanuit Eduarte en Osiris tijdens overleg op 23-07. Terugkoppelen naar @roelgrif

JosVanderArend commented 4 months ago

We hebben afgesproken dat het SIS zelf bepaalt of een Association in status "canceled" actief blijft of wordt verwijderd. In het laatste geval zal TPS een foutmelding krijgen bij aanlevering van een resultaat. TPS zal hiermee moeten omgaan (registratie in de log en/of gebruiker inschakelen).

Wel zijn volgende punten belangrijk:

TPS doet zijn best om wijzigingen (cancel) tijdig te verwerken en door te voeren naar TA, zodat TA dit ook zo snel mogelijk kan verwerken.
TA verwerkt een cancel voor de start van de toetsafname; nadat toetsafname gestart is zal toetsafname plaatsvinden en een resultaat volgen.
TPS krijgt dus soms resultaten binnen nadat de inschrijving is gecanceled (cancel na start toetsafname en resultaat was nog niet verstuurd).
TPS heeft de verantwoordelijkheid om elk resultaat aan het SIS aan te bieden (flow 5) en niet zelf te bepalen of dat nog relevant is. Het SIS mag zelf bepalen wat te doen met dit resultaat, bij voorkeur registreren op de juiste plek in de administratie.

mcginkel commented 4 months ago

extra bij opmerking Jos hierboven:

als het SIS Associations weggooit en niet op cancelled zet, zal het wel een push notificatie geven om te informeren? of moet de TPS uit de afwezigheid van de Association afleiden dat het gecancelled is?
Een resultaat afmelden op een niet meer bestaande association zal dan een fout geven bij aanroep , maar de TPS moet dat dan negeren en niet opnieuw aanbieden. TPS kan inderdaad beluiten hoe het intern handelt (log of tonen)

roelgrif commented 4 months ago

Ik ben het oneens met bovenstaande. Het uitgangspunt dat we bij het ontwerp van de OKE standaard gekozen hebben is dat we eenmaal aangemaakte zaken, of het nu associations, offerings, programs, components of persons zijn, nooit verwijderen in de uitwisseling, en dat betekent dat de betrokken partijen aan beide kanten er over moeten kunnen blijven communiceren. Een keiharde error 'dit ID is hier onbekend' terwijl er een geaccepteerde uitwisseling over heeft plaatsgevonden zet de deur open voor uitwisselingsissues, handmatig benodigde troubleshooting, emailen over verdwenen zaken, etc. etc. Als het genoemde uitgangspunt nu verlaten wordt en we zelfs gaan praten over notificaties van verwijdering ergens door een ketenpartij, maken we m.i. van de OKE variant van OOAPI een kreupel paard. Het minimale wat je van een OKE partij mag verwachten is een berichtje in de trant van 'hoho, deze ID is weliswaar bekend, maar inmiddels niet meer van toepassing, staat bij ons op [vul maar iets in als geannuleerd of zo], ons pakket doet daar verder niets meer mee'. Natuurlijk is het allerbelangrijkste voor ons SIS dat wij de resultaten op een geannnuleerde toetsinschrijving alsnog terug gaan krijgen van het TPS. Dus ik kan, de laatste aandachtspunt van Jos lezende, mijn ogen sluiten en denken van 'als het bij ons maar goed gaat', laat maar dan. Maar voor een standaard vind ik bovenstaande voorstel echt een zwaktebod.

mcginkel commented 3 months ago

error == warning

JosVanderArend commented 3 months ago

Opmerking bij bovenstaande (error == warning): Het SIS geeft geen foutmelding maar een waarschuwing dat het bijgaande bericht is ontvangen en niet zal worden verwerkt omdat het vermelde associationId niet meer bestaat. Met bijbehorende meldingstekst. Hiermee wordt het een probleem van het SIS en hoeft TPS niet te blijven proberen het resultaat te versturen.

JosVanderArend commented 3 months ago

In het specificatiedocument is in paragraaf 5.1 Deelnemerregistratiekoppelvlak de volgende tekst toegevoegd: Let op, bij de verwerking van het verzoek PATCH /associations/{associationId} van TPL aan DR/SIS kan het voorkomen dat de Toetsinschrijving aangeduid door padparameter associationId niet meer bestaat binnen DR/SIS omdat deze Toetsinschrijving vervallen of beëindigd is. In dit geval is het belangrijk dat DR/SIS niet een foutmelding (400) teruggeeft naar TPL maar het verzoek aanneemt (200) en reageert naar TPL met de meldingstekst “Your request was partly successful, the association was deleted”.

JosVanderArend commented 3 months ago

Vraag aan een ieder: zou bovenstaande ook moeten gelden voor PATCH /associations/{associationId} in flow 3 en PATCH /offerings/{offeringId} (flow 4)?

JosVanderArend commented 2 months ago

In de laatste versie (0.9.4 van 6 september) is in paragraaf 5.1 "Deelnemerregistratie koppelvlak" de volgende tekst beschreven: "Let op, bij de PATCH-operatie is de volgende HTTP foutcode naast 200 (OK) voorzien: 400 (Bad request). Aanvullende eis Bij de verwerking van het verzoek PATCH /associations/{associationId} door DR/SIS kan het voorkomen dat de betreffende resource, object ComponentOfferingAssociation aangeduid door associationId, is vervallen of beëindigd. In dit geval mag DR/SIS dit verzoek niet weigeren (foutcode 400) maar moet het dit verzoek aannemen en verwerken (200). De verwerking binnen DR/SIS is volgens de eigen interne logica."

En in paragraaf 5.2 "Toetsplanning koppelvlak": "Let op, bij de PATCH-operaties is de volgende HTTP foutcode naast 200 (OK) voorzien: 400 (Bad request). Aanvullende eis Bij de verwerking door TPL van het verzoek bij beide PATCH-operaties in laatste tabel (Tabel 2.5.A) kan het voorkomen dat de betreffende resource, Association of Offering aangeduid door padparameter id, is vervallen of beëindigd. In dit geval mag TPL dit verzoek niet weigeren (foutcode 400) maar moet het dit verzoek aannemen en verwerken (200). De verwerking binnen TPL is volgens de eigen interne logica."

NetwerkExamineringDigitalisering / NED-OOAPI

gemaakt werk met beoordeeld resultaat - hoe terugkoppelen als SIS intussen de association heeft gecanceld? #149