Maximo Open Forum

 View Only

 Query regarding maximo mobile api calls

Jump to  Best Answer
  • Mobility
Invading Moss's profile image
Invading Moss posted 08-28-2024 07:49

Hi,

I noticed the below API calls being made by maximo mobile for EAM

Any particular reason why the request method for fetching data is POST instead of GET? For the work order API I can  understand that this allows us to bypass the URL length limitation but not sure why can't we use a GET call for other master data API's

And in some calls we do use GET method as below

So not quite sure why this mix and match between GET and POST calls for API's used to fetch data?

Also another question related to Work Order fetch API. I can a lot of relationships and rel being used in the API call as below

rel.inspectionresult.mxapiinspectionres{inspectionresultid--inspresultid,resultnum--inspresult,href},computedWODtlStatusPriority,computedWorkTypeButton,relatedrecord._dbcount--relatedrecordcount,rel.workorderspec{workorderspecid,assetattrid,measureunitid,datevalue,numvalue,alnvalue,assetattribute.description--assetattributedesc,displaysequence},rel.moddowntimehist{*},onbehalfof,assetuid,woactivity{taskid,status},rel.wohazard{wohazardid},location--

Question is why can't these objects be included directly included in the MXAPIWODETAIL itself? Is there an advantage to fetching the records using rel as opposed to adding all the child objects inside the Object Structure itself?

Steven Shull's profile image
Steven Shull posted 08-28-2024 08:21  Best Answer

This is honestly a great question because it highlights a REST API capability that most are not aware of.

Initially, we used GET API requests for all of the data pulls like you would normally expect. However, we encountered issues where the URL length became too long on some of our more complicated API requests like for workorder. That oslc.select is literally thousands of characters because we're combining a series of datasources together to download tasks, work logs, inspections, plans, actuals, attachments, desktop requisitions, asset/location meters, asset downtime, asset images, etc. Because the URL became too long, the web server would block the request and cause it to fail. We had to create technotes like this: https://www.ibm.com/support/pages/node/6480349 which required customers to adjust products outside of Maximo to make the requests work.

Instead of providing all the query parameters in the URL, there's a way to pass the query parameters into the REST API in the body of the message as FORM data. Since we're sending data to Maximo in the body, it should be a POST request. There's not a technical requirement that a GET doesn't contain a body but it's generally not done. The REST API sees this and then processes it using the normal processes that would get invoked if it had been a GET request.

Invading Moss's profile image
Invading Moss posted 08-28-2024 08:39

Thanks @Steven Shull. Just a follow up question

You mentioned that the oslc.select became quite large, example the work order get call. But I can see that we are making calls to a lot of child objects using rel which increased the overall URL length. Wouldn't it have been better if we included all these child objects in the MXAPIWODETAIL object structure, thereby reducing the oslc.select? Just want to understand the reasoning behind using rel instead of creating child object in the OS itself?

Steven Shull's profile image
Steven Shull posted 08-29-2024 11:36

@Invading Moss Only objects that are modified as a child of the record should be part of the object structure. Everything else should be through relationships. 

In the past, you'd see object structures that contain a lot of child objects like ASSET and LOCATIONS for example. However, you are not updating the asset information as part of the WO outside of specific flows like asset meter readings. What you'll see there is we actually use an alternate object structure to support those flows because they're being done independent of the WO.

That being said, the rel. notation is not explicitly required. You can do something like relationship{column1, column2} if it's 1:many. If it's a 1:1 you can do relationship.column1. The rel. just helps make it a bit more obvious that it's coming from a relationship rather than a child object. 

Related Content