ESI response xml is generated with wrong language specific formats

[JD_8606834]

Dear all,

when a ESI xml is generated, the number and date formats are always following the language that the user has chosen in the UI. That means e. g.

English : 0.000

German: 0,00 (Comma instead of a dot)

Same for date formats.

This is very annoying because the connected systems are getting the values in the wrong formats and this is then causing errors..

Is there any way to confiqure that behaviour in order to get date and numeric values always in english

format?

We are using Version 11.1.

Thanks,

Juergen

[Florent]

Hi,

have you looked at the PTC KB ? There are few articles about ESI and locale formatting, including

CS223836: Unit of BOMComponent section in ESI response xml file is giving the Display value and not the Key as it is for Part section DefaultUnit when a publishing a BOM to ESI

CS277355: How to change the date format in the ESI response file in Windchill Enterprise Systems Integration 

There is also a dedicated section in Windchill Help Center:

Internationalization Considerations

[JD_8606834]

Hi Florent,

I will have a look, thanks a lot.

Best,

Jürgen

[d_graham · Accepted solution]

@JD_8606834 , hi

Are you using the OOTB "Release to Manufacture" workflow or a copy of it?

If yes, take a look at the "Release" expression robot.

You can comment out the existing line below

java.util.Locale lcl = wt.util.LocaleUtilities.makeLocale(locale);

and instead do something like this to always be English or whatever.

java.util.Locale lcl = java.util.Locale.ENGLISH;

or, and I like this better, add the following to set the OOTB process String variable "locale" and the Locale to English.

I like this the best as it keeps the String variable and the Locale in synch in the event the variable is used anywhere else in the workflow.  A query of the dB shows locale is not used elsewhere in the OOTB workflow but you might be.

locale = java.util.Locale.ENGLISH.toString();

java.util.Locale lcl = java.util.Locale.forLanguageTag(locale);

FYI, I did not test this so please test and let me know if this fixes the issue.

David

[JD_8606834]

Hi David,

sorry for the late reply, but we were busy and we couldn't implement your solution immediately.

But it seems, that your advice fixed the problem.

We are still testing but it looks good so far.

So thank you very much, that saved us a lot of time.

Thanks,

Jürgen