Webservice: String als null übergeben?

[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.