Maximo Open Forum

 View Only
  • 1.  Steps to add Classification to a custom object and custom application

    Posted 3 days ago

    Hi everyone, I want to add classification and specification support for a custom object in Maximo. I found the following article from IBM support that makes the required steps sound very straightforward and easy: https://www.ibm.com/support/pages/steps-add-classification-custom-object-and-custom-application?view=full

    Has anyone tried this and did it really work with only what's described in the article? I'm yet to try this but I'm wondering where would the corresponding SPEC table come from to store the specification values and how would it get populated if the article doesn't even mention any of the out-of-the-box classes that you see on the existing CLASSSTRUCTUREID attribute (psdi.app.assetcatalog.FldCommonClassStructureid) and spec table attributes, i.e. ALNVALUE on WORKORDERSPEC (com.ibm.tivoli.maximo.fwm.app.FldSpecificationAlnValue) ?


    #Customizations

    ------------------------------
    Greg Tsarev
    MRM-EAM Consulting Inc.
    ------------------------------


  • 2.  RE: Steps to add Classification to a custom object and custom application

    Posted 2 days ago

    We created two java classes that extend SpecificationMbo and SpecificationMboSet (along with the 2 remote classes of course) that we reference. They were relatively simple classes to do the most basic things. We opted for generic names (using REFOBJECTID for example to store the unique ID) and checked for SITEID & ORGID that we populated in the add method so that we could reference it on multiple specification tables without needing to worry about the type of object. Though we found people like to query these tables and often add columns that are more user-friendly fields (think the equivalent of WONUM) so those get populated in OBJECTNAME.NEW automation scripts when needed.

    The main value in extending this class is all the other methods specifications depend upon like getDataType() to determine the type of specification being added. Then we reference the core classes (like psdi.app.assetcatalog.FldSpecificationAlnValue on ALNVALUE) on the specification related columns. 



    ------------------------------
    Steven Shull
    Naviam
    ------------------------------



  • 3.  RE: Steps to add Classification to a custom object and custom application

    Posted 2 days ago

    Thanks for your response Steven! Wow, that's way more complicated than the steps IBM mentions in the article! And it's not an old one, says it was modified on September 18, 2025. I'm curious, why exactly did you have to extend the java classes? I'm definitely trying to avoid that! I'm looking at the decompiled code of these generic classes (SpecificationMboSet, AssetCatalogService, FldCommonClassStructureid), and I don't see anything that would break if I had a custom object and a corresponding SPEC object with all the same attributes as WORKORDERSPEC for example, and the same generic relationships between the two, and just wanted to have the basic spec generation and validation behavior as the other ootb objects, no additional search or anything like that.



    ------------------------------
    Greg Tsarev
    MRM-EAM Consulting Inc.
    ------------------------------



  • 4.  RE: Steps to add Classification to a custom object and custom application

    Posted 2 days ago

    To answer my own question - SpecificationMboSet and SpecificationMbo are abstract classes that cannot be instantiated and are meant to be extended! So the only way is to either create custom java classes to extend SpecificationMboSet and SpecificationMbo and deploy them with a customization archive, or use automation scripts to basically script most of the ootb logic of these classes if custom java classes is a not an option. 



    ------------------------------
    Greg Tsarev
    MRM-EAM Consulting Inc.
    ------------------------------



  • 5.  RE: Steps to add Classification to a custom object and custom application

    Posted 2 days ago

    We almost exclusively use automation scripts, but this one made sense to do as java classes so that we could utilize all the out of the box classes on the attributes rather than write our own logic to handle them. Since the attribute classes expect methods like getClassSpecRecord() to exist, you need a lot of automation scripts to handle the different events (validate, retrieve list, initialize access restrictions, etc.) for everything. And then as Maximo enhances the framework (like the addition of DATEVALUE after we built it) it's easier to incorporate those features as well. 

    I'm not sure why a generic version that wasn't an abstract class wasn't created because you are correct, if this wasn't abstract, we could have done all the logic we had in the classes in other ways (like OBJECTNAME.NEW scripts to default values). It would be a good enhancement request IBM Sustainability Software - Ideas Portal



    ------------------------------
    Steven Shull
    Naviam
    ------------------------------