1

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?

Jesse Williams
  • 140
  • 1
  • 8
  • What are you looking for? Are you trying to determine which field to display on the screen? Are you trying to determine the composite primary key (the more human usable ones)? Are you trying to find the uniqueid/sequence field (if it has one)? Are you looking for the field(s) that the lookup should be returning to the MBO? – Dex Sep 30 '20 at 02:42
  • That list of fields you got back is the composite primary key. I would have to look at a database (which I no longer have access to) to remember if there really is a unique id/sequence field on those rows, so you may not be able to get that one. The fields to be returned to the source MBO (from the lookup) varies based on a few things (common names across the composite key, maxlookupmap, crossover domain settings, etc.). – Dex Sep 30 '20 at 02:44
  • Let me use the WO `status` field as an example. When I post an update to a WO to oslc, I can send, say, `"WAPPR"` as the status. When I post that update, clearly only one of the fields that is returned by `getlist` (either oslc or java method) is being used in that JSON post, not all of them (in this case, specifically one of the fields that has value `WAPPR`). I'm trying to figure out how to determine which of those fields contains the actual value you would post to oslc when doing an update. I'm also somewhat interested in which I would display on screen, but that is a secondary concern. – Jesse Williams Sep 30 '20 at 15:40
  • 2
    Ah, so the last option then. Well, that is all over the place. The wostatus example is both a simple one and a complex one. Simple in that it is "returning" one value to one field (the field the lookup is tied to even), but that isn't always the case. Complex in that it isn't using the more obvious methods of doing that (primarykeycolseq and name overlaps or maxlookupmap configurations) and is instead determined by code, and a lot of it. Normal Maximo isn't even actually returning a value to that field there; it is instead running some very complex change status logic when you select a value. – Dex Sep 30 '20 at 23:15
  • 1
    Using the OSLC for a status field is actually different than using Maximo, and you should be careful how you use that; it is likely you are actually bypassing a lot of built-in Maximo logic. – Dex Sep 30 '20 at 23:17

1 Answers1

2

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).

Dex
  • 1,241
  • 6
  • 13
  • It's funny, I actually implemented this section of our app last year doing exactly what you just said and hard coding in the values for commonly used ones. I am rewriting that section of the app and was hoping to make something a bit more automatic and generalized which had evaded me then, but it's kind of comforting if a little disappointing to know that the way I did it then is more or less the best solution. Thanks for the help! – Jesse Williams Oct 01 '20 at 14:53
  • Zooming out a bit, my ultimate goal here is to essentially let users edit WOs from an external app, but the key holdup is honoring the domains on each field, hence my usage of `getlist`. The other holdup is, I know the domains for some fields are dependent on other fields, so I would have to somehow detect those updates even though the user hasn't saved the WO yet. If I pass the WO edits into a Java customization, I was considering using the Mbo `setValue` and `getList` methods to ephemerally set the values and get the updated domains. Is that a viable way of mirroring maximo's functionality? – Jesse Williams Oct 01 '20 at 15:37
  • (assuming I can hard code in a way to consume the results of `getList` as you said above) – Jesse Williams Oct 01 '20 at 15:38
  • These are familiar problems I worked through earlier this year. `getlist` is great for not having to worry about domain filtering, but that built-in filtering only works if your data is already saved in Maximo, as you point out, something that I found was not doable in some cases. – Dex Oct 02 '20 at 00:05
  • The end result there, for me, was to create a configuration in the app where administrators could go and enter some base SQL-like syntax that the app would use to fetch the base domain values for the field. The admin could then also specify a filter based on field data that the app would interpret locally to created the filtered lookup (that way the server need not be available as the local data is changed or the record need not be (re)saved each time a field changes and this lookup needs to be re-evaluated). – Dex Oct 02 '20 at 00:07
  • 1
    If the server and code (Java or scripts) are always available to you, then what you propose is a good idea. You can send your data to that code, that code could create an MBO, set all the data, *not* save it, call the getlist method for the relevant field and then return those results back. This is what the now-deprecated RMI interface was all about, and why it is often times still unmatched by the REST services. – Dex Oct 02 '20 at 00:12
  • 1
    Trying to wrap that logic in a REST service gets tricky since Maximo expects the service results to match a pre-defined object structure schema. That means your service couldn't be generic for lookups and would have to be duplicated for each OS return type your lookups need. – Dex Oct 02 '20 at 00:13
  • Let us [continue this discussion in chat](https://chat.stackoverflow.com/rooms/222384/discussion-between-dex-and-jesse-williams). – Dex Oct 02 '20 at 00:18