Eigene Workflow-Aktionen in JTL-Wawi: Custom Workflows per SQL – mit Praxisbeispiel

JTL-Workflows nehmen viel Handarbeit ab – bis man an eine Stelle kommt, die die Standard-Aktionen nicht erreichen. Für genau diesen Fall gibt es Custom Workflows: eigene Aktionen, die als SQL-Prozedur in der Datenbank liegen und im Workflow-Editor erscheinen wie jede andere Aktion.

Wir zeigen das an einem Fall aus dem Support, der in B2B-Shops regelmäßig auftritt.

Das Problem: Die Kundengruppe im Auftrag bleibt alt

Ein Workflow soll Neukunden automatisch einer B2B-Kundengruppe zuordnen. Mit der Aktion „Werte setzen“ kommt man im Auftrag nur über den Pfad Stammdaten → Kunde → Kundengruppe an die Gruppe heran. Damit ändert sich aber die Gruppe des Kunden – nicht die des Auftrags.

Der Auftrag hat eine eigene Kopie der Kundengruppe. Sie wird beim Anlegen aus dem Kunden übernommen und danach nicht mehr aktualisiert:

In der Oberfläche ist dieses Feld nicht erreichbar. Auswertungen, Folge-Workflows oder Druckvorlagen, die auf die Gruppe im Auftrag schauen, arbeiten dann mit dem falschen Wert.

So funktionieren Custom Workflows

• Eine eigene Aktion ist eine Stored Procedure im Schema CustomWorkflows.
• Der erste Parameter ist immer der Schlüssel des Objekts – beim Auftrag @kAuftrag, beim Artikel @kArtikel, beim Kunden @kKunde.
• Der Name im Workflow-Editor kommt aus einer Extended Property DisplayName an der Prozedur.
• Weitere Parameter brauchen je einen eigenen benutzerdefinierten Datentyp im Schema CustomWorkflows. Der Basistyp bestimmt das Eingabefeld: BIT wird zur Checkbox, INT zum Zahlenfeld, NVARCHAR zum Textfeld.
• Ob alles korrekt registriert ist, zeigt die Sicht CustomWorkflows.vCustomActionCheck.

Legen Sie Custom Workflows zuerst in einer Testkopie der Datenbank an und sichern Sie die Produktivdatenbank, bevor Sie Prozeduren einspielen.

Die Lösung: eine Aktion ohne Parameter

Statt die Gruppe als Parameter zu übergeben, liest die Aktion die aktuelle Gruppe direkt vom Kunden und schreibt sie in den Auftrag. Damit passt ein und dieselbe Aktion in jeden Workflow – egal, welche Gruppe vorher gesetzt wurde.

USE eazybusiness
GO

IF OBJECT_ID('CustomWorkflows.spAuftragKundengruppeVomKunden') IS NOT NULL
    DROP PROCEDURE CustomWorkflows.spAuftragKundengruppeVomKunden
GO

CREATE PROCEDURE CustomWorkflows.spAuftragKundengruppeVomKunden
    @kAuftrag INT
AS
BEGIN
    SET NOCOUNT ON;

    UPDATE a
       SET a.kKundengruppe = k.kKundenGruppe
      FROM Verkauf.tAuftrag AS a
      JOIN dbo.tkunde       AS k ON k.kKunde = a.kKunde
     WHERE a.kAuftrag = @kAuftrag
       AND k.kKundenGruppe IS NOT NULL
       AND ISNULL(a.kKundengruppe, -1) <> k.kKundenGruppe;
END
GO

EXEC sys.sp_addextendedproperty
     @name = 'DisplayName', @value = 'Kundengruppe vom Kunden übernehmen',
     @level0type = 'SCHEMA',    @level0name = 'CustomWorkflows',
     @level1type = 'PROCEDURE', @level1name = 'spAuftragKundengruppeVomKunden'
GO

-- Kontrolle: Status muss "OK" sein
SELECT cName, cDisplayName, cObjekt, nParamCount, Status
  FROM CustomWorkflows.vCustomActionCheck
 WHERE cName = 'spAuftragKundengruppeVomKunden';

Einbau in den Workflow

Workflow-Objekt Auftrag, Aktionen in dieser Reihenfolge:

1. Werte setzen: Stammdaten → Kunde → Kundengruppe = gewünschte Gruppe
2. (optional) Historieneintrag schreiben
3. Kundengruppe vom Kunden übernehmen – die neue Aktion, ohne Parameter

Ab jetzt stehen Kunde und Auftrag auf derselben Gruppe.

Stolperfallen aus der Praxis

Beim Entfernen einer Aktion: erst aus allen Workflows herausnehmen, dann die Prozedur löschen und erst danach die zugehörigen Datentypen – sonst bleiben kaputte Einträge im Workflow stehen.

Fehler finden: das Workflow-Protokoll

Fehler einer Custom-Aktion landen im Workflow-Protokoll. Diese Abfrage zeigt die letzten Einträge:

SELECT TOP 50 l.dDatum, w.cName AS Workflow, l.nTyp, l.kObjektPk, l.cLog
  FROM dbo.tWorkflowLog l
  LEFT JOIN dbo.tWorkflow w ON w.kWorkflow = l.kWorkflow
 ORDER BY l.dDatum DESC;

Was die Aktion bewusst nicht tut

Geändert wird nur das Kopf-Feld der Kundengruppe im Auftrag. Preise der Positionen bleiben unverändert – sie werden beim Anlegen der Position berechnet. Soll der Auftrag nach dem Gruppenwechsel neu bepreist werden, ist das ein eigener Schritt.

Custom Workflows sind ein starkes Werkzeug – und eines, mit dem man direkt in der Datenbank arbeitet. Wenn Sie unsicher sind, ob eine Aktion so gebaut ist, dass sie auch das nächste Wawi-Update übersteht, sprechen Sie uns an.

Häufige Fragen