Neues Thema starten

php curl

 Hallo Team,

ich habe hier eine Struktur per API zu übermitteln und komme nicht dahinter, wie ich das in einen UrlDownload-Step bekomme. Als Basis habe ich ein php-Script, in welchem zuerst eine Variable erzeugt wird, die die zu übermittelnden Daten in einer XML-Struktur beinhaltet. Dann wird ein Array erzeugt, das diverse Felder beinhaltet und auch die xml-Variable referenziert und dann Base64 encoded. Das Ganze sieht so aus:


// Prepare XML data
$xml_data = '<?xml version="1.0" encoding="UTF-8"?>
<import version="1">
  <order id="123" date="2015-02-01T12:34:56">
    ...
  </order>
</import>';

// Setup
$url = 'https://.../api/import/';
$post_data = array(
    'token'     => 'c0JmAKCXig0MzkDE', // <- place your individual token here!
    'version'   => '1',
    'type'      => 'xml',
    'load'      => base64_encode($xml_data),
);

// Start cURL session
$curl = curl_init($url);
curl_setopt($curl, CURLOPT_POST, true);
curl_setopt($curl, CURLOPT_POSTFIELDS, $post_data);
curl_setopt($curl, CURLINFO_HEADER_OUT, true);
curl_setopt($curl, CURLOPT_RETURNTRANSFER, true);
curl_setopt($curl, CURLOPT_BINARYTRANSFER, true);

$post_result = curl_exec($curl);

curl_close($curl);


Das System erfordert es, daß alle vier Parameter (token, version, type und load) gefüllt/übermittelt werden. Wie kann ich das umsetzen?


Danke und Gruß,

Micha


Danke die Logs sind auch hilfreich. Requestbin ist halt eine schicke Möglichkeit einen Request sichtbar zu machen, was wirklich auf der Gegenseite ankommt.


Was schon auffällt:


POSTMAN: schickt multipart, aber kein Charset.


Content-Type: multipart/form-data; boundary=.....


Synesty schickt charset=UTF-8

Content-Type: multipart/form-data; boundary=R-6UPJjM96MytJ5V0txdYqftyyCDAxVristpnTCc; charset=UTF-8


(das boundary-Zeug kommt automatisch dazu...)


Hast du bei Synesty schonmal versucht das charset wegzulassen? 


also nur multipart/form-data; bei bodyContentType?

Gerade probiert, derselbe Mißerfolg

Hast du davon auch noch mal einen Log?

Ja, s. Anhang

log

Danke. Wir schauen uns das im Detail an. 

Hier nur kurz: 


Du kannst gern auch nochmal im Texteditor beide Requests nebeneinander legen. ISO-8859-1 wird von uns nirgends mitgeschickt. Uns ist schleierhaft, warum die API den Fehler {code":106,"message":"Encoding not supported","data":{"encoding":"ISO-8859-1"}}  wirft. 


Auffällig ist, dass POSTMan einige HTTP-Header weglässt wie z.B. Accept-Encoding (was du uns leer übermittelt wird). Vielleicht stört sich die API daran. 


Evtl. kannst du mal bei den requestHeaders folgendes Accept-Encoding=application/json; charset=utf-8 mitgeben.
(Zumindest scheint deren API mit Content-Type: application/json; charset=utf-8 zu antworten)


1. Hast du eine Doku der API, wo das grob steht, was die alles im Request erwarten?

2. Hast du zufällig auch ein log von der PostMan Response?

3. Kannst du bei Postman mal versuchen "Accept-Encoding:" (also leer) mitzugeben und schauen, ob der Fehler kommt? Evtl. stört sich die API an irgendeinem header, den wir zusätzlich mitschicken wie z.B. User-Agent.



Erstmal danke für eure Hilfe! Leider funzt es nicht. Ich habe in PM jetzt einieg parameter ausgeschaltet, und es geht trotzdem:


image



Dann habe ich ein leeres Accept-Ecoding in PM übergeben, geht auch:

image



Dann hab ich auch mal den User-Agent mit eurem überschrieben und auch das xml an einer Stelle geändert, um zu überprüfen, daß er auch eine neue order anlegt und ich hier keinem Irrtum aufsitze - auch das klappt problemlos:

image


Auch Accept-Encoding=application/json; charset=utf-8 klappt:

image

Zu Deiner Frage nach der PM Response: Ich weiß nicht genau was Du meinst, das ist doch nur die Meldung daß die Order aufgebaut wurde. Ich habe mir den letzten Call aber in der PM-Konsole angesehen und alles rauskopiert und angehängt


Zur Doku: Zu den Parametern habe ich da nichts weiter gefunden, hier ist der Link:


https://halbmond-orders.de/help/api/import


txt
(3.77 KB)

Dank dir. Das ist wirklich seltsam. 

Wir versuchen dem auf die Spur zu kommen. 


Kannst du bitte nochmal den Requestbin-Ansatz probieren:


1. gehe auf http://requestbin.net/ und erstelle ein Bin (entferne die checkbox). Das ist wichtig, damit du uns dann die URL schicken kannst, damit wir das untersuchen können. Gern per Ticket. 



2. Dadurch kommst du auf eine Seite die dir eine URL zeigt.

An diese URL schickst du deinen Request. Den Browser lässt du auf dieser Seite geöffnet. 

a) Request per POSTMan

b) und per Synesty (dazu diese URL bei Host eintragen)

3. Im Browser klickst du dann mal Neu Laden, und dadurch solltest du dann die Requests sehen, die per PostMan und Synesty geschickt wurden.


4. Nach dem du das gemacht hast schickst du uns per Ticket die URL die URL in deinem Browser 


Dadurch können wir dann auch sehen, was du dort hingeschickt hast.


Vorteil davon ist, dass wir durch Requestbin eine verlässliche Source-of-Truth, und sehen was auf der Gegenseite ankommt. Die ganzen Logfiles sind zwar auch ok, aber die zeigen eben nicht die Gegenseite sondern nur aus Perpektive der sendenden Partei.  



Hallo Micha, 


ich habe gerade nochmal den Postman Log mit dem HTTP Log von uns verglichen.  Mir ist noch aufgefallen, dass PM den Parameter offenbar noch die Leerzeichen durch + ersetzt ( URL encoded). Im HTTP Log von uns sind die Leerzeichen vorhanden, da es nicht automatisch url encoded wird. 


PM Log :


Flow HTTP Log:


Kannst du eventuell nochmal versuchen um den aktuellen "load" Wert noch die Template Funktion urlEncode zu packen. Das sollte dann in etwa so aussehen:


${urlEncode(encodeBase64(xmlData, "UTF-8"))}




DAS war's! Endlich klappt es. Ich hatte schon mit dem Entwickler der API gesprochen und einiges ausprobiert, nichts hatte geholfen. DANKE

Danke für die Rückmeldung. Vielleicht wars das von Anfang an.... Wir schauen uns auch noch mal an, dass wir auch bodyContentType=application/x-www-form-urlencoded mit Key-Value Paaren unterstützen und dass diese dann automatisch URLEncoded werden. Müssen nochmal in die Spec. schauen. 



Super! Ja, ich glaub auch, daß das von Anfang an das Problem war

Anmelden um einen Kommentar zu veröffentlichen