Maximo Integration

Maximo-ICON.png

Maximo

Learn how to increase the operational efficiency of the assets you manage, and improve overall equipment effectiveness by using IoT data and AI.

Maximo-ICON.png

TRIRIGA

Reduce the operational costs of the facilities you manage, and create more engaging occupant experiences through the application of IoT data and AI.

Maximo-ICON.png

Engineering

Learn how IoT data and AI are being applied to transform the end-to-end engineering lifecycle.

Expand all | Collapse all

Automation Script Debugging

  • 1.  Automation Script Debugging

    Posted Tue October 20, 2020 10:26 AM
    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
    ------------------------------


  • 2.  RE: Automation Script Debugging

    Posted Wed October 21, 2020 08:57 AM
    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
    ------------------------------



  • 3.  RE: Automation Script Debugging

    Posted Wed October 21, 2020 09:18 AM
    Hi @Steven Shull thanks for you reply!

    I see, I already using like that.

    Actually I'd like to have another way than ​try and catch the errors on log, something more fast and easy like step by step debug.

    But OK, thanks to clarify that.

    Kind regards,

    ------------------------------
    ---
    Maycon Belfort
    Senior Consultant
    Maxinst Consultoria e Tecnologia
    Brazil, MG
    ------------------------------



  • 4.  RE: Automation Script Debugging

    Posted Wed October 21, 2020 10:45 AM
    Sorry, misunderstood what you were asking. Logging is still the approach we use as we haven't found a better alternative. I agree being able to execute a script on a record with break points and being able to step through each line (seeing what values each variable has for example) would be ideal. For now we just depend on logging.

    ------------------------------
    Steven Shull
    Director of Development
    Projetech Inc
    Cincinnati OH
    ------------------------------



  • 5.  RE: Automation Script Debugging

    Posted Wed October 21, 2020 06:09 PM

    A novice question:

    Is it possible to use Eclipse for Jython automation scripts? If so, can you "use breakpoints and step through each line (seeing what values each variable has for example)"?




  • 6.  RE: Automation Script Debugging

    Posted Thu October 22, 2020 11:27 AM
    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
    ------------------------------



  • 7.  RE: Automation Script Debugging

    Posted Thu October 22, 2020 02:59 AM
    Hi Maycon,

    I debug the scripts in a which many people would not like I guess. But here it goes:
    1. Put some random undefined methods after a line of the code i am checking if code is going there. 
    For example:
    if ( mbo.getOwner()=="ASSET"):
     random.test()
     mbo.setValue("worktype","CM")

    This helps me to track if the code is going into certain part of the logic. Helps me to do a quick debug.

    2. Use the description field to set values from different part of the code. It is like doing sysout or print statements in the description field.
    helps me to do a quick test without looking into the log file continuously.
    example:
    if ( mbo.getOwner()=="ASSET"):
     mbo.setValue("worktype","CM")
    else:
     mbo.setValue("DESCRIPTION",str(mbo.getowner()),11L)

    Development for small scripts is faster in this ways.

    Hope this helps!

    cheers

    ------------------------------
    Biplab Choudhury
    Maximo Consultant
    Tata Consultancy Services
    Melbourne
    ------------------------------



  • 8.  RE: Automation Script Debugging

    Posted Thu October 22, 2020 07:55 AM
    Hi @Biplab Choudhury,

    Yes, It's like Steven said pointing some value on the log or on other fields.

    But what I was expecting for is ​like @User1971​ said, something in IDE application to debug. I know that this could be hard to do once Maximo's automation scripts not run the scripts on the server side like java classes, so I don't know how this can be done.

    Thanks

    ------------------------------
    Maycon Belfort
    Consultant
    Maxinst Consultoria e Tecnologia LTDA
    Belo Horizonte
    Brazil
    ------------------------------



  • 9.  RE: Automation Script Debugging

    Posted 21 days ago
    Edited by User1971 21 days ago
    Would it be worthwhile to submit an RFE to IBM to enhance debugging functionality (in the automation scripting application) for the Jython language?
    1. Use breakpoints and step through each line (seeing what values each variable has for example)
    2. Other?

    That way, hopefully, IBM would either:
    1. Confirm that what you want isn't possible in Maximo, Eclipse, etc., or...
    2. Acknowledge that there is a gap and the functionality should be added

    Just a thought from a novice.


  • 10.  RE: Automation Script Debugging

    Posted 21 days ago
    There's this RFE (IBM Software RFE Community: View request) that requests some additional features but seems more oriented towards simplifying debugging by exposing additional data points easily/previewing a script. It's hard to say what in here is planned to implement (sometimes IBM will implement only a portion of a request, and there's no way to see/distinguish that).

    What I would say is I want this 100%, but I don't see IBM doing it unless they can enhance the REST API to support it. The way most would accomplish this today (especially from Eclipse) would be utilizing RMI and RMI is something they're trying really hard to phase out for external processes (it'll still be used inside the application of course). Application Suite is container based and having outside processes communicate to containers over RMI isn't good and IBM isn't planning to support it. 

    The REST API would be a logical extension point as it's the framework for how the new UI interacts with the Maximo business logic layer, so what they'd build here could be utilized by their new UI framework if they get to it for Automation Scripts. I'm not sure if the way they execute the scripts would be able to stop at each line or not and what impact it would have to leave the script running in the background while you debug. It's worth asking as the worst they can say is no but I'm honestly not sure how feasible it is.

    ------------------------------
    Steven Shull
    Director of Development
    Projetech Inc
    Cincinnati OH
    ------------------------------



  • 11.  RE: Automation Script Debugging

    Posted 20 days ago
    Hi,
    I have some contacts in Development so I will see if they will comment on this.
    As one of the other people said I don't think it will be possible to interactive debugging because of the complexity of the system.

    I don't know if you would need a debug connection to the JVM and another one to the Jython environment within the JVM.
    You may be able to get to the Jython environment without needing a debug connection to the JVM.

    The other commands about using the logger are all valid.

    these articles reinforce the points made by other people:

    The importance of using the correct logger - 18/07/2017

    System.out.println and System.err.println – writing logs the wrong way - 25/07/2017

    I talk about the logger in these blog posts in my "Logger related messages/settings mini-series" series here - https://www.linkedin.com/pulse/maximo-support-advice-from-non-ibm-engineer-article-mark-robbins/

    You may find other articles useful.
    best regards,
    Mark






    ------------------------------
    Mark Robbins
    Support Lead/Technical Design Authority / IBM Champion 2017 & 2018 & 2019 & 2020
    Vetasi Limited
    Bristol
    https://www.linkedin.com/pulse/maximo-support-advice-from-non-ibm-engineer-article-mark-robbins/
    ------------------------------