Webservice: String als null übergeben?

[Phoenix]

Ich habe einen Webservice, den ich mittels Delphi 6 ansprechen will (siehe auch den anderen Thread).

Die erste Hürde ist genommen, da erscheint sofort die zweite:
Ich habe folgende aus dem WSDL generierte Methode:

Delphi-Quellcode:

function  GetReportParameters(const Report: String; const HistoryID: String; const ForRendering: Boolean; const Values: ArrayOfParameterValue; const Credentials: ArrayOfDataSourceCredentials): ArrayOfReportParameter; stdcall;

Nun unterstützt der Report Server keine Historie der Reports. Ich darf also keine HistoryID übergeben. Ein Leerstring wird aber nicht als 'nichts' erkannt. Ich muss hier also 'null' bzw. 'nil' übergeben. Nur geht das hier ja nicht. Was nu?

[turboPASCAL]

Nuja, PChar's währen hier an Stelle von Strings angebracht.

[Phoenix]

Delphi-Quellcode:

PChar(nil)

geht auch nicht.

[DeddyH]

Nur nil ohne Cast.

[Apollonius]

Vorweg: Ich habe keinerlei Ahnung von WSDL und dem Import in Delphi. Aber: Wenn du in Delphi einer lokalen Variable oder einem Parameter einen Leerstring übergibst, wird intern nil übergeben. Das Äquivalent zum C-String #0 existiert in Delphi also nicht direkt. Insofern gibt es vermutlich keine Möglichkeit, an dem Delphi-Wrapper (ich hoffe mal, ich erzähle hier keinen Unsinn) ein nil vorbeizuschleusen, da dieser nil automatisch in einen Leerstring übersetzt.

[Phoenix]

Zitat:

Zitat von DeddyH

Nur nil ohne Cast.

Häh? Der Parameter ist vom Typ String. Ich kann da kein nil übergeben. Das lässt der Compiler nicht zu.

[DeddyH]

Zitat:

Zitat von turboPASCAL

Nuja, PChar's währen hier an Stelle von Strings angebracht.

Dann würde nil auch gehen.

[Phoenix]

Ich habe ein WSDL. Das gibt an der Stelle nunmal String vor. Der WSDL-Importer erzeugt auch eine Unit, die hier String erwartet. Ich kann doch nicht einfach hergehen und das dort in PChar umwandeln? Dann bin ich doch nicht mehr mit dem WSDL konform?

[mjustin]

Zitat:

Zitat von Phoenix

Ich habe ein WSDL. Das gibt an der Stelle nunmal String vor. Der WSDL-Importer erzeugt auch eine Unit, die hier String erwartet. Ich kann doch nicht einfach hergehen und das dort in PChar umwandeln? Dann bin ich doch nicht mehr mit dem WSDL konform?

Mit Delphi 2009 funktioniert es aber? Falls ja, vermute ich dass der Fehler in der alten SOAP Implementierung von Delphi 6 liegt.

[DeddyH]

Dann habe ich auch keine Idee, ein String kann nunmal nicht nil sein.

[Der.Kaktus]

Zitat:

Zitat von DeddyH

Dann habe ich auch keine Idee, ein String kann nunmal nicht nil sein.

vielleicht ist der Variant Typ "null" interessant..NIL ist ja nicht unbedingt = 0 ???

[DeddyH]

Es geht ja um String und nicht um Variant.

[mirage228]

Zitat:

Zitat von Der.Kaktus

vielleicht ist der Variant Typ "null" interessant..NIL ist ja nicht unbedingt = 0 ???

Also wenn ich mich recht erinnere müsste dann ein Fehler kommen, weil er das Variant "null" nicht nach String konvertieren kann ...

[Der.Kaktus]

Zitat:

Zitat von mirage228

Zitat:

Zitat von Der.Kaktus

vielleicht ist der Variant Typ "null" interessant..NIL ist ja nicht unbedingt = 0 ???

Also wenn ich mich recht erinnere müsste dann ein Fehler kommen, weil er das Variant "null" nicht nach String konvertieren kann ...

Wenn ich es richtig verstanden habe..ist diese Funktion von C --> Delphi uebersetzt worden..in "C" gibt es "NIL" nicht. koennte doch der Grund sein oder?

P.S.: gilt auch fuer Deddy ;-)

[DeddyH]

In C heißt es NULL (in Deiner Lieblingssprache Java btw. auch ;))

[Der.Kaktus]

Zitat:

Zitat von DeddyH

In C heißt es NULL (in Deiner Lieblingssprache Java btw. auch ;))

lool ich hasse Java *gg*..aber Null iss echt nicht NIL bei Uebersetzung..mal gelesen habe Detlef :cheers:

[DeddyH]

Kann möglich sein, ich hab seit 4 Jahren keine Zeile C mehr geschrieben. Leider löst das alles aber das Kernproblem auch nicht :mrgreen:

[Der.Kaktus]

Zitat:

Zitat von DeddyH

Kann möglich sein, ich hab seit 4 Jahren keine Zeile C mehr geschrieben. Leider löst das alles aber das Kernproblem auch nicht :mrgreen:

Ich lese bei Phoenix seinem Quelltext ein "stdcall..das bedeutet (IMHO)..DLL aufruf..da iss das schon von Interesse ob Null oder NIL??? :cry:

P.S.: gehe nun mal zu Bett..Tag war lang..Morgen mal weiter lese hier..mal sehen..was passiert *g*

[Sir Rufo]

Zitat:

Zitat von Phoenix

Ich habe ein WSDL. Das gibt an der Stelle nunmal String vor. Der WSDL-Importer erzeugt auch eine Unit, die hier String erwartet. Ich kann doch nicht einfach hergehen und das dort in PChar umwandeln? Dann bin ich doch nicht mehr mit dem WSDL konform?

Obwohl es schon sehr ungewöhnlich ist, das gerade MS bei einer DLL einen String als Parameter erwartet.
Weiterhin überrascht es mich, weil bei der Entwicklung einer DLL mit String in den Exports da ja so ein rumgezicke mit dem SharedMem ist.
Ich glaub ich würde da tatsächlich mal aus jedem String ein PChar machen :mrgreen: und schauen was passiert.

cu

Oliver

[alzaimar]

DLL != WebService

[Sir Rufo]

Ok, dann mal die C -> Delphi Experten, so geht das in C# (siehe MSDN)

Code:

using System;
using System.Web.Services.Protocols;

class Sample
{
   public static void Main()
   {
      ReportingService2005 rs = new ReportingService2005();
      rs.Credentials = System.Net.CredentialCache.DefaultCredentials;

      string report = "/SampleReports/Employee Sales Summary";
      bool forRendering = false;
      string historyID = null;
      ParameterValue[] values = null;
      DataSourceCredentials[] credentials = null;
      ReportParameter[] parameters = null;

      try
      {
         parameters = rs.GetReportParameters(report, historyID, forRendering, values, credentials);

         if (parameters != null)
         {
            foreach (ReportParameter rp in parameters)
            {
               Console.WriteLine("Name: {0}", rp.Name);
            }
         }
      }

      catch (SoapException e)
      {
         Console.WriteLine(e.Detail.InnerXml.ToString()); 
      }
   }
}

[alzaimar]

C#.string != Delphi.string

Phoenix, vergleiche doch mal das SOAP von D2009 mit dem SOAP von D6. Wie wird ein 'NULL' String im D2009-SOAP dargestellt?

[Sir Rufo]

Zitat:

Zitat von alzaimar

C#.string != Delphi.string

aber das ist doch genau das, worauf ich eigentlich hinaus will, dass die Typen der Übergabe-Parameter nicht der Delphi-String sein können.
In VisualBasic wird bei HistoryID in diesem speziellen Fall Nothing übergeben.
In C# wird NULL übergeben.

Da ich in Delphi aber über einen Delphi-String keinen dieser Werte als Äquivalent übergeben kann (nil oder Variant-NULL) kann eigentlich nur noch die Deklaration so nicht stimmen.

[SubData]

Was passiert, wenn du einfach #0 übergibst?

[Phoenix]

Egal, ob ich #0 oder auch einen Leerstring übergebe: Der Webservice ist der Meinung, ich hätte eine HistoryID übergeben und schmeisst eine Exception, dass die Snapshots nicht aktiviert seien.

Das stdcall hat übrigens gar nichts mit einer dll zu tun. Ich weiss nicht genau, warum das ein stdcall sein muss, es wird halt genau so generiert.

Den Datentyp in der generierten Unit kann ich auch nicht auf PChar ändern, denn dann schmeisst mir der Compiler einen Fehler, dass der Typ PChar für diesen Aufruf nicht definiert sei. Das heisst also, ich kann keine Typen verwenden, die nicht im WSDL definiert werden.

Allerdings habe ich eine Lösung gefunden, wenn auch eine extrem unsaubere:
Ich habe den Aufruf in dem Remoting-Objekt mit overload gekennzeichnet, und einen gleichlautenden Aufruf deklariert, der diesen einen Parameter nicht hat.

Im Code überprüfe ich nun, ob die HistoryId EmptyStr ist, und wenn ja, rufe ich die Methode ohne den Parameter auf und wenn ich einen Wert habe halt die mit dem Parameter.

Ist der Parameter nicht im Methodenaufruf, wird der Wert im Soap-Envelope gar nicht mitgeschickt und vom Webservice als nicht angegeben -> null interpretiert.

Das Problem ist also gelöst (wenn auch durch einen Hack). Morgen früh werde ich wohl mit dem nächsten Problem kommen ;-)

[mjustin]

Zitat:

Zitat von Phoenix

Das Problem ist also gelöst (wenn auch durch einen Hack). Morgen früh werde ich wohl mit dem nächsten Problem kommen ;-)

Web Services Server wurden in Delphi Win 32 als deprecated gekennzeichnet. Hier kann man für eine Weiterentwicklung der Win32 Delphi Web Services / SOAP Unterstützung stimmen:

http://qc.codegear.com/wc/qcmain.aspx?d=66864

Man darf auch mehr als eine Stimme abgeben :wink:

Mehr Infos gibt es auch unter
http://www.bobswart.nl/Weblog/Blog.aspx?RootId=5:2720

[Phoenix]

Zitat:

Zitat von mjustin

Web Services Server wurden in Delphi Win 32 als deprecated gekennzeichnet. Hier kann man für eine Weiterentwicklung der Win32 Delphi Web Services / SOAP Unterstützung stimmen:

Ich will ja auch keinen Web Service Server schreiben, sondern einen Webservice konsumieren. Und mit Delphi 2009 geht das auf Anhieb und Einwandfrei. Leider muss ich das was ich in Delphi 2009 habe zu Delphi 6 (möglicherweise geht auch 7, das muss ich noch abklären) zurückportieren.

[turboPASCAL]

Aus diesem Grund verwies ich auf PChars. Das stdcall kennzeichnet für mich einen externen Aufruf zB. aus einer DLL.
Strings machen da nun mal Probleme. Du müsstest im String[0] die Stringlänge auf "0" setzen das könnte dann klappen wenn es Delphi zu liesse.

[mjustin]

Falls jemand noch eine Lösung sucht:

der Experte für den WSDL-Import

http://docwiki.embarcadero.com/RADSt...en_WSDL-Import

hat diese beiden relevanten Optionen:

Optionale und nillable Elemente verarbeiten - Aktivieren Sie diese Option, damit das WSDL-Importprogramm relevante Informationen über optionale und nillable Eigenschaften erzeugt. Die SOAP-Laufzeit verwendet diese Informationen, um zu ermöglichen, dass bestimmte Eigenschaften nil sind.

TXSString für einfache nillable Typen verwenden - Der WSDL-Standard lässt zu, dass einfache Typen in Delphi nil bzw. in C++ NULL sind. Delphi und C++ lassen das nicht zu. Aktivieren Sie diese Option, damit das WSDL-Importprogramm diese Beschränkung umgeht, indem Instanzen von Wrapper-Klassen verwendet werden.

Aus diesem Post von J.M. Babet:

Zitat:

Support for 'nil' has been an ongoing issue. Several built-in types of Delphi are not nullable. So we opted to use a class for these cases (not elegant but it works). So with the latest update for Delphi 2007 I have added several TXSxxxx types to help with this. Basically: TXSBoolean, TXSInteger, TXSLong, etc. TXSString was already there but it was not registered. Now it is. When importing a WSDL you must enable the Use 'TXSString for simple nillable types' option to make the importer switch to TXSxxxx types. On the command line it is the "-0z+" option.