Working with JSON in Mendix

One of the best parts about Mendix is that it is especially useful for integrating with other systems. Building integrations is fast and easy for industry standards such as REST and Web services.

Lennart Spaans
Mendix Community
Published in
6 min readApr 18, 2023


Working with JSON in Mendix — Banner Image: The symbol for JSON on an orange background
Working with JSON in Mendix - Banner Image

I won’t go into detail about how to set up or connect to these services since Mendix provides excellent technical documentation on the subject. Instead, allow me to share how I solved a problem I recently encountered with a JSON structure while connecting to another system’s API.

JSON (JavaScript Object Notation) is a lightweight data-interchange format. It is easy for humans to read and write. It is easy for machines to parse and generate. —

In short, easy to read for machines and humans and basically comprises a collection of key/value pairs. e.g:

{"firstName": "John", "lastName": "Doe"}

Sounds easy enough so far, right?

The way Mendix handles these key/value pairs is to visualize the data and its relations by creating a domain model containing auto-generated entities holding attributes that correspond to the name and type of value of the key/value pair. The example above would result in the following JSON object, with firstName and lastName included as string attributes.

Auto-generated non-persistent entity

This works very well since most APIs have a clear definition of exactly what a consuming application can expect to receive. The message is well-defined and it is certain that when I decide to look up the values of firstName and lastName, they will contain a string value. Any message that is received after mapping it to the domain model can now be processed in the same way since the value type is known, and the key is fixed.

But what if the keys change? Or new keys are generated by the source system for every message? Well, our domain model won’t contain the necessary attributes, resulting in an error to map the corresponding values. A new domain model will need to be generated in order to be able to process the data again.

Consider the following JSON message:

"2023-02-22T09:30:00.000Z": 758,
"2023-02-22T09:45:00.000Z": 774,
"2023-02-22T10:00:00.000Z": 776,
"2023-02-22T10:15:00.000Z": 751,
"2023-02-22T10:30:00.000Z": 791,
"2023-02-22T10:45:00.000Z": 789,
"2023-02-22T11:00:00.000Z": 775,
"2023-02-22T11:15:00.000Z": 797

Here we see a JSON object where the attributes all have a dateTime as key and an integer as value. In this case, it’s possible to generate a domain model in Mendix based upon this JSON structure, but it won’t work for any future messages, since the key names continuously change with every passing minute.

This particular example message provides information to a travel company about the number of people that have passed through a portal during a particular timeslot so that the source system can generate a nice and fancy graph based upon it. However, the data is wrapped in a single object and not in an array of objects. This means that the more data points we have, the larger the object will be. To handle this situation, we need to process the data above into a list that should look something like this example below:

"Time": "2023-02-22T15:15:00.0000000Z",
"Pax": 482
"Time": "2023-02-22T15:30:00.0000000Z",
"Pax": 508

For each attribute in the original JSON structure, we need to create a new object and add it to the list. The original key will become a value (“Time”), and the original value will receive a new key (“Pax”). This way, we can apply import mapping and generate a domain model that will stand the test of time.

Restructuring the data

If you think there is only one way to deal with this situation, you are wrong. Being a developer is a creative profession after all, so I have worked out the following 3 options to achieve the goal of transforming the attributes of a single JSON object to a list of objects.

  1. Manipulating the message as a string

2. Utilizing the JSON Structure module from the Mendix Marketplace

3. Creating a custom Java action

I have also benchmarked each option’s performance, so if you want to guess which is fastest, now is your chance….

Option 1 — Manipulating a String

The biggest drawback of this solution is that any change to the message— even a comma—could break the process.

First, I manually created the domain model that I need for the array of objects.

non-persistent domain model

After that, I started removing some characters using basic Mendix functions and used the “String split” action from the Community Commons Module to separate the attributes.

After that, I could just iterate over the list of split items and create new objects to fill with the extracted data.

Option 2 — JSON Structure Module

This module is what Mendix is all about in the sense of visual modeling and it is extremely easy and effective to use. Since the JSON message is processed visually, any changes or maintenance in the future will also be relatively simple to perform. It seems like a much more robust and agile solution compared to the first option.

Domain model of JSON Structure Module
Casting the JSON Value to a JSON Object
Creating and serializing the new JSON structure

Option 3 — Creating a Java action

This solution is the most custom and therefore least maintainable option. It is written for a specific purpose and at high volumes can have significant advantages over the first two options.

The Java action takes the original JSON string as a parameter and parses it to a new JSON structure that can be used to generate a domain model and import mapping.

Since Mendix is all about visual modeling, I’m not in favor of having a lot of custom Java in a Mendix app, but sometimes it can be the correct, if not only choice.

Java code for parsing JSON

Comparing the options

And so, the winner? Well, it depends.

As far as performance is concerned, the custom Java action is the winner and absolutely obliterates the other options.

However, for most apps, milliseconds won’t matter for overall performance. Option 2 visualizes JSON perfectly and I would definitely consider using the JSON Structure module for that reason combined with its ability to easily make future changes. Even though the performance is not the best, it can handle any situation and all types of developers, which is often the most important.

Happy modeling!

Credits: thanks to for helping out with the Java code.

Read more

From the Publisher -

If you enjoyed this article you can find more on our Medium page. For great videos and live sessions, you can visit our library of on-demand videos or our community Youtube page.

For the makers looking to get started, you can sign up for a free account, and get instant access to learning with our Academy.

Are you interested in getting more involved with our community? Join us in our Slack community channel.



Lennart Spaans
Mendix Community

Certified Mendix Expert at Ordina Digital Services and Lean Six Sigma Black Belt