Locator field overloading

One benefit of using locator fields to reference other records (as opposed to smart sections) is that a locator field can be populated with record types other than those they are defined to receive in the Data Modeler. This ability, called overloading, is beneficial in a few instances. First, the ability to overload a locator field is beneficial when you need to populate a locator field with records from more than one Business Object, or even from more than one Module. Similarly, it also is beneficial when all of the types of records you may need to populate into a locator field are not known at the time the locator field definition is created.

For example, the triApproval business object is used in the IBM® Maximo® Real Estate and Facilities approval engine and has been set up to work with most kinds of business objects. During the approval process, a triApproval record is created and associated to the record being sent for approval. The association is created by populating a locator field named triLinkedRecordTX with the record being sent for approval via a workflow. By populating the locator field, both a direct reference and an association from the triApproval record to the record being sent for approval are created. However, since triApproval records can potentially be created for an almost unlimited number of types of records, the corresponding number of types of values that may need to be referenced by the single triLinkedRecordTX locator field is also virtually infinite, and hence, the need to overload locator fields is sometimes necessary.

When overloading a locator field with a value it is not defined in the Data Modeler to receive, certain steps need to be taken to ensure the process works correctly:

First, since a locator field can only be defined to create an association to one type of business object in the Data Modeler, when overloading a locator field the type of association that will be created when overloading a locator field is still determined by the Association String property defined in the locator field, although the association type also should be specified by the workflow. This is done by setting the Association Type property in the Object Mapping window of a Create Record or Modify Records task in a workflow (this setting is described in "Object mapping"). The Association Type property only shows those association types for which business object-level association definitions have been defined, from the perspective of the business object that contains the locator field to be overloaded (e.g., the triApproval object in our scenario) to the Business Object whose records will be referenced by, and mapped into, the locator field (for more information on creating association definitions, see Association definition). Even though using Source mapping to populate the locator field usually creates the association as defined in the locator field in the Data Modeler, this step ensures the association gets created in the event that the record you are populating into the locator field is still in the null state (e.g., for a new record whose first state transition has yet to be invoked). Note, that in this scenario, the workflow mapping results in the locator field not being populated and having a blank value, since there is no Record Name or other field value yet for the record to map into the locator field.

The second requirement to overload locator fields is to make sure the locator field is populated using the Source option in the Object Mapping window in the locator field. The process of populating locator fields is described in "Object mapping".