Neu API Integration via Workflow

[ChrisKokuvin]

Hallo zusammen,
eigentlich habe ich eine in meinen Augen einfache Herausforderung, nur in der WAWI scheint sie mir nicht so einfach 🤔.

Ich möchte im Rahmen der Auftragsverarbeitung via Workflow Daten aus externen System lesen und die Felder des Auftrages in der WAWI damit befüllen.
Soweit so gut: API Call -> Response -> Daten auslesen -> Daten schreiben. Eigentlich einfach.
Nur kann ich partout nicht erkennen wie ich nach einem API Call die Response auch vernünftig verarbeiten kann.

Wie löst Ihr das?

Ich habe mir folgende Optionen angeschaut:

A) API Call (Web Request) Response innerhalb JTL WAWI parsen und Wert schreiben -> geht nicht
B) API Callback vom anderen System geht nicht, da JTL API nicht verfügbar.
C) Datei mit Response schreiben, Script Aufrufen dass das parsing vornimmt und in eine andere Datei schreibt, um es direkt wieder einzulesen. Geht nicht -> Workflows können Dateien schreiben, aber nicht lesen. WHY?
D) Wie C) nur dass das Einlesen via Ameise erfolgen soll. Das macht imho keinen Sinn, da wir hier einen transaktionalen Kontext haben der an einem Objekt innerhalb eines Prozesses arbeitet. Ameise ist ein Massenimport-Tool ohne den Transaktionskontext.

Hat JTL WAWI hier ein funktionales Gap bei den Integrationsmöglichkeiten oder habe ich den goldenen Weg noch nicht finden können?
Ich bin für jeden Tipp und Ansatz dankbar.

Grüße!
Christian

PS:
Ich habe zwar Themen entdeckt, die nah heranreichen, aber Sie haben mich nicht wirklich weiter gebracht.
-> https://forum.jtl-software.de/threads/moeglichkeit-json-mit-dotliquid-zu-parsen.180394/
-> https://forum.jtl-software.de/threads/dotliquid-string-extrahieren.109952/

 

[no80]

Was sind es für Daten.
Was spricht gegen die Ameise.
Die macht nix anderes wie du in der wawi.

 

[wawi-dl]

Wir haben ein ähnliches Thema, der Ansatz die RestAPI zu verwenden ist schon richtig und die Ameise wäre für uns auch keine Lösung.

Die Ameise ist langsam und auch nicht zwingend updatesicher.

Per RestAPI könnte man auf JTL interne Prozesse zugreifen und sind eher updatesicher.

 

[no80]

Die Ameise ist eine „kleine“ Wawi.
Warum sollte die nicht update sicher sein.

wenn die RestApi stable ist , ist die zu bevorzugen.

 

[wawi-dl]

Nein die Ameise ist nicht updatesicher ... hier können sich Feldernamen ändern.

 

[css-umsetzung]

A) API Call (Web Request) Response innerhalb JTL WAWI parsen und Wert schreiben -> geht nicht

warum nicht?
habe ich hier mit einem Shop Besitzer gemacht: https://forum.jtl-software.de/threads/web-request-ueber-alle-artikel-im-auftrag.159331/

Aber dazu müsste man deine genaue Anforderung kennen, dann könnte man dir vermutlich eher sagen ob das was du machen möchtest möglich ist.

 

[no80]

Nein die Ameise ist nicht updatesicher ... hier können sich Feldernamen ändern.

in der Api genauso.

 

[wawi-dl]

in der Api genauso.

Kann ich nicht unterschreiben, lange nicht so wie in der Ameise, bei der man sogar die Felder selbst benennen kann.
Wir sprechen aus Erfahrung und können sagen, wenn RestAPI verfügbar, dann ist diese zu bevorzugen, zumal man hier auch ein besseres übersichtliches Changelog hat.

 

[no80]

hatte beim Import mit der Ameise bis jetzt keine Probleme gehabt.
Aber wie gesagt, mit der Api ist man auch flexibler.

 

[ChrisKokuvin]

Vielen Dank für die zahlreichen Antworten. Scheint ja eine hitzige Diskussion zu sein.

Ich bin der Meinung, dass die Ameise (zumindest in meinem beschrieben Fall) maximal ein unsauberer Workaround ist.
Warum? Stichwort: Transaktionaler Kontext.
Die Ameise hat meinem Verständnis nach einen komplett unabhängigen transaktionalen Kontext. Sie ist ein Massenimport-Tool.

Da ich Rahmen eines Ereignis-getriggerten Workflows (zu einem Auftrag) Daten zu genau diesem Ereignis verarbeiten will, ist die Ameise für mich ein umständlicher und unsauberer Workaround. Mein transaktionaler Kontext endet mit Beendigung des getriggerten Workflows.
Angenommen ich setze im Workflow einen Web Request ab. Ich schreibe das Ergebnis in eine Datei. Ich rufe die Ameise evtl. via CMD zum Import auf. Erstes Problem: Ich habe bei der Ameise keine Möglichkeit zur Interpretation von JSON Daten gefunden. Also muss ich noch ein Skript dazwischenschieben, dass eine Umwandlung in z.B. CSV vornimmt.
Ich benötige nun einen Callback/eine Rückmeldung von der Ameise. OK, ein Skript Call kann auf den Prozess warten, aber war der Import erfolgreich? Nur dann macht es Sinn den nächsten Schritt des Workflows aufzurufen.
Mal abgesehen von diesem theoretischen Ablauf - Was für ein Overkill für eine solch simple Aufgabe ("Response eines ausgehendes API-Calls verarbeiten") 😵

Eine API oder integrierte Parsing Funktionen für Standardformate, wie XML oder JSON wären genau richtig. Da es die noch nicht zu geben scheint, dachte ich, Ihr kennt eventuell bessere Alternativen zur Ameise.

Wo ich bei der Antwort von @css-umsetzung angekommen bin - vielen Dank.
Was ich tun möchte ist simpel. Die fachlichen Details sind zur Umsetzung weniger relevant.
Im Rahmen eines Workflows rufe ich via Web Request, die API eines anderen Systems auf. Ich erhalte eine saubere JSON-Response zurück. Aus dieser Response möchte Felder lesen/parsen und in Felder des WAWI-Objektes (in meinem Fall der auslösende Auftrag) schreiben. Alles soll im Kontext meines Ereignisses zum Auftrags-Objekt passieren.
Ich bin kein dotliquid Profi, aber ich konnte noch keine Möglichkeiten zum sauberen JSON Parsing entdecken.

Herzliche Grüße!
Christian

 

[css-umsetzung]

Theoretisch könntest du dein JSON über MS SQL parsen lassen

Ich hab dir mal hier mal ein Beispiel herausgesucht, klar je nach Struktur kann auch das recht aufwendig werden, aber ein MS SQL Profi (ich mag MS SQL nicht) würde das bestimmt sauber hinbekommen:

DECLARE @JSONData AS NVARCHAR(4000)
SET @JSONData = N'{
        "FirstName":"Jignesh",
        "LastName":"Trivedi",
        "Code":"CCEEDD",
        "Addresses":[
            { "Address":"Test 0", "City":"Gandhinagar", "State":"Gujarat"},
            { "Address":"Test 1", "City":"Gandhinagar", "State":"Gujarat"}
        ]
    }'


SELECT * FROM OPENJSON(@JSONData)