ERP-Integration

Die nahtlose Anbindung an microtech büro+ ist ein zentraler Bestandteil der Workflow-Engine. Die Kommunikation erfolgt über eine moderne GraphQL-Schnittstelle, die es ermöglicht, Daten präzise zu lesen und Statusänderungen in Echtzeit zurückzuschreiben.

Beteiligte Tabellen und Felder

Die Workflow-Engine interagiert primär mit der Tabelle tblTransactions (Vorgänge) innerhalb von microtech. Hierbei werden spezifische Felder genutzt, um den Prozess zu steuern und Rückmeldungen aus dem Workflow direkt im ERP sichtbar zu machen.

Steuerung des Workflow-Starts

Damit ein Vorgang in den Workflow gelangt, müssen bestimmte Felder belegt sein:

• fldSel30312 (Start-Trigger): Dieses Feld fungiert als Ampel. Steht es auf Workflow angefordert, erkennt die Engine den Datensatz als neuen Task.
• fldSel30313 (Workflow-Name): Hier wird hinterlegt, welcher spezifische Prozess (z.B. ein Freigabeverfahren) gestartet werden soll.
• fldInExtBeaInfo (Start-Notiz): Ein Textfeld für initiale Kommentare, die dem ersten Bearbeiter im Workflow angezeigt werden.
• fldDokGUID (Dokument-Referenz): Über diese GUID kann die Engine das verknüpfte Dokument (z.B. ein PDF) direkt aus dem ERP abrufen.

Rückmeldung und Status-Updates

Die Engine steuert den Prozess und den Zugriffsschutz über folgende Felder in tblTransactions:

• Status (fldSel30312): Mapping der Prozesszustände (im Workflow, Workflow erfolgreich abgeschlossen, Workflow fachlich abgelehnt).
• Historie & Protokoll (fldGspInfo): Export der Workflow-Kommentare sowie des Abschluss-Ergebnisses (Datum Zeit, END, SYSTEM: <Status>) als Textblock mit Trennlinie (__________), vorangestellt vor eventuell bestehenden Notizen.
• Sperr-Logik:
  • Aktiv: fldInExtBeaKz = true (Technischer Lock während der Laufzeit).
  • Abschluss: fldGspKz bleibt unverändert. Der Datensatz wird durch fnUnlockFromExternalProcessing entsperrt (fldInExtBeaKz = false), und fldInExtBeaInfo wird automatisch geleert.

Benutzer-Stammdaten für Rückfragen (tblUsers)

Neben Vorgängen greift ConnectWORKFLOW auf die Benutzertabelle tblUsers zu, um auswählbare Ansprechpartner für Rückfragen bei Aufgaben zu ermitteln.

Welches E-Mail-Feld hierbei abgefragt wird, ist mandantenabhängig konfigurierbar (userEmailField). Über die GraphQL-Schnittstelle wird die Abfrage dynamisch mit dem konfigurierten Feld parametrisiert:

• Unterstützte E-Mail-Felder: fldEMail1 (Standard), fldEMail2, fldFirEMailInt (E-Mail von intern) und fldFirEMail (E-Mail von extern).
• GraphQL-Filterkriterien:
  • fldGspKz == false (Benutzerkonto darf nicht gesperrt sein)
  • <userEmailField> != "" und isNotNull (das konfigurierte E-Mail-Feld muss gepflegt sein)
• Gelesene Benutzerfelder: fldAnmNa (Anmeldename), fldVNa (Vorname), fldNNa (Nachname), fldGspKz (Gesperrt-Kennzeichen) sowie das jeweils ausgewählte E-Mail-Feld.

Technischer Datenaustausch

Zeitpunkt	Feld ERP	Richtung	Logik / Format
Start	fldInExtBeaInfo	ERP → Workflow	Import als InitialNote in die Historie.
Abschluss	fldInExtBeaInfo	Workflow → ERP	Automatische Bereinigung (auf leeren Wert gesetzt, wenn fldInExtBeaKz von true auf false wechselt).
Abschluss	fldGspInfo	Workflow → ERP	Prepend (neue Daten oben). Format: Datum Zeit, Schritt, Bearbeiter: Kommentar gefolgt vom Protokolleintrag Datum Zeit, END, SYSTEM: <Sel30312-Ergebnis> und Trennlinie __________

Sperr-Mechanismus (Locking)

Die Synchronisation erfolgt via GraphQL unter Nutzung des microtech Sperrsystems.

1. Lock: Setzen von fldInExtBeaKz beim Workflow-Start.
2. Runtime: Datensatz ist in microtech für manuelle Änderungen gesperrt (Hinweis: "Workflow Engine").
3. Unlock: fnUnlockFromExternalProcessing wird vor dem finalen Schreibvorgang aufgerufen (fldInExtBeaKz = false).
4. Final Status: Abschlussstatus (fldSel30312) und Protokolleintrag in fldGspInfo schreiben (fldGspKz bleibt unverändert), sowie fldInExtBeaInfo leeren.