Lehrplan: Integrationsmuster

Um den Systemen, die Daten aus dem Curriculum verwenden, stets aktuelle Informationen zur Verfügung zu stellen, empfiehlt sich ein ereignisbasierter Ansatz mit Hilfe von Hooks, die geänderte Objekte, die einen bestimmten Status erreichen, automatisch an einen Prozess senden.

Der Vorteil dieses Ansatzes ist:

• alle Daten in den Empfangssystemen sind immer aktuell
• geringe Auswirkungen auf die Ressourcen, da die Last über den Tag verteilt wird
• keine langwierigen Integrationsprozesse durch nächtliches Abrufen aller Daten

Je nach den Fähigkeiten des ESB und Ihrer Empfangssysteme kann dies eine Option sein oder nicht.

Weitere Einzelheiten zur Konfiguration von Hooks finden Sie in der allgemeinen Integrationsanleitung.

‍

Ein Ansatz, der zusätzlich zur ereignisbasierten, aber auch als Ersatz verwendet werden kann, ist eine regelmäßige (z. B. tägliche) anforderungsbasierte Aktualisierung nur für die geänderten Objekte.

Der Vorteil dieses Ansatzes ist:

• begrenzte Auswirkungen auf die Ressourcen, da nur geänderte Objekte über den ESB abgerufen und aktualisiert werden
• keine langwierigen Integrationsprozesse durch nächtliches Abrufen aller Daten

Da es sich um einen geplanten Auftrag handelt, der Daten in regelmäßigen Abständen, z. B. täglich, abruft, sind die seit der letzten täglichen Aktualisierung geänderten Daten nicht zu 100 % aktuell. Indem die letzten 2 Jahre abgerufen werden, hält diese Option die empfangenden Systeme mit allen Änderungen auf dem neuesten Stand. Wenn dies für keine der Daten ein Problem darstellt, könnte diese Option die erste Option (ereignisbasiert) vollständig ersetzen.

 Der Endpunkt Version unterstützt die Abfrage aller Versionen (Änderungen) seit einem bestimmten Datum im angegebenen Jahr. Durch die Verwendung eines Zeitfensters von 'letzten x Tagen' können Sie dies nachts ausführen und haben einen standardmäßig implementierten Fallback, falls ein nächtlicher Auftrag fehlschlägt. In der nächsten Nacht werden die Änderungen der letzten x Tage abgerufen, einschließlich derjenigen, die in der Nacht zuvor nicht verarbeitet wurden. 

Der Endpunkt Version liefert alle geänderten Objekte, ihre Version(en) und ob sie veröffentlicht sind.
Falls nur genehmigte (veröffentlichte) Daten ausgetauscht werden sollen, könnte der Ansatz folgender sein:

• Alle geänderten Objekte abrufen
  • ‍fromDate: Geben Sie ein allgemeines Datum an, z. B. now() - 3 Tage, oder verwenden Sie einen intelligenteren Ansatz, indem Sie den Zeitstempel des letzten erfolgreichen Laufs angeben.‍
  • Jahr: in den letzten 2 Jahren zweimal durchgeführt.‍
  • Seite: holt das nächste X, wenn die Liste länger als die Seitengröße ist‍
  • size: Definieren Sie die Seitengröße (Anzahl der Datensätze, die pro Aufruf abgerufen werden).
• Bestimmen Sie die zu bearbeitenden Objekte‍
  • die relevanten Objekte verdünnen, z.B. nur veröffentlichte und neueste‍
  • Datum: Datum der Version, kann auch als Option bei der Abfrage der letzten 4 Tage in Kombination mit dem letzten erfolgreichen Lauf verwendet werden.
  • latest: gibt an, ob es sich um die neueste Version handelt oder ob seit dem angegebenen Tag weitere Versionen dieses Objekts existieren‍.
  • veröffentlicht: gibt an, ob dies die letzte veröffentlichte Version ist.

Verarbeitung der Objekte, die implementierungsspezifisch ist und die entsprechenden Endpunkte auf der Grundlage der zu verarbeitenden Objekte verwendet.

‍

Während sich die ersten Optionen nur auf die Verarbeitung von Änderungen konzentrieren, besteht aus architektonischer Sicht immer die Anforderung einer vollständigen Synchronisierung "aller Daten". Die vollständige Synchronisierung wird in bestimmten Intervallen durchgeführt, z. B. wöchentlich, zweiwöchentlich, monatlich, und ruft alle Daten im Lehrplan für ein bestimmtes akademisches Jahr über die Standard-API ab und verarbeitet die Objekte über den ESB an das/die empfangende(n) System(e).

 Es gibt keine Vorteile, aber es ist ein vorgeschriebenes Integrationsmuster, also muss es implementiert werden.

Wenn dies anstelle der beiden zuvor beschriebenen Optionen verwendet wird, besteht der Nachteil darin, dass die Verarbeitung langwierig ist (bis zu einer Stunde) und ziemlich viele Ressourcen in Anspruch nimmt. Ein täglicher Betrieb ist wahrscheinlich nicht die beste Lösung und sollte nur dann erfolgen, wenn die ersten beiden Optionen nicht unterstützt werden können.

Die geplante (z. B. wöchentliche) Ganzjahressynchronisation sollte nur zum Abruf der aktiven Jahre verwendet werden, um die Synchronisation auf Jahre/Daten zu beschränken, die im System noch änderbar sind.

Der genaue Aufbau und die benötigten Dienste hängen von der Systemnutzung ab. Die übertragenen "Daten", mit denen Informationen angefordert werden, können über den Parameter "expand" gesteuert werden. Dieser kann verwendet werden, um die Standardantwort zu begrenzen oder nur zu erweitern und die Anzahl der Aufrufe zu begrenzen, z. B.:

• ‍?expand=-:die minimalste Antwort ‍
• ?expand=*:die am meisten erweiterte Antwort‍
• ?expand=group: erweitert die Gruppeninformationen in der Antwort‍.
• ?expand=study: erweitert die Studieninformationen in der Antwort‍.
• ?expand=Studie,Gruppe: erweitert sowohl die Studien- als auch die Gruppeninformationen in der Antwort

Die letzte Möglichkeit besteht darin, eine Synchronisierung aller Daten im Curriculum durchzuführen.

Wenn diese Option erforderlich ist, geht es meist um die "Wiederherstellung aller Daten" aufgrund eines Systemausfalls eines nachgelagerten Systems, das Daten von Curriculum über den ESB erhält, oder wenn Änderungen an Jahren vorgenommen wurden, die nicht mehr bearbeitet werden können.

Die Vollsynchronisation kann als Spezialfall der Ganzjahressynchronisation betrachtet werden, bei der nicht nur die aktiven Jahre, sondern alle Jahre im Curriculum synchronisiert werden. Da die Ganzjahressynchronisation nur für jedes erforderliche Jahr repliziert wird, entspricht die Verarbeitungszeit der Zeit für ein einzelnes Jahr mal der Anzahl der synchronisierten Jahre.

Ausgehend von der Annahme, dass dies nur auf der Grundlage von Vorfällen geschieht, oder vielleicht als Ausweichlösung, um alle Daten alle 6 Monate zu synchronisieren, würden wir den folgenden Ansatz empfehlen.

• Falls eine Synchronisierung aller Daten aufgrund eines Vorfalls oder als geplanter (z. B. vierteljährlicher) Prozess erforderlich ist, verwenden Sie einen 2-Phasen-Ansatz
  • die wirklich benötigten Daten zu synchronisieren, d. h. die standardmäßige Ganzjahressynchronisierung für die aktiven Jahre durchzuführen.
    Diese Aktion könnte bereits vor kurzem durchgeführt worden sein, so dass es sich um eine optionale Aktion handeln könnte.
  • die anderen Jahre (Option 3) an einem Wochenende zu synchronisieren, wobei davon ausgegangen wird, dass die historischen Daten weniger relevant sind als die aktuellen Daten.