Effiziente Integration des Lernmanagement in die interne IT-Infrastruktur

    State-of-the-Art der Schnittstellentechnik und Fallbeispiel

    15. August 2008 von Kurt Saar

    Mit der Einführung des softwaregestützten Lernmanagements in einem Unternehmen oder einer öffentlichen Institution sind nicht allein die Auswahl einer Lernplattform und die Installation von Web Based Trainings verbunden. Als integrativer Bestandteil einer organisationsweiten Personalentwicklungsstrategie oder einer Online-Akademie darf das Lernmanagementsystem keine Insellösung darstellen, das sich allein auf die Auslieferung von Lerninhalten beschränkt. In dem Beitrag werden die verschiedenen Realisierungsmöglichkeiten und strategische Aspekte bei der Gestaltung der Schnittstellen vorgestellt. Dazu gibt es ein kurzes Fallbeispiel.

    Mit der Einführung des softwaregestützten Lernmanagements in einem Unternehmen oder einer öffentlichen Institution sind nicht allein die Auswahl einer Lernplattform und die Installation von Web Based Trainings verbunden. Als integrativer Bestandteil einer organisationsweiten Personalentwicklungsstrategie oder einer Online-Akademie darf das Lernmanagementsystem (im Folgenden kurz: LMS) keine Insellösung darstellen, das sich allein auf die Auslieferung von Lerninhalten beschränkt.

    Zu den Basisfunktionen eines LMS gehören vielmehr auch die Benutzerverwaltung, die Vergabe von Berechtigungen, eine Reihe von Kommunikationsfunktionen (Diskussionsforum, Chat, Pinboard, Tutormail, etc.), Assessments, Suchfunktionen und das Reporting von Lernprozessen in Form aufbereiteter Nutzungs- und Lernstandsdaten.

    Erweiterte Funktionen umfassen die Unterstützung von Autorenprozessen, Bildungscontrolling mit umfassenden Werkzeugen zur Evaluation des Lernerfolgs, Skill Management, Veranstaltungsmanagement mit der detaillierten Pflege von Kundendaten, Trainerdaten und allen Aspekten des Veranstaltungsangebots und -umfeldes, möglicherweise bis hin zur Verwaltung jeglicher Lernmedien in Blended-Learning-Veranstaltungen und der abschließenden Fakturierung durchgeführter Bildungsmaßnahmen.

    Mächtige Lernmanagementsysteme unterstützen all diese Funktionen, andere nur einen Teil davon. Häufig jedoch existiert für die eine oder andere der genannten Funktionen auch bereits eine unternehmensspezifische, oft über Jahre hinweg gewachsene und kostenintensive Lösung, die entweder parallel zur neuen Lernumgebung weiterverwendet werden soll oder aber abgelöst werden kann, sofern das LMS die Funktion anbietet. Im Fall der Ablösung sollen jedoch historische Datenbestände in die Lernplattform vor deren Inbetriebnahme übernommen werden.

    In beiden Fällen besteht die Notwendigkeit, wohldefinierte Schnittstellen zum Datenaustausch herzustellen. Neben technischen Gesichtspunkten kommen hier auch betriebswirtschaftliche Belange ins Spiel: Die Lernplattform muss flexibel und modular erweiterbar sein und sich so in die bestehende IT-Infrastruktur integrieren lassen, dass bei der Konstruktion des Gesamtsystems eine möglichst hohe Investitionssicherheit gewährleistet ist.

    Realisierungsvarianten

    Für die Realisierung solcher Schnittstellen steht nun ein breites Spektrum technischer Möglichkeiten bereit, um Daten von dem System, das die Daten bereitstellt, also der Datenquelle, auf das importierende System, die Datensenke, zu übertragen. Wir wollen die Varianten im Folgenden kurz kategorisieren und einige davon mit Anwendungsbeispielen näher beleuchten.

    Variante 1: Dateibasierte Schnittstellen

    Die Datenquelle exportiert die zu übertragenden Daten in eine Datei, die auf das importierende System zum Einschleusen der Daten übertragen wird. Die Übertragung selbst kann je nach Anwendungsfall automatisch oder manuell, einmalig, je nach Bedarf oder in einem regelmäßigen Rhythmus geschehen.

    Variante 2: Datenbankbasierte Schnittstellen

    Da Datenquelle und Datensenke in der Regel ihre Daten in relationalen Datenbanken halten, lassen sich die Datenbankinhalte zwischen beiden Datenbanken über SQL-Skripte austauschen. In Einzelfällen mag dieser Ansatz praktikabel sein, doch oft erfordern die über zahlreiche Tabellen verteilten und hochgradig referenzierenden Datenmodelle des einen oder anderen Systems komplexe relationale Operationen, mit denen die Datenkonsistenz nur schwierig zu gewährleisten ist. Vorzuziehen ist in aller Regel eine losere Kopplung der Systeme über Dateien oder Netzwerkprotokolle.

    Variante 3: Netzwerkbasierte/dienstbasierte Schnittstellen

    Webbasierte LMS verfügen per se zumindest über eine HTTP-Schnittstelle; zu koppelnde Systeme in einem Client-Server-Umfeld bieten eine unterschiedliche Anzahl netzwerkbasierter Schnittstellen. Damit ist nicht der einfache Austausch oben genannter Dateien über das Netz (etwa E-Mail oder FTP) gemeint, sondern der uni- oder bidirektionale Datenaustausch zwischen den Systemen über ein gemeinsames Netzwerkprotokoll. Nicht nur für den Austausch von Stammdaten oder Nutzdaten, auch für Authentifizierungsaufgaben (Single-Sign-On) kommen netzwerkbasierte Lösungen in Frage. Protokolle für netzwerkbasierte Schnittstellen gibt es seit längerer Zeit auf unterschiedlichen Ebenen. Nur einige der bekannteren seien hier genannt, ohne dass wir sie alle im Einzelnen erläutern wollen: CORBA, DCOM, CGI, RMI, RPC, LDAP, EJB.

    Ein einfaches Fallbeispiel: Bidirektionale Web Services

     

    Bei der Schweizer Manor AG werden Personalstammdaten, ein Ausbildungskatalog und Personalentwicklungskennzahlen in SAP HR und VM verwaltet. Als LMS kommt der IBT® SERVER der time4you GmbH zum Einsatz. Die Anforderung bei Projektbeginn bestand in der Entwicklung einer einfachen stabilen, synchronen, bidirektionalen Schnittstelle, die wir hier grob skizzieren wollen.

    Von SAP-System zum IBT® SERVER sollen fließen:

    • Stammdaten (Name, Login, Telefonnummer, E-mail, ...) von Mitarbeitern, sowohl initial wie auch nach jeder Änderung an Datenfeldern.
    • Buchungsinformationen: Mitarbeiter X wurde für Kurs Y angemeldet.
    • Vom IBT® SERVER zum SAP-System soll fließen:
    • Mitarbeiter X hat Kurs Y am Tag D mit SCORM-Status S bestanden oder nicht bestanden.

     

    Ein besonderer Charme bei Web Services besteht nun darin, dass die Schnittstellendefinition der Dienste in Form einer WSDL-Datei von den konkreten Implementierungsdetails abstrahiert. Die Service- bzw. Dienste-Programmierer auf der einen Seite und die Client-Programmierer auf der anderen Seite lassen nun jeweils aus den WSDL-Dateien mit ihren bevorzugten Programmierwerkzeugen automatisch Code-Fragmente erzeugen, die ein Grundgerüst für die Datenkommunikation bereitstellen und Teilfunktionen erledigen (z.B. Verbindungsaufnahme, Datentransformation, Fehlerbehandlung). Die Entwickler können sich auf die Ablauflogik und Tests konzentrieren.

    In unserem Fallbeispiel bietet der IBT® SERVER drei Web Services an, mit denen SAP-Komponenten zu beliebigen Zeitpunkten die gewünschten Aktionen auslösen können: Mitarbeiter-Stammdaten liefern, Mitarbeiter-Stammdaten ändern, Mitarbeiter für Kurs buchen.

    Umgekehrt bietet SAP einen Web Service an, über den das LMS zu beliebigen Zeitpunkten die Information über den Abschluss eines Kurses durch einen Teilnehmer an SAP zurückmeldet.

    Auf Seiten des LMS sind die konkreten Ausprägungen der SAP-internen Abläufe dabei unerheblich. Zur Realisierung kommen im IBT® SERVER das OpenSource-Framework Axis und Java zum Einsatz, SAP-seitig .NET.

    Nach dem gegenseitigen Austausch von WSDL-Dateien konnten so die Web Services und Web Clients unabhängig voneinander in wenigen Tagen entwickelt, und ihre Interoperabilität bewiesen werden. Die Schnittstelle läuft seit Jahren stabil, bei Bedarf ist sie ohne größeren Aufwand erweiterbar.

    Strategische Aspekte bei der Gestaltung der LMS-Schnittstellen

    Für die Umsetzung der Schnittstelle von und zu einem LMS genügt die Einigung auf ein Dateiformat und eine Übertragungsart allerdings bei weitem noch nicht. Weitere Aspekte sind in die Betrachtung aufzunehmen:

    • Interoperabilität: Ist sichergestellt, dass beide Seiten die Daten korrekt übermitteln, empfangen und verarbeiten, so dass die wohldurchdachte Geschäftslogik der Anwendungen auch zwischen heterogenen Systemen von unterschiedlichen Herstellern in unterschiedlichen Programmiersprachen auf unterschiedlicher Hardware verteilt funktioniert?
    • Synchronisation: Welche Anforderungen stellen wir an die Aktualität der Daten? Handelt es sich um einen einmaligen Datentransfer vor Inbetriebnahme des LMS oder sollen Daten zwischen LMS und anderen Systemen regelmäßig ausgetauscht werden? Bei einem regelmäßigen Austausch ergeben sich Fragen nach der Häufigkeit (am Monatsende, täglich, stündlich) und nach dem Grad der Synchronisation (sofortiger Datenaustausch bei jeder relevanten Datenänderung).
    • Datenumfang: Wird bei regelmäßiger Übertragung der volle, jeweils aktuelle Datenbestand übertragen (Beispiel: Sämtliche Personalstammdaten von SAP/HR in das LMS) oder beschränkt sich die Übertragung auf die letzten relevanten Änderungen (Beispiele: Benutzer X hat Kurs Y mit n Punkten bestanden, Benutzer Z hat seinen Nachnamen/seine Abteilung geändert)?
    • Sicherheitsaspekte: Welche Authentifizierungen und Autorisierungen sind für Export und Import der Daten erforderlich? Werden vertrauliche Daten ausgetauscht? Wie sensibel sind diese? Müssen Daten insgesamt oder teilweise verschlüsselt werden? Falls ja, mit welchem Verschlüsselungsverfahren?
    • Schnittstellen-Tests: Anders als bei Funktionstests lokaler Software kommen bei Schnittstellen zusätzliche potenzielle Fehlerquellen ins Spiel: in der Datenquelle beim Export, in der Datensenke beim Import und auch auf dem Übertragungsweg. Bei netzwerkbasierten Schnittstellen sind für das Monitoring der Übertragung unter Umständen spezielle Werkzeuge nötig und Spezialisten müssen auf beiden Seiten der Schnittstelle ein- und ausgehende Daten analysieren.
    • Fehlerbehandlung: Wie ist mit Fehlern umzugehen? Was geschieht, wenn eine Austauschdatei unlesbar oder nur teilweise übertragen worden ist? Wie werden Fehlern in einzelnen Datensätzen behandelt? Was geschieht bei Hard- oder Software-Ausfällen auf der einen oder anderen Seite während der Datenübertragung oder bei einem Ausfall der Netzwerkverbindung?

    Fazit

    Zur Integration eines LMS in eine vorhandene IT-Infrastruktur steht uns eine breite Palette erprobter und bewährter Techniken zur Verfügung. Es gibt kaum einen Anwendungsfall, in dem sich die Systeme nicht auf elegante und robuste Weise miteinander koppeln lassen. Doch die Schnittstelle "von der Stange" gibt es auch dann nicht, wenn beide Systeme XML-Import und -Export beherrschen. Ausnahmen bilden standardisierte Formate, wie etwa IMS-Manifest-Dateien für den Austausch von SCORM-WBTs. In den weitaus meisten Fällen besteht die Herausforderung für die Projektteams auf beiden Seiten darin, die geeignete und von beiden Seiten einer Schnittstelle unterstützte Technik zu wählen und alle Aspekte der Datenübertragung detailliert zu spezifizieren.

    Anhang

    Typische Formate bei dateibasierten Schnittstellen

    Exemplarisch seien hier einige typische Vertreter für Dateiformate genannt. Es handelt sich in allen Fällen um Textdateien, die sich auch mit Texteditoren öffnen lassen und für den Menschen lesbar sind.

    CSV (Comma Separated Values): Jede Zeile enthält einen Datensatz, etwa sämtliche Felder einer Lernveranstaltung oder Stammdaten eines Mitarbeiters. Dabei sind die einzelnen Datenfelder innerhalb einer Zeile durch einen Separator, meist Komma oder Semikolon, voneinander getrennt sind. CSV-Dateien sind von Datenquellen besonders leicht zu erzeugen und von Datensenken leicht zu importieren. Entwickler der Schnittstellen müssen sich im Wesentlichen darauf verständigen, welches Datenfeld welche Position in den Zeilen einnimmt und wie die Datei heißen soll.
    CSV ist als Dateiformat auch deshalb beliebt, weil es von den meisten Tabellenkalkulationsprogrammen (Excel, OpenCalc) sowohl gelesen wie auch erzeugt werden kann.

    LDIF (LDAP Data Interchange Format): Häufig bilden Unternehmen ihre hierarchischen Organisationsstrukturen in Verzeichnis-Servern ab (Beipiel: Active Directory). Solche Server bieten anderen Anwendungen Zugang über das standardisierte LDAP-Netzwerk-Protokoll, können ihren Datenbestand alternativ auch in LDIF-Dateien exportieren. Anders als bei CSV wird hier ein Datensatz durch mehrere Zeilen beschrieben und die Zeilen enthalten jeweils intrinsisch die nötigen Zusatzinformationen über die Einbindung des Datensatzes in der Datenhierarchie und die Namen der Attribute. Die in der Datei enthaltene Information erlaubt also einen Import ohne detaillierte Vereinbarungen über den Aufbau der Datei.

    XML (eXensible Markup Language): Die Metasprache XML hat sich in den letzten Jahren zum allgemein akzeptierten und standardisierten universellen Austauschformat für hierarchische Datenstrukturen entwickelt und hält Einzug in eine zunehmende Zahl von Anwendungen. Auch Office-Anwendungen verwenden in ihren jüngeren Versionen XML als internes Datenformat. XML verdankt seine Mächtigkeit nicht zuletzt der Möglichkeit, für jegliche Anwendung eigene Elemente und Attribute zu definieren, um damit die auszutauschenden Objekte zu beschreiben. Entscheiden wir uns bei der Schnittstellenentwicklung für den Einsatz von XML, so ist zunächst für Datenquelle und -senke das gemeinsame XML-Schema festzulegen, das die Namen und Typen von Datenelementen, ihren Attributen und ihrer Struktur bestimmt. Für den Umgang mit XML sind zahlreiche Werkzeuge (Editoren, Parser, Validierer, Serializer) auf dem Markt oder als Open Source-Produkt verfügbar.

    SOA, SOAP, Web Services, - State-of-the-Art der Systemschnittstellen

    Als anerkannte Säule künftiger Infrastrukturen gelten seit einigen Jahren Plattformen mit SOA-Unterstützung. SOA (Service Oriented Architecture) steht dabei weniger für eine spezifische Schnittstellentechnik, sondern vielmehr für ein Software-Architekturkonzept, in dem Systeme einander wohldefinierte, voneinander unabhängige und lose gekoppelte Dienste anbieten und über diese Dienste eben auch Daten austauschen können. Prinzipiell lässt sich dieses Konzept mit verschiedenen, auch älteren Client-Server-Technologien umsetzen. Die wachsende Akzeptanz in jüngerer Zeit wurde ausgelöst vom Erfolg der Programmierumgebungen Java und .NET. Inzwischen ergänzen viele Hersteller wie IBM, SAP, Oracle ihre Systeme und Produktportfolios mit Hilfe von SOA-Baukästen um wiederverwendbare Anwendungsbausteine. Aus der Mehrzahl aktueller Studien lässt sich der Schluss ziehen, dass mittelfristig kaum noch ein größeres Unternehmen an dieser Architektur vorbeikommen wird.

    Einen idealen Satz von Werkzeugen zur Umsetzung dieses Konzeptes liefern die Web Services. Dieser Begriff bezeichnet hier nicht allgemein "Dienste im Web", sondern ganz konkret die Verknüpfung der Technologien SOAP (Simple Object Access Protocol), WSDL (Web Service Description Language) und UDDI (Universal Description, Discovery and Integration). Allen drei Technologien dient XML zur Formatierung der Daten, üblicherweise wird HTTP als Trägerprotokoll eingesetzt.

    In diesem Umfeld stellen also Web Services derzeit den favorisierten Ansatz zur Realisierung netzwerkbasierter Schnittstellen in modernen heterogenen Umgebungen dar.

Kommentare

Das Kommentarsystem ist zurzeit deaktiviert.