Waarom deze opzet?
Ik gebruik C# en Azure Functions omdat dit aansluit op de omgeving van de OU. APIM is de ingang voor de API. Zo kan de koppeling onderdeel blijven van de bestaande omgeving.
Code hergebruiken
Courses en programmes komen allebei uit productgegevens. Daarom gebruik ik ProductService voor beide. Ik geef het producttype en het DTO mee:
ListResponse<CourseDto> listResponse = await _productService.GetProducts<CourseDto>(0, query);
ListResponse<ProgrammeDto> listResponse = await _productService.GetProducts<ProgrammeDto>(4, query);Deze regels staan in Functions/Course.cs en Functions/Programmes.cs in de projectcode. Hiermee hoef ik dezelfde ophaallogica niet twee keer te maken. Het nadeel is dat een fout in de service beide onderdelen kan raken. Na een wijziging moet ik ze dus allebei testen.
De mapping staat apart in MappingProfiles.cs. Bijvoorbeeld: SKU wordt primaryCode en de productnaam wordt een taalwaarde in name. Als een veld verkeerd terugkomt, kan ik daar gericht naar kijken.
Wat eerst haalbaar is
Ik maak eerst de drie basisonderdelen en map velden die al in de database staan. Voor nieuwe bronvelden heb ik hulp nodig. Offerings houd ik daarom apart als uitbreiding. Dat past bij de must-haves en de tijd die ik heb.
Privacy, security en omgaan met gegevens
De OU wil alleen gegevens laten ophalen. Daarom gebruiken deze routes GET. Dat beperkt het terugschrijven, maar toegang tot de data moet nog steeds gecontroleerd worden. De functions hebben een Reader-attribuut en de middleware controleert het token en de policy.
Secrets horen in de Azure-configuratie en niet in mijn voorbeelden. Ik neem geen tokens of connection strings op als bewijs. De volledige configuratie en het afwijzen van verkeerde rechten moeten apart gecontroleerd worden.
Als een bronveld ontbreekt, vul ik niet zelf onderwijsgegevens in. Een verkeerde waarde kan een andere applicatie ook verkeerd informeren. Ik controleer eerst of het veld verplicht is en stem af of de bron of de mapping aangepast moet worden.
Bij het opnieuw bekijken van ProductService.cs, regel 70, zag ik dat primaryCode direct in de SQL-string staat. Dat wil ik vervangen door een gebonden parameter. Toegangscontrole alleen lost dit niet op. Dit staat als verbetervoorstel beschreven.