The Issue – can the Location Drilldown tool start where I want it to?
Maximo has a great drilldown tool which is very useful when you have a large distributed Location Hierarchy. A lot of instances deploy such hierarchies when there is a need to represent the Assets geographically or within a corporate management structure. However, with a large number of Locations to search, the challenge is to make it as simple as possible for the user to find the appropriate Location and/or Asset.
Maximo’s drilldown tool makes it very easy to represent the hierarchy visually to the user, so they can quickly find what they are looking for. Still, if you have not pre-selected a Location or Asset then the drilldown always starts at the top of the tree.
Location Drilldown in Maximo – always starts at the top
When the hierarchy represents a large organization then the user will often have to drilldown to the Location at which they will find all their work. This c
an take several clicks. Given that the Location (and Asset) Drilldown is a library function this means that it’s not readily changeable, but we did find a very neat solution!
Firstly, we implemented the use of Person’s Location. Click on “the head” in the top right-hand corner of Maximo and select Personal Information. In the Workplace Information section, you can set a Site and Location within the hierarchy. This can also be set in the People Application by an administrator, or users can also set their own.
Secondly, although this is extra to the drilldown solution, we implemented Global Data Restrictions to limit the users to only see records that related to the current selected Person’s Location. This means that users only see the records that they are interested in but can edit this should their work change.
A byproduct of this is that the same restriction is applied to any Start Centers that have been created with a query from an Application that also has the restriction applied.
Thirdly, we implemented an option that allows for the drilldown to always start at the Person’s Location as set for the current user. There were a few options that we looked as solutions. The key is the LOCVALUE Attribute on the Non-Persistent Object that the Drilldown Dialog uses. Setting a default value on the LOCVALUE Attribute did not work due to the order of when the Java runs and therefore an alternative solution was required.
To implement the Drilldown Solution, we had to complete the following steps:
- We created a Crossover Domain to the Person Object with a source field for Location and a destination field of LOCVALUE.
- An attribute was added to the non-persistent object DRILLDOWN for Person ID. This attribute needs to be the same as PERSON.PERSONID and it is good practice to prefix the Attribute Name with something to identify differently from a standard field. This Attribute should be linked to the Crossover Domain created.
- We now need to trigger the validation when the drilldown is run. To do this, we created an automation script that launches on validation of the DRILLDOWN.LOCVALUE Attribute.
Attribute Launch Point for Automation Script
- The Automation Script we used, in python language, gets the current user’s details (as an object) then validates to their Person record. This provides the connection to the Crossover Domain to get the Person’s Location and store it in the Drilldown’s LOCVALUE.
Here is the code:
Code used in Automation Script
If you also want to implement the limiting of records by default to the Person’s Location, this is going to require the following steps:
- Decide which records you want to limit. It does not make much sense to limit Location as this would stop the user from being able to see any locations above their current selected. Each record set will require a Condition to be set up that uses Person’s Location and the LOCANCESTOR table to find all Locations below the Person’s Location.
- For Ticket (Incidents, Service Requests, etc.) Objects, the code can be very simple. You need a query that will find ticket location in LOCANCESTOR where Ancestor matches the Person’s Location.
Simple SQL Used in Condition
- For PMs this is a lot more complicated as there are a number of combinations to consider. You have to include PMs that are assigned to a Location or an Asset within the Location Hierarchy or a Route that has a Location or Asset in the Hierarchy!
Complex SQL Used in Condition
Word to the wise, depending on your DB version, different engines prefer different SQL methods. This Query can potentially use a large number of records and this can significantly impact on performance, particularly if you are using a very large detailed Location Hierarchy.
We found that the OR statements above worked well in a SQL Server Environment with a wide but not deep hierarchy. When we deployed the same on a DB2 Environment with a deeper hierarchy (more LOCANCESTOR records) then we had to replace the ORs with UNION Joins.
We had SQL clauses developed for a number of Objects including Assets, Routes, Work Orders, Incidents, Investigations, Purchase Orders, Purchase Requisitions etc. If you need to limit Job Plans, then you need to consider that Job Plans are not specific to a Location. We added an Owning Location that allowed us to limit Job Plans by Facility where appropriate.
When the Conditions have been created with responsive SQL statements, then these can be assigned to Global Data Restrictions. These are found in Security Groups > Select Actions.
Add an Object Restriction, specify the Application, Condition and as a Type Qualified.
Object Restriction using the Condition
Note that these solutions aren’t for novice Maximo users to implement! Each Maximo implementation may also require the options to be tailored to suit the specific business need. However, the impact that we saw in the user base was excellent.
Users are now able to manage what they see, purely by changing their Person’s Location. The ability to reduce the Drilldown clicks was also greatly appreciated. Sometimes simple solution can make a very big difference.
This blog post was co-produced by Simon Barnes and Maxwell Nguyen
About the Authors
Simon has been working with Maximo for over ten years in a variety of industries (Oil and Gas, Utilities, Facilities Management). He has a passion for sharing his experience and passing on his Business, Functional and Technical Know-How. Simon has worked with BPD Zenith in both Canada and the UK on a wide variety of projects. He takes a no-nonsense, direct approach and loves to solve problems. He has also worked for end users in senior management positions, giving him an insight into the challenges of making Maximo work for the business and its operations.
Maxwell qualified as a Chemical Engineer before becoming a Technical Consultant / Developer for BPD Zenith 3 years ago. He has quickly become a valued member of the team and Clients appreciate his no-nonsense, can-do attitude. As well as a sound technical ability with Maximo, he understands the need to follow procedure, document and share what he has learned with his peers. Quality of Delivery and being able to pass expectations has become a hallmark of his work.