Discussion :

[sbouvetJD]

Bonjour,

Je vous présente d'abord mon environnement de travail :
Notre version du framework est le 1.1
Site développé en ASP.Net non code-behind initialement sous Dreamweaver / Microsoft Visual Studio 2005.

Je dois faire l'appel d'un webservice d'un prestataire en SOAP. J'ai construit ma classe proxy via l'utilitaire WSDL.exe du SDK 1.1

Code :

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

"C:\Program Files\Microsoft.NET\SDK\v1.1\Bin\wsdl.exe"  <URL du fichier WSDL distant> /proxy:<adresse de mon proxy> /pu:<USERNAME> /pp:<PASSWORD> /language:VB /namespace:hello.world /out:<fichier de sortie.vb>

J'obtiens déjà un avertissement de validation de schéma :
"l'espace de noms 'http://api.service.nsapi.<monprestataire>.com" n'est pas disponible pour être référencé dans ce schéma"
Lorsque je ping ou que j'effectue un tracert sur cette url, elle est effectivement introuvable. Mais comme ce n'est qu'un warning, j'inclus mon espace de nom hello.world dans mon projet.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
 
Imports hello.world
 
Namespace hello.ws
    Public Class Nmp
        Public Sub relancePanier()
            Dim Proxy As New NotificationServiceService
            Dim RequestedData As New sendRequest
 
            RequestedData.email = HttpContext.Current.Session("prod_EmailClient")
            RequestedData.senddate = DateTime.Now()
            RequestedData.content = "Ceci est le message à transmettre"
 
            Proxy.sendObject(RequestedData)
        End Sub
    End Class
End Namespace

A l'appel de la méthode sendObject du WS, j'obtiens le message "The underlying connection was closed"

Comme c'est notre première manipulation d'un WS en SOAP, a helping hand would be worthy !

[DotNetMatt]

Framework 1.1 Tu n'as pas la possibilité de migrer ?

Sinon concernant le problème, peux-tu décrire un peu plus précisément ce que tu fais ? Est-ce que tu lances des requêtes qui durent longtemps ? Est-ce que tu transfères de gros volumes de données ?

[sbouvetJD]

A ce jour la migration du framework n'est pas prévue (mais on y pense...)

Les données envoyées sont légères, en fait le principe est le suivant :
on envoie des données textuelles qui vont alimenter un template d'e-mail envoyé à un client donc les données sont :
- l'e-mail du client
- la date de programmation de l'envoi de l'e-mail
- l'id du template ciblé
- le texte qui va alimenter le template (~on table sur moins de 1000 car.)

Le message "underlying connection" pourrait-il être lié à un problème de proxy de notre côté ?
Nous attaquons d'autres WS
- en JSON, sans problème (outil de normalisation d'adresse)
- en HTTP:GET via une méthode un getWebRequest où je spécifie notre adresse proxy

Mais dans le cas de la classe proxy générée par l'utilitaire WSDL.exe, je ne vois nulle part un bout de code qui spécifie le proxy à traverser.

[DotNetMatt]

Les causes peuvent être multiples. Effectivement un proxy peut être à l'origine du problème, notamment si ça passe par un port spécifique (vérifier que le firewall ne bloque pas). S'il y a une authentification, il faut passer les credentials.

Mais le problème peut être causé par d'autres choses, comme par exemple un mauvais réglage des horloges entre les serveurs/les proxy/le client...

Bref difficile de diagnostiquer. Si tu analyses le traffic HTTP à l'aide de Fiddler, as-tu des messages d'erreur ?

[sbouvetJD]

Les causes peuvent être multiples. Effectivement un proxy peut être à l'origine du problème, notamment si ça passe par un port spécifique (vérifier que le firewall ne bloque pas). S'il y a une authentification, il faut passer les credentials.

Mais le problème peut être causé par d'autres choses, comme par exemple un mauvais réglage des horloges entre les serveurs/les proxy/le client...

Bref difficile de diagnostiquer. Si tu analyses le traffic HTTP à l'aide de Fiddler, as-tu des messages d'erreur ?

Le souci est que Fiddler nécessite au minimum .Net 2, et comme dit précédemment, nous sommes encore en 1.1 sur le domaine de production.
En outre, dois-je installer Fiddler sur mon poste de développement ou sur le serveur de test ?
Dans le cas où il s'agit du proxy qui bloque, y a-t-il un moyen de bidouiller la classe proxy générée automatiquement ?

La fonction que j'appelle pour envoyer mon message SOAP ressemble à ça :

Code :

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

1
2
3
4
5
6
 
<System.Web.Services.Protocols.SoapDocumentMethodAttribute("", RequestNamespace:="http://<url du ws que je n'arrive pas à pinger>/", ResponseNamespace:="http://<url du ws que je n'arrive pas à pinger>/", Use:=System.Web.Services.Description.SoapBindingUse.Literal, ParameterStyle:=System.Web.Services.Protocols.SoapParameterStyle.Wrapped)> _
        Public Function sendObject(<System.Xml.Serialization.XmlElementAttribute(Form:=System.Xml.Schema.XmlSchemaForm.Unqualified)> ByVal arg0 As sendRequest) As <System.Xml.Serialization.XmlElementAttribute("return", Form:=System.Xml.Schema.XmlSchemaForm.Unqualified)> String
            Dim results() As Object = Me.Invoke("sendObject", New Object() {arg0})
            Return CType(results(0), String)
        End Function

Autant vous dire que là tout de suite ça me dépasse un tantinet.

[DotNetMatt]

En outre, dois-je installer Fiddler sur mon poste de développement ou sur le serveur de test ?

Oui il faut l'installer sur ton poste de développement. L'idée étant d'intercepter les messages HTTP qui transitent entre le client (ton poste dév) et le serveur.

Dans le cas où il s'agit du proxy qui bloque, y a-t-il un moyen de bidouiller la classe proxy générée automatiquement ?

Il vaut mieux éviter de toucher à la classe générée automatiquement, car si demain tu as besoin de la regénéré, tu vas perdre toutes tes modifications...

Si le web service utilise un port spécifique, il faut vérifier que sur tout le trajet des messages, il n'y ait pas de firewall qui bloque (donc il faut s'assurer que les règles ouvrant les ports utilisés soient bien en place). Là difficile de t'aider plus que ça, car tout dépend de la topologie du réseau...

Je peux te donner un exemple dans une boîte où je bossais. On avait en très gros 3 ensembles d'ordinateurs : les postes utilisateurs, les serveurs locaux (hébergés dans le datacenter à l'intérieur de notre bâtiment), et les serveurs distants (hébergés par un prestataire à l'étranger). Entre chacun de ces ensembles, il y avait un firewall, donc on avait ça :
- Postes utilisateurs <--> Firewall <--> Serveurs locaux
- Postes utilisateurs <--> Firewall <--> Serveurs distants
- Serveurs distants <--> Firewall <--> Serveurs locaux
Donc il fallait toujours avoir à l'esprit que chaque applications pouvait nécessiter la mise en place de règles spécifiques dans chacun des firewalls...