Récemment, je travaillais sur un client qui appelle un webservice. Je l'avais déjà fait et je pensais que c'était facile. Cependant, certains problèmes que j'ai rencontrés au cours du processus m'ont fait réaliser que j'en savais encore trop peu.
Le côté serveur du service Web nécessite une authentification par certificat. Le certificat m'a été envoyé au format cer. Après avoir utilisé l'outil Java keytool pour extraire le certificat, exécutez l'instruction suivante lors de l'appel du service Web :
System.setProperty("javax.net.ssl.trustStore", "xxxx.truststore");
Dites au serveur que mon client possède un certificat et jusqu'à présent, il n'y a aucun problème.
Ensuite, j'ai utilisé wsdl2java d'axis2 pour générer le code client, mais l'erreur suivante s'est produite dès son exécution :
org.apache.axis2.AxisFault : [ISS.0088.9125] La requête SOAP n'est pas conforme au modèle de message SOAP
Cette erreur a été trouvée dans le document de développement Soap car le format de message Soap demandé est incorrect. L'adresse du document est : http://documentation.softwareag.com/webmethods/wmsuite7/Developer/Guides/7-1-1_SOAP_Developers_Guide.pdf (89). Page)
À ce moment-là, l'autre partie m'a demandé d'envoyer le message de demande de savon. J'en étais seulement au stade de l'utilisation du service Web. Je pouvais utiliser des outils tels que axis et xfire pour écrire le serveur et le client, mais je ne connaissais que peu de choses sur le savon. .J'ai cherché des informations sur Internet et demandé à un collègue, après avoir longtemps lutté, j'ai finalement trouvé le message de demande. La méthode proposée par les collègues consiste à utiliser des outils tels que TCP Monitor, mais le service Web est au format https et ne peut pas être utilisé. Plus tard, j'ai tapé SOAPEnvelope.toString() dans le code client généré pour l'obtenir, comme suit :
<?xml version='1.0' encoding='utf-8'?>
<soapenv:Envelope xmlns:soapenv=" http://schemas.xmlsoap.org/soap/envelope/ ">
<soapenv:Corps>
<ns1:UPLGenerate xmlns:ns1=" http://www.alcatel-lucent.com/webService/WS_UPL ">
<CodeOpération>1 </CodeOpération>
<Plante>2 </Plante>
<QuoteNumber>3 </QuoteNumber>
<IDUtilisateur>4 </IDUtilisateur>
<IncludePriceType>5 </IncludePriceType>
</ns1:UPLGenerate>
</soapenv:Corps>
</soapenv:Enveloppe>
En fait, la raison de ce problème est que le codage de transfert par défaut du client axis2 est fragmenté, il y aura donc deux nombres au début et à la fin du corps du message de demande de savon. Vous pouvez utiliser tcpmon pour le tester. .net ou certains autres serveurs ne prennent pas en charge ce mode. Oui, définissez-le simplement dans le code, comme suit :
stub._getServiceClient().getOptions().setProperty(HTTPConstants.CHUNKED, false);
Je l'ai fait des recherches ce week-end. J'ai consulté un responsable de l'entreprise pour le vérifier pour moi et m'a fait quelques suggestions. Merci beaucoup à lui !
Il ne devrait y avoir aucun problème avec l'exécution maintenant, pensais-je, mais il y a un autre problème.
Exception dans le thread "principal" org.apache.axis2.AxisFault : org.apache.axis2.databinding.ADBException : sous-élément inattendu xxxxResponse
sur org.apache.axis2.AxisFault.makeFault(AxisFault.java:430)
Ce problème me dérange depuis trois jours. J'en ai trouvé beaucoup sur Internet. Certains ont dit d'utiliser wstx-asl-3.2.1.jar, etc., mais je les ai tous essayés et ça n'a pas fonctionné. pas à cause de cette erreur de mon côté. Je suis très urgent. Je n'en avais aucune idée. Plus tard, j'ai accidentellement imprimé org.apache.axiom.soap.SOAPEnvelope _returnEnv dans le stub, qui est _returnEnv.toString(). . J'ai trouvé que le résultat renvoyé par soapUI était différent car le service Web était https, il ne pouvait donc pas être utilisé en utilisant tcpmon, je comprends maintenant, car les éléments suivants dans la réponse renvoyée ne sont pas toujours là, mais ils ne sont pas définis. dans la définition wsdl, c'est-à-dire que minOccurs="0" n'est pas écrit. Par conséquent, si le code client généré par ce wsdl n'est pas récupéré. Si vous trouvez les éléments qui ne sont pas renvoyés, une erreur sera naturellement signalée. minOccurs="0" au wsdl, régénérez le code client, testez et réussissez.
Lors de la dernière étape, après le déploiement sur websphere, une erreur s'est produite lors de l'exécution de l'appel du webservice :
java.net.SocketException : sockets non connectés non implémentés
C'était un problème de certificat. Cela a pris plusieurs jours, puis cela s'est répété. C'était parce que le certificat parent de ce certificat manquait. Bref, si vous ne pouvez pas obtenir tous les certificats via l'hôte et le port dans Websphere, y compris les certificats utilisés. directement à l'autorité de certification. Pour les certificats, le seul moyen est d'importer le fichier .cer. La racine du problème est là : le certificat ! ! !
Les problèmes que j'ai rencontrés étaient ennuyeux, mais les récompenses n'étaient pas minimes. En quelques jours seulement, j'ai approfondi ma compréhension du webservice. J'ai honte de dire qu'avant, je ne savais utiliser axis que pour écrire le serveur, puis utilisez wsdl pour générer le client. Je ne sais pas si wsdl peut être utilisé pour générer côté serveur. Heureusement, grâce à cette opportunité, j'ai progressé et tout le monde peut m'encourager.
-