Wissenswertes zu edoc content services

Lernen Sie in diesem Artikel grundlegende technische Konzepte und Besonderheiten des Dienstes kennen.

Ein grundlegendes Verständnis zu folgenden technischen Konzepte ist hilfreich für den Umgang mit edoc content services:

Lokales Hosting und Hosting in der Cloud: edoc content services ist so konzipiert und implementiert, dass der Adapter sowohl On-Premises oder Cloud (z.B. Microsoft Azure) verwendet werden kann. Damit edoc content services korrekt funktioniert, müssen Sie lediglich eine HTTP-Verbindung zum Zielsystem aufbauen können.
Keine Datenspeicherung: edoc content services persistiert keine Daten. Für technische Zwecke werden nur die Datentypen von Dokumenteigenschaften in einer In-Memory-Datenbank (Redis) aufbewahrt. Diese Daten werden nur im Arbeitsspeicher temporär gespeichert und gehen nach einem Neustart verloren. Die Daten werden bei Bedarf neu erstellt.
Zustandslose Verarbeitung: edoc content services funktioniert “stateless” (zustandslos). Sie müssen bei jeder Anfrage alle notwendigen Daten, wie z.B. Adresse des Zielsystems oder Anmeldeinformationen (Credentials) ebenfalls bereitstellen.
Fehlerbehandlung von Zielsystemen: edoc content services kommuniziert mit Zielsystemen, bei denen es auch Fehlern kommen kann. Die Fehler der Zielsysteme werden in edoc content services einfach im Original angezeigt und weder aufbereitet, ausgewertet noch übersetzt. Wenn die Fehler nicht eindeutig oder verständlich sind, schauen Sie in das Log des Zielsystems. Im Protokoll sind die Informationen zum Fehler oft umfangreicher als die angezeigte Fehlermeldung.
Log für edoc content services: edoc content services schreibt ein Log um das Verhalten des Dienstes zu protokollieren. Standardmäßig finden Sie das Log in der Konsole des Dockercontainers, in dem der Dienst ausgeführt wird.
Unterstützte Zielsysteme (Module): Module, auch Connectoren genannt, bezeichnen die unterstützten Zielsysteme. Damit edoc content services erkennt, in welcher Form die Anfragen an das entsprechende Zielsystem gesendet werden müssen, müssen Sie bei jedem Aufruf die ID des gewünschten Zielsystems angeben. Welche Zielsysteme die jeweilige edoc content service-Instanz unterstützt, können Sie unter dem /System-Endpunkt abrufen.
Verbindungszeichenfolge (Connection String): Die Bezeichnung “Connection String“ kennen Sie möglicherweise von verschiedenen Datenbanksystemen. Mit der Verbindungszeichenfolge werden Verbindungsdaten transportiert. Diese Verbindungsdaten werden in Key/Value-Konstrukten (Bezeichnung=Wert) angegeben. Diese Konstrukte werden dann in einem String (Zeichenfolge) hintereinander aufgeführt und durch Semikolon voneinander getrennt. In edoc content services hat jedes Modul eine eigene Verbindungszeichenfolge. Die Verbindungsdaten für das jeweilige Zielsystem können Sie unter dem /System-Endpunkt nachlesen. Beispiel: targetHost=https://test.sharepoint.com;User=sharepoint_user;Password=sharepointuser_password;ListId=ac4af181-dd54-4735-bad3-42517e8653f1;

Gut zu wissen

Die Verbindungszeichenfolge wird als Header-Parameter eines HTTP-Aufrufs an edoc content services übertragen.

Laut der Spezifikation RCF 7230 dürfen in Header-Parametern nur Zeichen des US-ASCII-Zeichensatzes verwendet werden. Die Beschränkung auf den US-ASCII-Zeichensatz kann bei Passwortwerten zu Problemen führen, wenn Passwörter Zeichen aus anderen Zeichensätzen enthalten, z.B. Umlaute.

Empfehlung: Verwenden Sie für ein Verbindungszeichenfolge und insbesondere für Passwörter ausschließlich Zeichen des US-ASCII-Zeichensatzes.

Es gibt folgende Besonderheiten bei der Verarbeitung von Daten:

Unix Timestamp als standardmäßiges Datumsformat: edoc content services kann in einer Microservices-Infrastruktur zusammen mit anderen edoc-Apps und edoc-Diensten ausgeführt werden. Aus diesem Grund müssen alle Apps und Dienste dasselbe Datumsformat verwenden. Der Unix Timestamp-Standard (Unix-Zeit) gilt daher für alle Eigenschaften (Attribute) vom Typ Date oder DateTime. Das Format wird auch für die Ausgabe von Attributen verwendet.
JSON-Format für die transportierten Daten: Die Nutzdaten (Payload) sind die Daten eines Datenpakets bei der Kommunikation zwischen den Apps und Diensten. Die Nutzdaten befinden sich bei einer HTTP-Anfrage im Body der Anfrage. edoc content services verwendet das JSON-Format für diese Daten.
Limitierte Anzahl der Dateien pro Dokument: Es gibt einige Zielsysteme, die mehr als eine Datei pro Dokument beinhalten können. edoc content services ist so konzipiert, dass der Adapter pro Dokument nur eine Datei verarbeiten kann. Wenn ein Dokument erstellt wird, können Sie nur eine einzelne Datei hochladen. Auch wenn ein Dokument mehrere Dateien enthalten sollte, liefert edoc content services immer nur eine einzelne Datei. Bei dieser Datei handelt es sich immer um die erste Datei, die das Zielsystem liefert.

Für Entwicklungsteams bietet die REST-API von edoc content services verschiedene Möglichkeiten:

API-Funktionen einfach verwenden: Die REST-API können Sie mit verschiedenen Programmen verwenden, z.B. Postman.
Beschreibung der Endpunkte in Swagger: edoc content services bietet eine Swagger-UI, die alle Endpunkte mit einer Beschreibung enthält. Sie können die Swagger-UI im Browser öffnen und alle Endpunkte einfach ausprobieren. Zusätzlich können Sie die Datei swagger.json herunterladen, mit deren Hilfe Sie für manche Programmiersprachen automatisiert einen Webclient für edoc content services erstellen können.

Sie finden die API standardmäßig unter der URL https://<hostname>/api/content-service.

Erfahren Sie mehr zu den besonderen Merkmalen der einzelnen Module unter: Eigenheiten der einzelnen Module in edoc content services