Hi,
I'm having problems with the JsonFragmenter. When I supply de HTTPCaller output to the Defragmenter some values are adjusted. I can't explain why.
Anyone with a solution?
Regards,
Eddy
FME Information
Edition: FME Database Edition (floating)
Version: FME(R) 2018.1.1.2 (20190121 - Build 18586 - WIN32)
Best answer by nielsgerrits
Hi Niels, that's correct. The HTTPCaller delivers a body containing an array of rows. The Fragmenter has to separate thw rows and that exactly what happens, however in the "raw" HTTPCaller output the returned value is still correct ( 45,98000....) and after fragmentation the value has changed in 44.153....
I can't understand why this happens en where this transition is performed.
It probably is an issue which is fixed in a later version. :-( You can always check with Safe if this is the case. I'm afraid you need to upgrade to dodge it. Can you attach this workspace? I can then test if the issue goes away if I run it in 2019.
+60Not sure I understand your issue. You highlighted a floating point value which looks like a part of the HTTPCaller response?
Not sure I understand your issue. You highlighted a floating point value which looks like a part of the HTTPCaller response?
Hi Niels, that's correct. The HTTPCaller delivers a body containing an array of rows. The Fragmenter has to separate thw rows and that exactly what happens, however in the "raw" HTTPCaller output the returned value is still correct ( 45,98000....) and after fragmentation the value has changed in 44.153....
I can't understand why this happens en where this transition is performed.
+60Hi Niels, that's correct. The HTTPCaller delivers a body containing an array of rows. The Fragmenter has to separate thw rows and that exactly what happens, however in the "raw" HTTPCaller output the returned value is still correct ( 45,98000....) and after fragmentation the value has changed in 44.153....
I can't understand why this happens en where this transition is performed.
Ah I understand. I tried to reproduce your issue in 2019.1 but I just works as expected, returning 45.98 and 9.6.
Can you try to reproduce your issue with my sample?
[
{
"id" : "1",
"attribute1" : 45.9800000000000000000,
"attribute2" : 9.6000000000000000000
},
{
"id" : "2",
"attribute1" : 45.9800000000000000000,
"attribute2" : 9.6000000000000000000
}
]
Hi Niels, that's correct. The HTTPCaller delivers a body containing an array of rows. The Fragmenter has to separate thw rows and that exactly what happens, however in the "raw" HTTPCaller output the returned value is still correct ( 45,98000....) and after fragmentation the value has changed in 44.153....
I can't understand why this happens en where this transition is performed.
Thnx, that's a good suggestion. The data now directly comes from an API call, so I've to re-arranged some things to build this simulation...
Hi Niels, that's correct. The HTTPCaller delivers a body containing an array of rows. The Fragmenter has to separate thw rows and that exactly what happens, however in the "raw" HTTPCaller output the returned value is still correct ( 45,98000....) and after fragmentation the value has changed in 44.153....
I can't understand why this happens en where this transition is performed.
The test data shows the same errorneous translation.... any thoughts on updating de JSONFragmenter?
+60Hi Niels, that's correct. The HTTPCaller delivers a body containing an array of rows. The Fragmenter has to separate thw rows and that exactly what happens, however in the "raw" HTTPCaller output the returned value is still correct ( 45,98000....) and after fragmentation the value has changed in 44.153....
I can't understand why this happens en where this transition is performed.
It probably is an issue which is fixed in a later version. :-( You can always check with Safe if this is the case. I'm afraid you need to upgrade to dodge it. Can you attach this workspace? I can then test if the issue goes away if I run it in 2019.
Hi Niels, that's correct. The HTTPCaller delivers a body containing an array of rows. The Fragmenter has to separate thw rows and that exactly what happens, however in the "raw" HTTPCaller output the returned value is still correct ( 45,98000....) and after fragmentation the value has changed in 44.153....
I can't understand why this happens en where this transition is performed.
Thnx! I can't check this with Safe. We just started migrating some ETL jobs from Talend to FME. I think it's probably better to upgrade to FME 2019 first.
Thanks a lot!
+44Hi Niels, that's correct. The HTTPCaller delivers a body containing an array of rows. The Fragmenter has to separate thw rows and that exactly what happens, however in the "raw" HTTPCaller output the returned value is still correct ( 45,98000....) and after fragmentation the value has changed in 44.153....
I can't understand why this happens en where this transition is performed.
I can recreate the issue in FME 2018 Build 18520, the exact same workspace returns the expected output in FME 2019 Build 19823.
If upgrading isn't possible, you could use python to fragment the JSON
