Maximo Open Forum

 View Only
Expand all | Collapse all

need help with custom lookup

  • 1.  need help with custom lookup

    Posted 07-20-2020 10:09
    Hi all,

    I'm hoping you can help me.  I'm stumped.

    In Work Order Tracking, we're creating a bunch of work orders, and  relating  them to one other work order.  These just have a RELATED relationship type -- not Originator, not Parent, etc.  Just RELATED.

    I want to add a search box in the Advanced Search so that users can search for that one work order.  And I've done that, it works -- as long as you know the WONUM.

    What I can't get to work is a lookup for that field.  The field is RELATEDRECKEY, or, better, RELATEDRECWONUM.  But RELATEDRECWONUM is non-persistent, and if you try to search it you get an error.  Any lookup I've tried for RELATEDRECKEY, even the 'RELATEDWO' lookup, retrieves a list of Tickets, not Work Orders.  However, if I manually put in the Wonum, it still works.

    I want the lookup to show the list of Work Orders, not Tickets.  Any ideas?
    #Customizations

    ------------------------------
    Travis Herron
    Pensacola Christian College
    ------------------------------


  • 2.  RE: need help with custom lookup

    Posted 07-20-2020 11:42
    While seemingly simple, this is a complicated problem and I'm not sure what the best way to address it would be. Because the same table is used whether you're relating to a SR or WO, there are challenges when the context is on the advanced search dialog (where there is no corresponding MBO record). The relatedreckey was only intended for looking up ticket based records (which is why they created a separate non-persistent attribute for WO related lookups), but both values are stored in the same attribute. This lookup is populated via the java class on the RELATEDRECKEY attribute. Without potentially breaking it (by utilizing an automation script retrieve list event for example), I don't think you could make this work. You can't search on RELATEDRECWONUM because that is a non-persistent attribute (meaning it isn't stored on the database). So while you can perform the lookup, once you execute the search it would fail. It's really only intended for the lookup & then behind the scenes setting the appropriate attributes on the RELATEDRECORD object for permanent storage.

    You could build/utilize a relationship from RELATEDRECORD->WORKORDER, but the WONUM field on workorder doesn't have a getList event so you couldn't tie a lookup to that without also adding a table domain or retrieve list automation script, which again could cause a negative side effect 

    I think the way I would approach this is to add a new persistent attribute on RELATEDRECORD with a retrieve list automation script on that attribute. Be sure to filter out task & history records (similar to how the non-persistent attribute works). I would also use an automation script to set this new attribute with an object launch point on save. Since related records are only deleted (can't be updated) you really only need the add option enabled. I would add an index to this attribute since you intend to search on it (to avoid full table scans). Then I would display this attribute in the advanced search instead of the out of the box attributes. I know it's a bit involved for what you're looking to do, but I can't think of a less involved approach for looking up the records. 

    The solution left out a lot of the specifics, so if you have questions about how to implement any part of it let me know.

    ------------------------------
    Steven Shull
    Projetech
    ------------------------------



  • 3.  RE: need help with custom lookup

    Posted 07-21-2020 15:45
    Steven, thanks for using that in today's webinar!

    Following up on that thought, and adding https://www.ibm.com/support/pages/how-create-automation-script-retrive-lookup-list -- if I made a custom lookup in Lookups.XML, and used that custom lookup in the Advanced Search dialog, would I have to do those extra steps of adding the persistent field and scripting the copying of the value to it?

    Or in other words, you had said in the webinar to never use one of these Retrieve List scripts against an OOTB field, unless you make sure it works everywhere.  If I make a custom lookup, and only use it here, does that count as 'everywhere' or am I overlooking something/not understanding it correctly?

    ------------------------------
    Travis Herron
    Pensacola Christian College
    ------------------------------



  • 4.  RE: need help with custom lookup

    Posted 07-22-2020 08:15
    Thank you for attending and thank you for the inspiration. 

    Unfortunately the lookup dialog in lookups.xml doesn't really address the issue. These will control the fields displayed in the lookup, but when the object it's looking at is SR/TICKET it'll just cause invalid bindings if you're using a WO based lookup.

    If you create the automation script on recordkey, it'll change how that attribute works which could cause issues. On relatedrecord you would have to test associating a ticket based record to a WO, a WO based record on a ticket based record, a WO to WO record, a ticket to ticket record, creating a ticket from a WO, creating a WO from a ticket, creating a ticket from a ticket, and finally creating a WO from a WO. All these flows are normal out of the box functions that you wouldn't want a customization to break. Some organizations even do some of these actions via escalation or workflow actions to create the follow up records which could be additional scenarios to test. This would also prevent searching for related tickets in this scenario because you'd only be able to choose one or the other in the list tab scenario. 

    Storing data redundantly isn't great, but in this situation it felt like the best option to ensure that related records weren't impacted in any way while still enabling the lookup functionality on both ticket & work order.

    ------------------------------
    Steven Shull
    Projetech
    ------------------------------



  • 5.  RE: need help with custom lookup

    Posted 07-22-2020 10:17

    At the risk of "beating a dead horse" here's what I did in my test system:

    1) create the Automation Script much as you did in the webinar, but tweaked it a little:

    Attribute Launchpoint
    Retrieve List

    relationObject="WORKORDER"
    relationWhere="wonum= :relatedreckey and :relatedrecclass in ('WORKORDER', 'ACTIVITY')"
    if mbo.isZombie():
        listWhere="istask=0"
    else:
        listWhere="istask=0 and siteid=:relatedrecsiteid"
    srcKeys=["wonum"]
    targetKeys=["relatedreckey"]



    2) Add a lookup to Lookups.XML:

    <table id="relatedwo_pcc_woactivity" selectmode="single" inputmode="readonly">
    <tablebody id="relatedwo_pcc_woactivity_lookup_tablebody" filterexpanded="true" filterable="true" displayrowsperpage="20">
    <tablecol id="relatedwo_pcc_woactivity_lookup_tablebody_col_2" type="link" sortable="true" mxevent_desc="Go To %1" mxevent="selectrecord" dataattribute="wonum"/>
    <tablecol id="relatedwo_pcc_woactivity_lookup_tablebody_col_3" type="link" sortable="true" mxevent_desc="Go To %1" mxevent="selectrecord" dataattribute="description"/>
    <tablecol id="relatedwo_pcc_woactivity_lookup_tablebody_col_4" type="link" sortable="true" mxevent_desc="Go To %1" mxevent="selectrecord" dataattribute="woclass"/>
    <tablecol id="relatedwo_pcc_woactivity_lookup_tablebody_col_5" type="link" sortable="true" mxevent_desc="Go To %1" mxevent="selectrecord" dataattribute="status"/>
    <tablecol id="relatedwo_pcc_woactivity_lookup_tablebody_col_6" type="link" sortable="true" mxevent_desc="Go To %1" mxevent="selectrecord" dataattribute="siteid"/>
    </tablebody>
    </table>
    

    3) In Application Designer, added a textbox to WOTRACK's Advanced Search dialog:
    Attribute=RELATEDWO.RELATEDRECKEY
    Lookup=RELATEDWO_PCC_WOACTIVITY
    Menu Type=WORKORDER
    Go To Application=WOTRACK

    That appears to work.  What doesn't work 'perfectly' is that if on that textbox I set the attribute MENUTYPE=WORKORDER without setting Go To Application = WOTRACK, then it implicitly sets the Go To as Service Requests.  But again, it seems to be working.

    Would you be willing to try it out and/or think through it and tell me where the functionality would fall apart or where it would 'break' something somewhere else?








    ------------------------------
    Travis Herron
    Pensacola Christian College
    ------------------------------



  • 6.  RE: need help with custom lookup

    Posted 07-22-2020 16:15

    The reason for the Go To trying to go to Service Request is due Automation Scripts not having a way to handle the getAppLink() funciton. This is a function on attribute field classes that returns which applications you want to show for a particular record. In this case, if it doesn't have relatedrecclass it will return PROBLEM, SR, & INCIDENT but PROBLEM & INCIDENT would be suppressed unless you have HS&E so you'd just see SR in the advanced search. As you identified, if you override that in application designer that will take precedence. 

    As for potential issues, by overriding the core attribute for RELATEDRECKEY you've broken the ability to relate ticket based objects in some situations. For example, if you go and add a row to the related tickets and try to use the lookup you'll see invalid bindings and no records because it's trying to look at WORKORDER now instead of TICKET. See below of a screenshot. You also wouldn't be able to utilize the Go To SR function without additional changes.

    Without testing other scenarios, some of which I called out in the previous response, I'm not sure what else would be broken but even that list isn't necessarily comprehensive (just what I could think of off the top of my head). This wouldn't be a use case we would support one of our customers doing nor would IBM support it. Even if you validate all scenarios in Maximo today, these types of changes can break things down the road. For example, this could break a new work center or they could change some underlying logic where you potentially couldn't even select related tickets using the select ticket dialog for example. I strongly recommend creating the custom attribute example like I did or require users to type in the WONUM manually. 



    ------------------------------
    Steven Shull
    Projetech
    ------------------------------



  • 7.  RE: need help with custom lookup

    Posted 07-23-2020 09:37
    You're right, it broke what you said it would break.

    I guess what I'm struggling with is why they would have designed it like this in the first place.  Did they not think that someone would want to search across that relationship?

    That and why if I only put the custom lookup on the Advanced Search dialog, why it affects other lookups in other places.

    ------------------------------
    Travis Herron
    Pensacola Christian College
    ------------------------------



  • 8.  RE: need help with custom lookup

    Posted 07-23-2020 10:29
    Related records was built for the intent of service desk as well so they had to pick one in regards to the advanced search. The java classes are all associated with the ticket package, which shows IBM really intended this as a service desk feature first that just happens to also support work orders. On advanced search, it would work for ticket based records. And inside a record it works for both because it knows based on which table is chosen what the user is looking to see. The limitation exists because in a single attribute they store the value from multiple objects and on the advanced search, you have no concept of an actual MBO to know which type of record you're looking at. It's a similar limitation to searching for failure where you can't filter causes by the problem record that was selected. 

    But, in typing up a response I remembered something that works perfectly without the need for a custom attribute or automation script. If you create your own custom lookup by exporting the lookup.xml in application designer, you can specify the mboname on the lookup itself. For example, I created a lookup called emxwolookup like below and it works perfectly. I can't believe I didn't think of this earlier but this allows you to change just the lookup without impacting any core logic. This would have no impact outside of the advanced search.

        <table id="emxwolookup" inputmode="readonly" selectmode="single" mboname="WORKORDER" whereclause="historyflag=0 and istask=0">
            <tablebody displayrowsperpage="20" filterable="true" filterexpanded="true" id="emxwolookup_lookup_tablebody">
                <tablecol dataattribute="wonum" id="emxwolookup_lookup_tablecol_1" mxevent="selectrecord" mxevent_desc="Go To %1" type="link" sortable="true"/>
                <tablecol dataattribute="description" id="emxwolookup_lookup_tablecol_2" mxevent="selectrecord" mxevent_desc="Go To %1" type="link" sortable="true"/>
                <tablecol dataattribute="siteid" id="emxwolookup_lookup_tablecol_3" mxevent="selectrecord" mxevent_desc="Go To %1" type="link" sortable="true"/>
            </tablebody>
        </table>


    ------------------------------
    Steven Shull
    Projetech
    ------------------------------



  • 9.  RE: need help with custom lookup

    Posted 07-24-2020 09:45
    Fantastic!

    I'm still getting an error though.  I added your code to Lookups.XML and applied it to the textbox in Application Designer.  Then I go to WOTRACK and use it.  The lookup menu works correctly, but when I pick something from the list I get:

    BMXAA4107E - Because of an implementation or customization problem, the system cannot determine how the attributes of object RELATEDRECORD correspond to the attributes SITEID,WONUM of object WORKORDER. You might need to populate the MAXLOOKUPMAP table and restart the server.


    Did you encounter that?  How did you configure your textbox control in App Designer?  Mine is currently:

    Attribute: RELATEDWO.RELATEDRECKEY
    Lookup: EMXWOLOOKUP
    Go To Applications: WOTRACK
    Input Mode: Query
    Menu Type: WORKORDER


    ------------------------------
    Travis Herron
    Pensacola Christian College
    ------------------------------



  • 10.  RE: need help with custom lookup

    Posted 07-24-2020 10:24
    Yeah, sorry you're right unfortunately. I had tested the script on relatedreckey briefly to test things that were broken and by having it, it adjusted the mapping which made this underlying change work until the system was restarted. I honestly can't think of any other options right now than my one approach.

    ------------------------------
    Steven Shull
    Projetech
    ------------------------------



  • 11.  RE: need help with custom lookup

    Posted 07-24-2020 12:05
    Is there some way to write the Script wrapped in a great big IF statement? The idea being, IF we're working with Tickets then generate a lookup of Tickets, ELSE generate a lookup of Work Orders.


    ------------------------------
    Travis Herron
    Pensacola Christian College
    ------------------------------