Neu Möglichkeit json mit DotLiquid zu parsen?

[sjk]

Moin zusammen,

Wir würden gerne verschiedene APIs nutzen, um uns den Arbeitsalltag zu erleichtern. Dazu gehören z.B. die API unserer Hauptspedition, Export von Produktdaten in unser internes Wiki etc. Das funktioniert alles theoretisch auch super über die Webrequests der Workflows. Das Problem ist dann aber, die responses der Webrequests zu verarbeiten. Diese kämen bei den APIs, die wir im Auge haben immer als json zurück und wir müssten daraus z.B. die Angebots-ID, die wiki-Seiten-ID usw extrahieren können. Ohne diese Informationen kann die Wawi z.B. nur wiki-Seiten erstellen, nicht aber später updaten; Transporte buchen, aber nicht ein Angebot einholen und dann dieses Angebot buchen. Im Forum habe ich einige alte Beiträge gefunden, dass die Webrequests fast nicht zu gebrauchen sind wenn man die Antworten irgendwie verarbeiten muss.

Hat jemand einen Workaround, um gezielt Daten aus json-responses zu extrahieren? Am schönsten wäre natürlich eine Lösung wie hier beschrieben.

 

[sjk]

Verarbeitet hier wirklich niemand webrequest responses in der Wawi?

 

[sjk]

Ich hol das nochmal hoch weil es uns sehr viel Mehrwert bringen würde!

 

[301Moved]

Je nachdem, wie komplex das Antwort-json ist, könntest du es in ein Feld schreiben lassen und dieses Feld wiederum in Folge per Workflow verarbeiten lassen.
Hier war bspw. mal ein Ansatz etwas zu filtern: https://forum.jtl-software.de/threads/dotliquid-string-extrahieren.109952/
Wenn komplexer, wäre es auch möglich das json über Workflow in JQ ausführen zu lassen und das Ergebnis als CSV zu schreiben und per Ameise wieder reinzuholen.
Oder auf die REST API warten: https://forum.jtl-software.de/threads/rest-api-fuer-jtl-wawi-fuer-artikelanlage.144580/post-851029

 

[sjk]

Hi, ja, den den zuerst verlinkten Thread kenne ich. Dafür wäre das Antwort-json aber leider oft zu komplex bzw. so verschachtelt, dass der identifier an sich nicht mehr eindeutig ist. JQ ist ein wirklich guter Tipp, danke! Mal sehen, ob ich es damit umgesetzt bekomme oder ob ich doch noch weiter auf die REST API warten muss 🙂

 

[Powalowski]

Hi, ja, den den zuerst verlinkten Thread kenne ich. Dafür wäre das Antwort-json aber leider oft zu komplex bzw. so verschachtelt, dass der identifier an sich nicht mehr eindeutig ist. JQ ist ein wirklich guter Tipp, danke! Mal sehen, ob ich es damit umgesetzt bekomme oder ob ich doch noch weiter auf die REST API warten muss 🙂

die REST API ist leider kaum zu gebrauchen. Deckt eigentlich kaum was ab.
Wie hattest du das mit dem Parsen gelöst? Wir haben bisher immer den Inhalt per RegEx rausgeholt aber das ist bestenfalls eine Bastellösung 😀

 

[css-umsetzung]

Das geht schon, aber man muss den umständlichen über MS SQL gehen, dann kannst du Daten die du per Request abfragst auch aus komplexen json Strukturen extrahieren.

 

[Powalowski]

Das geht schon, aber man muss den umständlichen über MS SQL gehen, dann kannst du Daten die du per Request abfragst auch aus komplexen json Strukturen extrahieren.

An sich eine lustige Lösung. Mich stört eigentlich im Wesentlichen, dass man kaum Werte setzen kann und größere Veränderungen an z.B. Aufträgen nicht einfach über SQL gemacht werden sollten. JSON mit SQL-Queries zu parsen ist ja ein super witziger Workaround aber klingt ja wohl erstmal praktikabel und ohne externe Zusatztools.

https://n8n.io/ - Alleskleber für Schnittstellen, Requests und Daten aller Art. Man könnte sicher in vielen Fällen damit einen "Umweg" bauen und sich entsprechend die Daten sauber vorbereiten.

 

[css-umsetzung]

Ich sage es mal so, es stresst den SQL Server ja nicht wirklich und am Ende wird es ja auch in einem Workflow laufen und niemand muss sich beschweren das es lange dauern könnte, was es nicht ja auch nicht tut.

Ich habe hier mal ein einfaches Beispiel aus einem Projekt:

{% capture json -%}
{
   "identificationprocess":{
      "status":"OK",
      "companyid":"musterfirma",
      "filename":"musterfile.zip",
      "processtype":"VIDEO"
   },
   "contactdata":{
      "mobilephone":"+497xxxxxxxxxx",
      "email":"max@musterdomain.de"
   },
   "userdata":{
      "firstname":{
         "status":"MATCH",
         "value":"Max"
      },
      "address":{
         "zipcode":{
            "status":"MATCH",
            "value":"10711"
         },
         "country":{
            "status":"MATCH",
            "value":"DE"
         },
         "city":{
            "status":"MATCH",
            "value":"BERLIN"
         },
         "street":{
            "status":"MATCH",
            "value":"Musterstraße 10"
         }
      },
      "birthplace":{
         "status":"MATCH",
         "value":"Berlin"
      },
      "nationality":{
         "status":"MATCH",
         "value":"DE"
      },
      "gender":{
         "status":"MATCH",
         "value":"MALE"
      },
      "lastname":{
         "status":"MATCH",
         "value":"Mustermann"
      }
   },
   "identificationdocument":{
      
   },
   "attachments":{
      "pdf":"muster.pdf",
      "xml":"muster.xml"
   }
}
{% endcapture -%}
\
{% assign key = 'identificationprocess.status' -%}
{% capture query -%}
    SELECT JSON_VALUE('{{ json |Replace:"result":"status" }}','$.{{ key }}') as out;
{% endcapture -%}
Status:                     {{ query |DirectQueryScalar }}
\
{% assign key = 'userdata.address.street.value' -%}
{% capture query -%}
    SELECT JSON_VALUE('{{ json |Replace:"result":"status" }}','$.{{ key }}') as out;
{% endcapture -%}
userdata.address.street:    {{ query |DirectQueryScalar }}
\
{% assign key = 'userdata.address.zipcode.value' -%}
{% capture query -%}
    SELECT JSON_VALUE('{{ json |Replace:"result":"status" }}','$.{{ key }}') as out;
{% endcapture -%}
userdata.address.zipcode:   {{ query |DirectQueryScalar }}
\
{% assign key = 'contactdata.mobilephone' -%}
{% capture query -%}
    SELECT JSON_VALUE('{{ json |Replace:"result":"status" }}','$.{{ key }}') as out;
{% endcapture -%}
\
{% assign key = 'contactdata.email' -%}
{% capture query -%}
    SELECT JSON_VALUE('{{ json |Replace:"result":"status" }}','$.{{ key }}') as out;
{% endcapture -%}
contactdata.email:          {{ query |DirectQueryScalar }}
\
{% assign key = 'userdata.address.city.value' -%}
{% capture query -%}
    SELECT JSON_VALUE('{{ json |Replace:"result":"status" }}','$.{{ key }}') as out;
{% endcapture -%}
userdata.address.city:      {{ query |DirectQueryScalar }}
\
{% assign key = 'attachments.pdf' -%}
{% capture query -%}
    SELECT JSON_VALUE('{{ json |Replace:"result":"status" }}','$.{{ key }}') as out;
{% endcapture -%}
attachments.pdf:            {{ query |DirectQueryScalar }}

 

[Powalowski]

Ich habe hier mal ein einfaches Beispiel aus einem Projekt:

Krass, es steht ja noch nicht mal in der DB. Manchmal, da sieht man den Wald vor lauter Bäumen nicht. Unglaublich.

 

[css-umsetzung]

Naja das wäre ja übel wenn ich es erst in der Datenbank speichern müsste um dann damit arbeiten zu können 😀
Ich hab da damals echt lange dran getüftelt bis ich den (in der JTL Welt) besten Weg gefunden habe.

 

[Powalowski]

Naja das wäre ja übel wenn ich es erst in der Datenbank speichern müsste um dann damit arbeiten zu können 😀
Ich hab da damals echt lange dran getüftelt bis ich den (in der JTL Welt) besten Weg gefunden habe.

Das ist wirklich ein schöner Weg. Bestätigt und Zertifiziert 👍🏻
Gerade mal in der REST Doku gestöbert, da sind ja doch einige nützliche Punkte dazugekommen - vielleicht starten wir da mal mit der Nutzung.

 

[mh1]

Das geht schon, aber man muss den umständlichen über MS SQL gehen, dann kannst du Daten die du per Request abfragst auch aus komplexen json Strukturen extrahieren.

An sich eine lustige Lösung. Mich stört eigentlich im Wesentlichen, dass man kaum Werte setzen kann und größere Veränderungen an z.B. Aufträgen nicht einfach über SQL gemacht werden sollten. JSON mit SQL-Queries zu parsen ist ja ein super witziger Workaround aber klingt ja wohl erstmal praktikabel und ohne externe Zusatztools.

Ich bin ja ein Freund davon, Dinge vom SQL-Server machen zu lassen.

Meiner Meinung nach ist Liquid für komplexere Anforderungen ungeeignet. Damit will ich nicht sagen, dass Liquid schlecht wäre, sondern: Liquid ist was es ist: eine Template Sprache. Dafür da, um in dynamischen Berichten Werte aus der Datenbank anzuzeigen. Es gibt zwar ein paar einfache Filter und auch bestimmte Kontrollstrukturen, aber auch viele Stolpersteine.

 

[css-umsetzung]

Ich bin ja ein Freund davon, Dinge vom SQL-Server machen zu lassen.

Ich auch nicht, aber es ist für mich, der derzeit einzige Weg um Daten sicher auszulesen.