User Regional Settings vs NAV2009 Web Service problem

JAJ · 2011-12-22

Hi everybody!

I'm facing a problem to validate Dates and Decimals format from users with Regional Settings different than Web Service Regional Settings.
The users in our system could have several Regional Settings (ES, FR, BG, EN, etc) and they are sending information to my NAV2009 WS which is on a server with Regional Settings = EN. So when a user send an amount like 1.000 (a thousand in ES), the EVALUATE in the WS validates it as 1,00 (one in EN).
Same problem with Dates that could be DMY or YMD, and on my WS validates MDY.

I tried the User Personalization solution that is related to other topic in here, but it didn't work.
The NAV version is NAV 2009 R2 (6.00.32900).

How can I solve this problem?
Had it happen this problem to some of you?

Many thanks in advance!!

chethanht · 2011-12-23

The post viewtopic.php?f=32&t=38402 discusses about similar confusion around date format. Please take a look.

ldreamsl · 2012-01-03

I too am still looking for a solution to the problem.
The problem is that from hotfix 32558, the web service works only in English and no longer consider the "User table Personalization (2000000073)".

Is there a solution?

mohana_cse06 · 2012-01-03

Check whether this link helps or not..
http://blogs.msdn.com/b/nav/archive/2011/10/03/en-us-as-web-services-default-language.aspx

ldreamsl · 2012-01-03

mohana_cse06 wrote:

Check whether this link helps or not..
http://blogs.msdn.com/b/nav/archive/2011/10/03/en-us-as-web-services-default-language.aspx

Yes, the problem is just that.
The web service recognizes and responds only to EN-US!

Is there a solution to this problem?

Sog · 2012-01-11

Why don't you use language independent formatted data?
Or is modifying code on the sending party side a problem?
For Date you can use the xml-formatted date.
For decimals you can check if the point comes before the comma.
And if it does, you know what the thousand seperator is, remove it, than replace the comma and point with the decimal seperator of the system. OR remove all seperators, send it as a string formatted as iiiiiiiiiiiiiiiddddd with i the integer part and d the decimal part: this way 6.022,56 and 6,022.56 would be :
check:

if strpos(amount,'.') <>0 and strpos(amount,',') <> 0 then 
  if strpos(amount,'.')>strpos(amount,',') then
      delstr(amount,'.') else delstr(amount,',')

Would turn out 6022,56|6022.56. Then you replace point and comma with the local decimal seperator (always . in code)
or formatted 6.022,56 would be 602256000 (5 decimal points in this example)

Vjeko · 2012-01-11

Why are you doing EVALUATE in the first place? If the variable you are passing to WS is known to be date, then you should not pass it as Text. In that case, the format doesn't matter, because the variable will be stongly typed at caller end as well, and you will not have any issues with regional settings on client side, or the fact that WS always uses EN-US.

Another approach, which is ugly, but will work, is to do something like this:

IF (NOT GUIALLOWED) AND ISSERVICETIER THEN
  GLOBALLANGUAGE := xyz;

in your CompanyOpen trigger in Codeunit 1. You can make it smart and make it read from User Personalization table, or somewhere else.

mdPartnerNL · 2012-01-11

Ok, so when you have used this update. All current webservices will change to US and will stop working if the connecting application still sends NL dates? What then about option fields? Im not sure what the implecations are?

Vjeko · 2012-01-11

That's not true. This update will only affect strings (texts). If you send a string over to NAV, and that string contains e.g. a date, and then you want to EVALUATE that into a date field, NAV will presume it was in EN-US format. However, if you have a date field, and you populate it with a date value, then call the web service, it will work just as nice as it worked before this update.

The same goes for dates, integers, decimals, options... As long as you are strongly typed on NAV side (as opposed to passing texts around), you are on the safe side.

mdPartnerNL · 2012-01-11

Vjeko wrote:

That's not true. This update will only affect strings (texts). If you send a string over to NAV, and that string contains e.g. a date, and then you want to EVALUATE that into a date field, NAV will presume it was in EN-US format. However, if you have a date field, and you populate it with a date value, then call the web service, it will work just as nice as it worked before this update.

The same goes for dates, integers, decimals, options... As long as you are strongly typed on NAV side (as opposed to passing texts around), you are on the safe side.

Ok thanks for the info. Was a bit scared of the new hotfix. :-#

JAJ · 2012-01-12

Vjeko wrote:
Why are you doing EVALUATE in the first place? If the variable you are passing to WS is known to be date, then you should not pass it as Text. In that case, the format doesn't matter, because the variable will be stongly typed at caller end as well, and you will not have any issues with regional settings on client side, or the fact that WS always uses EN-US.

Another approach, which is ugly, but will work, is to do something like this:
IF (NOT GUIALLOWED) AND ISSERVICETIER THEN
  GLOBALLANGUAGE := xyz;
in your CompanyOpen trigger in Codeunit 1. You can make it smart and make it read from User Personalization table, or somewhere else.

Many thanks for the response, but is not worthy for me...
I tried to use GLOBALLANGUAGE but it doesn't work.
I agree about the strongly typed is the best we can use, but I can't use it in my development. I'm trying to send an XML to a NAV WS, but the NAV WS does not allow complex types as parameters, so I use a Bigtext in order to send the "XML" as valid type of parameter. Then I cannot type the values in the WS because everything is a text. I use a CDATA in order to pass the XML as a string.

WS Function:
ImportLiquidation(parXML : BigText) : Text[1024]
...

How can I validate the WSDL when i receive an XML as bigtext format?

Find attached part of my NAV WSDL.

Vjeko · 2012-01-12

JAJ wrote:

Many thanks for the response, but is not worthy for me...
I tried to use GLOBALLANGUAGE but it doesn't work.
I agree about the strongly typed is the best we can use, but I can't use it in my development. I'm trying to send an XML to a NAV WS, but the NAV WS does not allow complex types as parameters, so I use a Bigtext in order to send the "XML" as valid type of parameter. Then I cannot type the values in the WS because everything is a text. I use a CDATA in order to pass the XML as a string.

WS Function:
ImportLiquidation(parXML : BigText) : Text[1024]
...

How can I validate the WSDL when i receive an XML as bigtext format?

Find attached part of my NAV WSDL.

Are you using NAV 2009 R2? If so, you could use .NET interop here. Have an object which has strongly typed data - serialize it as XML on client side, pass that XML to a Web service, then deserialize it from XML using .NET interop, and you have your strongly typed data back again, without worrying about regional settings.

JAJ · 2012-01-24

Vjeko wrote:

Are you using NAV 2009 R2? If so, you could use .NET interop here. Have an object which has strongly typed data - serialize it as XML on client side, pass that XML to a Web service, then deserialize it from XML using .NET interop, and you have your strongly typed data back again, without worrying about regional settings.

Thanks a lot for your reponse Vjeko.
Yes, I'm using Dynamics NAV R2.
I agree with your solution. I'm going to implement it. But may be I need a bit help with the .NET object that I have to use and the way to use it.(But not the use .NET interoperability in Dynamics NAV)
Could you show me a little example,please?

Thanks in advance.

Vjeko · 2012-02-14

JAJ wrote:

Thanks a lot for your reponse Vjeko.
Yes, I'm using Dynamics NAV R2.
I agree with your solution. I'm going to implement it. But may be I need a bit help with the .NET object that I have to use and the way to use it.(But not the use .NET interoperability in Dynamics NAV)
Could you show me a little example,please?

Thanks in advance.

JAJ, sorry - I was busy lately, so I've completelly missed this extra question of yours. Did you manage to solve it? Please check in Mibuso download sections, and look for downloads of sessions from NAV Tech Days conference - there is my session on .NET interop with a ton of examples. Also, you have a post or two about that on my blog, search a bit. If you still don't know what exactly you need to do, then reply here, and I'll make a short example to help you.

mohana_cse06 · 2012-02-14

Did you check this?
http://blogs.msdn.com/b/nav/archive/2012/02/06/ws-on-a-multilanguage-environment.aspx

JAJ · 2012-02-21

Vjeko wrote:

JAJ wrote:

Thanks a lot for your reponse Vjeko.
Yes, I'm using Dynamics NAV R2.
I agree with your solution. I'm going to implement it. But may be I need a bit help with the .NET object that I have to use and the way to use it.(But not the use .NET interoperability in Dynamics NAV)
Could you show me a little example,please?

Thanks in advance.

JAJ, sorry - I was busy lately, so I've completelly missed this extra question of yours. Did you manage to solve it? Please check in Mibuso download sections, and look for downloads of sessions from NAV Tech Days conference - there is my session on .NET interop with a ton of examples. Also, you have a post or two about that on my blog, search a bit. If you still don't know what exactly you need to do, then reply here, and I'll make a short example to help you.

Hi Vjeko, Thanks for your response.
I know more or less how to use .NET interoperability (I was in NAV Tech Days

) but I tried to implement your solution but I need help with the serialize the xml. Could you show me a short example of xml serialization in NAV .NET Interoperability.

A lot of thanks!!

JAJ · 2012-02-21

mohana_cse06 wrote:

Did you check this?
http://blogs.msdn.com/b/nav/archive/2012/02/06/ws-on-a-multilanguage-environment.aspx

Thanks Mohana,

I saw this hotfix, and it is related with my issue but in our case we have users in 9 countries and every user can have differents Regional Settings and this not solve our problem.

Regards.

Vjeko · 2012-02-22

JAJ wrote:

I know more or less how to use .NET interoperability (I was in NAV Tech Days ) but I tried to implement your solution but I need help with the serialize the xml. Could you show me a short example of xml serialization in NAV .NET Interoperability.

Here you go: http://navigateintosuccess.com/blog/pas ... b-services

I hope it helps.

ajhvdb · 2012-02-22

Vjeko wrote:

Here you go: http://navigateintosuccess.com/blog/pas ... b-services

I hope it helps.

Nice blog and example download. Really helps

I read somewhere that the only problem left with this is that some characters in the xml text nodes are not converted correctly. The only way to solve this is to convert it to base64 and back?

BTW:
I can repeat the question on the blog too if you want?

Vjeko · 2012-02-23

Yes, sure, you can always repeat the question on the blog as well. Do you need me to give you an example of converting to Base64 and back?

ajhvdb · 2012-02-28

Found NAV code for this in viewtopic.php?f=23&t=5735

So I guess this is the best way to prevent character conversion. May be even better to use a small .net project which does the conversion..

Howdy, Stranger!

Quick Links

Categories

User Regional Settings vs NAV2009 Web Service problem

Comments