Comment consommer des non-IIS hébergés, WCF, C # Web Service Web de Delphi 2007?

J'ai également fait face au même problème lors de la consommation de service Web C # à Delphi.
Delphi 7.0 / 2005/2007 ne prend pas en charge les nouvelles définitions de la WSDL.
Pour cela, vous devrez télécharger la dernière importateur WSDL (WSDLIMP.EXE). Il fournira également un code source pour les fichiers Pass de code source Delphi mis à jour.

Ceci est causé par une inadéquation de la version du savon. Le service C # attend un message SOAP12 et la réception d'un message SOAP11 de votre application Delphi. En fonction de votre situation, vous devez modifier l'un des deux côtés. Je ne peux pas vraiment commenter le côté Delphi. Sur le côté WCF, vous pouvez utiliser le BasichttpLinding qui par défaut sur SOAP11 ou, si vous avez besoin de plus de contrôle, utilisez un plan de signalisation spécifiant un type de message SOAP11.

a trouvé la solution. C'est plusieurs parties et nécessite quelques modifications au côté C #, plus au côté Delphi. Notez que cela a été testé avec Delphi 2007 et Visual Studio 2008.

C # Side: Utilisez BasichttpBinding plutôt que WShttpbinding. P>

Fixez l'étape 1 forte> p> xxx pré>

Ce changement résoudra les erreurs d'application / SOAP + XML sur Le côté Delphi. P>

Delphi 2007 Side: En cours d'exécution contre le service Web C # modifié, générera désormais des erreurs telles que ceci: P>

Classe d'exception EremoTableException avec message 'le message avec action '' ne peut pas être traité au Récepteur, en raison d'un contratFilter Mismatch à l'extrémitéPointDispatcher. Cela peut être à cause de l'un ou l'autre Mismatch contractuel (actions incompatibles entre l'expéditeur et le récepteur) ou un Mistimatch de liaison / de sécurité entre le expéditeur et le destinataire. Regarde ça L'expéditeur et le récepteur ont la même chose contrat et la même liaison (y compris les exigences de sécurité, par exemple Message, transport, aucun). ' P> blockQuote>

Pour résoudre ce problème, ajoutez des savapactions à toutes vos interfaces prises en charge. Voici l'exemple de mon code; Cela doit être fait après toutes les modifications de la facturation apportées par la section d'initialisation de l'importateur-from-WSDL-PAS-PAS-PAS-PAS-PAS: P>

Étape 2 FORT> P>

var
  R: THTTPRIO;
  C: IVMProvisionCore;
begin
  R:= THTTPRIO.Create(NIL);
  C:= GetIVMProvisionCore(False, TheURL, R);
  R.Converter.Options:= R.Converter.Options + [soLiteralParams];

Merci - Cela a beaucoup aidé beaucoup. J'ai eu des problèmes avec quelques ridules supplémentaires. Pour moi, Numéro n ° 2 (Soapaction) a tout été encrassé parce que l'opérationName ne correspondait pas. Le groupe .NET normalisé en plaçant "In" à la fin de la savon, mais pas l'opération.
Alors yadda.yadda.com/whatever/services/%OperationName% a vraiment besoin d'être yadda.yadda.com/whatever/services/%OperationName%in Dans ce cas particulier.

Il m'a fallu un peu de temps pour taper cela, mais j'ai finalement remarqué en testant en parallèle avec SoaPui, qu'il avait des savapacations différentes que celles qui revenaient dans la réponse des erreurs. J'ai réparé ça et ça a fonctionné. Mais c'était après avoir du mal à jouer tout en essayant de comprendre ce qui devrait être dans la valeur par défaut. Encore une fois, Soapui était utile ici.
Donc, quand même, si vous trouvez que vous obtenez cette erreur: "Action (peu importe) ne peut pas être traitée au récepteur, en raison d'une inadéquation de contratTfilter à la finPointDispatcher ..." La première étape consiste à remplir la valeur par défaut et que les problèmes persistent, comparez celui rapporté dans l'erreur contre ce qui devrait vraiment être là.
HTH, Chris