During my last expert webinar, which focused on debugging and troubleshooting, we ran out of time and couldn’t cover all audience questions. While I followed up with answers to each individual, I thought it could be useful to share my responses with the community as well. So here it is, a quick Q&A follow-up on the questions that I didn’t cover during the live event.
“Is there a special reason why you use a constant for the log node? In complex applications, the number of constants gets quite large. I tend to use a variable that I set with the Microflow name so I can trace back to the Microflow when I see messages in the server logs”
As a bit of background, during the webinar I demonstrated the use of a constant as the log node name in a Log Message activity. I answered David’s question during the webinar, but I think it’s worth expanding upon the topic. The goal of my approach here was simply to create a single log node for all log entries in a module. Doing so allows you to more easily set log levels when troubleshooting your application.
David’s approach here also has merits, as it allows him to link logs to a specific Microflow. However, the sheer number of log nodes in this situation could also become unmanageable. Microflows rarely stand alone, so setting the log level to, say, Debug on a specific Microflow might miss important logging on a related sub-flow with its log level set to Info.
Instead, I would recommend using a constant or otherwise consistent log node name throughout a module, and including the offending Microflow name in the log text itself. That way, you still know what Microflow is creating the log entries, but you maintain a manageable list of log nodes. A large number of constants in a complex application is an issue, but we’re talking about 1 extra constant per module. With a solid naming convention, that’s not too much of an issue.
“Can we enable the debugger for eclipse when we are connected to a live application?”
The answer is, yes. You need to enable Java debugging on your live application. Take a look at this how-to article that addresses this exact question.
“How do you remotely debug in an on-premise situation? Or where can I find more information on this subject?”
Activating remote debugging is as simple as opening your service console, selecting your application, and then selecting the “Enable Debugging” option from the Advanced menu as shown in the image below.
The remaining steps should be the same as in the webinar – get your URL and password and enter them into the Business Modeler.
There are m2ee commands for enabling/disabling remote debugging:
These should appear in the output when you run the help expert command. The output from the enable command should return a URL and password, which you can use just as in the webinar.
That’s it for now. If you have any additional questions or comments, please feel free to ask in the comments section below.