I am using oslc's getlist functionality to determine the domain on various fields of a workorder. What I am lost on is how to determine the key field in each list item returned. It seems like, depending on the field, the foreign object referenced by the response has a different structure, and that makes it difficult to determine on the fly what the key field is. For example, suppose I call getlist~lead on a particular workorder. I get a list of person mbos back - the key field of which is personid. But if I call getlist~status, I get a view into the synonymdomain for status - so the key field is maxvalue or value.
I decided to try pulling this into a Java customization to see if I could get more clarity by working directly with the Java classes rather than trying to poke around the oslc API for something that seems to not be there. I have found the method mbo.getList(field).getMbo(i).getKeyValue().getAsString(), but I'm kind of puzzled that it returns a String[] rather than a single String. When I call getList("status"), I get this as the "key fields": ["DOMAINID", "MAXVALUE", "VALUE", "SITEID", "ORGID"]. Is there any way I can determine what the actual key field of the mboSet returned by getList(field) is?
Knowing what field value(s) to return to from a lookup into which field(s) is fairly complex. In some cases you can use the primarykeycolseq of the two objects and see where field names overlap to know what goes where, in some cases you can read the maxlookupmap table and determine what needs to go where, in some cases you can read the crossover domain and see what needs to go where, in some cases you are out of luck because some code (a script or actual MBOs) determines what goes where. There was an IBM article on the fallback methods Maximo uses to determine this itself, but I seem to have lost it (and can't find it on Google). Some of those cases you won't be able to determine outside of Maximo (or even inside of Maximo) because it is in the code, like your status field.
Every external-to-Maximo solution I have seen (including one I helped create) has had its own configuration items to define lookup returns (as well as the exact lookup itself, since those also have a lot of possible rules that can't always be determined, like the status field normally only lets you pick a subset of statuses depending on your record data, not just any of them). You are probably going to need to start doing something like this yourself. Either "just know" each case and put it in your code, or create some semi-complex configuration that allows the user to (re)define these lookups and their returns in your app and leave it to them (maybe help them out and supply the commonly used ones).