Schreibende Verbindung in SQL-Datenbanken

[Alexander Gensler]

Guten Tag zusammen,

nach meinem aktuellen Kenntnisstand ist es in KIX 18 mit Connect Database nicht möglich, schreibend in der Datenbank zu agieren, es sind nur SELECT-Abfragen möglich. Nachdem für die Abfragen bereits eine funktionierende Datenbankverbindung besteht, dürfte es aus meinem Verständnis jedoch mit überschaubarem Aufwand möglich sein, in Jobs oder Ticket-Aktionen die Möglichkeit anzubieten, INSERT, UPDATE, DELETE oder EXECUTE (für Stored Procedures) mit KIX-Platzhaltern als Übergabe-Parameter auszuführen.

Ich bitte um Evaluierung und die Bitte, dies in den Entwicklungsprozess aufzunehmen. Nur mit o.g. Möglichkeiten ist aus meiner Sicht eine effektive Automatisierung von Prozessen zu ermöglichen.

Viele Grüße
Alexander

[René Hartman]

Hallo Alexander,

Das Connect-Modul ist nur für den lesenden Zugriff gedacht, aber wenn du mir deinen Anwendungsfall erläuterst können wir gucken ob dein Anwendungsfall anderweitig umsetzbar ist.

Viele Grüße,
René

[Alexander Gensler]

Hallo René,

vielen Dank für die Rückmeldung.
Unser Anwendungsfall ist konkret, dass wir eine SQL-Datenbank haben, in der diverse Tabellen (Personal, Inventar, Beschaffungen, usw.) gepflegt werden. Beispielsweise muss bei einer Personalveränderung "Abteilungswechsel inkl. Bürowechsel" die Tabelle Personal und Inventar aktualisiert werden. Da diverse Fachanwendungen auf diese Datenbank aufbauen ist eine Abkehr von dieser Datenbank z.B. hin zu KIX-Assets + Active Directory keine Option.

Bei o.g. Beispiel wäre der Status Quo, dass die IT-Abteilung und die Organisations-Abteilung derzeit von der Personal-Abteilung die Informationen per Mail zugeschickt bekommt und diese per Datenpflege-Anwendung händisch in die Datenbank einträgt. Das ist leider aufgrund des Faktors Mensch fehleranfällig. Mein Ziel ist es, diesen Prozess weitestgehend zu digitalisieren und automatisieren. So sollen die Daten zukünftig von der Personal-Abteilung in einen KIX-Workflow eingegeben werden und die Organisations- und IT-Abteilung diese nur noch auf Korrektheit sichten, bevor diese in die Datenbank (und Active Directory) automatisiert übertragen werden. Dadurch wäre nur eine einzige Eingabe der Daten notwendig.

Da auch für das Active Directory durch KIX keine direkte schreibende Verbindung möglich ist (siehe https://forum.kixdesk.com/index.php?topic=12164.msg18070), habe ich bereits eine auf C# MinimalAPI-basierende Schnittstelle für KIX programmiert, die per KIX Connect Webservice Powershell-Skripte auf dem Host-Server der Schnittstelle ausführen kann und so die Pflege des AD ermöglicht. Daher dürfte die von dir angesprochene "anderweitige Umsetzung" aus meiner Sicht auch auf diesem Wege machbar sein: ich erweitere die Schnittstelle um die Ausführung von Stored Procedures auf der SQL-Datenbank und steuere diese KIX-seitig über Connect Webservices an.

Allerdings hatte ich mir erhofft, auf eine erneute Programmierung verzichten zu können. Bei oben verlinktem Thema des ADs habe ich die Argumentation verstanden, dass man aufgrund des Linux-Backends keine windows-spezifische Technologie wie das AD einfügen kann (wenn gleich dies in manchen Programmiersprachen inzwischen sogar möglich ist). Im Falle der Datenbank kann ich das jedoch nicht nachvollziehen, nachdem ODBC auch für Linux gängig ist und - wie angesprochen - durch die lesende Verbindung ja bereits eine standardisierte Datenbankverbindung besteht. Mich würde daher die konkrete Erwägung seitens KIX interessieren, warum man hier den Funktionsumfang beschränkt.

/edit: Eine ergänzende Rückfrage: Nachdem das Baramundi-Plugin gleich bepreist ist, wie das Datenbank-Plugin: Ist auch das Baramundi-Plugin nur lesend?

Viele Grüße
Alexander

[Frank Niethardt]

Hi Alexander,

zum Baramundi Plugin - was wir im Einsatz haben - kann ich dir sagen, dass das im Prinzip ein verbogenes Connect Webservice Modul ist. Sprich, es gibt eine Zentrale Konfiguration für die bConnect URL und deren Zugangsdaten und dann Aufrufe, um diese möglichst trivial ansprechen zu können.
In dem Sinne ist es auch eher für den lesenden Zugriff gedacht, wenn man auch Nutzdaten mitgeben kann. Aber ich bin mir nicht sicher, ob es auch POST kann, oder nur GET macht...

Mit dem Connect Webservice Modul könntest du das aber auch alles erreichen.

Viele Grüße
Frank

[Torsten Thau]

Hallo,

KIXConnect-Baramundi kann derzeit nur GET-Requests absenden und greift auf eine zentral definierte Basis-URL und Auth-Parameter zurück. Je nachdem was die Gegenseite damit macht, kann das "lesende" oder auch "schreibende" Auswirkungen haben. Wird das HTT-Protokoll seiner Absicht nach benutzt, wird ein GET-Request idR nur Informationen lesen. Es gibt aber auch andere Implementierungen... Soweit wir informiert sind bieten die Baramundi-Endpunkte in bConnect hinsichtlich GET nur lesenden Zugriff. Allerdings kennen wir zugegebenermaßen nicht alle Details der aktuellen geschweige den der kommenden bConnect-Schnittstelle.

Im Laufe von 2025 wollen wir auch ein POST im bConnect-Webhook ermöglichen. Das Zielszenario ist, Baramundi zu einer Job-Ausführung auf einem oder mehreren Clients zu bewegen, ohne dafür KIXConnect-Webservice zu benötigen. Aus Sicht der Business Cases wird KIXConnect-Baramundi damit wesentlich mehr Potential erhalten. Leider bietet bConnect selbst aber noch keine guten Endpunkte um Kataloge von verfügbaren Softwares oder Jobs einfach (und ohne gesonderte Extraktion) auflisten zu können. Das wäre dann natürlich noch besser und ließe sich sehr schön in Tickets integrieren.

Zum Thema KIXConnect-Database: KIX hat nicht die Ambition als Ersatz GUI für beliebige Datenmodelle zu dienen. Grundsätzlich kann ich nur stark davon abraten, direkt in der Datenbank einer anderen Applikation zu schreiben. Das wäre ein "informatisches No-Go". Das Schreiben von Daten in der DB einer Applikation sollte nur die Applikation selbst oder eine dafür erstellte API  (z.B. via REST) tun. Das ist ähnlich der Fall bei Zugriffen auf ein Active Directory. In der Regel hängen hier wesentlich mehr Auswirkungen an einer solchen Aktion als in KIX eingesammelt werden - Lizenzen/Nutzer sind da nur ein kleiner Aspekt.

Für solche Szenarien (KIX gibt Informationen an integrierte Systeme) greifen wir auf KIXConnect-Webservice und einen vom "Zielsystem-Wissenden" bereitgestellten Webservice zurück - wie Frank schon schreibt. Es wird dazu eine klare Schnittstelle mit klarer Funktion und Abgrenzung definiert. Damit kann KIX und der spezifische Anwendungsfall dann bestens und ohne KIX-exklusive Entwicklung integriert werden, muss aber nicht die Interna das Zielsystems kennen. Letztlich kann die Schnittstelle auch von anderen Systemen genutzt werden.

Ich hoffe das hat ein wenig geholfen - auch wenn es vermutlich nicht die erhoffte Antwort war... 🤷�♂️

Viele Grüße und eine angenehme Weihnachtszeit, Torsten

[Alexander Gensler]

Hallo Torsten,
hallo Frank

vielen Dank für eure Antworten.

Ich muss wohl doch kurz das Thema "Fachanwendung" in diesem Fall näher spezifizieren. Es handelt sich um hauseigene Anwendungen, die spezifische Sichten auf die Daten aus der Datenbank bereitstellen. So haben wir bspw. eine Anwendung, die die organisatorischen Daten für unsere Organisations-Abteilung anzeigt, eine IT-bezogene Inventarsicht oder auch eine abgespeckte Mini-Fachanwendung, die den Empfangsdamen eine Übersicht über die Zuordnung Mitarbeiter <-> KfZ-Kennzeichen ermöglicht.

All diese Mini-Anwendungen haben Funktionen zur Pflege von sehr spezifischen Datenbereichen, die aber SQL-seitig durch vorgegebene Stored Procedures angesprochen und validiert werden. In Fällen, in denen die zu pflegenden Daten nur über eine Stelle laufen, wird dies auch weiterhin über o.g. Funktionen in den Fachanwendungen erfolgen (z.B. die KfZ-Pflege). Für Fälle, in denen die Daten jedoch über mehrere Stellen laufen und ohnehin in KIX vorliegen (z.B. den bereits genannten "Abteilungswechsel"), ergibt es aus meiner Sicht Sinn, die in KIX eingegebenen Daten im Sinne einer Automation zur Datenbankpflege zu nutzen. Andernfalls würden die Daten bspw. durch die Personalstelle eingetragen werden und im nächsten Workflow-Schritt bei der Organisationsabteilung wieder händisch per Fachanwendung in die Datenbank übertragen werden. Ob nun KIX oder die Fachanwendung die Stored Procedure aufruft, macht aus Informationssicht m.E. keinen Unterschied, ich kann mir nur einmal den Fehlerfaktor Mensch sparen.

TL;DR: Im Falle unserer Datenbank sind die existierenden Stored Procedures die von dir erwähnte Schnittstelle mit klarer Funktion und Abgrenzung. Ich werde diese daher per REST Webservice ansprechen.

Viele Grüße und frohe Weihnachten
Alexander