Hi Vishwa,
What the error means
Cannot invoke "String.toString()" because the return value of "java.util.Map.get(Object)" is null is a Java NullPointerException from inside the connector. At runtime, the connector looks up a value by name in a map and gets nothing back.
When the Query External Database activity runs, the connector uses two pieces of information saved with the query in the External Database Connection document:
The parameter list (name → value)
The column → attribute mapping of the response entity, captured when you clicked Use Response
If a column returned by the database, or a parameter used in the SQL, doesn’t match the saved definition, the lookup returns null and you get this error.
Why the test interface works but the microflow fails
The test interface (Run Query) builds its result from the live result set every time. It doesn’t depend on the saved mapping, so it always works.
The microflow uses the saved metadata from when the query was originally created against UAT1. If UAT2 returns a slightly different result set, the saved mapping no longer matches. Creating a new query “fixed” it because a new query saves fresh metadata based on UAT2. That confirms the cause is stale query metadata, not the SQL itself.
What usually differs after migrating to a new database
SELECT *: the UAT2 table has an extra, missing, or reordered column.
Column name casing: for example CustomerName vs customername vs CUSTOMERNAME. This happens often when tables are recreated with or without quoted identifiers (PostgreSQL and Oracle behave differently here).
Different data types or precision for the same column.
Different schema or database at runtime: the test interface uses the design-time connection details, while the microflow uses the runtime connection parameters (constants such as DBSource, username, password). If those still point to UAT1, or to a different schema in UAT2, the columns returned won’t match what the query was saved with.
How to fix it without recreating every query
Check the runtime connection. In the Query External Database activity, open the connection parameters and confirm that the constants point to UAT2, with the same database and schema you test against.
Refresh the existing query instead of creating a new one. Open the External Database Connection document, select the existing query, make sure the connection points to UAT2, and click Run Query. Then choose Use Response and save it against the existing entity. The docs describe this flow under Update Existing Query. It refreshes the saved mapping while keeping the same query name, so all microflow references keep working.
Avoid SELECT *. List the columns explicitly and give them stable aliases, for example SELECT cust_id AS CustomerId, cust_name AS CustomerName .... Then a change in table structure or casing between environments can’t break the mapping.
Check the parameters. Every {parameter} in the SQL must exist in the query’s parameter list with exactly the same name. In the microflow, every parameter must have a value assigned.
Restart the app after saving, then run the microflow again.
If it still fails
Set the log level for the External Database Connector log node to Trace and run the microflow again. The full stack trace usually shows whether the failing lookup is a column (mapping) or a parameter. Compare that name with the result set in the test interface.
To prevent this in future environment migrations
Use explicit column lists with aliases in every query, make sure the table definitions (column names, casing, data types) are identical across UAT1, UAT2 and production, and keep the runtime connection constants per environment in sync with the design-time connection.
Hope this helps! If this solution works for you, kindly mark it as the accepted answer so it can help others facing the same issue.
Hi Vishwa,
Based on your symptoms, I would first eliminate the saved-query configuration issue, because Mendix documents that using an intermediate-saved query in a microflow can cause runtime exceptions.
Please follow these steps in order:
Open the affected External Database Connection document in Studio Pro.
Open the query and press Ctrl + S. Ensure there are no unsaved changes before using it in a microflow.
Click Run Query, then select Use Response and verify that the response structure matches the actual columns returned by the UAT2 database. If the table structure changed during migration, recreate or update the response entity as required.
Save the query and its response configuration completely.
Open the affected microflow and double-click Query External Database. Reselect the saved query, verify its parameters, and confirm that the correct database connection is selected.
Check the active configuration values for the connection's DBSource, DBUsername, and DBPassword constants to ensure the runtime connects to the intended UAT2 database.
Run the microflow again.
If the same exception still occurs, the next step is to identify the missing map key from the complete runtime stack trace. The error means a value retrieved from a Java map is null, but the message alone does not identify which key is missing.
Official references:
Hope this helps! If you find this answer helpful, please mark it as the accepted answer.