I have to admit, I’m a big fan of automation scripts.
Recent updates released with Maximo 7.6.0.9 have almost covered all the possible customization needs including library scripts, REST APIs, MIF processing, before/after save event. All the new features are well documented in this somewhat secret document.
However whatever nice feature will be added in the next feature pack, we will never have a debugger like we have with Java and Eclipse. This could be a serious problem when you have to develop and maintain a complex set of scripts in your environment.
The best way to mitigate such problem is to correctly use Maximo logging APIs.
In my projects I usually define a custom logger in the Logging application. It’s a good practice to give a short name of your customer. In this example I have defined mxdev logger for my MaximoDev customer.
I can now log messages to this custom logger using Maximo APIs. In the following example I first import the MXLoggerFactory class, then I get the reference to my mxdev logger and then I use the MxLogger APIs to write messages in the system log.
from psdi.util.logging import MXLoggerFactory
logger = MXLoggerFactory.getLogger("maximo.mxdev")
logger.info("Entering SR_INIT script for ticket " + mbo.getString("TICKETID"))
logger.debug("This is a debug message")In Maximo 7.6 you can also use the service object to get the logger.
logger = service.getLogger("maximo.mxdev")
logger.info("Entering SR_INIT script for ticket " + mbo.getString("TICKETID"))
logger.debug("This is a debug message")There are several good reasons for doing that.
- I can select the logging level of my scripts dynamically in the Logger applications. I typically have that set to DEBUG in development and test environment. In production I set that to WARN or INFO to reduce verbosity.
- Logging is always a good way of commenting the code.
- It allows me to search for a specific string in the scripts when I see strange behaviors in the logs.
Hello Bruno, you have great posts! Sometimes add an additional dotted term to my logger (like mxlogger.mxdev.scrxyz) and set up a new root logger (for example devlog as maximo.mxdev) with a dedicated appender. That way I can add loggers (like maximo.maxdev.scrxyz) to the new root logger and manage multiple script logs. When I am through with a logger, I just turn it off (usually I have a lot of log.debug statements and just a few info)
Good article. But you can get MXLogger from service var like this:
service.getLogger("maximo.mxdev")
This is much easier than treating raw Java class because it allows to remove the first line.
Hello, Bruno, I have a question for you (as a Maximo customisation specialist).
In our organisation we want to make the tabs highlighting (e.g. to make a Worklog tb red if there are no entries). Do you know if it is technically difficult or not?
Looks good. Thank for sharing this.
I think it’s better to log to the mbo.getMboLogger(), since that’s the first thing the new support person is going to turn up logging on when trying to track down odd behaviour. It also means your log messages will naturally have context, particularly if you change the Appender’s Conversion Pattern to include [%3c] to show the “category” / logger name that was logged to.
Your link to the somewhat secret document just takes me to the IBM Community home page.
IBM really broke a lot of great documentation when they implemented that.
If you have the direct link it would be great.