API (nicht REST) sagt "Wrong Hash"

OK, mittlerweile habe ich per Ticket erfahren:

• Die alte API gemäß der oben verlinkten Doku wurde von Xentral deaktiviert (oder so verändert, dass die Authentifizierung per Hash wie in der Doku beschrieben nicht mehr funktioniert). Sie soll nicht mehr verwendet werden (deprecated).
• Stattdessen soll man die neue REST-API verwenden.
• Der neuen REST-API fehlen aber noch viele Funktionen, die zur Zeit nur die alte API bietet.
• Unter dem neuen REST-API endpoint soll es eine Möglichkeit geben, die alte API zu nutzen. Allerdings ist diese Option nicht ausreichend dokumentiert. “In diesem Fall erwartet die API immer einen POST-Request und die Nutzdaten müssen im Request-Body mitgeschickt werden.” Welche Nutzerdaten in welcher Form übergeben werden müssen steht weder in der alten Doku noch in der Doku der REST-API, und konnte ich auch nicht erraten oder dem Support nicht entlocken.

Hi Lars,

danke für deine Antwort! Jetzt habe ich es genau so gemacht, wie du gesagt hast:

• API-Account existiert mit username und password
• Recht standard_exportvorlageget ist angehakt
• Export-Vorlage mit ID 2 existiert (wie in deinem Screenshot)

Aufruf:

curl --digest -su "$XENTRAL_API_USER_SCRIPT_USER:$XENTRAL_API_USER_SCRIPT_PASSWORD" \
     -H 'Content-Type: application/xml' \
     "https://schlievet.xentral.biz/api/index.php?path=/ExportVorlageGet&id=2"

Ergebnis:

EDIT: Funktioniert jetzt. Nach index.php kommt ein “?” und danach “&” Zeichen.

Anderer Aufruf:

curl --digest -su "$XENTRAL_API_USER_SCRIPT_USER:$XENTRAL_API_USER_SCRIPT_PASSWORD" \
     "https://schlievet.xentral.biz/api/v1/belege/auftraege/339?include=positionen"

In der verlinkten Dokumentation steht keine weitere Hilfe zu “Bad Request”. Haben wir vielleicht unterschiedliche Xentral Versionen (ich: 21.1)? Oder hast du dem API user noch zusätzliche Rechte geben müssen?

Was mich noch wundert, warum muss Content-Type xml sein? Die Antwort ist ja CSV und Content (Payload) gibt’s ja gar nicht, weil es ja nur ein GET ist…

Oh, das hab ich auch übersehen. Ja mit dem “&” geht’s, danke!

Ohne dem Content-Type Header geht’s, allerdings kommt immer XML raus, also leider kein CSV, egal was für einen Accept Header man übergibt.

Leider auch noch ungültiges XML, das u.a. solche Zeilen enthält:

<
>
</
>

xmllint kann es nicht parsen. Aber mit einem awk oder sed script kann man es zur Not zu CSV umwandeln.

Danke!

Danke, das wäre eigentlich die bessere Lösung. Aber ich hatte da andere Probleme, z.B. konnte man aus irgendeinem Grund nicht nach dem Feld “useredittimestamp” sortieren. Fehler: “Reports can only use SELECT statements!” Nach anderen Feldern kann man aber sortieren... und ich wollte sortieren, damit ich nur die “recently edited” Adressen habe (mit LIMIT clause, die man aber auch nicht testen kann, weil dann wieder ein anderer Fehler kommt...).

Ansonsten hat mich bei den SQL Berichten noch die uralte MySQL Version gestört, die kein REGEX_REPLACE konnte (zum Vereinheitlichen von Telefonnummern) und, dass man die zu exportierenden Felder immer doppelt pflegen muss (im SQL-Eingabefeld und in der Tabelle darunter).

Aber CSV Export wär schonmal ein Bonus und dann muss ich halt post-processing machen...

useredittimestamp und “Reports can only use SELECT statements!” habe ich hier auch. Und wieder keine Lösung...hach

Zur Fehlermeldung bei den Reports:

Das Report Modul von Xentral verbietet das Vorkommen folgender SQL Keywords im SQL Statement.

INTO, INSERT, UPDATE, DELETE, ALTER, SHOW, USE, TRUNCATE, LOAD, CREATE, DROP, RENAME

Damit soll sichergestellt werden, dass nur SELECT Abfragen erlaubt sind, und die DB nicht von Berichten geändert werden kann.
Bestehen Spaltennamen zufällig aus einen dieser Keywords, wie eben USEredittimestamp das verbotene Keyword USE, so ist die Query nicht erlaubt und es erscheint die Fehlermeldung
Reports can only use SELECT statements!.

Abhilfe schafft hier das Escapen der betroffenen Namen mit `` .

ORDER BY `useredittimestamp` funktioniert.
ORDER BY useredittimestamp funktioniert nicht.