web service wsdl e flag Conversione Automatica

[Federico]

Premetto che non so se è un bug di inde o se è un buon candidato per una miglioria.
Problema:
importare in inde un web service che come parametri ha valori stringa ma restituisce un oggetto .net System.Data.DataSet

System.Data.DataSet Invio (string , string …)

Usando visual studio e generando una classe proxy il metodo viene prodotto in questo modo
[System.Web.Services.Protocols.SoapDocumentMethodAttribute("http://tempuri.org/Invio", RequestNamespace="http://tempuri.org/", ResponseNamespace="http://tempuri.org/", Use=System.Web.Services.Description.SoapBindingUse.Literal, ParameterStyle=System.Web.Services.Protocols.SoapParameterStyle.Wrapped)]
public System.Data.DataSet Invio(string CodiceCliente….) {
object[] results = this.Invoke("Invio", new object[] { CodiceCliente, …..});
return ((System.Data.DataSet)(results[0]));
}

Visual studio crea la riga con il tipo corretto introduce un cast da object a dataset…

Importando in inde il wsdl questo produce una classe leggermente diversa classe che viene depositata nella cartella app_code

[SoapDocumentMethodAttribute("http://tempuri.org/Invio", RequestNamespace = "http://tempuri.org/", ResponseNamespace = "http://tempuri.org/", Use = SoapBindingUse.Literal, ParameterStyle = SoapParameterStyle.Wrapped)]
public Object Invio (String CodiceCliente, String Password, String Mittente, bool Notifica, String Testo, String ListaNumeri)
{
Object[] Res = this.Invoke("Invio", new Object[] {CodiceCliente…..});
return ((Object)Res[0]);
}

public IDVariant Invio_ws (IDVariant CodiceCliente…..)
{
return IDVariant.convertObject(Invio(CodiceCliente.stringValue…..));
}

Inde incapsula la chiamata usa il suo solito idvariant.
È qui inizia il problema il metodo .convertobject chiaramente falisce la conversione da dataset a idvariant.

Nella libreria di tipo web service importata in inde esiste un flag la Conversione Automatica che rimuove o meno il cast automatico fra i tipi di dato. Questo flag agisce a livello di chi richiama la funzione importata e non nella generazione della classe proxy.
Io ho risolto inserendo in inde il tipo .net System.Data.DataSet come libreria.
Ed ho aggiunto il metodo populate all’oggetto recordset nativo di inde.
$0.populate($1.Tables[$2.stringValue()]);
questa funzione la utilizzo per caricare in un tipo di dato standard di inde attingendo dal dataset .net
ed usando il file list e la custom sovrascrivo la classe proxy di inde con una classe modificata che non richiama il convertobject .

il tutto pare funzionare.
Se il flag di Conversione Automatica oltre a sospendere il cast in chi usa la funzione lo facesse anche per la classe proxy che sottende mi risparmierei di dover riscrivere e sostituire la classe proxy generate da inde.
Lasciando il solo problema di gestire il tipo restituito.

io la butto li
ps
se qualcuno ha una soluzione migliore accetto consigli.

[lucabaldini]

Il tipo di dato DataSet non è gestito... uno dei motivi è che non sarebbe portabile se cambi il progetto in Java... inoltre non c'è un tipo DataSet dentro alle librerie di InDe.

Nel caso di web service che restituiscono tipi complessi (compreso DataSet) suggeriamo sempre di creare una classe Proxy di interfaccia che si occupi di estrarre i dati necessari e fornirli all'applicazione tramite oggetti noti come IDVariant, IDDocument, etc...

Questo a meno che uno non sia in grado di "sistemare" le cose, proprio come hai fatto tu :-)
Complimenti!

P.S. Per completezza ti linko un articolo che è ancora valido e descrive quali sono le limitazioni, anche riguardo l'importazione e uso di ws di terze parti:

http://doc.instantdeveloper.com/default.aspx?artid=1c5b43d1-7b9e-96a3-a807-ff0f24520b57&lang=it

[Federico]

Grazie per la fulminea risposta. Si conosco la limitazione non è il primo web service che dobbiamo tirare dentro ad inde.
la dll proxy le abbiamo già usate in quei casi dove i dati richiesti sono particolarmente articolati.
in questo caso riceve tutto in modo tranquillo e restituiva un tipo di dato gestibile con un barbatrucco.

per la portabilità nel mio caso non è un problema. tutto .net

io ipotizzo che mediante quel flag si potesse bucare e lasciare a chi gestisce la responsabilità di castare correttamente il dato. nel caso specifico un dataset ma spesso sono classi articolate ma semplici. importabili in inde. (meno dll esterne includo meglio è per me)

ps
Grazie i complimenti da un Baldini non sono cosa da poco.

[lucabaldini]

In effetti credo di poter gestire il caso anche garantendo la portabilità :-)
Non dovrebbe essere difficile... Me lo segno.
Se vedo un DataSet(o l'analogo oggetto di Java) potrei creare io il RS e popolarlo proprio come fai tu... senza bisogno di mappare l'oggetto DataSet nativo...

Ho creato l'attività NPQ02203 per tenere conto di questa conversazione. Quando verrà valutata, potrai seguirne l'andamento con Instant Developer Roadmap.