The Hidden Feature of Crossover Domain
Abstract
The Hidden Feature of Crossover Domain
Body
Recently, I encountered a use case of crossover domain that worth blogging about.
The concept of crossover domain is simple. It is a way to trigger something to happen when an attribute is
being populated. That something is to copy one or more attributes from a related object to the current object
that is involved in the operation at this moment. For example, you want to “crossover” the item’s description
when you are putting the item on the purchase order that you are creating.
Crossover domain is a very useful function, but I also encountered quite some good challenges when I try to
use it. For example, during my creation of purchase order, I want some information that I just entered on the
purchasing order to be copied to my purchasing order line as soon as I hit add new line. But I can’t really
make it happen using a crossover domain because the “related object” is obtained through a relationship and
when maximo retrieves the content of a relationship, it goes to the database. In this case, my PO is not save
to the database yet, so I don’t get anything back.
It has always been a restriction in using crossover domain, until I found a way around it, thanks to a hidden
feature of the crossover domain in maximo 7.5.
In 7.5, you can use a dot notation, relationship.field, on the domain’s source field. You can also use the
relationship dot notation on the domain’s destination field.
For example, you have an object A, A has a related object of B through relationship RB, and B has a related
object of C through relationship RC, but there is no direct relationship from A to C. You want to add a
crossover domain on A’s field X so that when you set X, an attribute Y on C can be copied over to A’s field Z.
What you can do is
1. Create a crossover domain, set target object to “B”.
2. The validation where clause of the domain is the relationship where clause of RB.
3. Set the source field of the crossover domain to “RC.Y”, set the destination field to “Z”.
4. You assign this domain to A.X.
This is great. This allows you to crossover a field from anywhere to a field anywhere as long as they can be
reached by relationship or chained relationships, because you can also do relationshipA.relationshipB.field.
To make it even better, reserved keyword &owner& can be used in the relationship notation. Working similar
as a relationship, it represents the owner object of the current object. If you use &owner&.field on the source
field of the crossover domain, it means field of the owner of the related object, in our example, that is the
owner of B, which is object A itself.
Did the light bulb go off? This would be exactly how we can solve my earlier problem, how to crossover from
record that is not saved in the database. The &owner& keyword allows me to find back that object in memory
This is how I did it.
I created a crossover domain, the relationship is to DUMMY_TABLE object, which guaranteed that there is
always one record in this table. So with a relationship of 1=1, I can guarantee that the validation will be
successful so that the cross over action will happen. Then I used &owner&.&owner&.PO1 in my source crossover
field. I then assigned this crossover domain to POLINE.PONUM field.
(https://www.ibm.com/support/pages/system/files/inline-images/iotl3_Picture5.jpg)
When crossover happens, the first &owner& gets the owner of the DUMMY_TABLE, which is the POLINE
record I’m just inserting. The second &owner& resolves to the owner of the POLINE, which is the PO. Now I
get to the object in memory. The crossover worked!
The caveat here is that the &owner& and the relationship notation is not supported on the domain application
UI. You have to do this nice work directly updating the database. That’s why it is a “hidden feature”, but a nice
one to have. If you think of other ideas to tackle this problem, please let me know.