The Hidden Feature of Crossover Domain
6S4Q_Jenny_Wang 2700026S4Q Comments (7) Visits (10784)
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 saved 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
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 rela
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 a 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.
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.