invoking a web service from vast601 (cast Problem)

[mariocarrera]

Hi!
For many day the services was out of service.
Today I try the both methos work well.
The only one is that the service retur a Float but from vast I get an Integer!
If I put 'germany' and 'usa' I get 6714 insted 0.6714 and
if I put 'usa' and 'germany' I get 14871 instead 1.4871

Thank you
Mario Carrera

[tc]

Hello,

I just tried it and got back a float inspector with 0.6749 as the exchange rate for usa and germany.

--tc

[mariocarrera]

Hi I retry, but the returns is the same, a smallInteger not a float.

This is my System Transcript
I execute the method, on the bottom is the result.
any ideas?
Thank you.

VisualAge Smalltalk Enterprise, V6.0.1
(C) Copyright IBM Corporation, 1994, 2002. All Rights Reserved.
VM Timestamp: 4.0,(NC) 10/28/2002


[
| aTimestamp aPort aContainer aServiceCollection aService aStream result |
aContainer := SstWSContainer containerNamed: 'ContainerValuta' ifNone: [
SstWSContainer createContainerNamed: 'ContainerValuta'
].
aServiceCollection := aContainer deploy: 'http://www.xmethods.net/sd/2001/CurrencyExchangeService.wsdl'.
aService := aServiceCollection first.
Transcript cr; show: (aService invoke: 'getRate' withArguments: #('GERMANY' 'USA')) printString.
] fork.
6738[/img]

[tc]

Hello,

I copied and ran your your code in a workspace and 0.6724 was printed.

I recommend you start with a fresh, virgin image and load the web services.

--tc

[mariocarrera]

Hi
This is a vergin image, no my working one. I loaded only the web services.
If you used the same version of VAST (6.0.1). I dont know wat is wrong.
I am in Italy and whe use the coma as decimal point in some cases we need to do something to work with float, as VAST use always the (.) as decimal point. Do you think there is something else? who or wat converts or get the reult from services?

Thanks
Mario

[marten]

Hi
This is a vergin image, no my working one. I loaded only the web services.
If you used the same version of VAST (6.0.1). I dont know wat is wrong.
I am in Italy and whe use the coma as decimal point in some cases we need to do something to work with float, as VAST use always the (.) as decimal point. Do you think there is something else? who or wat converts or get the reult from services?

Thanks
Mario

I've tested it with 6.03 image and 7.01 image and I get your results in my Transcript. But the correct result is returned to VA:

<Result xsi:type=''xsd:float''>0.6731</Result>


Marten

[marten]

I've tested it with 6.03 image and 7.01 image and I get your results in my Transcript. But the correct result is returned to VA:

<Result xsi:type=''xsd:float''>0.6731</Result>


Marten

The reason is simple: the instance of SstDoapInputDeserializer creates an instance of AbtTypeConverter and then asks Float class >>abtXmlFromString: , which is actually done by String>>abtAsNumber - which uses the client-local locale ... and there everything goes wrong (the method first removes the locale thousand separator (in the client locale a $. ) - actually removing the decimal point (in the answer locale also a $.))

I've never worked with WebServices - is the representation of Floats defined ????

Within

[marten]

I've never worked with WebServices - is the representation of Floats defined ????

Within

To answer myself - the specification

"
....
The decimal separator is always a point (.), and no thousands separator may be added.
...
"

[mariocarrera]

Thank you.
I will rewrite the method abrAsNumber, we use "," as decimal separator and "." as thousands separator.

[tc]

> The decimal separator is always a point (.), and no thousands
> separator may be added.

You are saying if the service is invoked from Europe, for example, a number is returned in the form of ',6731' rather than '.6731'?

--tc

[mariocarrera]

No, the service returns '1.4806' (actualy I am in Italy ). So the proble is like you say that the method (abtAsNumber) first removes the thousand separator (.) and then everything goes wrong.

Mario Carrera

[marten]

> The decimal separator is always a point (.), and no thousands
> separator may be added.

You are saying if the service is invoked from Europe, for example, a number is returned in the form of ',6731' rather than '.6731'?

--tc

No, this was not said - I would say, that we have found a bug within VAST - nothing more. At this point no localized method has to be used. Perhaps this may also happen with other data types (Decimal ?). On the other hand I'm surprised to see, that this bug has not been found over the years ... or are there no users of WebServices here in Europe using VA ....

Marten

[marten]

Thank you.
I will rewrite the method abrAsNumber, we use "," as decimal separator and "." as thousands separator.

abtAsNumber is used in several locations of the system ... changing such a base method may lead to problems. You should perhaps look at the class AbtTypeConverter how it works.

As a first step I would add a method Float>>abtXmlFromString: and do the actual conversion from there.

Marten

[tc]

Hello,

So, the service is returning '.6731' but ST thinks it is working with European-ized numbers?

If that is true, I am not sure why it is an ST bug. If a person, in Europe, entered '1.700' then it should be read as 'one thousand seven hundred' by ST.

It seems like it falls more in the category of a system mis-match?

--tc

[marten]

Hello,

So, the service is returning '.6731' but ST thinks it is working with European-ized numbers?

If that is true, I am not sure why it is an ST bug. If a person, in Europe, entered '1.700' then it should be read as 'one thousand seven hundred' by ST.

It seems like it falls more in the category of a system mis-match?

--tc

No, within the XML specification for floats there seems (as I said - I'm not an expert there) to be no place for locales or stuff like this. floats are represented by the US locale worldwide - point.

Computers in Europe (or anywhere else) are configured for other locales (via their operating system) - meaning, that they interpret a US-locale float using the local locale - which results into wrong results.

I do not know, how the VA will create such a XML stream (if it would be the server) and if it considers locales when printing the float. If this problem is also present when writing the XML stream a German WebService might have problems with US clients ....

... therefore when creating or reading this XML stream one has to use non localized methods ...

This has nothing to do with system mis-match - its a bug within the VAST XML logic.

But again: I'm not an expert in this area. I read the initial message, was interested and just looked in this WebService area, the internet and within VASmalltalk and this is my conclusion.


Marten