| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| JSON integer value converted to scientific notation |
« View previous topic :: View next topic » |
| Author |
Message
|
| rekarm01 |
 Posted: Sun Nov 05, 2017 2:42 pm Post subject: Re: JSON integer value converted to scientific notation |
 |
|
Grand Master
Joined: 25 Jun 2008
Posts: 1415
|
| souciance wrote: |
| rekarm01 wrote: |
| Use Trace nodes to confirm where the data types of the relevant input and output fields might be changing from INTEGER to FLOAT, ..., looking more closely at the code that creates the output fields .... |
|
So, ... how's that going? What did the Trace nodes reveal about the data types of the input and output fields? If, for example, either the input field or the output field were a FLOAT, then that would explain why the output message would format the output value using exponential notation. Any program that assigns an INTEGER value to a FLOAT variable is going to convert the value, regardless of any "decimal points, or anything like that". The next question would then be why the message flow had created the input or output field as a FLOAT.
| souciance wrote: |
| Well if it isn't the JSON parser, then what could it be? |
You tell us. So far, aside from a possibly unnecessary call to FIELDVALUE() in a "generic loop", you have not provided any information about how the message flow copies data from an input field to an output field, certainly not enough for anyone else to reproduce the problem. Does the message flow use ESQL SET statements, CREATE statements, Mapping nodes, other non-ESQL nodes, or something else? Are there any JSON schemas or Swagger documents involved?
| souciance wrote: |
| The user trace showed the data to be an integer when the JSON parser first receives the message. |
Since the problem seems to occur after that point, that might be a better place to look.
| souciance wrote: |
| There should therefor be no need to change the format after a FIELDVALUE. |
The message flow stores INTEGER or FLOAT values internally using a binary format. The JSON parser needs to change the format when converting numeric data from text to binary while parsing the input, and again when converting from binary to text while serializing the output. Whether the final output format matches the initial input format depends on the message flow. |
|
| Back to top |
|
 |
| souciance |
| Posted: Sun Nov 05, 2017 11:42 pm Post subject: Re: JSON integer value converted to scientific notation |
|
|
Disciple
Joined: 29 Jun 2010
Posts: 169
|
| rekarm01 wrote: |
| souciance wrote: |
| rekarm01 wrote: |
| Use Trace nodes to confirm where the data types of the relevant input and output fields might be changing from INTEGER to FLOAT, ..., looking more closely at the code that creates the output fields .... |
|
So, ... how's that going? What did the Trace nodes reveal about the data types of the input and output fields? If, for example, either the input field or the output field were a FLOAT, then that would explain why the output message would format the output value using exponential notation. Any program that assigns an INTEGER value to a FLOAT variable is going to convert the value, regardless of any "decimal points, or anything like that". The next question would then be why the message flow had created the input or output field as a FLOAT.
| souciance wrote: |
| Well if it isn't the JSON parser, then what could it be? |
You tell us. So far, aside from a possibly unnecessary call to FIELDVALUE() in a "generic loop", you have not provided any information about how the message flow copies data from an input field to an output field, certainly not enough for anyone else to reproduce the problem. Does the message flow use ESQL SET statements, CREATE statements, Mapping nodes, other non-ESQL nodes, or something else? Are there any JSON schemas or Swagger documents involved?
| souciance wrote: |
| The user trace showed the data to be an integer when the JSON parser first receives the message. |
Since the problem seems to occur after that point, that might be a better place to look.
| souciance wrote: |
| There should therefor be no need to change the format after a FIELDVALUE. |
The message flow stores INTEGER or FLOAT values internally using a binary format. The JSON parser needs to change the format when converting numeric data from text to binary while parsing the input, and again when converting from binary to text while serializing the output. Whether the final output format matches the initial input format depends on the message flow. |
I'll provide more details on this shortly. |
|
| Back to top |
|
|
| souciance |
| Posted: Mon Mar 26, 2018 11:01 am Post subject: |
|
|
Disciple
Joined: 29 Jun 2010
Posts: 169
|
| Found the issue. Values were saved to a CHARACTER field and that field's value was saved to the output. The conversion caused the parser to transform the value to scientific notation. Once we took the input as is without saving it to CHARACTER field we got the outut value to look similar to the input. |
|
| Back to top |
|
|
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
