Deployment issue; runs fine in Studio Pro

0
I’m having an issue with the “Acceptance Environment Crash on Restart Log”.  As mentioned, this runs fine from Studio Pro locally.  The issue seems to be related to a piece of code used to covert “very long integers” from string to numeric.  The log message is: PMAPPERRORCore: An exception occurred while running the after-startup-action. PMAPPERRORCore: com.mendix.modules.microflowengine.MicroflowException: Failed to evaluate expression, error occurred on line 3, character 6 I don’t understand the references here, where can I check this “line 3, character 6”?  Well, I guess first, the “after-startup-action”, is this triggered when the application starts in the cloud or is this when a user logs into the application?  (Yes, I’m still rather new to Mendix development and have many questions.)  Th PMAPPINFOif length($ProcessingRecID) < 10 PMAPPINFOthen parseInteger($ProcessingRecID) PMAPPINFOelse parseInteger(substring($ProcessingRecID, 0, length($ProcessingRecID) - 9)) * 1000000000 PMAPPINFO^ PMAPPINFO+ parseInteger(substring($ProcessingRecID, length($ProcessingRecID) - 9, 9)) PMAPPINFOat Preferences.ACT_Integ_JotForm_JAFABSkanditra.nested.4a3b4704-45a0-48ed-b6ca-1c6632d04f70 [0 of 532] (CreateOrChangeVariable : 'Change variable ProcessingRecKey') Which is referencing this bit of logic in a ChangeVariable activity, for translating the string to an Integer/Long ($ProcessingRecKey) : if length($ProcessingRecID) < 10 then parseInteger($ProcessingRecID) else parseInteger(substring($ProcessingRecID, 0, length($ProcessingRecID) - 9)) * 1000000000 + parseInteger(substring($ProcessingRecID, length($ProcessingRecID) - 9, 9))   by the way, the value of $ProcessingRecID is like: “5079126663155979538” – and this does work in Studio Pro... Any guidance in what’s actually going on here with the deployment issue? I don’t know how much of this is relevant, but here’s a few more lines from the log which may be of relevant information: PMAPPINFOAdvanced stacktrace: PMAPPINFOat com.mendix.languages.mxexpressions.MxExpressionImpl.evaluate(MxExpressionImpl.scala:32) PMAPPINFOCaused by: com.mendix.languages.expressions.ExpressionException: java.lang.NumberFormatException: For input string: "100: 02.998.080/0001-41 - SM - EX - REKA INDÚSTRIA COM. IMP. E E" PMAPPINFOat com.mendix.languages.expressions.Expr.evaluate(Expr.scala:16) PMAPPINFOCaused by: java.lang.NumberFormatException: For input string: "100: 02.998.080/0001-41 - SM - EX - REKA INDÚSTRIA COM. IMP. E E" PMAPPINFOat java.base/java.lang.NumberFormatException.forInputString(Unknown Source) PMAPPINFOat java.base/java.lang.Long.parseLong(Unknown Source) PMAPPINFOat java.base/java.lang.Long.parseLong(Unknown Source) PMAPPINFOat scala.collection.StringOps$.toLong$extension(StringOps.scala:923)     Much thanks in advance!!!
asked
2 answers
0

What happens is that you have a after start up microflow, which converts data from one type to another. Locally your data set works with this behavior, But on an other (cloud) node the data set contains data which doesn't match the used microflow expressions.
In other words; your after start up microflow isn't correctly modeled.

How to find and solve;

  1. Find related microflow Open the App settings -> Runtime -> Show
  2. Check for Object create/change actions, Create/change variable actions and Decisions. In one of those a expression is used where in the 3 text line the 6th character is breaking the logic.
    It is related to where a object of $ProcessingRecID is changed/used

 

You might not find this easily, depending on the complexity of your microflow. So if its to complex, can do the following

  1. remove the microflow from the after start up configuration
  1. Add a button on the administrator home page
  2. connect the microflow to that button
  3. Allow the administrator role to use the microflow
  4. Add a breakpoint on the first activity or decision
  5. Run the app
  6. login as administrator and hit the button to trigger the microflow
  7. investigate your microflow using the debugger
  8. Fix it
answered
0

For closure and in case this helps anyone else, the issue appears to have been in the else clause of the statement:

parseInteger(substring($ProcessingRecID, 0, length($ProcessingRecID) - 9)) * 1000000000 +  parseInteger(substring($ProcessingRecID, length($ProcessingRecID) - 9, 9)

Changing instead to specifically group the multiplication operation to explicitly define precedence:

                        v                                                                                                                              v

parseInteger( (substring($ProcessingRecID, 0, length($ProcessingRecID) - 9)) * 1000000000) + parseInteger(substring($ProcessingRecID, length($ProcessingRecID) - 9, 9))

 

This of course didn’t change the operation, but now builds and runs on cloud as it did on local.

answered