API Connect

API Connect

Join this online group to communicate across IBM product users and experts by sharing advice and best practices with peers and staying up to date regarding product enhancements.

 View Only
Back to discussions
Expand all | Collapse all

Error mapping a number type field

  • 1.  Error mapping a number type field

    Posted Wed July 17, 2024 10:17 PM

    Hi team. 

    I have a problem with a mapping. 

    In the mapping node I have a field named "Id" which I need to map to a 20-digit number, but I am getting the wrong mapping, starting with the 17th digit the response I am getting is a rounded number. 

    - Example: the JSON of the request has "Id" with the following value: 24015100010011087 

    and when converting to XML I am getting the following value: 24015100010011090 

    - I have used the following data types in the api swagger without obtaining the expected results: 

     

     

     

     

    - The only option that has worked is the "string" type, however in the tests, the field reads the value when it is sent between quotes "" and without them. 

    - I am looking to make a mapping that obtains the value that is being sent and that does not accept another input method, if the String field is defined, it only accepts data between quotes, if the field is defined as number it only accepts data without quotes. How can I implement it within the mapping node? 

    Thank you 



    ------------------------------
    JIMMY VIVAS PERILLA
    ------------------------------


  • 2.  RE: Error mapping a number type field

    Posted Thu July 18, 2024 09:14 AM

    Hi Jimmy,
    This is a long known issue and is not a problem with the map policy, but with JavaScript and large numbers where numbers over 16 digits (actually 53 bits) are rounded when a JSON payload is parsed using JSON.parse, which of course API Connect product definitely does do for JSON data.  In searching the internet, I did find this interesting article https://2ality.com/2022/11/json-parse-with-source.html that discusses a November 2022 ECMAScript proposal concerning this issue, but that of course isn't helping you now.  I found it interesting that the article cited Twitter's documentation that their id properties are returned in both a numeric and string data type specifically due to this issue.  Bottom line, you're running into a current JavaScript restriction and your only workaround would be to provide the long numeric data as a string.  Sorry I don't have better news.

    Best Regards,
    Steve Linn



    ------------------------------
    Steve Linn
    Senior Consulting I/T Specialist
    IBM
    ------------------------------

    Original Message