Maximo

 View Only

  • 1.  Are Automation Scripts considered Customization?

    Posted 26 days ago

    Hello All,

    I need a clarification and if possible IBM's official position on customization vs configuration.

    in my organization, we are implementing Maximo with a "No Customization" policy. We have created several Automation Scripts and Conditional Expressions in our system (7.6.13).

    We are clear that Java class modification is considered as customization in Maximo.

    What about other options in Maximo, e.g., Automation Scripts and Conditional Expressions.

    Also, what happens during upgrade process, e.g., Upgrade to MAS. Does Maximo upgrade utility, automatically handles Automation Scripts?



    ------------------------------
    mx pro
    ON
    ------------------------------


  • 2.  RE: Are Automation Scripts considered Customization?

    Posted 23 days ago

    The whole customization vs configuration question is one that has made me cringe for many years now.  Whenever I hear somebody say that something is over customized, I always ask them to define customization.  I don't think I've ever got the same answer twice.  Typically, the term is used differently depending on what you Are being sold at the moment.  The best answer I ever got was that customization is changing source code whereas configuration is using the tools available in Maximo to implement customer required functionality.  So guess what, Java based MBO extensions are not customization by that definition (and they upgrade just fine by the way).  You are writing new code that extends existing objects which is a well-accepted pattern in object-oriented development.  Changing source code would be something along the lines of altering one of the JSPs or CSS files.  Things like this are stomped on by upgrades, but even that is not all that big a deal as long as you are following good practices and documenting all your changes and using a source code repository. 

    To me, the more important thing is to use good development practices.  Whether you are using automation scripts or Java MBO extensions, take the time to understand good vs bad coding practices.  Keep in mind that somebody else is going to have to come in and maintain your "code" at some point.  Comments, comments comments!!!  Use well named variables, no unnecessary abbreviation.  Decompose all logic into the smallest possible unit. 

    That's my two cents on the subject.  I'm interested to hear what others think. 



    ------------------------------
    Chris Hanna
    ------------------------------

    Original Message


  • 3.  RE: Are Automation Scripts considered Customization?

    Posted 23 days ago

    In general, if a change is made via the UI, such as Automation Scripts it is considered a configuration, the scripts are considered metadata, which is handled the upgrade process. If it is changed outside of the UI, such as Java classes, it is considered a customization and may need to be addressed outside upgrade process. 



    ------------------------------
    Rick White
    ------------------------------

    Original Message


  • 4.  RE: Are Automation Scripts considered Customization?

    Posted 23 days ago

    Automation scripts are as much a customization as where clauses for relationships. IBM supports your ability to create, update and delete them, and IBM will do what they reasonably can to upgrade them. However, the actual "code" in the where clause or automation script is yours, and they will not write it for you or let you use support to help you debug it. If you have a problem that is theirs in your code (relationship where clause or automation script), the burden of proof is heavily on you that it is their problem. It doesn't happen often, but if attributes move to a new object over an upgrade, IBM will not "upgrade" your where clause. If your script uses attribute bound variables, those references should be upgraded, but if you "getString()" that attribute in your script, that will be your problem.



    ------------------------------
    Blessings,
    Jason Uppenborn
    Sr. Technical Maximo Consultant
    Cohesive
    ------------------------------

    Original Message


  • 5.  RE: Are Automation Scripts considered Customization?

    IBM Champion
    Posted 23 days ago

    From an IBM perspective, automation scripts are not a customization, although as Jason pointed out IBM will not be responsible for your where clause or your automation script if it breaks something.

     

    With that said, from a technical perspective there is zero difference between an automation script and a Java class.  In fact, you can write Java classes in automation scripts, as I covered in this blog post https://www.sharptree.io/blog/2023/2023-09-05-custom-script-classes/.

     

    My opinion is that you should treat automation scripts with the same care and discipline you would any custom Java class.

     

    Jason




    Original Message


  • 6.  RE: Are Automation Scripts considered Customization?

    Posted 23 days ago

    "zero difference between an automation script and a Java class"

    In the case of an Mbo customization or field listener / validation class, Maximo has no choice but to use your class. In the case of an automation script, your code is merely called on by the Mbo class or the validation class. And there is plenty of fallout from this difference. When I can put my script in the Class Name field on a Database Object or Attribute and enjoy the applicable benefits, then autoscripts will have been upgraded from being a configuration to being a customization.



    ------------------------------
    Blessings,
    Jason Uppenborn
    Sr. Technical Maximo Consultant
    Cohesive
    ------------------------------

    Original Message


  • 7.  RE: Are Automation Scripts considered Customization?

    Posted 8 days ago
    You can already do this in the definition of a relationship where you can write a sql-like clause, indicate the name of a Java class method but also the name of a script.
    That said, in my opinion scripts are just a more limited but very convenient alternative of writing Java code. In fact, at 90% script code invokes product Java classes and methods, and as such you can do almost the same things but also the same errors, from missing a mboset closure to an infinite loop. The manager imposing the "no-customization" rule I think cares little whether the memory leak was created by a script or a poorly written method.
    Finally, remember that in MAF-based applications the custom logic must be written in Javascript, and apart from the different language I see no difference in the old practice of writing a DataBean.


    ------------------------------
    Diego Visentin
    EAM BU Director
    Tempestive S.p.A.
    ------------------------------

    Original Message


  • 8.  RE: Are Automation Scripts considered Customization?

    Posted 22 days ago

    I too follow the 'no customization' rule almost all the time. And by that, I am referring to updates of class files on the back end. But, to include 'automation scripts' in that rule would be a very bad idea, in my opinion. The organization, no doubt, at some point will find the limits of base Maximo and will want some scripting to meet requirements. For instance, here, we notify Users when closing a Work Order that there are related, open POs in the system. As for upgrades, you should have no issue with automation scripts.



    ------------------------------
    Richard Foster
    ------------------------------

    Original Message


  • 9.  RE: Are Automation Scripts considered Customization?

    Posted 21 days ago

    Aside from the crafted difference between customization and configuration, all our clients (and ourselves) should abandon Java-based customization. Eventually I'd like all of them to be converted to scripting.

    The reason is simple: they are a drag for making Manage more fitting the cluster environment it lives now in.

    Java-based customization requires the product images to be rebuilt. To use the new images, the pods needs a restart and given the still stateful nature of the classic UI, those restart implies a short but annoying interruption of service.

    A scripting based approach will allow a much more dynamic environment that does not suffer from downtime.



    ------------------------------
    Alex Donatelli
    IBM
    ------------------------------

    Original Message