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 läuft aktiv in der Cloud.
  • Workflow erfolgreich abgeschlossen: Regulärer Abschluss nach Freigabe.
  • Workflow fachlich abgelehnt: Beleg wurde im Prüfschritt abgelehnt.
  • Workflow technisch fehlgeschlagen: Systemstörung oder nicht erfüllte Startbedingungen (TRIGGER_NOT_MATCHED).
  • Leerer String (""): Beim administrativen Abbruch durch einen Tenant-Administrator werden fldSel30312 und fldSel30313 geleert, sofern davor Werte hinterlegt waren.
• Workflow-Name (fldSel30313): Belegtes Kennzeichen für den gestarteten Blueprint. Wird beim administrativen Abbruch ebenfalls selektiv auf leer zurückgesetzt.
• 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. Bei nicht erfüllten Startbedingungen wird hier die konkrete nicht erfüllte Formel hinterlegt.
• Sperr-Logik:
  • Aktiv: fldInExtBeaKz = true (Technischer Lock während der Laufzeit).
  • Abschluss (regulär): fldGspKz bleibt unverändert (oder true bei Ablehnung). Der Datensatz wird durch fnUnlockFromExternalProcessing entsperrt (fldInExtBeaKz = false), und fldInExtBeaInfo wird automatisch geleert.
  • Abschluss (administrativ): Der Datensatz wird durch fnUnlockFromExternalProcessing entsperrt (fldInExtBeaKz = false), fldGspKz bleibt false (keine Belegsperre) und vorhandene Werte in fldSel30312 / fldSel30313 werden gelöscht.

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 (regulär)	fldInExtBeaInfo	Workflow → ERP	Automatische Bereinigung (auf leeren Wert gesetzt, wenn fldInExtBeaKz von true auf false wechselt).
Abschluss (regulär)	fldGspInfo	Workflow → ERP	Prepend (neue Daten oben). Format: Datum Zeit, Schritt, Bearbeiter: Kommentar gefolgt vom Protokolleintrag Datum Zeit, END, SYSTEM: <Sel30312-Ergebnis> und Trennlinie __________
Administrativer Abbruch	fldInExtBeaKz / fldInExtBeaInfo	Workflow → ERP	Aufruf von fnUnlockFromExternalProcessing: fldInExtBeaKz = false, fldInExtBeaInfo = "".
Administrativer Abbruch	fldSel30312 / fldSel30313	Workflow → ERP	Selektives Leeren ("") via GenerateTblTransactionsClearFieldsMutation, sofern zuvor Werte vorhanden waren. fldGspKz bleibt false.
Startbedingung verfehlt (TRIGGER_NOT_MATCHED)	fldGspInfo / fldSel30312	Workflow → ERP	Hinweissperre (fldGspKz = true, fldSel30312 = "Workflow technisch fehlgeschlagen"). In fldGspInfo wird die nicht erfüllte Startbedingung ausgewiesen.

Sperr-Mechanismus (Locking)

Die Synchronisation erfolgt via GraphQL unter Nutzung des microtech Sperrsystems:

1. Lock: Setzen von fldInExtBeaKz = true 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. Finaler Zustand je nach Abschlussart:
   • Reguläre Freigabe/Ablehnung: Abschlussstatus (fldSel30312) und Protokolleintrag in fldGspInfo schreiben (fldGspKz = true bei Ablehnung), sowie fldInExtBeaInfo leeren.
   • Administrativer Abbruch: Datensatz via fnUnlockFromExternalProcessing entsperren, fldSel30312 und fldSel30313 bei vorhandenem Inhalt leeren, fldGspKz bleibt false (Beleg ist sofort wieder frei bearbeitbar).
   • Startbedingung nicht erfüllt: Datensatz entsperren (fldInExtBeaKz = false), aber mit Prüfsperre (fldGspKz = true, Status Workflow technisch fehlgeschlagen) und konkreter Bedingungsformel in fldGspInfo versehen.