Neu Workflows per Script ausführen

[timblicker]

Hallo zusammen,

ist es möglich Workflows mit einem Script (Bsp: PowerShell, .NET Programm, o.ä.) remote aufzurufen?

 

[timblicker]

Gibt es keine Möglichkeit?
Ist das nur für mich interessant, oder gibt es noch mehr die das gebrauchen könnten?

 

[tobiasgraeber]

Ich fände das ebenfalls sehr interessant. (Könnte ggf. aber auch schon über die wawi dlls gehen...)

 

[csaeum]

Nein wäre auf jedenfall interessant.

 

[T4DT.GmbH]

Ja geht. Wie genau, hängt aber sehr stark von der verwendeten Wawi-Version ab. Wir haben uns dazu eine ausführbare Exe geschrieben, welche wir von allen Programmen parametrisiert aus aufrufen

 

[timblicker]

Lässt du uns daran teilhaben? Wie habt Ihr es denn gelöst?

 

[nesh]

Hallo,

ich hatte mich auch schon mal an das Thema gesetzt (EXE via Kommandozeile und Parametern aufrufen) und dann div. Dinge via scripts aus zu führen..
Es war sogar schon so weit, dass man nicht die Internen IDs der verschiedenen Bereiche übergeben musste, sondern je nach Bereich die Kundennummer, Bestellnummer, Externe Auftragsnummer oder auch Artikelnummer als Parameter übergeben konnte.
Die Id habe ich mit dann aus der entsprechenden Tabelle "gezogen" und dann via Extern.DLL übergeben.

Leider habe ich mir dann die Doku dazu zu spät genauer angeschaut. Da ich dann erst gesehen habe, dass man die *Manuell Events nicht aufrufen kann, habe ich das "Projekt" begraben.
Da man nur die Ereignisse aufrufen kann die sowieso schon vom Worker oder "sofort" ausgeführt werden, hat das dann für uns keinen Sinn mehr gemacht....

MEGA wäre es, wenn man via Extern.DLL nicht nur ein Ereignis (In meinem Fall "Manuell") sondern zusätzlich auch noch gezielt einen Workflow übergeben könnte, der abgearbeitet werden soll.
Dann würde ich das Projekt wieder zum Leben erwecken... Nicht aus zu denken, was man dann alles Extern triggern könnte....

 

[T4DT.GmbH]

Hallo,

ich hatte mich auch schon mal an das Thema gesetzt (EXE via Kommandozeile und Parametern aufrufen) und dann div. Dinge via scripts aus zu führen..
Es war sogar schon so weit, dass man nicht die Internen IDs der verschiedenen Bereiche übergeben musste, sondern je nach Bereich die Kundennummer, Bestellnummer, Externe Auftragsnummer oder auch Artikelnummer als Parameter übergeben konnte.
Die Id habe ich mit dann aus der entsprechenden Tabelle "gezogen" und dann via Extern.DLL übergeben.

Leider habe ich mir dann die Doku dazu zu spät genauer angeschaut. Da ich dann erst gesehen habe, dass man die *Manuell Events nicht aufrufen kann, habe ich das "Projekt" begraben.
Da man nur die Ereignisse aufrufen kann die sowieso schon vom Worker oder "sofort" ausgeführt werden, hat das dann für uns keinen Sinn mehr gemacht....

MEGA wäre es, wenn man via Extern.DLL nicht nur ein Ereignis (In meinem Fall "Manuell") sondern zusätzlich auch noch gezielt einen Workflow übergeben könnte, der abgearbeitet werden soll.
Dann würde ich das Projekt wieder zum Leben erwecken... Nicht aus zu denken, was man dann alles Extern triggern könnte....

Nun ja, du kannst zumindest im Workflow hinterlegen, dass der Workflow nur "extern", also über die DLL aufgerufern werden kann. Dann hinterlegst du den Workflow für "geändert" und startest ihn extern

 

[T4DT.GmbH]

Lässt du uns daran teilhaben? Wie habt Ihr es denn gelöst?

Nun ja, im Grunde ist es auf https://developer.jtl-software.de/Wiki/JTLwawiExterndll_einbinden/ hervorragend erklärt. Man geht den Guide einmal durch, baut sich daraus nach Bedarf dann eine Exe-Datei und fertig. Sehr schwierig ist es nicht. Ich hatte bis zur 1.1 auch in Powershell eine fertige Lösung, die ist allerdings nicht kompatibel mit der 1.3 und 1.4. Die hätte ich teilen können. Allerdings ist das Dependency-Loading in der 1.3 und 1.4 leider nicht mehr so sauber gelöst (gab ja vorher auch schon viele kleine Bugs im Speicherhandling der DLL), sodass diese nicht mehr (in Powershell) einwandfrei geladen werden kann. Schade eigendlich.

 

[mvh]

Hallo,
wir haben uns auch zuerst JTLwawiExtern.dll angeschaut.
Jetzt benutzen wir Worker + Script, da wir über SQL Server-Agent zeitgesteuert die manuellen Workflows aufrufen.
Nur zwei SQL-Inserts (die Tabellen sind tWorkflowQueue und tWorkflowLog) werden verwendet, wobei das mit dem Log ist nicht unbedingt notwendig.
Die Lösung ist individuell und wir nutzen die Spalte cLog für unsere Zwecke aus.
Wie immer, direkte Manipulation geschieht auf eigene Gefahr.
Ihr mvh-Team

 

[forumjtlolshopag]

Hallo,
wir haben uns auch zuerst JTLwawiExtern.dll angeschaut.
Jetzt benutzen wir Worker + Script, da wir über SQL Server-Agent zeitgesteuert die manuellen Workflows aufrufen.
Nur zwei SQL-Inserts (die Tabellen sind tWorkflowQueue und tWorkflowLog) werden verwendet, wobei das mit dem Log ist nicht unbedingt notwendig.
Die Lösung ist individuell und wir nutzen die Spalte cLog für unsere Zwecke aus.
Wie immer, direkte Manipulation geschieht auf eigene Gefahr.
Ihr mvh-Team

Das ist interessant. D.h. ihr tragt einfach im Queue den jeiligen Workflow mit dem passenden "Objekt" ein und der Worker führt es durch, richtig?

 

[mvh]

Das ist interessant. D.h. ihr tragt einfach im Queue den jeiligen Workflow mit dem passenden "Objekt" ein und der Worker führt es durch, richtig?

Ja, und es funktioniert.

 

[wawi-dl]

Würdest du die Lösung zur Verfügung stellen?

 

[mvh]

SET QUOTED_IDENTIFIER ON
INSERT INTO eazybusiness.dbo.tWorkflowQueue (
    nEvent
    ,kWorkflow
    ,kObjektPk
    ,kBenutzer
    ,dStartDate
    ,nStatus
    )
SELECT nEvent  -- passendes nEvent zu kWorkflow, in dem Beispiel ist es ein Feld aus tWorkflow-Tabelle
     kWorkflow -- z.B. 23, in dem Beispiel ist es ein Feld aus tWorkflow-Tabelle
    ,1234 AS kObjektPk --z.B. kAuftrag oder kArtikel
    ,11 AS kBenutzer --Workflow Benutzer
    ,DATEADD(N, 1, GETDATE()) AS dStartDate --damit es Worker ausführt, Verzögerung für 1 Minute
    ,1 AS nStatus
FROM eazybusiness.dbo.tWorkflow twa --oder lvAuftrag, tArtikel,
--Dieser Code ist nur eine nicht notwendige zusätzliche Prüfung, 
--ob der Workflow schon gelaufen ist oder gerade in der Queue steht.
--OUTER APPLY (
--    SELECT TOP (1) kWorkflowLog AS Log_Vorhanden
--    FROM eazybusiness.dbo.tWorkflowLog wfl
--    WHERE wfl.kWorkflow IN (
--            23
--            )
--        AND wfl.kObjektPk = lvAuftrag.kBestellung
--        AND wfl.cObjectId = lvAuftrag.cBestellnr
--        AND wfl.cLog IN ( 'Der Workflow wurde erfolgreich beendet.')
--        AND kWorkflowAktion = - 1
--    ORDER BY dDatum DESC
--    ) workflow_log
--OUTER APPLY (
--    SELECT TOP (1) wfq.kWorkflowQueue AS Queue_Vorhanden
--    FROM eazybusiness.dbo.tWorkflowQueue wfq
--    WHERE wfq.kWorkflow IN (
--            23
--            )
--        AND wfq.kObjektPk = lvAuftrag.kBestellung
--        AND wfq.nStatus = 1
--    ORDER BY dStartDate DESC
--    ) workflow_queue


WHERE twa.cName='Mein Auftrag Erstellen'
--AND workflow_log.Log_Vorhanden IS NULL AND workflow_queue.Queue_Vorhanden IS NULL

Würdest du die Lösung zur Verfügung stellen?

 

[mvh]

So könnte SQL-Server-Agent Auftrag aussehen.
Besonders die Zeitpläne sind sehr nützlich.

 

[forumjtlolshopag]

Danke für die Abfrage, so ähnlich hätten wir die dann auch für uns aufgebaut. Wir nutzen für "Zeitpläne" das NiFi, dann können wir noch weitere Bedingungen abfragen, die teilweise außerhalb der DB ggf. sogar außerhalb der SQL Welt liegen.

 

[wawi-dl]

Die SQL-Anweisung hatte einen kleinen Fehler, es fehlte ein Komma vor kWorkflow bzw. nach nEvent:

SET QUOTED_IDENTIFIER ON;

INSERT INTO tWorkflowQueue (
nEvent,
kWorkflow,
kObjektPk,
kBenutzer,
dStartDate,
nStatus
)
SELECT
nEvent,
kWorkflow,
1234 AS kObjektPk,
11 AS kBenutzer,
DATEADD(N, 1, GETDATE()) AS dStartDate,
1 AS nStatus
FROM
tWorkflow
WHERE
tWorkflow.cName = 'mein Workflow-Name';

Der Workflow ist aber so nicht sofort ausführbar, richtig?
Wir hätten gerne einen Workflow direkt angestoßen, sofern das geht.

So wäre man doch immer von Worker und Laufzeit abhängig.

 

[dazligth]

Danke, dein Beitrag hat mir das Puzzleteil geliefert, dass noch fehlte.
Hier mein knappes Beispiel das einen manuellen Workflow (für Aufträge) in die Queue legt, die dann vom worker im nächsten durchlauf abgearbeitet werden können.

INSERT INTO BSSW_EU.dbo.tWorkflowQueue
    (nEvent, kWorkflow, kObjektPk, kBenutzer, dStartDate, nStatus)
VALUES
    (120, -- nEvent eintragen wie es in der tWorkflow zu WF 102 steht.
    102, -- Workflow Nummer - 102 UK B2B: ZA ändern & RE erstellen
    738804, -- Kontextbezogender Key in dem Fall kAuftrag von Auftrag xyz
    8, -- Benuzer 8 Emma, Benutzer 14 = Automation
    GETDATE(), -- Ausfühungszeit sofort
    1); -- nStatus 1 = neu, 2 = geplant

 

[ple]

Die SQL-Anweisung hatte einen kleinen Fehler, es fehlte ein Komma vor kWorkflow bzw. nach nEvent:


Der Workflow ist aber so nicht sofort ausführbar, richtig?
Wir hätten gerne einen Workflow direkt angestoßen, sofern das geht.

So wäre man doch immer von Worker und Laufzeit abhängig.

Ja das würde mich auch interessieren, wie man direkt einen worfklow auslösen könnte ohne diesen in den Queue zu schieben.
Hat das schon mal einer gemacht zufällig?