2015-02-23T06:35:49 bianca

Wie würdest du das machen, rosti?

Analytisch denken und genauso vorgehen. Bei Deinem Webservice wird eine XML-Datei gesendet und es wird eine XML-Datei empfangen. Erster Schritt: Ist die gesendete Datei fehlerhaft oder die Datei, welche empfangen wurde? Zweiter Schritt: In die Doku zum Parser schauen, ob es evnt. Möglichkeiten zum Tracen gibt. Wenn es die Doku nicht hergibt, in den Code schauen, wie die Fehlerbehandlung aussieht, ggf. ist ebendiese nicht so optimal programmiert, dann wird sie eben umgebaut. Perl hat ein eigenwilliges aber wirksames Exception-Modell, verwende es, Stichwort eval. Wenn die Datei fehlerhaft ist, wirft der Parser einen Fehler, fange den Fehler auf, und mach das so, dass Du alles, was zur Auswertung gehört, wegspeicherst (im Dateisystem, in einer DB, oder ne Mail senden), also auch die XML-Datei speichern zum Angucken.

Btw., SOAP, gesehen, gelacht, abgeheftet. Es ist schon interessant, welche Blüten sich in Sachen Webservices entwickelt haben, umständlicher gehts nicht mehr und warum das an XML gebunden ist, ist mir ein Rätsel. Die Programmierer machen sich das Leben unnötig schwer. Letztendlich wird nur eine Datei übertragen und wie diese aufgebaut ist, das ist für einen Webservice vollkommen Wurscht, das ist nur die Verpackung der Daten und dafür gibt es zig andere Möglichkeiten, die weniger störanfällig sind.

Zum Remote-DB-Management, Content-Management und Remote-Procedure-Call für meine Website/Server verwende ich seit Jahren einen eigens entwickelten Webservice, der mit SOAP allenfalls vom grundsätzlichen Prinzip her ähnlich ist. Integriert über das in meinem Framework ohnehin vorhandene Login-System (hier wird eine Session aufgebaut) wird eine Datei übertragen, woraus Client- wie serverseitig eine Datenstruktur im Hauptspeicher erzeugt wird (Serializer statt Parser). Diese Datenstruktur beeinhaltet als Hash-Referenz einen control-Block, da steht alles drin, was serverseitig, oder clientseitig zu tun ist. Für die Daten gibt es einen Datenblock, auf alle Daten ist also ein wahlfreier Zugriff gegeben. Übertragen wird die Datei einheitlich mit Request-Methode PUT, ich könnte mir auch eine eigene Request-Methode ZITRONE ausdenken (HTTP ist ein offener Standard) und hätte dazu nur zwei Zeilen CODE zu ändern. Serverseitig werden bei bestimmten Actionen ggf. weitere Packages eingehängt wegen der Übersicht. Mein Serializer ist ein austauschbarer Layer und wenn die Daten in XML verpackt sein müssen, würde das eine minimale Code-Änderung erfordern, der Layer ist austauschbar. Alles modular, beliebig erweiterbar und selbstverständlich wartungsfreundlich im Gegensatz zu SOAP. Von REST wollen wir gar nicht erst reden, da blühts genauso. Achja, nicht einnmal einen speziellen URL muss ich mir für meinen Webservice ausdenken, ich kann den auch auf der Startseite meiner Domäne einrichten, Stichwort Content-Negotiation (beliebig viele Benutzer betreffend).

Btw., ich bin nicht der Einzige mit dieser Denkweise, guck Dir mal bei Gelegenheit die NVP-API von Paypal an, es ist eine Freude, damit zu arbeiten.

Schöne Grüße.

PS: Noch ein Webservice von mir http://rolfrost.de/sunservice.html

Der Service liegt auf demselben URL wo ich ihn dokumentiert habe.
Last edited: 2015-03-17 09:21:59 +0100 (CET)