SOAP: XE3-Client liefert Daten, XE8-Client liefert Fehler

[mkinzler]

Eine vollständige IDE ist nicht unbedingt notwendig, es reicht ja der Remote Debugger. U.U. könntest Du Dir auch einen Testrecher aufsetzen.

[Bernhard Geyer]

Ich Tipp mal auf den MS XML-Parser der in neuerer Version erwartet wird aber in dieser W2k3-Installation zu alt ist.

[mquadrat]

Zitat von Bernhard Geyer:

Ich Tipp mal auf den MS XML-Parser der in neuerer Version erwartet wird aber in dieser W2k3-Installation zu alt ist.

Klingt auf jeden Fall plausibel

[kretabiker]

Guten Morgen allerseits,

danke für die Ratschläge zu diesem Problem.

1. Remote Debugger: Daran habe ich nicht gedacht, da noch nie benutzt. Ein kurzer Blick in die Doku, das sollte auch auf dem Kundenserver möglich sein. Ich kläre das mit dem Kunden und werde es dann damit versuchen.
2. W2k3-Testumgebung: Daran habe ich gedacht. Derzeit sucht mein Systemlieferant eine VM, auf der ich testen kann. Das wird parallel zu 1. passieren.

[kretabiker]

Update von dieser Front:

- Der Fehler tritt auch auf einem anderen Win2k3R2-Server auf, den ich für Testzwecke nutzen konnte. Auf allen anderen getesteten Systemen (Win7, Win8, W2k8, W2k12) läuft es.
- Der Versuch, die Fehlerursache per Remote Debugger einzukreisen, ist gescheitert. Zwar gelang es mir im lokalen Netz, ein Verbindung aufzubauen und zu debuggen, aber da waren beide Systeme Win7. Der Versuch, mein Programm auf den in fremden Netzen befindlichen W2K3-Rechnern anzusprechen, gelang nur teilweise: Zwar konnte ich mich mit den jeweiligen Prozessen verbinden, aber die von mir gesetzten User-Breakpoints wurden nicht erkannt, debuggen war daher nicht möglich. Vielleicht habe ich was falsch gemacht? Ich meine aber auch gelesen zu haben, dass das RD nur innerhalb eines Netzes funktioniert. Firewalls wurden - sofern vorhanden - für die Tests kurzfristig abgeschaltet.

Ich habe mal unsere Kundenliste gecheckt: Wir haben tatsächlich nur einen Kunden mit W2k3 im Einsatz - nämlich den, bei dem der Fehler aufgetreten ist. Dem Kunden ist das Problem des End-Of-Life seines Systems auch bewußt und er strebt einen kurzfristigen Umzug auf einen neuen Rechner mit dann aktuellem Windows Server OS Windows Server 2012. Trotzdem bleibt ein ungutes Gefühl, die Ursache nicht wirklich zu kennen.

[Bernhard Geyer]

Compiliere die exe doch mit maximalen Debug-Infos (Debug-DCU) und lass dir mit JCLDebug-Units (oder auch mit Madexpert oder ähnlichen) den vollständigen Aufrufstack geben

[kretabiker]

So, vorläufige Abschlussmeldung zu diesem Thema: Nach ausführlichen Tests mit PAServer konnte ich das Problem auf einen Aufruf der WinInet-Funktion HttpSendRequest (bzw. auf eine Fehlerprüfung im Umfeld davon) in der Unit SOAP.SOAPHTTPTrans.pas einkreisen. Dieser Aufruf erfolgt in XE8 nach dem Muster

Delphi-Quellcode:

{$IFDEF UNICODE}
          HttpSendRequest(Request, nil, 0,
                          DatStr.Bytes, DatStr.Size);
{$ELSE}
          HttpSendRequest(Request, nil, 0,
                          @DatStr.DataString[1],
                          Length(DatStr.DataString));
{$ENDIF}
          
          RetVal := HandleWinInetError(GetLastError, Request, True);

d.h. der Aufruf der Funktion HandleWinInetError erfolgt immer unabhängig vom Ergebnis der HttpSendRequest-Funktion, welche entweder True oder False liefern kann.

In XE3 sieht das noch ein wenig anders aus:

Delphi-Quellcode:

{$IFDEF UNICODE}
          WinInetResult := HttpSendRequest(Request, nil, 0,
                          DatStr.Bytes, DatStr.Size);
{$ELSE}
          WinInetResult := HttpSendRequest(Request, nil, 0,
                          @DatStr.DataString[1],
                          Length(DatStr.DataString));
{$ENDIF}
          if not WinInetResult then
            RetVal := HandleWinInetErrorEx(GetLastError, Request, True);

Hier erfolgt der Aufruf von HandleWinInetError nur, wenn das Ergebnis von HttpSendRequest False ist, was meines Erachtens richtig ist.

Ändere ich den Sourcecode in XE8 so, dass der Aufruf an dieser Stelle wie bei XE3 erfolgt, funktioniert die Webservice-Abfrage auch unter W2k3R2 einwandfrei; es war wohl reine Glücks- bzw. Pechsache, dass es auf meinem Entwicklungsrechner und unter Win7 funktioniert, nicht jedoch auf W2k3R2-Maschinen, woher dort der Errorcode 2 auch immer kommt. Ich denke, das ist ein Bug in XE8, jedenfalls habe ich das so an den Embarcadero-Support gemeldet. Wer es gerne in seinem eigenen Source mal nachschauen möchte: Soap.SOAPHttpTrans.pas, class THTTPReqRes, function Send, Zeile 1156ff. Der (meines Erachtens) fehlerhafte Aufruf von HandleWinInetError erfolgt aber noch an zwei weiteren Stellen innerhalb der Unit.

Wenn sich der Emba-Support meldet, gibt es noch ne abschließende Abschlußmeldung.

[kretabiker]

Vom Emba-Support: Wurde als Bug anerkannt. "Reported internally as RS-64962"