Mein Verständnis: Es soll in der Definition der Quell-Systeme ein oder mehrere Endpunkte ergänzt werden, welche eine API und ein Token enthält. Diese API wird für jedes xAPI Statement aufgerufen, welches Polaris empfängt. Eine Filterung oder Validierung innerhalb von Polaris ist nicht vorgesehen, bevor die Weiterleitung der Statements erfolgt.
Das Ziel der Weiterleitung ist richtig erfasst. Ob die Umsetzung für jede Definition eines Quellsystems geeignet ist muss sich zeigen. Der Forschungsbetrieb kann auf mehrere Quellsysteme ausgeweitet werden und ggf. ist eine zentrale Verwaltung einfacher zu warten und zu erweitern. Das kann ich nicht abschätzen.
die Modellierung im Commit sieht okay aus. Den Authorization Präfix (Basic, Bearer, Api-Key, ...) brauchen wir aber auch im Schema Konfig. Gerne als drittes Attribut mit einem fixen Wertebereich, um Fehl-Konfigurationen vorzubeugen.
Unelegant finde ich das Forwarding. Jedes Statement einzeln zu Verschicken erzeugt einen riesigen Overhead bei Sender und Empfänger und sollte vermieden werden. Zudem braucht es einen besseren Umgang mit nicht akzeptierten Statements. Ist das Ziel ausgelastet oder down, sollte das Verschicken später erneut versucht werden. Gibt es Probleme mit dem Statement, sollte dies der ursprünglich versendenden Instanz zurückgemeldet werden, damit z. B. der Logger das erfahren und darauf reagieren kann.
Leider nein. Ich hatte unsere/meine aktuelle Situation Kyra schon erklärt. Wenn es den Rest der Woche so "ruhig" bleibt wie heute und ich mit meinen Projekt ToDos gut voran komme, hab ich Freitag ein Zeitfenster dafür.
Der Code sieht okay aus, ich muss aber noch mehr praktisch testen. Dafür konnte ich dank des von Martin angelegten Accounts unter polaris-test.medien.rwth-aachen.de ein Schema hochladen, bekomme im Frontend zwar auch eine Erfolgsmeldung über den Upload, ob die additionalLrs Liste aber übernommen wurde ist mir unklar, die wird unter "Toggle Definition" nicht angezeigt.
Zudem muss das Enum der token types um "Api-Key" erweitert werden.