Add option to return any MxObject from JAVA based on GUID or string input or whatever else the JAVA code generates/retrieves. - Mendix Forum

Add option to return any MxObject from JAVA based on GUID or string input or whatever else the JAVA code generates/retrieves.


It would be a great flexibility addition if the ParameterType "AnyObject” could also be returned from JAVA, so that it can then be cast into an inheritance split into it's actual entity type.

Of course for this to be a clean solution it should offer the ability to have a fallback split in the inheritance split. So that you can select the entities that you wish to continue with in the microflow, and the fallback solution is used for all entities in the domain models that aren't used in the following logic.

4 answers

Going to give that a try Ockert, cool solution and thanks for thinking along :)


Current workaround, reflect into the action stack and manipulate:

var ctx=this.getContext();
var astack=ctx.getActionStack();
action=astack[1];//one level up from the java action call, verify with action.getName()
var arr_test=action.getVariable("arr_test");
var obj_test=action.getVariable("obj_test");
var int_test=action.getVariable("int_test");
var bool_ret=action.getVariable("bool_ret");
//manip bool blue block, does not even need to exist
//retrieve imendixobject blue block
//manip imendixobject blue block
//list blue block is actually class java.util.ArrayList
//and you can put any IMendixObject in it, not like in the microflow




The wish is to pass an OQL query / Xpath query or whatever set of parameters without an actual definition of the entity type returned because it isn't known based on the parameters available inside the microflow beforehand, but are accessible through JAVA. The only thing known is that it should return a MxObject or a list of MxObjects and that it can be cast after to the developers choice. Or based on the JAVA return statement.

Yes it will be for advanced use cases only, but it will allow some neat functionality.


Hi Marnix,

Not sure what exactly you’re trying to achieve, but have you tried using type parameters in your java actions ( You can configure return type of your java action to use the type parameter, thus making it more dynamic when modeling, while still maintaining the type safety.