cancel
Showing results for 
Search instead for 
Did you mean: 

Agentry Work Manager for Maximo - Meter Reading above 1000 problem

Former Member
0 Kudos

Hello,

Firstly, I'm sorry if this is being posted in the wrong place, I'm not completely familiar with the SAP community network since it changed over from the Syclo resource center.

My problem: When a user enters a new reading for a meter above 1000, such as 2540, the value is sent to Maximo as 2.54.  I know this functionality is because it is using the system locale for Java to control the number, but I have no idea why it is changing the value from thousands to a decimal single digit number.

The Java is as follows:

Variable declaration:

     double dReading = _user.getDouble("transaction.reading");

Setting the variable to entered value:

     setValueNoValidationAccess(deployedMeterRemote, "NEWREADING", NumberFormat.getInstance().format(dReading));

I have, unsuccessfully, tried to just send the value as a string instead.

String dReading = _user.getString("transaction.reading");

setValueNoValidationAccess(deployedMeterRemote, "NEWREADING", dReading);

The note above the variables states:

* CDC: 11-07-11 internationalization of the reading entry, changed the old string value for a double, the user's java locale should help translate the double in the proper way for their locale.


So my question is, is there any way to stop Java translating the double/string value?  The user will never enter a value such as 1,500 (1500) and for decimal numbers would write 1.5


Any ideas?

Best regards,

Gary

Accepted Solutions (0)

Answers (1)

Answers (1)

jason_latko
Active Contributor
0 Kudos

Gary,

You found the right place to ask this.  CDC in that code comment is Cliff Carter who works in my development group here at SAP.  I can get him involved if needed.

Ok, so what locale are you working with?  Are you in Europe or USA?  Europe uses a decimal point as their thousands separator, so my guess is that the number would normally be represented as 2,540 in USA but is being changed to 2.54 because of a European locale?

What happened when you stored your string dReading value?  Is it formatted correctly at that point after doing the _user.getString("transaction.reading"); ?  You said setting this was unsuccessful.  How so?  I would have thought that your idea was the correct approach.

Jason Latko - Senior Product Developer at SAP

Former Member
0 Kudos

Hi Jason,

I'm in Europe (Norway specifically).  All of our numbers in maximo are represented without commas to separate the thousands etc, so 2540.  But our decimals are represented as 2,54.

2.540,30 is how a thousands number (with decimals) looks in a default Norwegian locale, if that sheds any light on the problem.

When I stored the variable as a string the exact same formatting was applied, I really wasn't expecting it to format the number when saved as a string but I'm wondering if the formatting is done automatticaly when the number is written in or something.  Even though a number shows as, for example, 1250 in Syclo. 

I have just tested then to make absolutely sure, but aye, the value is changed regardless of if the variable is stored as a string or a double.  I tried the value 1250, checked the meter in maximo and it held the value 1,25

The formatting is being done before it reaches maximo though.  Because if I have (in maximo) set a new reading as 5, then (after synchronizing) trying to add a new reading via syclo with the value 1250 during the next sync I get the error:

Sending EditMeterReading...

com.syclo.agentry.BusinessLogicException: meter: lowReading

But the validation for syclo isn't set off (ensuring a number is higher than the last reading) because... well 1250 is higher than 5 of course.

I really don't understand what is going on between entering the value, it being saved, and being sent to maximo.

Thanks again for the help!

Regards,

Gary

jason_latko
Active Contributor
0 Kudos

Gary,

I would like you to try debugging the java during runtime when you are sending up one of your meter readings.  Are you familiar with the process in Eclipse?

I am curious what the state of the variable is immediately after doing the  String dReading = _user.getString("transaction.reading");

Set a breakpoint on that line and single-step through it, then look at the variable.  Is it already in the incorrect state at this point?

Is the reading field in the Agentry transaction a Decimal data type?  What about the object property that the transaction property is tied to?

What client platform are you using?  As a test, try using the ATE (Agentry Test Environment).  Using that tool, you can inspect the object and transaction after taking the meter reading before transmit and see how it is stored.

Try these things are let me know what you find.

Jason Latko - Senior Product Developer at SAP

Former Member
0 Kudos

Hello again Jason,

The customer decided to take the solution into production without fixing the error first.  After some testing in the production environment it seems that the error is not present.  They are using iPad's so it most likely is still something to do with the locale of the java that causes problems with the PC client.

Either way since the error isn't present in the production environment using iPad's I will not be trying to find the solution to this problem. 

Thanks again for the assistance!