Lookups using REST API

Often while designing applications we would need to provide the lookups for a given attribute. Attributes in Maximo objects can have variousl types of domains or field validation classes associated with them. Those can be leveraged by the application developer (of the Mbo) to provide conditional set of lookup records. Fortunately, there is a way to leverage that logic using the REST apis. A sample below shows how to get a list of possible status for a workorder status attribute.

Note that the above example uses a specific workorder Mbo {id} and does a getlist on this Mbo on the attribute status. The generic template is

These calls can be done on child objects too. The example belows demonstrates that.

As you understand from this template, it is a collection query which follows all the syntaxes descibed in the previous sections. his implies you can put an order by, oslc.select, paging, oslc.where and time line queries and every thing else supported in a collection query. Note also that this same template can be used for list tab filter lookups. Note that in the list tab, you will need to do the lookup on an attribute based on no real mbos as the list tab is a collection of mbo’s. The rest api below uses the Maxiumo zombie mbo concept to do the lookup.

Similarly, if you were to provide a lookup on a new instance of say workorder, you can use the rest query below

Note that in both the above example zombie and newmbo are key words recognized by the REST api framework. Note that these calls will return the json response by evaluating the field validation getList or the domain getList logic and hence the object type (ie assets/locations/items/alndomain/synonymdomain/numericdomain etc) returned would be totally controlled by the server side application lookup logic.

It is also possible that in certain cases, the lookup logic needs some more context than what is available in a zombie/new mbo or for that matter a mbo loaded from the db ({id}). This happens when say the end user sets value to a few related attributes that modify the selection filter for the lookup. To handle this extra transient context we can use a query parameter setupdata. An template example is shown below

As evident from the above example, you can pass in a json content to set value to attr1 and attr2 for the newmbo mbo. This will poetantially impact the lookup for the attribute attr3. Now this needs some knowledge from the client side to pass in the required attribute values. That knowledge may come from looking at the relation where clause or from knowing the internal working of the application mbo.