The last few weeks I have been talking about the messages generated by the loggers. This week I’ll talk about the importance of using the correct logger when implementing customisations.

Using the correct logger

It is quite common to see code/scripts that references “standard loggers” e.g. maximo.script for automation scripts.

This can be a real problem for support staff because support staff may need to set the loggers to DEBUG to gather additional information.

Imagine:

• An installation has 10 scripts and they are all configured to use the “maximo.script” logger.
• Each script writes out separate lines for variables – as discussed in this article

If the logger is set to DEBUG then all 10 scripts will then start writing out DEBUG statements. For systems executing a lot of transactions that could generate a lot of confusing messages and delay the investigation.

When deploying a new customisation it is worth taking a little time to check the customisation.

Is the logger the logical choice from a support perspective?

If you have a workorder that has the wrong value then you may not automatically think about configuring the script logger. You are more likely to want to configure the workorder loggers to DEBUG. Or to put it another way... If you put the workorder loggers into DEBUG then it would be great if it returned all the relevant messages.

Advice for developers – look at it from the support person’s perspective

When choosing the right logger it is important to approach the problem from the viewpoint of the person trying to debug a problem with the code.

• The support person may not know there is a script involved or they may not be able to set the logger (e.g. maximo.script) to DEBUG
• The support person will want to minimise the impact of any investigations so ensure that changing the logger level won’t have a negative impact
• A support person is likely to have multiple cases open so they will want to gather the relevant information as quickly as possible. They will want to process the information as quickly as possible
• The support staff may not have enough information to replicate the problem so the logger may need to be set to DEBUG for an extended period of time causing problems for other investigations
• If the support staff know that multiple scripts are using a high level logger (e.g. maximo.script) then they won’t want to switch the script logger to DEBUG unless they absolutely have to
• The longer the problem is open the greater the pressure to fix it

Minimising these problems

If you are a support person then try and get involved in the testing or at a minimum checking the log entries for the testing. I’ll blog more about testing in the future.

When reviewing the release:

• Is the logger using a very generic logger e.g. maximo.script ? - Advise recoding it to use a specific logger e.g. maximo.script.script1
• Is it logging to the right logger e.g. if the code only works on workorder records then is it writing to the workorder logger? - If you are investigating a problem with a workorder then it is logical to use the workorder loggers.... not to suddenly set the script logger to DEBUG
• Ensure the code logs important information to help debug the situation e.g. userid, record identifier like workorder number and siteid
• Ensure the code is not writing multiple lines with minimal information e.g. single value
• Confirm that debug statements are surrounded by ifDebugging calls to ensure they are only written when the logger is set at debug level
• Comment out / remove irrelevant code