Discussion :

[Cyanatide]

Bonjour.
J'ai un Webservice entre mon code C++ et mon site en php. Mon code appelle une fonction php qui fait une requête sur ma base et me retourne l'objet renvoyé.
J'ai cependant un problème avec mes entiers: en effet, ceux ci peuvent être null dans ma base de donnée, mon webservice me renvoie alors une ligne du type :

Code :

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

<f_nb_site xsi:nil="true"/>

Dans mon Webservice, aucun problème quand je cast les int en int ou en long int. Par contre dès que j'essaye de caster mon int en LONG64, il semble bien me traduire ma valeur null par 0, mais mes champs suivant ne sont pas pris en compte...
Avez vous une idée? Pour régler ça j'ai cherché à affecter une valeur pour les xsi:nil="true", j'ai cherché un peu sur internet j'ai rien trouver...

[white_tentacle]

Dans mon Webservice, aucun problème quand je cast les int en int ou en long int. Par contre dès que j'essaye de caster mon int en LONG64, il semble bien me traduire ma valeur null par 0, mais mes champs suivant ne sont pas pris en compte...

Ça veut dire quoi, « mes champs suivants ne sont pas pris en compte » ?

Sinon, dans ton webservice, tu as la distinction 0 / valeur nulle. Ce n’est pas le cas avec un LONG64. Ça peut te poser un problème, auquel cas il faut passer par un autre type (boost::optional est ton ami).

Sinon, pense à poster un petit exemple de code qui a le problème, ça aidera à le comprendre.

[Cyanatide]

Voici un objet qui m'est retourné par le Webservice:

<f_task_id xsi:type="xsd:int">30266</f_task_id>
<f_title xsi:type="xsd:string">test</f_title>
<f_description xsi:type="xsd:string">test</f_description>
<f_display_level xsi:type="xsd:int">2</f_display_level>
<f_date_schedule xsi:type="xsd:string">2013-01-24 10:49:21</f_date_schedule>
<f_period xsi:nil="true"/> //Note: ceci est un entier Null
<f_date_hidden xsi:nil="true"/>
<f_command_externe xsi:type="xsd:string">test</f_command_externe>
<f_params_externe xsi:type="xsd:string"></_params_externe>
<f_command_interne xsi:type="xsd:string">HTTP</f_command_interne>
<f_params_interne xsi:type="xsd:string"></f_params_interne>
<f_synchronize_status xsi:type="xsd:string">OK</f_synchronize_status>

Dans mon code voici l'objet retourné est rempli sans problème jusqu'a périod qui est casté en 0. Par contre, les champs suivants (date_hidden, commande externe etc...) gardent une chaine vide. Un peu comme si la variable était mal fermée. Si je met une valeur dans mon champ f_period, ça marche jusqu’à la prochaine valeur entière null. Cela marchait pourtant avec int et long int...

[white_tentacle]

Il faut que tu montres ton code, sinon, ça va être dur de te dire d’où vient le problème.

[Cyanatide]

Bah mon code c'est juste l'appel au webservice:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
 
	T_USCOREsite_USCOREtask_USCOREexecControllerBindingProxy		site_WebService;
	TaskExec__t_USCOREsite_USCOREtask_USCOREevent				newEvent;
 
 
	soapErrorCode = site_WebService.getCommand(task_exec);
	if (soapErrorCode!=SOAP_OK)
	{
		this->m_Logger.LOG_ERROR(1401010, "SOAP error when trying to get the new command (%d)", soapErrorCode);
	}
	else
	{

Dans mon soapErrorCode, je récupère la valeur 4 qui correspond à TYPE_ERROR.
Donc c'est bien dans mon objet soap que ça cafouille.

Aussi, mon programme tourne sur une machine Windows 32bits, mais normalement ça ne poste pas problème avec des entier de 64bits, si?
Et je compile mon code en 32 bits, ça vaut le coup que j'essaye de le compiler en 64?

[white_tentacle]

TYPE_ERROR ce n’est pas étonnant si tu passes un entier 64 bits là où le webservice définit un entier nullable : ce n’est pas la même chose.

Le fait que ça marche avec un int : probablement un bug.

Après, quelqu’un qui connaît mieux gsoap pourra me corriger si je dis une connerie, mais :
- ton wsdl définit l’interface d’une fonction
- tu dois mapper cette interface avec des types compatibles. La doc de gsoap doit te préciser ce qu’elle attend comme types compatibles. Normalement il y a un utilitaire qui te génère le .h à partir du wsdl.
- si tu ne mappes pas correctement, pas étonnant que ça fasse une erreur.

Sinon :

Code :

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

1
2
	T_USCOREsite_USCOREtask_USCOREexecControllerBindingProxy		site_WebService;
	TaskExec__t_USCOREsite_USCOREtask_USCOREevent				newEvent;

Le nom de ces types fait peur . Ce ne serait pas plutôt des types internes pas destinés à être utilisés directement ? )

[Cyanatide]

- tu dois mapper cette interface avec des types compatibles. La doc de gsoap doit te préciser ce qu’elle attend comme types compatibles. Normalement il y a un utilitaire qui te génère le .h à partir du wsdl.

Oui, oui, c'est bien ce que je fais, et pour le mappage, je rajoute uniquement dans mon typemap.dat

Code :

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

1
2
3
4
5
6
 
#	Remember: type bindings are given on a single line (use \ when needed).
#	Here is an example binding for the XSD int type:
 
# xsd__int	= | int
xsd__int	= | LONG64

TYPE_ERROR ce n’est pas étonnant si tu passes un entier 64 bits là où le webservice définit un entier nullable : ce n’est pas la même chose.

Je suis bien d'accord, d'ou mon idée de départ: redéfinir une valeur null par zéro ( ce qu'il fait pour un int ou un long, et même pour long64 mais il semble mal le faire puisqu'il n'arrive pas a gérer la suite). Mais du coup ce serai plutôt une question de configuration de gsoap.