ExecuteMicroflowAsUser Argument Type Change?

0
I am upgrading an app from 6.10.12 to 7.14.1.  In this app, I have a call to Java action ExecuteMicroflowAsUser from Community Commons Module.  However, this Java action has changed in a significant way. In 6.10.12, the microflow action takes a string argument of the fully qualified microflow name, as shown below: In 7.14.1 (latest release of Community Commons), this Java action takes an argument of type Microflow, as shown below: What this means is that I can no longer use this Java action to run a microflow that I specify at run time.  Instead, I have to select the microflow to run at design time.  But maybe I am missing something, and there is a different way to retrieve and run a microflow at run time. Any feedback or ideas appreciated!
asked
2 answers
1

Hi Mike,

  Looking into the Java of the latest version of Community Commons, I see that the action executeMicroflowAsUser has the following declaration:

 

	public executeMicroflowAsUser(IContext context, java.lang.String microflow, java.lang.String username, java.lang.Boolean sudoContext)

 So it looks like on the back end, nothing has changed.  The name of the microflow is still passed as a string, which makes sense because all the core API actions take string parameters when referring to microflows.  I assume this change was made to make it easier for less knowledgeable users to reference existing microflows, but changing the 'type' of the microflow parameter from microflow to string in the java action in Mendix should work just fine.  This would allow you to use any old string including ones you define at runtime.  I think the developers of this action missed your important use case when updating the module.  

answered
0

The simplest solution is probably to just change the action parameter type back to String (as Rob says, the java API has not changed). Alternatively create your own java action wrapper (as changing the module causes again problems with the next update)

This change in community commons has btw. already been discussed. It makes sense to have this action with the microflow as a parameter. That way you can properly find usage of microflows that are called this way and you also prevent refactoring issues when renaming microflows.

However I also think it was a bad decision to simply change the existing API.

https://forum.mendix.com/link/questions/89454

answered