Integration von Drittanbieter-Inhalten

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

Unterstützung einer Einbettung durch Drittanbieter

Unterstützt die Software aktiv oder wird über Schnittstellen eingebettet? Die meisten web-basierten Dienste tun dies heutzutage, aber einige schränken die Funktionalität ein.

Einbettung von Widgets verfügbar: Im besten Fall hat der Drittanbieter bereits einige Snippets bereit, die alle notwendigen Einbettungen durchführen. Dies ist zum Beispiel für YouTube -Videos der Fall. Hier verwenden wir die Erweiterung Widgets. Diese erstellt einen "Wrapper", der die Ausschnitte hauptsächlich so inkludiert, wie sie bereitgestellt werden. Dies ist aus Sicherheitsgründen erforderlich. Einbettungen sind sehr gut, um komplexe Inhalte anzuzeigen, z. B. Videoplayer, spezialisierte Grafiken, dynamische Diagramme usw., für die eine Art von 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 zieht. Diese Daten müssen dann transformiert und innerhalb des Wiki präsentiert werden. Abhängig von der Komplexität der API kann dies eine sehr einfache Aufgabe sein, aber auch ein sehr herausforderndes Unterfangen. API ist sehr gut, um komplexe Abfragen in die Datenbank der Dritten Partei zu fragen, und wenn der Fokus hauptsächlich auf den abgerufenen Daten liegt (im Gegensatz zur Visualisierung).
Über SDK bereitsgestellt: Einige Drittanbieter stellen Software-Entwicklungskits zur Verfügung. Diese tragen dazu bei, komplexe Anwendungen über der Software zu erstellen. Die Verwendung von SDKs ist das beste Mittel, wenn zwischen dem Wiki und dem Drittanbieter eine komplexe Interaktion erforderlich ist. In der Regel ist die Entwicklung solcher Konnektoren sehr zeitintensiv.

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 der Drittanbieter angemeldet werden. Auf der Pro-Seite hat die Anwendung die volle Kontrolle über Authentifizierung und Zugriffskontrolle. Ein Nachteil kann sein, wenn es kein einzelnes Anmeldesystem gibt, da der Benutzer zu Anmeldungen aufgefordert wird.
Server-basierte Authentifizierung: Kommunikation zwischen dem Drittanbieter und dem Wiki erfolgt auf der Serverseite. Dies bedeutet, dass der Server die Kontrolle über die Authentifizierung übernehmen muss. In diesem Szenario findet die Kommunikation in der Regel mit einem Proxy-Benutzer statt. Auf der Pro-Seite bedeutet dies, dass sich der Wiki -Benutzer nicht um die Authentifizierung kümmert. Nachteil ist, dass die Zugriffskontrolle pro Benutzer schwierig zu implementieren ist (wobei es jedoch 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.

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