![]() |
SOAP Client und verschachtelte Namespaces
Hallo zusammen,
ich beschäftige mich gerade mit einem SOAP Client. Ich habe von dem Webservice Anbieter eine WSDL-Datei bekommen, die ich mit dem WSDL-Importer importiert habe. Es will mir aber nicht gelingen vernünftig mit dem Server zu kommunizieren, da der Namespace beim erzeugen der Klassen richtig gesetzt wird. Ich habe es sowohl mit Delphi 2007 als auch mit XE2 probiert, wobei letzters schon besser funktioniert... Hier mal ein Ausschnitt, wie die SOAP-Message aussehen soll:
Delphi-Quellcode:
Wenn ich das nun mit der importierten WSDL-Datei erstelle kommt bei Delphi XE2 folgendes raus:
<soapenv:Header>
<cis:Authentification> <cis:user>maxmuster</cis:user> <cis:signature>MusterPr00fi1971</cis:signature> <cis:type>0</cis:type> </cis:Authentification> <de:DeveloperAuthentification> <DEVID>musterdev</DEVID> <APPID>musterapp</APPID> <CERTID>mustercert</CERTID> </de:DeveloperAuthentification> </soapenv:Header> <soapenv:Body> <de:CreateRequest> <cis:Version> <cis:majorRelease>1</cis:majorRelease> <cis:minorRelease>0</cis:minorRelease> </cis:Version>
Delphi-Quellcode:
Hier ist definitiv das xmlns="" zuviel und die Erweiterung cis: und de: zuwenig. Der SOAP-Server nimmt mit der Delphi-Variante die Daten nicht an, die anderen schon...
<SOAP-ENV:Header>
<NS1:AuthentificationType xmlns:NS1="http://xxx.de/webservice/cisbase"> <user xmlns="http://xxx.de/webservice/cisbase">maxmuster</user> <signature xmlns="http://xxx.de/webservice/cisbase">MusterPr00fi1971</signature> <type xmlns="http://xxx.de/webservice/cisbase">0</type> </NS1:AuthentificationType> <NS2:DeveloperAuthentification xmlns:NS2="http://de.ws.xxxx"> <DEVID>musterdev</DEVID> <APPID>musterapp</APPID> <CERTID>mustercert</CERTID> </NS2:DeveloperAuthentification> </SOAP-ENV:Header> <SOAP-ENV:Body> <CreateRequest xmlns="http://de.ws.xxxx"> <Version xmlns="http://xxx.de/webservice/cisbase"> <majorRelease>1</majorRelease> <minorRelease>0</minorRelease> </Version> Hat hier schoneimal jemand sowas umgesetzt und kann mir sagen was ich falsch mache? Ich könnte zwar in dem HTTPRIO1.BeforeExecute alles mit StringReplace ersetzen, aber das kann ja nicht Sinn der Sache sein, oder? Für Eure Hilfe bedanke ich mich im voraus. VG Andreas |
AW: SOAP Client und verschachtelte Namespaces
Der Delphi Code sieht nicht falsch aus - eine Namespacedefinition dieser Art sollte der Server eigentlich verstehen (siehe auch Wikipedia
![]()
Code:
Ob die Namespace-Prefixe vom Client dann m oder anders genannt werden ist irrelevant, auch die von Delphi gewählten NS1, NS2 usw. sind daher Soap-konform.
<?xml version="1.0"?>
<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope"> <s:Body> <m:TitleInDatabase xmlns:m="http://www.lecture-db.de/soap"> DOM, SAX und SOAP </m:TitleInDatabase> </s:Body> </s:Envelope> Leider sind aber längst nicht alle Web Services so Soap-konform wie es möglich wäre. Ich würde den Anbieter fragen, mit welchen Soap Toolkits (c.B. .Net WCF oder Java JAX-WS) bisher erfolgreich gearbeitet wurde. Einen Test mit SoapUI würde ich auch versuchen, das ist eine anerkannte Test-Referenz. Aber wenn der Anbieter sagt, dass es nur so und nicht anders aussehen darf, hilft nur noch zusammenstricken der XML Payload mit XML Bibliotheken. p.s. als Alternative zum Delphi WSDl Importer gibt es noch das Free Pascal Web Service Toolkit, das auch Delphi unterstützt und sowohl einen Wizard als auch ein WSDL Kommandozeilentool bietet. |
AW: SOAP Client und verschachtelte Namespaces
Hallo,
das Problem habe ich leider auch immer (das xmlns="" ist zuviel und der Prefix fehlt). Ich nutze aber die Variante stringreplace, der Webservice ist einfach zu groß, um ihn manuell aufzubauen. Zitat:
Zitat:
Aber der WSDL-Importer kann ja nicht das Problem sein, es liegt ja mehr an der Generierung der xml-Nachricht. Herumspielen an diversen Optionen hat bei mir noch nicht zum Erfolg geführt. Hast Du einen Tipp, mit welcher Option man auf die Generierung der xml-Nachricht hinsichtlich der Namespaces einwirken kann? Gruß Frank |
AW: SOAP Client und verschachtelte Namespaces
Zitat:
Ich werde mir mal das Toolkit heute/morgen anschauen... GRüße |
AW: SOAP Client und verschachtelte Namespaces
Hallo,
danke für die Rückmeldungen. Schön zu sehen, dass ich nicht alleine mit diesen Tücken kämpfe... Ich werde mir mal das WebServiceToolkit anschauen und mal sehen wie weit man da "konform" wird... Parallel werde ich mal versuchen bei dem Anbieter etwas in Erfahrung zu bringen... Viele Grüße in die Runde. Andreas |
AW: SOAP Client und verschachtelte Namespaces
Oh nein, Du bist wirklich nicht allein. Ich habe nun drei Tage mit diesem Problem gekämpft. Dabei ging es um eine eBay-Anbindung, die unter Delphi 2010 noch problemlos lief, weil dort nicht diese xmlns=... hinzugefügt wurden.
Aber jetzt mit XE2 hatte ich genau das gleiche Problem. Nach drei Tagen qualvoller Suche und zusätzlicher Verwirrung wegen einer komplett falschen eBay-Fehlermeldung habe ich dann tatsächlich den String mit StringReplace verändert. Endlich läuft meine Anwendung nun auch mit XE2. Ich würde mich ebenfalls sehr freuen, wenn mir jemand einen besseren Weg nennen könnte. Einen Schalter bei der WSDL-Generierung oder eine Option für die XML-Erstellung fände ich deutlich besser. Wie aber hier schon gesagt wurde: der Erzeugte Pascal-Quelltext aus der WSDL ist wahrscheinlich nicht das Problem, da exakt dieser Quelltext unter Delphi 2010 noch problemlos läuft. Mit XE2 wird dann dieser total veränderte XML-Code erzeugt, der von eBay nicht akzeptiert wird. Viele Grüße Rüdiger |
AW: SOAP Client und verschachtelte Namespaces
Ja, SOAP und Delphi ... :)
Meine Daumenregel: * einfache Requests: die baue ich gleich mit IXmlDocument, das ist stabil und schnell realisiert * komplexere Services: wenn es nicht auf Anhieb funktioniert, wird in C# oder Java ein "Proxy" realisiert und auf diesen dann von Delphi aus über eine einfachere Schnittstelle zugegriffen. Bei Microsoft Dynamics CRM zum Beispiel wurden so zwei kleine, überschaubare und stabile Anwendungen benutzt - und dazwischen eine simple Dateisystem - Schnittstelle Mein bisheriger Eindruck: Microsoft ist mit sich selbst interoperabel (WCF), auch Java / .NET geht oft noch gut, aber Delphi's SOAP Implementierung wirkt wie eine "Insellösung". :roll: |
Alle Zeitangaben in WEZ +1. Es ist jetzt 21:55 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz