Some thoughts on using loggers.
First, use them. service.log() and print are second-class citizens relative to proper loggers. Neither support varied granularity, service.log() doesn't support performance improvements, and print saves up messages and dumps them to the log out of context when the script is finished. So, avoid both.
Second, my go-to logger is "mboLogger" -- whatever comes back from
mbo.getMboLogger(). One reason for this is that the person on support dealing with some problem will not think to, shouldn't have to, go rifling through mountains of autoscripts to find the right logger to see if your script is the problem. Instead, they will / should think something like, "The problem has to do with the IMPORTANT object, which is part of the SOMETHING service, so I'll turn logging to debug for maximo.service.SOMETHING.IMPORTANT." And then if mbo is an instance of IMPORTANT, my logs are going to go right where the support person is going to look for them. Obviously, the "mboLogger" isn't right for every situation, but having that habit and helps make better choices for loggers.
Third, which is a corollary to the second point, is to not log to a root logger. Specifically, never log to "maximo" or "maximo.script". I've seen cases where every script logs to maximo.script, which made it impossible to find the trees we were looking for because of all the forest we had to hunt through.
Finally, for now, if the string you want to log at the debug or info level is concatenated or formatted, then couch your call to
mboLogger.debug() or
mboLogger.info() in an
if mboLogger.isDebugEnabled() or
if mboLogger.isInfoEnabled(). Python, like any other language, will do the performance-costly string work before calling the debug() or info() method, so it knows what to pass to it. But if that log level is not enabled then the result of the string work will just be thrown away. The same principle can apply to logging warnings or errors, but messages logged at those levels should be few and far-between, so it shouldn't matter as much.
mboLogger.debug("this is %s for performance" % "bad")if mboLogger.isDebugEnabled(): mboLogger.debug("this is %s for performance" % "better")mboLogger.debug("this is better for performance, too")------------------------------
Blessings,
Jason Uppenborn
Sr. Technical Maximo Consultant
Ontracks Consulting
------------------------------
Original Message:
Sent: Wed October 21, 2020 08:57 AM
From: Steven Shull
Subject: Automation Script Debugging
Using the Maximo logging functionality is our preference. It's easy to do and allows you to be as granular as you need. For example, you can setup a separate logger for certain scripts that can have its own appenders (which file(s) it writes to) and control what log level that logger should be on to write that message (DEBUG, INFO, WARN, ERROR, etc.). This allows you to leave the statements in your code base so they're there when you need them and simply don't output otherwise.
If you've never used it, it's pretty easy to do. The implicit service variable has a getLogger function (so calling service.getLogger("maximo") for example will get the root Maximo logger but calling service.getLogger("maximo.autoscript") will get you the automation script logger. You can create children of these loggers (maximo.autoscript.customscript1 for example), each at their own log level.
Assuming you stored it in a variable (IE logger=service.getLogger("loggerName")) then you can call logger.error("error message"), logger.info("info message"), etc. and it'll only write when the logger is configured at that level or lower.
------------------------------
Steven Shull
Director of Development
Projetech Inc
Cincinnati OH
Original Message:
Sent: Tue October 20, 2020 08:17 AM
From: Maycon Belfort
Subject: Automation Script Debugging
Hello,
I'd like to ask how are you debugging your automation scripts, still using print messages on systemout logs?
Is there another and better way to debug it?
Thank you.
Kind Regards,
------------------------------
Maycon Belfort
------------------------------
#AssetandFacilitiesManagement
#MaximoIntegrationandScripting
#Maximo