web-dev-qa-db-fra.com

Générer des classes c # à partir de wsdl

Je veux générer des classes C # à partir de l'URL wsdl dans ASP.NET Core 2.1.

L'URL WSDL est: https://airarabia.isaaviations.com/webservices/services/AAResWebServices?wsdl

J'ai utilisé l'outil "Microsoft WCF Web Service Reference Provider" pour générer la classe C # et j'ai obtenu l'erreur suivante:

Erreur: aucun code n'a été généré. Si vous tentiez de générer un client, cela pouvait être dû au fait que les documents de métadonnées ne contenaient aucun contrat ou service valide ou parce que tous les contrats/services existaient dans/les assemblys de référence. Vérifiez que vous avez transmis tous les documents de métadonnées à l'outil. Terminé.

Toute solution sera appréciée.

c#wcfasp.net-corewsdl
5
Ahmad1334

Réponse courte

Ouvrez une invite de commande de développement et exécutez-la pour générer les classes proxy:

svcutil http://airarabia.isaaviations.com/webservices/services/AAResWebServices?wsdl

Notez que j'ai utilisé http au lieu de https. Le certificat du serveur provoque des problèmes avec svcutil. Copiez les classes dans votre dossier de projet.

Ajoutez System.ServiceModel.Primitives De NuGet aux dépendances du projet. Étant donné qu'ASP.NET Core n'utilise pas de fichiers web.config, Vous devrez peut-être créer vous-même les liaisons lors de la création de la classe proxy, par exemple:

var binding = new BasicHttpsBinding(BasicHttpsSecurityMode.Transport);
var address = new EndpointAddress("http://airarabia.isaaviations.com/webservices/services/AAResWebServices");
var client = new AAResWebServicesClient((Binding)binding, address);

Dans les liaisons, BasicHttpsBinding est utilisé car aucune compagnie aérienne n'acceptera de connexions non cryptées. Sabre nécessite TLS 1.2 ou supérieur.

Explication

Les compagnies aériennes et les GDS ne sont pas bons pour suivre les normes d'interopérabilité Web. Ils sont assez grands pour que s'il y a des changements, c'est l'agent de voyage qui doit les accueillir. Une fois qu'ils ont spécifié leur standard, ils ne se soucient pas de le changer non plus.

La norme OTA et l'implémentation de Sabre par exemple ont été créées en 2003 en utilisant ebXML, une proposition alternative à SOAP qui n'est pas devenue une norme. Ils ont ensuite utilisé ebXML sur SOAP en utilisant des mécanismes qui ne faisaient pas partie des normes SOAP ultérieures. Lorsque les normes WS- * ont été créées pour corriger le gâchis et garantir l'interopérabilité, elles n'ont même pas dérangé.

Le WSDL que vous avez fourni est similaire à celui de Sabre. Il utilise certaines des opérations OTA comme OTA_PING et ajoute des opérations personnalisées. Heureusement, il n'inclut aucun briseur d'outils comme les types internes anonymes.

Vous pourriez utiliser wsdl.exe pour créer un proxy ASMX, en utilisant la pile .NET antérieure à 2008. Pour autant que je sache, cela n'a pas été porté sur .NET Core. Peut-être cela fait partie du pack de compatibilité Windows. Après tout, il est non conforme et obsolète il y a 10 ans. ASMX n'a ​​pas eu non plus de mises à niveau importantes depuis des siècles. J'ai rencontré des problèmes de concurrence avec des désérialisateurs dans le passé, lors de l'utilisation des services ASXM, ​​par exemple avec Amadeus.

Et puis, il y a ceux qui ne respectent même pas leurs propres XSD, par exemple Farelogix. Ils peuvent renvoyer des valeurs hors limites pour les énumérations et dire "eh bien, le XSD est uniquement à titre informatif". Le fichier wsdl est clairement marqué not for production use

Il n'y a malheureusement pas de solution générique. Voici quelques options:

  • wsdl.exe Et ASMX sont hors de question si vous souhaitez utiliser .NET Core. Vous devrez passer au framework Full si vous devez les utiliser.
  • Créez des procurations WCF individuelles pour chaque service. La taille des fichiers est beaucoup plus petite et vous évitez les conflits entre les types comme Airport qui sont utilisés par plusieurs services avec de légères variations ou même des incompatibilités.
  • Utilisez Fiddler ou un autre outil pour capturer les demandes et les réponses. Utilisez-les comme modèles pour créer des requêtes HTTP GET simples. C'est une solution sale mais pourrait se révéler plus rapide et plus fiable si vous ne pouvez pas faire confiance au WSDL et aux XSD du fournisseur

AVERTISSEMENT

Passer l'appel ne signifie pas que vous pouvez communiquer avec le fournisseur. L'un des principaux problèmes avec ebXML sur SOAP est que le corps est OK mais les en-têtes , y compris ceux utilisés pour l'authentification sont tous faux. Cela signifie que l'on doit créer l'élément d'authentification

Un autre problème est que les champs d'authentification sont souvent mal utilisés, par exemple en utilisant des en-têtes d'authentification que nous considérerions les jetons de session . Les GDS utilisent toujours des mainframes et ces jetons de session sont souvent mappés aux sessions de terminal réelles.

Cela signifie que l'on doit créer des en-têtes d'authentification manuellement au lieu de s'appuyer sur WCF pour les générer. Cela signifie également que les transactions sont avec état - il faut garder une trace de la session qui a été utilisée pour cette réservation afin de la réserver, assurez-vous que toutes les transactions précédentes sont terminées avant de commencer une nouvelle, etc.

7
Panagiotis Kanavos

Téléchargez vos fichiers WSDL en local. Ensuite, exécutez la commande suivante:

wsdl.exe /verbose /namespace:Air /out:D:\t\ar /protocol:SOAP /language:CS C:\path\to\wsdl\AAResWebServices_1.wsdl

Remplacez l'espace de noms par un espace de noms de votre choix.

WSDL.exe fait partie de votre SDK Windows:

C:\Program Files (x86)\Microsoft SDKs\Windows

Le mien était dans C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin

Cela a généré les classes sans aucun problème. J'ai testé cette solution.

4
Sunil