Damit eine Kanzlei ein Partnerprodukt mit ihrem Dokumentenmanagement verbinden kann, sind drei Dinge nötig. Diese Anleitung sagt, welche das sind, wer sie erledigt und was die Kanzlei dabei selbst entscheiden muss.
Sie wollen selbst gegen die Schnittstelle entwickeln? Dann ist Eine eigene Anwendung anbinden der richtige Einstieg – dort stehen Client-Registrierung, Anmeldeablauf und der erste Aufruf.
Schritt eins: Voraussetzungen klären
| Was | Wer erledigt es |
|---|---|
| Die Kanzlei besitzt eine Lizenz für die Documents Partner API | STP |
| Der Connector ist installiert, angemeldet und mit dem Dokumentenmanagement verbunden | Die Kanzlei, unterstützt durch STP-Service |
| Die handelnden Benutzerkonten haben die passende Rolle | Der Administrator der Kanzlei |
Die ersten beiden sind erledigt, bevor Sie etwas tun müssen. Der dritte Punkt ist der, um den sich diese Anleitung dreht.
Welche Lizenzvariante was erlaubt, steht in Lizenzen und Berechtigungen. Zur Connector-Installation siehe Connector Installation Schritt für Schritt.
Schritt zwei: Die Benutzerkonten festlegen
Die Partneranwendung handelt nicht als „Anwendung“, sondern im Namen eines Benutzers des Mandanten. Dessen Rechte im Dokumentenmanagement entscheiden über jeden einzelnen Zugriff. Es gibt dafür zwei Modelle, und die Wahl gehört an den Anfang der Integration:
| Modell | Wie es aussieht | Wann es passt |
|---|---|---|
| Durchgereichter Benutzer (empfohlen) | Jede Anwenderin und jeder Anwender meldet sich in der Partneranwendung mit dem eigenen STP-Konto an. Die Anwendung handelt in der Schnittstelle unter genau diesem Konto. | Immer, wenn Menschen mit der Partneranwendung arbeiten |
| Technisches Konto | Ein einziges Konto gehört der Partneranwendung. Alle Zugriffe laufen unter diesem Konto, unabhängig davon, wer die Anwendung bedient. | Automatisierte Abläufe ohne handelnde Person – Stapelimporte, Hintergrunddienste |
Warum der durchgereichte Benutzer die bessere Wahl ist
Die Rechte des Dokumentenmanagements greifen dann genau so, wie die Kanzlei sie ohnehin gepflegt hat: Wer eine Akte im Dokumentenmanagement nicht sehen darf, sieht sie auch über die Partneranwendung nicht. Und in der Aktenhistorie steht, wer etwas getan hat.
Ein technisches Konto hebt beides auf. Er braucht die Vereinigung aller Rechte, die irgendein Anwender braucht – also mehr, als jeder Einzelne haben dürfte –, und in der Historie erscheint für jede Aktion dasselbe Konto. Das ist für einen Hintergrunddienst vertretbar, für eine von Menschen bediente Anwendung nicht.
Was der Administrator der Kanzlei einrichtet
In beiden Modellen bekommt das betreffende Konto eine der beiden Rollen:
| Anzeigename | Technischer Name | Wirkung |
|---|---|---|
| Documents Partner API User (read + write documents via the HTTP edge) | DmsCloudApi.User |
Dokumente lesen und ablegen |
| Documents Partner API Reader (list + download only) | DmsCloudApi.User.Reader |
Dokumente nur lesen |
Eine Rolle wird über eine Gruppe vergeben. Für beide Rollen ist in jedem Mandanten bereits eine passende Standardgruppe vorhanden – das Konto wird ihr einfach hinzugefügt. Wer die Rollen anders zuschneiden will, kann eigene Gruppen bilden. Beides beschreibt Rollen und Gruppen.
Zwei Dinge sind dabei wichtig:
- Die Rechte im Dokumentenmanagement zählen zusätzlich. Die Rolle öffnet die Schnittstelle; welche Akten, Ordner und Dokumente das Konto tatsächlich sehen und ändern darf, entscheidet weiterhin die Berechtigungsverwaltung des lokalen Dokumentenmanagements für genau diesen Benutzer.
-
Das Konto muss dem Dokumentenmanagement bekannt
sein. Die Anmeldung in der Cloud und das lokale
Dokumentenmanagement sind über eine Benutzerkennung verbunden. Fehlt
diese Verknüpfung, scheitert jeder Aufruf, der auf das
Dokumentenmanagement zugreift – mit
403 MISSING_USER_IDENTITY.
Schritt drei: Das Partnerprodukt verbinden
Wie die Verbindung hergestellt wird, entscheidet das Partnerprodukt – dort tragen Sie in aller Regel nur den Mandantennamen ein und melden sich einmal an.
Der Mandantenname ist der erste Teil Ihrer STP-Cloud-Anmeldeadresse:
https://<mandant>.stp-cloud.de
^^^^^^^^^Es ist derselbe Wert, den der Administrator bei der Installation des Connectors einträgt. Falls das Partnerprodukt danach fragt und niemand ihn zur Hand hat: Er steht in den Zugangsunterlagen der Kanzlei.
Alles Weitere – Anmeldung, Berechtigungen, Aufrufe – erledigt das Partnerprodukt.
Schritt vier: Prüfen, ob es funktioniert
Der erste Zugriff aus dem Partnerprodukt heraus ist zugleich die Probe. Klappt er, sind alle drei Voraussetzungen erfüllt.
Klappt er nicht, führt fast immer eine dieser Ursachen dorthin:
| Was der Anwender sieht | Wahrscheinliche Ursache | Wer hilft |
|---|---|---|
| Ein Hinweis auf fehlende Berechtigungen | Das Konto ist in keiner passenden Gruppe – oder die Standardgruppe fehlt im Mandanten | Administrator der Kanzlei, siehe Rollen und Gruppen |
| Ein Hinweis auf eine fehlende Lizenz | Die Lizenz fehlt oder passt nicht zum Produkt | STP |
| Es werden keine Akten gefunden, obwohl es welche gibt | Die Rechte des Kontos im Dokumentenmanagement – die gelten zusätzlich | Administrator der Kanzlei |
| Gar keine Verbindung, Zeitüberschreitungen | Der Connector läuft nicht oder erreicht die Cloud nicht | STP-Service |
Ihr Partnerprodukt zeigt diese Fälle möglicherweise anders an. Nennt
es einen Fehlercode oder einen Support-Code der Form
STP-DMS-…, geben Sie den bei einer Rückfrage mit an – damit
findet STP den Aufruf wieder.
Weiterführend
- Rollen und Gruppen – Standardgruppen, eigene Gruppen, und was zu tun ist, wenn eine Berechtigung nicht greift
- Lizenzen und Berechtigungen
- Eine eigene Anwendung anbinden – wenn Sie selbst entwickeln