Discussion :

[castorcharly]

Bonjour

J'ai développé un Web service sous XE2 et un client sous XE2 et tout fonctionne parfaitement.

Par contre ce Web service doit être utilisé par des tierces qui travaillent sous VB.net.

Ils rencontrent des problèmes lors de l'appel à certaine fonction, sûrement à cause des paramètres. Car les appels sans paramètre s'exécutent correctement sous vb.net.

Les paramètres passés sont parfaitement reçu par mon web service, la fonction qu'ils attaquent se déroule parfaitement, mais au retour ils obtiennent un message leur indiquant qu'il y a une erreur dans le XML.

Les params sont pourtant basique, string et integer. Pas de tableau ou autre.
Par contre les params sont passés sous forme de record:

Tpar = record
chaine1: string;
chaine2: string;
value: integer;
end;

function test(var par: Tpar): integer; sdtcall;

Avez vous déjà rencontré ce genre de problème ?

[ShaiLeTroll]

Delphi en WebService SOAP, c'est souvent du RPC-encoded comme je l'évoquais dans le sujet service web non décrit ?

Chez MS, c'est document-literal, voir la MSDN - Problèmes avec les messages RPC/Encoded

Cependant, si vous ne contrôlez pas le service Web que vous voulez utiliser et que vous devez vous connecter à un service Web utilisant le style RPC/codé, vous pouvez utiliser un service de proxy .NET (.NET Proxy Service) pour vous y connecter.

J'ai plutôt fait des clients Delphi de WS PHP, en bidouillant le WSDL ou en jouant sur les options de WSDLImp de Delphi, on arrive a utiliser du document-literal sans soucis et à y répondre, le PHP arrive a comprendre le literal ou l'encoded sans qu'on lui précise

Pour le .NET, cela a toujours été la galère et certains dev.NET contournaient cela avec des ANY contenant un XML (j'ai vu plusieurs WS contournant les specs .NET en utilisant qu'un seul paramètre non typé ANY), encore une fois, j'étais Client
Le Dev.NET avait fait ce choix du ANY dans BizTalk car cela simplifié l'Interop avec Java et PowerBuild

Par contre, en Serveur, le client DOIT s'adapter et MS a abandoner le RPC-encoded, je crois qu'il ne le supporte plus du tout et utilise un Proxy ASP.NET (IIS) qui fait l'intermédiaire entre le client VB.NET et le WS RPC-encoded

Voir aussi Free Pascal Web Service ToolKit permettant plus de chose que le SOAP Delphi

Certains membres en bidouillant le SOAP généré ont peut-être réussi des choses : Changer le format dans SOAP

[castorcharly]

Ok Shai,

on y est arrivé d'une autre façon:
function test(par: Tpar): Tpar; sdtcall;

en supprimant le var de la classe en entrée et en retournant la classe.

Ce qui m'ennui, c'est que le result de cette fonction (Tpar), c'est moi qui le crée
sur mon web service, mais comment libérer la mémoire suite au create ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
 
function test(par: Tpar): Tpar;
begin
       result:= Tpar.Create;
       /.....
       ..../
       result.chaine1:= 'tagada';
       result.chaine2:= 'tigidi';
      //mais je ne peux faire un FreeAndNil(Result) , 
      //sinon le client ne va rien recevoir !
 
end;

[ShaiLeTroll]

Ah, oui, les paramètres de retour, je n'avais pas fait attention, c'est l'inverse du COM, si c'est plus élégant de faire des paramètres de retour + HRESULT (typique en C++Builder simplifié en Safecall en Delphi)

En SOAP, faut mieux éviter car cela utilise les trucs qui diffère dans le RPC-Encoded du SOAP 1.0 et SOAP 1.1 !

Normalement, un objet TRemotable envoyé de cette façon au Marshaller sera libéré par le Marshaller !

C'est surtout côté client, ou en Delphi, il faut gérer ses libérations avec soin !
un Client doit libérer les paramètres qu'il a fourni et il est aussi responsable de la libération de valeur retournée lors du unmarshalling de la réponse SOAP

L'appelant d'une interface invocable (client) est responsable de la création de toute instance de TRemotable qu'il transmet en paramètre d'entrée, et de la libération de toute instance de TRemotable qu'il crée ou qui est renvoyée sous la forme de paramètres de sortie ou de résultats de méthode.

côté Server, il n'y a rien à faire, toutes les instances sont gérés par le Marshaller, du moins c'est ce que je comprends de :

Dans les applications serveurs, les instances de TRemotable utilisées comme paramètres d'entrée d'une interface invocable sont créées automatiquement lorsque l'appel de méthode est désassemblé et sont libérées automatiquement quand des paramètres de sortie ou une valeur renvoyée sont assemblés afin d'être envoyées au xclient. Quand un descendant de TRemotable est créé dans une méthode qui a été appelée à distance par le biais d'une interface invocable, l'instance est automatiquement libérée après le marshaling de la valeur du descendant de TRemotable pour le transport vers l'application client.

Active ReportMemoryLeakOnShutDown de ton Delphi XE2, si tu veux être tranquille à ce sujet

à la fin du DPR

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
 
...  Application.Run;
 
{$IFDEF DEBUG}
{$WARN SYMBOL_PLATFORM OFF}
  System.ReportMemoryLeaksOnShutdown := DebugHook <> 0;
{$WARN SYMBOL_PLATFORM ON}
{$ELSE DEBUG}
  System.ReportMemoryLeaksOnShutdown := False;
{$ENDIF DEBUG}
end.

[castorcharly]

Active ReportMemoryLeakOnShutDown de ton Delphi XE2, si tu veux être tranquille à ce sujet

à la fin du DPR

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
 
...  Application.Run;
 
{$IFDEF DEBUG}
{$WARN SYMBOL_PLATFORM OFF}
  System.ReportMemoryLeaksOnShutdown := DebugHook <> 0;
{$WARN SYMBOL_PLATFORM ON}
{$ELSE DEBUG}
  System.ReportMemoryLeaksOnShutdown := False;
{$ENDIF DEBUG}
end.

Oui, c'est une bonne idée, sauf que ça ne marche pas avec un ISAPI, qui est une DLL chargée par IIS et qui est déchargée quand tu arrêtes IIS...

Mais merci, j'avais pas pensé à l'aide de Tremotable.
Je vais éplucher de ce coté pour bien piger le truc.

[ShaiLeTroll]

Pour ReportMemoryLeaksOnShutdown, faudrait voir avec la version complète de FastMM peut générer un Fichier comme le fait CodeGuard pour C++Builder au lieu d'un MessageBox !