Delphi-PRAXiS

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   Netzwerke (https://www.delphipraxis.net/14-netzwerke/)
-   -   Delphi SOAP Client und verschachtelte Namespaces (https://www.delphipraxis.net/166919-soap-client-und-verschachtelte-namespaces.html)

ASKtec 6. Mär 2012 00:21

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:
<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>
Wenn ich das nun mit der importierten WSDL-Datei erstelle kommt bei Delphi XE2 folgendes raus:

Delphi-Quellcode:
<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>
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...

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

mjustin 6. Mär 2012 08:08

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 http://de.wikipedia.org/wiki/SOAP). Denn "irgendwo" müssen die Namespaces ja deklariert werden.Wikipedia-Beispiel:


Code:
<?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>
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.

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.

Keldorn 6. Mär 2012 09:05

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 von mjustin (Beitrag 1154689)
Einen Test mit SoapUI würde ich auch versuchen

Das ist ja auch immer das, was ich nicht verstehe, SoapUI oder Soapscope schaffen es ja immer, eine konforme Nachricht zu erstellen, bloß mit Delphi klappt es nicht.

Zitat:

Zitat von mjustin (Beitrag 1154689)
p.s. als Alternative zum Delphi WSDl Importer gibt es noch das Free Pascal Web Service Toolkit,

Ich habe mir das noch nicht angeschaut, hast Du damit schon Erfahrungen gesammelt :)?
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

Lemmy 6. Mär 2012 09:17

AW: SOAP Client und verschachtelte Namespaces
 
Zitat:

Zitat von Keldorn (Beitrag 1154696)
Aber der WSDL-Importer kann ja nicht das Problem sein, es liegt ja mehr an der Generierung der xml-Nachricht.

naja... ich habe schon ein paar Probleme mit dem WSDL-Import. Der Importer unter Delphi 7 funktioniert nicht bzw. die mit dem Code erzeugen Nachrichten können vom Server nicht gelesen werden. Es gibt zwar einen Fix, aber damit habe ich jetzt das Problem, dass die definierten Enums nicht korrekt kodiert werden (in Delphi wird aus "U" ein "U2" und beim senden der Nachricht an den Server bleibt ein "U2" stehen).

Ich werde mir mal das Toolkit heute/morgen anschauen...

GRüße

ASKtec 6. Mär 2012 12:27

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

chickenrudi 18. Jun 2012 18:42

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

mjustin 18. Jun 2012 19:05

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