Serverzeit bei API Call (inkl. Zeitumstellung)

Fragen und Antworten
1

Hallo Zusammen,

wir haben folgende Herausforderung. Unser SaaS PIM läuft auf der Serverzeit UTC+0.
Wenn wir einen Datensatz jetzt (10:00 Uhr) in unserer Zeit verändern, wird am Datensatz als Zeitstempel im PIM 09:00 Uhr gesetzt.
Wenn ich jetzt über Synesty einen API Call absetze, mit dem Ziel mir alle Daten zurückzugeben, die innerhalb der letzten 30 Minuten (Zwischen 10:00 Uhr und 09:30 Uhr) verändert wurden, geht der Request auch mit der Zeit zwischen 10:00 und 09:30 Uhr raus. Aber da im PIM die Serverzeit um eine Stunde zurückliegt und der Zeitstempel am Datensatz 09:00 Uhr ist, bekomme ich keinen Datensatz zurück.

Also hab ich den API Call mit Hilfe von

${datecalc(current_timestamp?datetime, \"MINUTE\", -60)?string(\"yyyy-MM-dd'T'HH:mm:ss\")}\",\"${datecalc(current_timestamp?datetime, \"MINUTE\",-90)?string(\"yyyy-MM-dd'T'HH:mm:ss\")}

so verändert, dass der Call quasi eine Stunde abzieht. In diesem Fall wird an das PIM der API Call mit zwischen 09:00 Uhr und 08:30 Uhr gesendet und ich bekomme den veränderten Datensatz von 09:00 Uhr zurück. Das passt dann auch wunderbar.

Allerdings haben wir ja einmal im Jahr die Zeitumstellung und hier gibt es dann wieder ein Durcheinander. Denn wenn bei uns die Zeit um 1 Stunde nach vorne gestellt wird, also statt 10:00 Uhr haben wir jetzt bei uns 11:00 Uhr und ich schicke den API Call exakt wie oben beschrieben ab, geht der Request mit zwischen 10:00 uhr und 09:30 Uhr raus. Was dann wieder zu keinem Ergebnis führt, da die Serverzeit weiterhin UTC+0 ist und der Zeitstempel am Datensatz weiterhin 09:00 Uhr ist.

Also muss ich einmal im Jahr meinen API Call um „60 Minuten“ verändern.

${datecalc(current_timestamp?datetime, \"MINUTE\", -120)?string(\"yyyy-MM-dd'T'HH:mm:ss\")}\",\"${datecalc(current_timestamp?datetime, \"MINUTE\",-150)?string(\"yyyy-MM-dd'T'HH:mm:ss\")}

Frage, das kann man doch bestimmt eleganter lösen, oder? :slight_smile:

Viele Grüße
Ramin

2

Hallo Ramin,

Freemarker hat ein paar built-ins für die Ausgabe Datum/Zeit Angaben in UTC. Vielleicht hilft dir das:
https://freemarker.apache.org/docs/ref_builtins_date.html

image
image1045×411 20.1 KB

Zum ausprobieren: Mapper - Transformy

VG Torsten

3

Hallo Torsten,

danke für die schnelle Rückmeldung. Ich habe jetzt zwei API Endpunkte bei Akeneo, gegen die ich den Call laufen lassen. Beim Asset API Endpoint läuft es wunderbar

/api/rest/v1/asset-families/product_images/assets?search=${urlEncode("{\"updated\":[{\"operator\":\"BETWEEN\",\"value\":[\"${datecalc(.now, \"MINUTE\", -45)?datetime?iso_utc}\",\"${.now?datetime?iso_utc}\"]}]}"!)!}&limit=100&pagination_type=search_after

Beim Product Endpoint bekomme ich, warum auch immer, folgende Fehlermeldung zurück

A-2 Get-Products: HTTP Status: 422 (unknown), Inhalt Antwort: {"code":422,"message":"Property \"updated\" expects a string with the format \"Y-m-d H:i:s\" as data, \"\" given."}

Also der meckert rum, dass das Format der Uhrzeit nicht korrekt ist, was ich nicht wirklich nachvollziehen kann.

Das hier ist der ursprüngliche Call, bei dem ich den String nochmal angegeben habe.
Aber auch nicht wirklich dem entspricht, wie es laut Fehlermeldung gefordert ist.

/api/rest/v1/products?search=${urlEncode("{\"updated\":[{\"operator\":\"BETWEEN\",\"value\":[\"${datecalc(current_timestamp?datetime, \"MINUTE\", -150)?string(\"yyyy-MM-dd HH:mm:ss\")}\",\"${datecalc(current_timestamp?datetime, \"MINUTE\", -60)?string(\"yyyy-MM-dd HH:mm:ss\")}\"]}],\"completeness\":[{\"operator\":\"=\",\"value\":100,\"scope\":\"ecommerce\"}],\"onlinestore_availability\":[{\"operator\":\"=\",\"value\":true}]}"!)!}&locale=de_DE&with_attribute_options=true&scope=ecommerce&limit=100&pagination_type=search_after

Kann man bei iso_utc den String nochmal mitgeben?

Viele Grüße
Ramin

4

Hallo Ramin,

der Fehler besagt, dass ein leerer Text statt des erwarteten Datums übergibt. Ich vermute, dass das Freemarker-Skript noch Fehler enthält. Wenn du versuchst, dein Skript einfach im HTML-Writer ausgibst, läuft das auch auf Fehler.

Ich hab versucht, das Skript aus dem letzten Part deiner Mail mal aufzuräumen. Außerdem habe ich als Stringstart- bzw. ende den einfache Anführungstrich genutzt. Dann kann man sich das Escapen der doppelten Anführungsstriche sparen.

/api/rest/v1/products?search=${urlEncode('{"updated":[{"operator":"BETWEEN","value":["${datecalc(current_timestamp?datetime, "MINUTE", -150)?string("yyyy-MM-dd HH:mm:ss")}","${datecalc(current_timestamp?datetime, "MINUTE", -60)?string("yyyy-MM-dd HH:mm:ss")}"]}],"completeness":[{"operator":"=","value":100,"scope":"ecommerce"}],"onlinestore_availability":[{"operator":"=","value":true}]}')}&locale=de_DE&with_attribute_options=true&scope=ecommerce&limit=100&pagination_type=search_after

Gruß
Gustav

5

Hallo Gustav,

der letzte API Call in meiner Antwort ist der, der aktuell verwendet wird und auch problemlos funktioniert. Nur haben wir hier das Problem mit der Serveruhrzeit. current_timestamp gibt nämlich UTC +1 raus, ich brauche aber UTC+0, also ?datetime?iso_utc
Sozusagen der erste API Call, der aber von Akeneo nicht angenommen wird

Also der hier funktioniert, aber gibt mir die falsche Uhrzeit zurück
/api/rest/v1/products?search=${urlEncode("{\"updated\":[{\"operator\":\"BETWEEN\",\"value\":[\"${datecalc(current_timestamp?datetime, \"MINUTE\", -150)?string(\"yyyy-MM-dd HH:mm:ss\")}\",\"${datecalc(current_timestamp?datetime, \"MINUTE\", -60)?string(\"yyyy-MM-dd HH:mm:ss\")}\"]}],\"completeness\":[{\"operator\":\"=\",\"value\":100,\"scope\":\"ecommerce\"}],\"onlinestore_availability\":[{\"operator\":\"=\",\"value\":true}]}"!)!}&locale=de_DE&with_attribute_options=true&scope=ecommerce&limit=100&pagination_type=search_after

Und der hier soll funktionieren, weil ich da mit iso_utc arbeiten kann
/api/rest/v1/asset-families/product_images/assets?search=${urlEncode("{\"updated\":[{\"operator\":\"BETWEEN\",\"value\":[\"${datecalc(.now, \"MINUTE\", -45)?datetime?iso_utc}\",\"${.now?datetime?iso_utc}\"]}]}"!)!}&limit=100&pagination_type=search_after

Viele Grüße
Ramin

6

Und danke mit dem Hinweis zu dem einfachen Anführungsstrich!

Viele Grüße
Ramin

7

Hallo @ramin-ww,

ich kann es leider nicht wirklich nachvollziehen, was genau das Problem ist. Der Fehler der API sagt, dass statt dem Datum im Format „Y-m-d H:i:s“ ein leerer String geliefert wurde.

Was ich mir noch denken kann, ist dass das Datum im ISO_UTC-Format nicht von Akeneo akzeptiert wird. Das gibt ja einen Zeitstempel wie „2016-02-04T23:00:00Z“ zurück. Vielleicht gibt es ein Problem mit dem „T“ bzw. „Z“ und der Zeitstempel müsste „2016-02-04 23:00:00“ sein.

Ich würde empfehlen, die URLs vielleicht vorab in HTML-Writerschritten zusammenzubauen, um das ganze ein bisschen übersichtlicher zu gestalten. Dann kannst du auch in Variablen vorab die Zeitstempel ausrechnen und dann in einer finalen Zeile zusammenbauen. Hier ein kleiner Mock-up.

<#assign ts_start = ...>
<#assign ts_end = ...>
<#assign search_query = ...>
/api/rest/v1/products?search=${urlEncode(search_query)}&locale=de_DE&with_attribute_options=true&scope=ecommerce&limit=100&pagination_type=search_after

So würde ich zumindest vorgehen, wenn ich da im Detail debuggen müsste. Ansonten bin ich ein großer Fan von RequestBin — A modern request bin to collect, inspect and debug HTTP requests and webhooks - Pipedream, um meine Anfragen inkl. Header im Detail zu prüfen.

Gruß
Gustav

8

Hallo @gustavfriedeheim,

danke für die Tipps! Werde ich mal testen.
Komischerweise tritt der Fehler auch nur beim Products API Endpunkt auf, beim Asset API Endpunkt läuft es sauber durch.

Viele Grüße
Ramin