Zuletzt bearbeitet vor einem Jahr
von Richard Heigl

Integration von Drittanbieter-Inhalten

Die Integration von Inhalten Dritter in eine Wiki-Seite kann auf verschiedene Weise erfolgen. Die Entscheidung hängt von verschiedenen Faktoren ab.

Unterstützung einer Einbettung durch Drittanbieter

Wird die Software aktiv unterstützt oder über Schnittstellen eingebunden? Die meisten webbasierten Dienste tun dies heute, aber einige schränken die Funktionalität ein.

  • Einbettung von Widgets verfügbar: Im besten Fall hat der Drittanbieter bereits einige Snippets vorbereitet, die alle notwendigen Einbettungen vornehmen. Dies ist beispielsweise bei YouTube-Videos der Fall. Hier wird die Erweiterung Widgets verwendet. Diese erstellt einen "Wrapper", der die Snippets im Wesentlichen so einbindet, wie sie bereitgestellt werden. Dies ist aus Sicherheitsgründen notwendig. Einbettungen eignen sich sehr gut für die Darstellung komplexer Inhalte wie Videoplayer, spezialisierte Grafiken, dynamische Diagramme usw., für die eine Art Player erforderlich ist.
  • Über API bereitgestellt: Wenn der Drittanbieter API-Zugriff gewährt, muss eine Erweiterung geschrieben werden, die die API aufruft und die entsprechenden Daten extrahiert. Diese Daten müssen dann transformiert und im Wiki dargestellt werden. Abhängig von der Komplexität der API kann dies eine sehr einfache, aber auch eine sehr herausfordernde Aufgabe sein. Die API eignet sich sehr gut, um komplexe Abfragen an die Datenbank des Drittanbieters zu stellen und wenn der Schwerpunkt auf den abgerufenen Daten liegt (im Gegensatz zur Visualisierung).
  • Über SDK bereitgestellt: Einige Drittanbieter stellen Software Development Kits (SDK) zur Verfügung. Diese helfen bei der Erstellung komplexer Anwendungen über die Software. Die Verwendung von SDKs ist am besten geeignet, wenn eine komplexe Interaktion zwischen dem Wiki und dem Drittanbieter erforderlich ist. Die Entwicklung solcher Konnektoren ist in der Regel sehr zeitaufwendig.

Authentifizierung und Zugriffskontrolle

Dieser Faktor schränkt ein, welcher der oben genannten Lösungen verwendet werden kann.

  • Client (Browser)-basierte Authentifizierung: Der Benutzer muss im System des Drittanbieters angemeldet sein. Auf der Pro-Seite hat die Anwendung die volle Kontrolle über Authentifizierung und Zugriffskontrolle. Dies kann ein Nachteil sein, wenn es kein einheitliches Anmeldesystem gibt, da der Benutzer aufgefordert wird, sich anzumelden.
  • Server-basierte Authentifizierung: Die Kommunikation zwischen dem Drittanbieter und dem Wiki erfolgt serverseitig. Das bedeutet, dass der Server die Kontrolle über die Authentifizierung übernehmen muss. In diesem Szenario findet die Kommunikation normalerweise mit einem Proxy-Benutzer statt. Auf der Proxy-Seite bedeutet dies, dass sich der Wiki-Benutzer nicht um die Authentifizierung kümmern muss. Der Nachteil ist, dass die Zugriffskontrolle pro Benutzer schwierig zu implementieren ist (obwohl es möglich ist).

Integrationsstufe

  • Erstanreiz mit Umleitung: In einigen Szenarien möchte eine Integration nur die Aufmerksamkeit eines Benutzers auf sich ziehen. Für die tiefe Interaktion wird der Benutzer in die Software der Drittanbieter weitergeleitet. Dies ist der Fall, z. B. zum Einbetten einer Ticketsystemnummer (die einfach den Ticketstatus anzeigt, aber für jede Interaktion muss der Benutzer dem Link zum Ticketsystem folgen).
  • Vollständiges Lesen: In diesem Szenario sollte der eingebettete Inhalt vollständig lesbar sein, z. B. mit Videos oder Grafiken. Es ist keine Bearbeitung erforderlich.
  • Volle Interaktion: In diesem Szenario sollte die gesamte Interaktionsspanne unterstützt werden. Dies ist bei BlueSpice mit eingebetteten drawio-Diagrammen der Fall.

Es gibt verschiedene technische Möglichkeiten, Inhalte einzubetten. Meistens würden wir versuchen, mit Widgets zu arbeiten, solange es einen Einbettungscode oder eine "Iframe" -Lösung gibt.

Siehe auch



Feedback zur Dokumentation ist im Community-Forum möglich.

Diskussionen