Skip to Main Content

This is an IBM Automation portal for Integration products. To view all of your ideas submitted to IBM, create and manage groups of Ideas, or create an idea explicitly set to be either visible by all (public) or visible only to you and IBM (private), use the IBM Unified Ideas Portal (

Shape the future of IBM!

We invite you to shape the future of IBM, including product roadmaps, by submitting ideas that matter to you the most. Here's how it works:

Search existing ideas

Start by searching and reviewing ideas and requests to enhance a product or service. Take a look at ideas others have posted, and add a comment, vote, or subscribe to updates on them if they matter to you. If you can't find what you are looking for,

Post your ideas
  1. Post an idea.

  2. Get feedback from the IBM team and other customers to refine your idea.

  3. Follow the idea through the IBM Ideas process.

Specific links you will want to bookmark for future use

Welcome to the IBM Ideas Portal ( - Use this site to find out additional information and details about the IBM Ideas process and statuses.

IBM Unified Ideas Portal ( - Use this site to view all of your ideas, create new ideas for any IBM product, or search for ideas across all of IBM. - Use this email to suggest enhancements to the Ideas process or request help from IBM for submitting your Ideas.

Status Not under consideration
Workspace App Connect
Created by Guest
Created on Feb 10, 2022

JSON Parser should serialize repeating objects to arrays

JSON Parser should serialize repeating objects to arrays

While the working of the JSON parser is documented to NOT DO this serialization, it is definitely the way it SHOULD work.

The currently constructed JSON is unconsumable/unusable by receivers using a wide range of available parsing libraries. (We are currently on IB10 but migrate to ACE very soon)

We see no point in producing JSON that nobody can easily parse and consume.

Idea priority Urgent
  • Admin
    Ben Thompson
    Mar 9, 2022

    RFE Review. Thank you for taking the time to submit this idea for enhancement. Unfortunately on this occasion we do not intend to take this idea forward. By the looks of the example provided in the "Additional details" section of this enhancement request, the logical tree may have been formed from XML or some other wire format, where that particular parser may well come with its own set of rules which are different to those of JSON. If you used the JSON parser then the logical tree which we generate looks like this:

    (0x01000000:Object):JSON = ( ['json' : 0x2574775a510]

    (0x01000000:Object):Data = (

    (0x01000000:Object):AllocList = (

    (0x03000000:NameValue):NoAllocs = 3 (INTEGER)

    (0x01001000:Array ):AllocGroup = (

    (0x01000000:Object):Item = (

    (0x03000000:NameValue):AllocAccount = '000000xx9814:2120xx01' (CHARACTER)

    (0x03000000:NameValue):AllocShares = 9 (INTEGER)


    (0x01000000:Object):Item = (

    (0x03000000:NameValue):AllocAccount = '000000xx9815:2120xx01' (CHARACTER)

    (0x03000000:NameValue):AllocShares = 5 (INTEGER)


    (0x01000000:Object):Item = (

    (0x03000000:NameValue):AllocAccount = '000000xx9816:2120xx01' (CHARACTER)

    (0x03000000:NameValue):AllocShares = 6 (INTEGER)






    Note in this example that AllocGroup has correctly been interpreted as a JSON array, and that each of its children has been classified correctly as a JSON Object (our parser gives each of these elements in the array the "Item" classification). This JSON logical tree is non-ambiguous and correctly serializes. Users also of course have full control if they have brought in data from XML (or other wire formats) which exhibit different rules to JSON ... so if you don't like the default beahviour for how XML trees are "converted" to JSON trees (I'm jumping to a conclusion here about how you created your logical tree) then you could also edit that within your flow under the flow developer's control. This behaviour is preferential to attempting to "guess" the intention of the XML structure - in some cases the the XML structure could deliberately have children within AllocGroup which have different structures ... and in that situation they should be interpreted as a set of different JSON objects rather than an array.

    For more detail on how to interact with JSON Objects and Arrays using mid-flow transformation nodes, in ACEv12 we have a set of new tutorials and worked examples (Help menu > Tutorial Gallery then do a search for "JSON"):

    JSON - Using a Compute node to create a JSON Object message

    JSON - Using a Compute node to create a JSON Array message

    JSON - Using a Mapping node to create a JSON Object message

    JSON - Using a Mapping node to create a JSON Array message

    JSON - Using a JavaCompute node to create a JSON Object message

    JSON - Using a JavaCompute node to create a JSON Array message