GraphQL FAQ - microtech ERP System
Allgemeine Funktionalitäten
Q: Wird die GraphQL-Schnittstelle auch andere Programmfunktionen wie eigene Abläufe und Bereichsaktionen starten können?
A: Ja, geplant ist das. In welcher Reihenfolge neue Funktionen dazu kommen, können Sie über unsere Ideenfabrik mitbestimmen - hier einreichen oder voten.
Q: Ist es geplant, dass der Client zukünftig nur noch über GraphQL kommuniziert?
A: Nein, auch in Zukunft wird der Client direkt mit dem Datenbankserver kommunizieren. Bestimmte Funktionen, die besonders datenintensiv sind (wie z.B. Vorgang buchen oder wandeln), werden aber zukünftig direkt im Anwendungsserver (der direkt neben der Datenbank läuft) ausgeführt, um dann viel schneller und datensparsamer zu sein. Das passiert dann über GraphQL.
Q: Wann kann über GraphQL ein Druck angestoßen werden?
A: Aktuell noch nicht. Bitte voten Sie dafür in der Ideenfabrik .
Geschäftsregeln und Automatisierung
Q: Werden Regeln beim Ändern von Datensätzen automatisch ausgeführt? Wenn ja, welche Regelanweisungen?
A: [Antwort folgt]
Q: Wie werden Prüfläufe bei Vorgangspositionen behandelt?
A: [Antwort folgt]
Q: Kann ich deaktivieren, dass die Schnittstelle beim Anlegen neuer Datensätze Regeln ausführt?
A: Aktuell noch nicht. Bitte voten Sie dafür in der Ideenfabrik .
Berechtigungen und Sicherheit
Q: Funktionieren die Benutzerberechtigungen auf Feldebene schon vollumfänglich?
A: [Antwort folgt]
Q: Kann ich verschiedenen GraphQL-Nutzern unterschiedliche Rechte geben (z.B. nur lesen/ändern, aber nicht löschen)?
A: Ja, das geht heute schon über die Berechtigungsstrukturen, da diese Rechte voll beachtet werden.
Q: Wie kann eine 2-Faktor-Authentifizierung implementiert werden?
A: Aktuell wird eine 2-Faktor-Authentifizierung nicht unterstützt, voten Sie hier für diese Idee in der Ideenfabrik.
Datenverwaltung und -konsistenz
Q: Muss ich absolut notwendige Felder selbst bestimmen und füllen, oder wird z.B. eine Adressnummer automatisch gesucht und vergeben?
A: Absolut notwendige Felder müssen selbst bestimmt werden. Das Feld Adressnummer gehört aber nicht dazu. Wenn das Feld fldStatus z.B. auf Kunde gesetzt wird, wird die nächste freie Adressnummer automatisch gesucht und vergeben. Über dieses Beispiel können Sie lernen, wie Sie abfragen, welche Felder unbedingt notwendig sind. Viele Felder werden aber automatisch vorbelegt, z.B. wenn es um verlinkte Datensätze geht (z.B. ein Kontakt zu einer Adresse - hier wird alles, was die Adresse angeht, vorbelegt; Sie füllen nur noch die für den eigentlichen Kontakt notwendigen Felder).
Q: Werden Indexfelder (wie die nächste freie Datensatznummer) in Freien Tabellen automatisch vergeben?
A: [Antwort folgt]
Q: Wird die LSN von allen Seiten (ERP Client-App, Import, COM und GraphQL) verwaltet und berücksichtigt?
A: Ja, die Nummern werden auf Datenbankebene verwaltet, unabhängig davon, ob über COM, GraphQL, Import oder Benutzeroberfläche.
Q: Warum werden die Tabellen in GraphQL englisch benannt und nicht mit der deutschen Bezeichnung aus dem DB Manager?
A:
Internationale Naming Conventions
GraphQL-Schemas folgen weltweit etablierten Patterns wie Transaction, Account, Document, Product - deutsche Begriffe wie Vorgang, Konto, Beleg, Artikel wirken in diesem Kontext unprofessionell und erschweren die Adoption.
IDE und Tooling Support Moderne Entwicklungsumgebungen, GraphQL-Clients (Apollo, Relay) und Code-Generatoren erwarten englische Bezeichner. Auto-Complete, Type-Hints und Linting funktionieren besser.
KI/LLM Integration
KI-Modelle sind primär auf englischen Code trainiert. Bei Product oder Transaction generiert KIs sofort sinnvollen Code, bei deutschen Begriffen ist die Codegenerierung unzuverlässiger.
Onboarding Mit englischen Tabellennamen ist ein neuer Entwickler am Tag 1 produktiv. Er muss nicht erst ein Wörterbuch studieren, sondern kann direkt mit seinem vorhandenen Domain-Knowledge loslegen.
Pragmatischer Kompromiss
Die Feldnamen sind deutsch (ArtNr, RabSz), da diese unseren Anwendern aus Tabellenansichten, Regeln, Drucklayouts und dem DB-Manager bekannt sind. Nur die Tabellen selbst werden englisch benannt - das schafft eine moderne API-Facade bei voller Rückwärtskompatibilität.
Datenbankzugriff und Sperren
Q: Wie geht GraphQL mit gesperrten Datensätzen um (z.B. Vorgänge durch andere Benutzer)?
A: Die mutation wird abgebrochen und alle Änderungen werden zurückgerollt. In der Antwort gibt es eine passende Fehlermeldung.
Q: Ist es möglich, mit GraphQL auf externe Datenbanken zuzugreifen und diese Werte dann in büro+ zu setzen/manipulieren?
A: GraphQL selbst ist eine reine Abfragesprache und kann nicht direkt auf externe Datenbanken zugreifen.
Was GraphQL kann: - Daten aus büro+ abfragen und manipulieren - Komplexe Datenverarbeitung durch microtech-spezifische Erweiterungen in der Abfragesprache - Parametrisierte queries & mutations für flexible Datenoperationen
Die microtech GraphQL-API ist bewusst als sichere, gekapselte Schnittstelle konzipiert, die nur auf büro+-Daten zugreift. Dies gewährleistet Datensicherheit und -integrität.
Integration und Synchronisation
Q: Wäre mit GraphQL eine vollständige Synchronisation zu einem Shop-System wie Shopify möglich?
A: Ja, die Schnittstelle bietet alles, was dafür notwendig ist. Mit einem passenden Programm, Script oder Automatisierungsablauf kann so etwas realisiert werden.
Q: Kann ich mit der SQL-Replikation oder GraphQL auch Daten wieder ins ERP zurückschreiben lassen?
A: Mit der SQL-Replikation nicht - diese reine Datenschnittstelle repliziert alle ERP-Daten in eine PostgreSQL-Datenbank, so dass dort die Daten weiter ausgewertet werden können. Mit GraphQL, unserer Business Logic-Schnittstelle, können Daten gelesen und auch zurück in das ERP geschrieben werden.
Q: Kann ich den Preis eines Kunden für einen bestimmten Artikel unter Berücksichtigung aller Preislogiken über GraphQL auslesen, ohne einen Vorgang anzulegen?
A: Nein, aktuell nicht. Dafür würde es eine neue Funktion auf der Schnitstelle brauchen. Bitte als Idee in der Ideenfabrik anlegen .
Stand: September 2025