Maximo

 View Only

  • 1.  WHOAMI API customization

    Posted yesterday

    Hi,

    Few questions I have around Maximo's OOB whoami API.

    1. Where is this API registered and where can I see the details of it?
    2. Is there a way we can customize this API like adding additional objects in the response?

    #IBMMaximo

    #IBMMaximoAssetManagement



    ------------------------------
    Suhas Joshi
    ------------------------------


  • 2.  RE: WHOAMI API customization

    Posted yesterday
     
     
     
    The whoami API is part of the Maximo REST API, typically registered within Maximo's REST framework. You won't find this API as a service in the Enterprise Services or Object Structures applications, as it's not managed through Maximo's MIF (Maximo Integration Framework).
     
    Maximo REST APIs, including whoami, are registered within the Maximo application code itself, specifically in the REST services configuration.
     
     
    The whoami API documentation can be accessed through Maximo's API documentation endpoint if enabled. You can view it by navigating to:
     
    http(s)://<your-maximo-host>/maximo/api
     
    Look under "System APIs" or search directly for "whoami" to see its description and available response details.
     
     
    Alternatively, calling the API directly with:
     
    http(s)://<your-maximo-host>/maximo/api/whoami
     
    will show you the response JSON containing user information.
     
     
    The whoami API is limited to the OOB response structure and doesn't directly support customization through configuration alone.
     
    Customizing the API would require extending Maximo's REST services. You can achieve this by:
     
    Creating a Custom REST API Endpoint: Implement a custom REST service in Java that mimics the whoami functionality and adds additional fields as required.
     
     
    Using an Automation Script for Custom APIs: Maximo allows you to create REST APIs through automation scripts, which could allow you to replicate the whoami API and customize the output by adding additional data fields.
     
     
    Adding a Custom Object Structure (for Data Extension): Create an Object Structure for the custom data you want to add, and call it from your custom API to supplement the whoami information.


    ------------------------------
    Sangaiah Nimmala
    ------------------------------

    Original Message


  • 3.  RE: WHOAMI API customization

    Posted yesterday

    The various route services are registered in the APIROUTE table. You can get the details for the whoami route with this SQL.

    SELECT * FROM APIROUTE a WHERE route = 'whoami';

    The class com.ibm.tivoli.maximo.oslc.provider.WhoamiRouteHandler is the actual handler for the whoami route, so you could theoretically extend that class and register your updated route handler.  You could also add a custom route handler.  


    With that said, you could also just use the standard script handler, write an automation script that returns the JSON you want and call that instead.

    Hope that is helpful.

    Regards,

    Jason



    ------------------------------
    Jason VenHuizen
    Sharptree
    https://sharptree.io
    https://opqo.io
    ------------------------------

    Original Message


  • 4.  RE: WHOAMI API customization

    Posted 3 hours ago

    Adding to the previous responses from Sangaiah & Jason, I wanted to describe the purpose of the whoami request and why adding additional objects is a bad idea. The purpose of the whoami request was to provide the most important data about the user (like default insert site, name, email, etc.) without needing to fetch data using the Mbos. The majority of the data comes from the UserInfo class which maintains a cache of that data. The entire JSON body is built in the UserInfo class.

    Over time, this has continued to get more things added to it out of the box. One of those was the last logout date for the user. This caused a performance issue in some customer environments which negatively impacted processes that depend on the API request (like Maximo Mobile). We had customers where the whoami was taking 1+ minutes and the timeout of the request was set to 30 seconds so we couldn't get any of the data we need. In more recent versions we have a system property to control this and disable it by default. After the change the API request was taking <1 second. 

    It's better to make a separate request to fetch the additional data, or build a specialized message like Jason mentioned using automation scripts, that handle your specific required scenario for your product. That way you don't impact core processes that won't need that data. 



    ------------------------------
    Steven Shull
    ------------------------------

    Original Message


  • 5.  RE: WHOAMI API customization

    Posted 3 hours ago

    Thanks everyone for the quick response. It has given lot of insights into this API.

    Steven, the system property you are talking about, which one is it and is it available in 7.6.1.2? We are also having issues with lastlogout query coming from whoami.



    ------------------------------
    Suhas Joshi
    ------------------------------

    Original Message


  • 6.  RE: WHOAMI API customization

    Posted 3 hours ago
    Edited by Steven Shull 3 hours ago

    No, the issue was fixed after 7.6.1.2 had stopped receiving updates. The fix is to stop returning the data so you could add 1=2 to the relationship to avoid the performance issue if you're not using the query for something else (we only use it out of the box for this purpose). On the MAXUSER object in Database Configuration, modify the LOGOUTTRACKING relationship and add "1=2 and" at the beginning. For example:

    1=2 and userid = :userid and attemptresult in (select value from synonymdomain where domainid='ATTEMPTRESULT' and maxvalue in ('LOGOUT','TIMEOUT','SYSLOGOUT')) order by attemptdate desc



    ------------------------------
    Steven Shull
    ------------------------------

    Original Message


  • 7.  RE: WHOAMI API customization

    Posted 2 hours ago
    Edited by Suhas Joshi 2 hours ago

    Thanks Steven,

    That's exactly what we were planning to do but were unaware if it will have any negative impact on out of the box functionalities. If we add 1=2 in the existing query, will it have any issues in any out of the box functionalities? I mean, if there are no records returned by the relationship, will it give any null pointer error anywhere in OOB classes? Is it safe to change this where clause if OOB will still work post this change? For custom changes, we will take care by changing the design.



    ------------------------------
    Suhas Joshi
    ------------------------------

    Original Message


  • 8.  RE: WHOAMI API customization

    Posted 2 hours ago

    Again, OOTB, we use this relationship in one place and only one place which is the whoami request. The whoami already supports no records being returned because the first time you login it will return no records. 

    Extending whoami should not be done. You risk breaking critical Maximo processes even if it doesn't slow down performance. Make a separate API request. If you absolutely need everything to be returned in a single request, build your own API that takes the response we build & adds in what you need. 



    ------------------------------
    Steven Shull
    ------------------------------

    Original Message


  • 9.  RE: WHOAMI API customization

    Posted 2 hours ago

    Thanks again, Steve. We are not going to customize the API now. We will be simply adding additional where clause (1=2) to the existing where clause. Whatever custom requirements we have, we will plan for a separate solution.



    ------------------------------
    Suhas Joshi
    ------------------------------

    Original Message